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

Versions: 00 01 02

Network Working Group                                            P. Tran
Internet-Draft                                                   B. Weis
Intended status: Standards Track                           Cisco Systems
Expires: September 10, 2012                                March 9, 2012


         The Use of G-IKEv2 for Multicast Router Key Management
                        draft-tran-karp-mrmp-01

Abstract

   The G-IKEv2 key management protocol protects group traffic, usually
   in the form of IP multicast communications between a set of network
   devices.  This memo defines extensions to G-IKEv2 allowing it to
   protect the communications of routing protocols using a one-to-many
   or many-to-many communications model.

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 10, 2012.

Copyright Notice

   Copyright (c) 2012 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.



Tran & Weis            Expires September 10, 2012               [Page 1]


Internet-Draft                G-IKEv2-MRKM                    March 2012


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . . . 3
   2.  Overview of Group Key Management  . . . . . . . . . . . . . . . 3
   3.  Exchanges . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Header and Payload Formats  . . . . . . . . . . . . . . . . . . 5
     4.1.  Group Security Association Payload  . . . . . . . . . . . . 5
       4.1.1.  GSA TEK Payload . . . . . . . . . . . . . . . . . . . . 6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 9
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



































Tran & Weis            Expires September 10, 2012               [Page 2]


Internet-Draft                G-IKEv2-MRKM                    March 2012


1.  Introduction

   The G-IKEv2 protocol [I-D.yeung-g-ikev2] has been defined to
   distribute group policy and keys to a group of network devices.  It
   uses IKEv2 protocols, incorporating payloads similar to GDOI
   [RFC6407].  This memo describes a mode of using G-IKEv2 to protect
   routing protocols using one-to-many communication models (e.g., OSPF,
   PIM), and is known as G-IKEv2 for Multicast Router Key Management
   (G-IKEv2-MRKM).

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].


2.  Overview of Group Key Management

   When a group of network devices need to communicate using multicast
   communications, the devices need to share keying material and the
   policy associated with that keying material.  A group key management
   (GKM) protocol is used to securely distribute this keying material
   and associated policy.  Typically each network device (also known as
   a group member (GM)) needing to participate in the group "register"
   to a group controller/key server (GCKS), during which mutual
   authentication and authorization occur.  The GCKS also distributes
   current group policy and keying material to the group member over an
   authenticated and encrypted session.  When G-IKEv2 is used, this is
   achieved in four messages: two to setup the encrypted session
   (identical to the IKEv2 [RFC5996] IKE_SA_INIT protocol, and two to
   authenticate, authorize, and distribute group policy to the GM
   (similar in construction to the IKEv2 IKE_AUTH protocol).

   A GKM protocol typically uses a "rekey" protocol to efficiently
   distribute replacement keying material and associated policy to GMs.
   However, this is primarily an optimization for scalability.  This
   optimization is less desirable for a small group of routing protocol
   participants.  In this memo, we describe how the group can utilize
   the registration protocol for both initial keying and rekeying
   purposes.

   G-IKEv2-MRKM is a GKM use case where a group of network routers
   participating in a routing protocol using a multicast transport act
   as GMs.  Which device takes the role of GCKS is not specified by this
   memo, but operationally it is most reliable for one of the GMs to
   take that role.  Additionally, for routing protocol reliability the
   routers may require the ability to use redundant key servers and to



Tran & Weis            Expires September 10, 2012               [Page 3]


Internet-Draft                G-IKEv2-MRKM                    March 2012


   elect a key server from available group members.  This memo does not
   address redundancy, however the protocols in this memo should be
   compatible with the redundancy strategy described in
   [I-D.hartman-karp-mrkmp].


3.  Exchanges

   The exchange of private keying material between two network devices
   using a dedicated key management protocol is a common requirement.
   There is no need to define an entirely new protocol for routing
   protocols having this requirement when existing mature protocol
   exchanges and methods have been vetted.  This memo extends the
   G-IKEv2 protocol exchanges, state machine, and policy definitions.

   The following two exchanges enable the group member to register to
   the key server to get the policy, traffic selector and keys used to
   communicate with others group member.

   The IKE_SA_INIT exchange is a two-message exchange allows the group
   member and key server devices to negotiate cryptographic algorithms,
   exchange nonces, and do a Diffie-Hellman exchange [DH].  At the
   conclusion of the IKE_SA_INIT, the group member (e.g., router) and
   key server can exchange private messages.  For the details of this
   exchange, refer to IKE_SA_INIT in RFC 5996.

       Group Member(Initiator)                    Key Server (Responder)
       -----------------------                    ----------------------
       HDR, SAi1, KEi, Ni            -->
                                     <--  HDR, SAr1, KEr, Nr, [CERTREQ,]

   Next, the group member and key server devices perform a GSA_AUTH,
   which is substantially the same as the IKE_AUTH exchange defined in
   RFC 5996, except that the SA, TSi, TSr payloads in IKE_AUTH are not
   used.  Policy and traffic selectors are pushed from the key server to
   group member using new payloads GSA and KD.  For the details of the
   rest of the exchange please refer to Section 4 of
   [I-D.yeung-g-ikev2].  Section Section 4 of this document includes
   additional GSA definitions specifically for the purpose of protecting
   routing protocol traffic.

       Group Member (Initiator)                   Key Server (Responder)
       ------------------------                   ----------------------
       HDR, SK {IDi, [CERT,] [CERTREQ,]
                [IDr,] AUTH, IDg}     -->
                                      <--    HDR, SK {IDr, [CERT,] AUTH,
                                                      GSA, KD}




Tran & Weis            Expires September 10, 2012               [Page 4]


Internet-Draft                G-IKEv2-MRKM                    March 2012


   In the GSA_AUTH exchange, the group member sends the identification
   of the group to which it wants to join or register.  The key server
   authenticates and authorizes the group member and pushes the policy,
   traffic selector in GSA payload, and the key in the KD payload to the
   group member.  At the successful conclusion of the GSA_AUTH exchange,
   the group member has policy and keying material to securely
   communicate with others group members that also registered with the
   key server.  With this IKEv2 SA established between GM and KS, the GM
   can request for policy and keys of an additional group using the
   GSA_CLIENT_SERVER exchange.  In the GSA_CLIENT_SERVER exchange, the
   GM will send group ID that it wants to join, where the key server
   response will include policy (GSA) and key material (KD).

    Group Member (Initiator)                  Key Server (Responder)
    ------------------------                  ----------------------
    HDR, SK {IDg}                  -->
                                   <--            HDR, SK { GSA, KD, [D]}

   Once a GSA_AUTH has completed the group member and key server MAY
   destroy the G-IKEv2 SA.  However when the number of group members is
   small, as is usually the case for routing protocol participants, it
   is RECOMMENDED for them to maintain the G-IKEv2 association SA for
   the key server to notify group members that they should re-register
   in order to obtain new group policy.  This notify exchange replaces a
   seperate rekey mechanism optimized for large group.

   In some cases, a GCKS may need to change the group policy and/or
   rekey before current keys expire.  In cases where the G-IKEv2 rekey
   protocol is not used the GCKS can send an INFORMATIONAL exchange with
   a Notify payload directing the group member to re-register using a
   REGISTER_REQUESTED status notify message (value TBD).  This event
   triggers a GSA_CLIENT_SERVER exchange, as described above.  The
   response to GSA_CLIENT_SERVER from the KS may include Delete payloads
   instructing the group member to delete old SAs.


4.  Header and Payload Formats

   The protocol defined in this memo uses a HDR defined in RFC5996.  GSA
   exchange types and payloads described in this section are added to
   same IANA registry containing G-IKEv2 definitions.

4.1.  Group Security Association Payload

   The Group Security Assocation (GSA) payload contains one or more sets
   of policy that a router is willing to use to protect a routing
   protocol.  It is identical to the GSA payload described in Section
   4.3 of [I-D.yeung-g-ikev2].  This memo makes no changes to this



Tran & Weis            Expires September 10, 2012               [Page 5]


Internet-Draft                G-IKEv2-MRKM                    March 2012


   payload.

      0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       ! Next Payload  !   RESERVED    !         Payload Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




4.1.1.  GSA TEK Payload

   One of GSA types is the Traffic Encryption Key (TEK) policy.  The TEK
   describes the Traffic Encryption Policy.  This document define new
   protocol ID of TEK protocol specific payload for routing protocol
   OSPFv2, OSPFv3 and PIM.

                        1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !    Type       !   RESERVED    !                 Length        !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       ! Protocol-ID   !       TEK Protocol-Specific Payload           !
       +-+-+-+-+-+-+-+-+                                               ~
       ~                                                               !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

       Protocol ID                       Value
       -----------                       -----
       RESERVED                            0
       GSA_PROTO_IPSEC_ESP                 1
       GSA_PROTO_IPSEC_AH                  2
       GSA_PROTO_OSPFv2                   TBD
       GSA_PROTO_OSPFv3                   TBD
       GSA_PROTO_PIM                      TBD

4.1.1.1.  TEK OSPFv2 Protocol-Specific Payload

   TEK OSPFv2 Protocol Specific Payload contains SPI, the authentication
   algorithm and key lifetime.

   The TEK OSPF protocol specific payload is defined as follows:








Tran & Weis            Expires September 10, 2012               [Page 6]


Internet-Draft                G-IKEv2-MRKM                    March 2012


     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ! SPI           !   RESERVED      |  Auth algo                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      !                GSA life Attributes                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

      SPI - (1 octet) Secure Parameter Index will be used in OSPFv2
            header as Key ID (RFC 2328, Appendix D)

      Auth algo - (2 octets) Authentication Algorithm
           Keyed-MD5               (defined in RFC 2328, Appendix D)
           HMAC-SHA-1              (defined in RFC 5709, Section 3)
           HMAC-SHA-256            (defined in RFC 5709, Section 3)
           HMAC-SHA-384            (defined in RFC 5709, Section 3)
           HMAC-SHA-512            (defined in RFC 5709, Section 3)


      TEK Attribute - Key lifetime, define in
           (draft-yeung-g-ikev2-03, section 4.5)



4.1.1.2.  TEK OSPFv3 and PIM IPsec Protocol-Specific Payload

   OSPFv3 and PIM IPSEC protocol specific payload similiar to GIKEv2 TEK
   payload for ESP and AH.  This payload doesn't include the traffic
   selector as protocol-ID value in the GSA TEK payload already indicate
   OSPFv3 or PIM traffic, because the traffic selectors are well known
   and unchanging values.  However it should be noted that a site
   requiring alternative transforms can use the G-IKEv2 definitions for
   ESP and AH to define this policy.

     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !                             SPI                               !
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
      | 0 (last) or 3 |   RESERVED    |        Transform Length       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Transform Type |   RESERVED    |          Transform ID         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      ~                      Transform Attributes                     ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      ~                   GSA Life Attributes                         ~



Tran & Weis            Expires September 10, 2012               [Page 7]


Internet-Draft                G-IKEv2-MRKM                    March 2012


      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

      SPI (4 octets) - Secure Parameter Index

      Transform - Same sa G-IKEv2 TEK transform define in
                  (draft-yeung-g-ikev2-03, section 4.5)
                  Where transform type can be 1 (Encryption Algorithm)
                  for ESP and/or 3 (Integrity Algorithm) for AH.



   Description                     Trans.  Used In
                                    Type
      ----------------------------------------------------------------
      Encryption Algorithm (ENCR)     1       ESP

      Integrity Algorithm (INTEG)     3       AH, optional in ESP

      Extended Sequence Numbers (ESN) 5       AH and ESP

   Transform Type 1 (Encryption Algorithm)
      Name                 Number      Defined In
      ---------------------------------------------------
      ENCR_NULL            11          (RFC2410)
      ENCR_AES_CBC         12          (RFC3602)

   Transform Type 3 (Integrity Algorithm)
      Name                 Number   Defined In
      ----------------------------------------
      NONE                 0
      AUTH_HMAC_MD5_96     1        (RFC2403)
      AUTH_HMAC_SHA1_96    2        (RFC2404)


      TEK Attribute - Key lifetime, define in
             (draft-yeung-g-ikev2-03, section 4.5)




5.  IANA Considerations

   G-IKEv2 [I-D.yeung-g-ikev2] defines a new registry.  This memo adds
   the following definitions to this registry.  (TBD)







Tran & Weis            Expires September 10, 2012               [Page 8]


Internet-Draft                G-IKEv2-MRKM                    March 2012


6.  Security Considerations

   This document describes a use case of group key management using
   G-IKEv2.  The security considerations in [I-D.yeung-g-ikev2] directly
   apply to this memo.


7.  Acknowledgements

   Sam Hartman and Dacheng Zhang previously published the MRKMP protocol
   [I-D.hartman-karp-mrkmp], which includes many operations and protocol
   elements in common with this memo.


8.  References

8.1.  Normative References

   [I-D.yeung-g-ikev2]
              Rowles, S., Yeung, A., Tran, P., and Y. Nir, "Group Key
              Management using IKEv2", draft-yeung-g-ikev2-03 (work in
              progress), July 2011.

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

   [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

   [DH]       Diffie, W. and M. Hellman, "New Directions in
              Cryptography", IEEE Transactions on Information
              Theory, V.IT-22 n. 6, June 1977.

   [I-D.hartman-karp-mrkmp]
              Zhang, D., Lebovitz, G., and S. Hartman, "Multicast Router
              Key Management Protocol (MaRK)",
              draft-hartman-karp-mrkmp-03 (work in progress),
              January 2012.

   [RFC6407]  Weis, B., Rowles, S., and T. Hardjono, "The Group Domain
              of Interpretation", RFC 6407, October 2011.







Tran & Weis            Expires September 10, 2012               [Page 9]


Internet-Draft                G-IKEv2-MRKM                    March 2012


Authors' Addresses

   Paulina Tran
   Cisco Systems
   170 Tasman Drive
   San Jose, California  CA
   USA

   Phone: +1 (408) 526-8902
   Fax:
   Email: ptran@cisco.com
   URI:


   Brian Weis
   Cisco Systems
   170 Tasman Drive
   San Jose, California  CA
   USA

   Phone: +1 (408) 526-4796
   Fax:
   Email: bew@cisco.com
   URI:



























Tran & Weis            Expires September 10, 2012              [Page 10]


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