[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

KARP Working Group                                              X. Liang
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                          March 07, 2011
Expires: September 8, 2011


               Negotiation in Keying Management Protocols
                  draft-liang-karp-negotiation-kmp-00

Abstract

   Negotiation is one prominent capability of keying managament
   protocols (KMPs), especially automated KMPs for Routing Protocols.
   This document discusses negotiation in KMPs, which includes the
   reasons for negotiation in KMPs, concerns and possible solutions when
   using negotiation, and several types of negotiation in KMPs.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 8, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.



Liang                   Expires September 8, 2011               [Page 1]


Internet-Draft             Negotiation in KMPs                March 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Conventions Used in This Document  . . . . . . . . . . . .  3
   2.  Why Need Negotiation . . . . . . . . . . . . . . . . . . . . .  3
   3.  Concerns and Possible Solutions When Using Negotiation . . . .  4
   4.  Negotiation in KMPs  . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  Initial SA Negotiation to Establish Secure Channel . . . .  5
     4.2.  Peer-to-peer SA Negotiation for Routing Protocols  . . . .  6
     4.3.  Group SA Negotiation for Routing Protocols . . . . . . . .  7
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
   7.  Acknowledgement  . . . . . . . . . . . . . . . . . . . . . . .  7
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     8.2.  Informative References . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10


































Liang                   Expires September 8, 2011               [Page 2]


Internet-Draft             Negotiation in KMPs                March 2011


1.  Introduction

   In RFC2408 [RFC2408] about ISAKMP, the need for negotiation and what
   can be negotiated were discussed in section 1.2 and section 1.3,
   respectively.  It pointed out that the main reason for security
   association (SA) negotiation is the diverse security requirements and
   security services of different networks, and the objective of
   negotiation is to achieve common supported security functionality for
   interoperation and cooperation between/among communicating peers.

   In the following sections of this draft, more reasons for negotiation
   in KMPs, concerns and possible solutions when using negotiation,
   types and technical details of negotiation in KMPs will be discussed.

1.1.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC2119 [RFC2119].

   When used in lower case, these words convey their typical use in
   common language, and are not to be interpreted as described in
   RFC2119 [RFC2119].


2.  Why Need Negotiation

   Before answer the question "Why need negotiation", it is good to make
   clear what negotiation is in the context of KMPs.  Negotiation is one
   technique by which communicating parties exchange information, which
   includes settings, conditions, proposals, etc., and achieve some
   decisions in common to allow subsequent procedures to go on.  In
   KMPs, communicating parties can establish secure channel by
   negotiating initial SAs, can protect application data by negotiating
   proper SAs for application being served.  Besides the main reason
   stated in Section 1, there are specific reasons in KMPs especially
   KMPs for routing protocols, which are listed as follows.

   o  Algorithm agility: It has three meanings.  First, the algorithm
      can be updated accordingly.  For example, router A supports SHA-1,
      and later step by step, A can be updated and support SHA-1, SHA-
      256, SHA-384, and SHA-512.  Second, alternative algorithm is
      available when the one in use is broken down.  In the case router
      A supports both SHA-1 and SHA-256, when SHA-1 gets broken down,
      SHA-256 takes place of SHA-1.  Third, when peers don!_t have the
      identical algorithms deployed, they can agree on using one
      algorithm in common by negotiation.  For example, peer A supports
      SHA-1 and SHA-256, and peer B supports SHA-256 and SHA-384, then A



Liang                   Expires September 8, 2011               [Page 3]


Internet-Draft             Negotiation in KMPs                March 2011


      and B can communicate using SHA-256 by negotiation.  In other
      words, the routers don!_t need to have the algorithm updating in
      sync.

   o  Implementation: Negotiation allows implementors to implement KMP
      or security mechanims or algorithms in differen ways, but to
      provide same parameters and/or API functions for interoperation.
      Because negotiation doesn't care about the implementation, it only
      care about the key parameters.  Attention should be paid to
      implementation and upgrading properly, since problems are often
      caused by improper implementation and upgrading, see Section 3,
      and negotiation makes the problems known, which are not hidden
      again.

   o  Configuration: Negotiation reduces the complexity of
      configuration, reduces the volume of work of configuration.
      Negotiation releases the rigidity of configuration, and makes
      configuration flexible.  Configuration will not need to be exactly
      the sync.

   Negotiation is one function or ability/capability of KMP, especially
   automated KMP.  Negotiation makes KMP more powerful, and helps KMP to
   realize the properties such as fresh traffic keys, managing SA
   lifetimes and easier rekeying.

   In summary, negotiation benefits both operators/administrators and
   users, since negotiation makes configuration of security mechanism
   more flexible and less complicated, and makes deployment of security
   mechanism more ease and gradual, hence lowers the cost of operation.


3.  Concerns and Possible Solutions When Using Negotiation

   Some people argue that negotiation will cause unexpected consequences
   and make problems far more hidden.  Looking closer at those
   situations, we will find that those problems are caused by improper
   implementation essentially, not by negotiation.  Actually, negotation
   allows diverse implementations according to Section 2.  In the other
   hand, if improper configurations and improper deployment exist, there
   will also be problems and unexpected consequences.

   In KMPs for routing protocols, what to be negotiated are some
   parameters, and exactly, the key parameters, not the implementation
   details.  The implementations can be different surely, but the
   parameters and/or the API functions associated with those parameters
   should be the same or identical according to some standards or
   references.  If they are implemented with different parameter name, a
   third party tool could take the role to do the translation or



Liang                   Expires September 8, 2011               [Page 4]


Internet-Draft             Negotiation in KMPs                March 2011


   transform, look at translator or transformer in following paragraph
   for reference.  That!_s not the fault caused by negotiation, since
   negotiation only involves parameters.  In practice, if
   implementations do according to some rules which at least ask for the
   same parameters or the same API function, negotiation will not cause
   problems.

   To reduce and solve the above mentioned problems, there may be two
   possible solutions:

   o  Translator or transformer: It may be from a third party, and is a
      tool to do the translation or transforming job for KMP and
      program.  For example, two different implementations impelment the
      parameters with different name or using different API functions.
      In this case the translator or transformer can translate the names
      of the parameters or API functions between KMP and the program.

   o  Falling-back negotiation mechanism, or re-negotiation mechanism:
      It seems like backward compatibility capability.  When the
      algorithm with higher security priority doesn't work properly by
      some reasons, the communicating parties can give up the algorithm,
      and re-negotiate one with lower security priority that can work.
      For example, two peers (A and B) negotiate cryptographic
      authentication, and everything is working before an upgrade.  B
      supports SHA-1 and SHA-256, but A only supports SHA-1.  A is
      upgraded and now supports SHA-256.  Unfortunately, B's
      implementation of the routing authentication using SHA-256 is
      buggy.  The upgrade causes things to break.  When using falling-
      back negotiation mechanism or re-negotiation mechanism, SHA-1 will
      be used in the case that SHA-256 fails.


4.  Negotiation in KMPs

   There are several kinds of negotiation in KMPs, which are initial SA
   negotiation to establish secure channel, peer-to-peer SA negotiation
   for appplication data such as routing protocols, and group SA
   negotiation for appplication data such as routing protocols.  KMPs
   such as ISAKMP [RFC2408], IKEv2 [RFC4306] [RFC5996], GDOI
   [I-D.ietf-msec-gdoi-update], G-IKEv2 [I-D.yeung-g-ikev2], and MRKMP
   [I-D.hartman-karp-mrkmp], will be discussed or involved in this
   section.

4.1.  Initial SA Negotiation to Establish Secure Channel

   In all the KMPs mentioned above, initial SA negotiation to establish
   secure channel is the first step and must take place, because secret
   keying materials will be transmitted under the protection of the



Liang                   Expires September 8, 2011               [Page 5]


Internet-Draft             Negotiation in KMPs                March 2011


   secure channel.  ISAKMP and IKEv2 have its own exchanges to negotiate
   initial SA, and these exchanges are called phase 1 (or the first
   phase) exchange in ISAKMP or initial exchange in IKEv2.  GDOI,
   G-IKEv2 and MRKMP exploit phase 1 exchange in ISAKMP or initial
   exchange in IKEv2 to fulfill their initial SA negotiation to
   establish secure channel.

   In phase 1 exchange of ISAKMP, there are four types of exchange that
   are defined to negotiate initial SA and/or have identity
   authentication, i.e., base exchange, identity protection exchange,
   authentication only exchange, and aggressive exchange.  Any of the
   four exchange types can be used individually.  The initial SA is
   called ISAKMP SA in ISAKMP.

   In initial exchange in IKEv2, there are exchanges (four messages in
   all) basically to perform initial SA negotiation and identity
   authentication.  The first exchange is IKE_SA_INIT, which includes
   one pair messages, i.e., IKE_SA_INIT request and IKE_SA_INIT
   response.  IKE_SA_INIT exchange is used to establish secure channel
   between the initiator and responder.  The initial SA is called IKE SA
   in IKEv2.  The second exchange is IKE_AUTH, which includes another
   pair messages, i.e., IKE_AUTH request and IKE_AUTH response.
   IKE_AUTH exchange is used to perform identity authentication and
   negotiate another SA, i.e., the first Child SA, which could be the
   content of Section 4.2.

4.2.  Peer-to-peer SA Negotiation for Routing Protocols

   Peer-to-peer SA negotiation for appplication data such as routing
   protocols happens in ISAKMP and IKEv2, and exactly, in phase 2 (the
   second phase) exchange of ISAKMP and the IKE_AUTH exchage and the
   CREATE_CHILD_SA exchange of IKEv2.

   The phase 2 negotiation in ISAKMP is used to establish SAs for other
   security protocols or appplication data to protect many message/data
   exchanges.  For example, SAs for routing protocols can be negotiated
   in phase 2 of ISAKMP and used to protect routing messages by the
   routing protocols.  The phase 2 negotiation of ISAKMP also use the
   four types exchanges stated in Section 4.1, and the negotiated SA is
   protocol SA.

   The IKE_AUTH exchage and the CREATE_CHILD_SA exchange of IKEv2 can be
   used to negotiate SAs for other security protocols or appplication
   data, and negotiated SAs are called Child SAs.

   Both ISAKMP and IKEv2 could be modified to supporting or serving more
   applications with better security service
   [I-D.liang-karp-auto-sa-management-rp].  For example, the above



Liang                   Expires September 8, 2011               [Page 6]


Internet-Draft             Negotiation in KMPs                March 2011


   mentioned exchanges can be modified with new payload or extende
   payload, and new exchanges can be created.

4.3.  Group SA Negotiation for Routing Protocols

   It is easy to understand initial SA negotiation to establish secure
   channel and peer-to-peer SA negotiation for other security protocols
   or appplication data, but it is not easy to understand group SA
   negotiation for other security protocols or appplication data such as
   routing protocols in multicast mode or broacast mode, because the
   group protocols such as the mentioned above GDOI, G-IKEv2, and MRKMP,
   don't have the group SA negotiation capability.  From Section 2, we
   can see that there are advantages to have negotiation capability,
   especially in group envirements, otherwise every router asking to
   join the group have to be configurated in sync.

   How to negotiate group SA?  One possible approach may be as follows.
   When GM and GCKS negotiate initial SA to establish secure channel
   and/or perform identity authentication, GCKS collects security
   parameters of other security protocols or appplication data such as
   routing protocols from GM, and those parameters are supported both by
   GCKS and GM.  After a period of time, e.g., two seconds, GCKS have
   collects parameters from more than one GMs.  According to the
   collected parameters from the legitimate GMs, GCKS chooses the
   parameters that are supported by all the legitimate GMs or most of
   the legitimate GMS in the case not all legitimate GMs support, to
   create the group SA.  Under the protection of the initial SA, GCKS
   sends the created group SA to GMs one by one.


5.  Security Considerations

   To be completed.


6.   IANA Considerations

   To be completed.


7.  Acknowledgement

   To be completed.


8.  References





Liang                   Expires September 8, 2011               [Page 7]


Internet-Draft             Negotiation in KMPs                March 2011


8.1.  Normative References

   [I-D.ietf-msec-gdoi-update]
              Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
              of Interpretation", draft-ietf-msec-gdoi-update-07 (work
              in progress), October 2010.

   [RFC2408]  Maughan, D., Schneider, M., and M. Schertler, "Internet
              Security Association and Key Management Protocol
              (ISAKMP)", RFC 2408, November 1998.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4306]  Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
              RFC 4306, December 2005.

   [RFC4307]  Schiller, J., "Cryptographic Algorithms for Use in the
              Internet Key Exchange Version 2 (IKEv2)", RFC 4307,
              December 2005.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)",
              RFC 5996, September 2010.

8.2.  Informative References

   [I-D.hartman-karp-mrkmp]
              Hartman, S. and D. Zhang, "Multicast Router Key Management
              Protocol (MRKMP)", draft-hartman-karp-mrkmp-00 (work in
              progress), October 2010.

   [I-D.ietf-karp-design-guide]
              Lebovitz, G. and M. Bhatia, "Keying and Authentication for
              Routing Protocols (KARP) Design Guidelines",
              draft-ietf-karp-design-guide-01 (work in progress),
              September 2010.

   [I-D.ietf-karp-framework]
              Atwood, W. and G. Lebovitz, "Framework for Cryptographic
              Authentication of Routing Protocol Packets on the Wire",
              draft-ietf-karp-framework-00 (work in progress),
              February 2010.

   [I-D.ietf-karp-threats-reqs]
              Lebovitz, G., Bhatia, M., and R. White, "The Threat
              Analysis and Requirements for Cryptographic Authentication
              of Routing Protocols' Transports",



Liang                   Expires September 8, 2011               [Page 8]


Internet-Draft             Negotiation in KMPs                March 2011


              draft-ietf-karp-threats-reqs-01 (work in progress),
              October 2010.

   [I-D.liang-karp-auto-sa-management-rp]
              Liang, X., Wang, H., Wei, Y., and C. Wan, "Automated
              Security Association Management for Routing Protocols",
              draft-liang-karp-auto-sa-management-rp-00 (work in
              progress), October 2010.

   [I-D.wei-karp-analysis-rp-sa]
              Wei, Y., Wang, H., Liang, X., and C. Wan, "Analysis of
              Security Association for Current Routing Protocols",
              draft-wei-karp-analysis-rp-sa-01 (work in progress),
              October 2010.

   [I-D.yeung-g-ikev2]
              Rowles, S., Yeung, A., and P. Tran, "Group Key Management
              using IKEv2", draft-yeung-g-ikev2-01 (work in progress),
              March 2010.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2402]  Kent, S. and R. Atkinson, "IP Authentication Header",
              RFC 2402, November 1998.

   [RFC2409]  Harkins, D. and D. Carrel, "The Internet Key Exchange
              (IKE)", RFC 2409, November 1998.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC4305]  Eastlake, D., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4305, December 2005.

   [RFC4718]  Eronen, P. and P. Hoffman, "IKEv2 Clarifications and
              Implementation Guidelines", RFC 4718, October 2006.

   [RFC4835]  Manral, V., "Cryptographic Algorithm Implementation
              Requirements for Encapsulating Security Payload (ESP) and
              Authentication Header (AH)", RFC 4835, April 2007.




Liang                   Expires September 8, 2011               [Page 9]


Internet-Draft             Negotiation in KMPs                March 2011


   [RFC5709]  Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M.,
              Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic
              Authentication", RFC 5709, October 2009.


Author's Address

   Xiaoping Liang
   ZTE Corporation
   No. 6, Huashen Avenue, Yuhuatai District
   Nanjing, Jiangsu  210012
   China

   Phone: +86 25 52878217
   Email: liang.xiaoping@zte.com.cn




































Liang                   Expires September 8, 2011              [Page 10]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/