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

Versions: 00 01

MSEC Working Group                                               B. Weis
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                       February 22, 2008
Expires: August 25, 2008


         Group Domain of Interpretation (GDOI) support for RSVP
                      draft-weis-gdoi-for-rsvp-01

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).














Weis                     Expires August 25, 2008                [Page 1]


Internet-Draft                  GDOI-RSVP                  February 2008


Abstract

   This memo describes the policy required for the Group Domain of
   Interpretation (GDOI) group key management system to distribute
   security policy for RSVP.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements notation  . . . . . . . . . . . . . . . . . .  3

   2.  GDOI Operations  . . . . . . . . . . . . . . . . . . . . . . .  5

   3.  SA TEK payload for RSVP  . . . . . . . . . . . . . . . . . . .  6
     3.1.  MAC Algorithm  . . . . . . . . . . . . . . . . . . . . . .  7
     3.2.  Sequence Number Types  . . . . . . . . . . . . . . . . . .  7
     3.3.  Optional Attributes  . . . . . . . . . . . . . . . . . . .  7

   4.  Key Packet definition for RSVP . . . . . . . . . . . . . . . .  8

   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11

   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Intellectual Property and Copyright Statements . . . . . . . . . . 14


















Weis                     Expires August 25, 2008                [Page 2]


Internet-Draft                  GDOI-RSVP                  February 2008


1.  Introduction

   The Group Domain of Interpretation (GDOI) is a group key management
   protocol fitting into the Multicast Security Group Key Management
   Architecture .  GDOI is used to disseminate group security policy and
   keying material to group members for use with a particular
   cryptographic system.

   The RSVP protocol provides a means for establishing resource
   reservations between cooperating systems.  To ensure the integrity of
   the associated reservation and admission control mechanisms, the RSVP
   Authentication mechanisms defined in [RFC2747] and [RFC3097] may be
   used.  These protect RSVP message integrity hop-by-hop and provide
   node authentication as well as replay protection, thereby protecting
   against corruption and spoofing of RSVP messages.

   [RFC2747] discusses several approaches for key distribution.  First,
   the RSVP Authentication shared keys can be distributed manually.
   This is the base option and its support is mandated for any
   implementation.  However, in some environments, this approach may
   become a burden if keys frequently change over time.  Alternatively,
   a standard key management protocol for secure shared key distribution
   can be used.  However, existing shared key distribution protocols may
   not be appropriate in all environments because of the complexity or
   operational burden they involve.  In effect, this impedes the
   practical use of RSVP Authentication.

   Another issue with RSVP Authentication is that shared key cannot be
   used among RSVP routers when those are interconnected via routers
   that do not run RSVP.  This is because, in this situation, an RSVP
   router does not always know the RSVP next hop for an RSVP message at
   the time of forwarding it.

   Such limitations with the current RSVP security mechanisms are
   further discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying].

   Since RSVP nodes effectively acts as a group of cooperating systems,
   they can benefit from sharing the same keying material.
   [I-D.ietf-tsvwg-rsvp-security-groupkeying] presents a framework for
   RSVP security using dynamic group keying and discusses its
   applicability.  In line with this framework, the present document
   describes extension to GDOI for distribution of security policy and
   keying material for RSVP.

1.1.  Requirements notation

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this



Weis                     Expires August 25, 2008                [Page 3]


Internet-Draft                  GDOI-RSVP                  February 2008


   document are to be interpreted as described in [RFC2119].


















































Weis                     Expires August 25, 2008                [Page 4]


Internet-Draft                  GDOI-RSVP                  February 2008


2.  GDOI Operations

   The GDOI group key management protocol [RFC3547]) actively manages
   keys for a set of group members.  In the case of RSVP, the set of
   group members belonging to a single group are routers and/or hosts
   that are trusted to establish reservations for a set of applications,
   and also trust the other group members to act appropriately within
   the group (e.g., not to spoof other group members).  A given group
   need not include all of the RSVP nodes passing a reservation.  For
   example, the group may be comprised of routers in a single ISP, where
   the RSVP packets are protected using a different model between ISPs.
   Similarly, different groups may be used for different sets of RSVP
   nodes.  Whether or not the group key is used and which RSVP nodes
   belong to a given group should depend on the trust model between the
   co-operating systems.

   GDOI begins operation when group members "register" to a GDOI key
   server using the GDOI GROUPKEY_PULL protocol.  The key server first
   authenticates and authorizes each group member.  GDOI also derives
   encryption keys shrared privately between the key server and the
   group member.  These keys are used to protect the group policy and
   keying material as it is distributed to the group member.  In the
   case of RSVP, the group policy consists of policy and keying material
   intended for use with the [RFC2747] [RFC3097] INTEGRITY Option.

   The GDOI key server also distributes policy and keys that describe
   how it will distribute updates to group policy in a "rekey" message,
   also known as the GDOI GROUPKEY_PUSH message.  Rekey messages are
   typically distributed as IP multicast packets.  They provide
   replacement RSVP policy and keying material (e.g., when RSVP keys
   expire) or to remove (i.e., revoke) group members in a non-disruptive
   manner.

   Both the GDOI registration and GDOI rekey protocols distribute
   cryptosystem policy in an SA TEK payload.  Each SA TEK payload
   describes a particular type of cryptographic system policy, and this
   memo describes a new type for the RSVP INTEGRITY Option.  Keying
   material is distributed in KD payload Key Packets.  This memo
   describes how those keys are distributed for the RSVP INTEGRITY
   Option.











Weis                     Expires August 25, 2008                [Page 5]


Internet-Draft                  GDOI-RSVP                  February 2008


3.  SA TEK payload for RSVP

   RFC 2747 describes a number of policy items that make up an RSVP
   security association.  When a centralized group key management system
   such as GDOI is used, the same RSVP policy is distributed to all
   group members.  The following SA TEK payload distributes 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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !                        Key Identifier                         !
       +                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !                               ! MAC Algorithm ! Seq. Num. Type!
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !                         Key Lifetime                          !
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!
       !                      Optional Attributes                      ~
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-!

   The SA TEK Payload fields are defined as follows:

   o  Key Identifier (6 octets) -- Value describing the identity of the
      key.  The group member will use this value as the Key Identifier
      in the RFC 2747 INTEGRITY Object.  The key identifier will
      uniquely define the particular key distributed in the KD payload.

   o  MAC Algorithm (1 octet) -- Value specifying which Message
      Authentication Code (MAC) is used to generate the Keyed Message
      Digest field of the RFC 2747 INTEGRITY Object .  MAC Algorithm
      types are defined below.  Values are defined in the IANA
      Considerations section.

   o  Sequence Number Type (1 octet) -- Value specifying how the
      sequence number field is constructed.  Sequence Number Types are
      defined below.  Values are defined in the IANA Considerations
      section.

   o  Key Lifetime (4 octets) -- Value specifying the remaining lifetime
      of the SA TEK, in seconds.  If the KeyStartValid optional
      attribute is included in the SA TEK, this lifetime specifies the
      entire lifetime of the SA TEK.  Otherwise, it represents the
      partial remaining lifetime.

   o  Optional Attributes (Variable) -- Optional TLV attributes, as
      defined below.






Weis                     Expires August 25, 2008                [Page 6]


Internet-Draft                  GDOI-RSVP                  February 2008


3.1.  MAC Algorithm

   The following MAC algorithms are defined for use with this TEK.

   o  HMAC-MD5.  The MD5 algorithm used with an HMAC construction
      [RFC2104].  This MAC algorithm is considered weak, but is required
      by a conforming RFC 2747 implementation.

   o  HMAC-SHA1.  The SHA1 algorithm used with an HMAC construction
      [RFC2104].

3.2.  Sequence Number Types

   The following methods of constructing sequence numbers is defined for
   use with this TEK.

   o  COUNTER.  This corresponds to the Simple Sequence Numbers method
      defined in Section 3.1 of RFC 2747.  When COUNTER based sequence
      numbers are used, each group member maintains its own sequence
      number for a given group in order to set the sequence number field
      in RSVP messages generated in this group.  Therefore, an RSVP
      receiver MUST track received sequence numbers separately for each
      RSVP neighbour in order to reliably distinguish between new and
      replay messages.

   o  TIME.  This corresponds to the Sequence Numbers Based on a Real
      Time Clock method described in Section 3.2 of RFC 2747 or the
      Sequence Numbers Based on a Network Recovered Clock method
      described in Section 3.3 or RFC 2747.

3.3.  Optional Attributes

   The following attributes may be present in the TEK Payload.  The
   attributes must follow the format defined in ISAKMP [RFC2408] Section
   3.3.  In the table, attributes that are defined as TV are marked as
   Basic (B); attributes that are defined as TLV are marked as Variable
   (V).  Values are defined in the IANA Considerations section.

   o  KeyStartValid (V).  This attribute specifies an real time in the
      future when the TEK will take effect [RFC2747].  Note that the
      corresponding KeyEndValid time defined in RFC 2747 is not
      distributed by GDOI, but is computed by adding the Key Lifetime
      value to KeyStartValid.  The KeyStartValid value is represented as
      the number of seconds since since 0 hours, 0 minutes, 0 seconds,
      January 1, 1970.






Weis                     Expires August 25, 2008                [Page 7]


Internet-Draft                  GDOI-RSVP                  February 2008


4.  Key Packet definition for RSVP

   Keying material for the RSVP INTEGRITY Option is distributed in a Key
   Packet as part of the GDOI KD payload.  The Key packet is formed as
   follows.

   o  KD Type.  The type of KD MUST be TEK.

   o  SPI.  The Key Identifier is placed in the SPI field.

   o  Key. The keying material for the MAC algorithm is placed in a
      TEK_INTEGRITY_KEY attribute.

   The Key Packet MUST NOT contain a TEK_ALGORITHM_KEY or
   TEK_SOURCE_AUTH_KEY attribute.




































Weis                     Expires August 25, 2008                [Page 8]


Internet-Draft                  GDOI-RSVP                  February 2008


5.  IANA Considerations

   A new GDOI SA TEK type Protocol-ID type [GDOI-REG] should be assigned
   from the RESERVED space.  The new algorithm id should be called
   GDOI_PROTO_RSVP_INTEGRITY, and refers to the INTEGRITY Object defined
   in [RFC2747].

   Terms describing policies for allocating new name space types below
   are defined in [RFC2434].

   The following MAC Algorithms are defined as a part of this memo.

                 MAC Algorithm Type        Value
                 ------------------        -----
                 RESERVED                    0
                 HMAC-MD5                    1
                 HMAC-SHA1                   2
                 Standards Action           3-127
                 Private Use              128-255

   The following Sequence Number Types are defined as a part of this
   memo.

                 Sequence Number Type        Value
                 --------------------        -----
                 RESERVED                      0
                 COUNTER                       1
                 TIME                          2
                 Standards Action             3-127
                 Private Use                128-255

   The following Optional Attributes are defined as part of this memo.

                 Optional Attribute        Value
                 ------------------        -----
                 RESERVED                    0
                 KeyStartValid               1
                 Standards Action           2-127
                 Private Use              128-255












Weis                     Expires August 25, 2008                [Page 9]


Internet-Draft                  GDOI-RSVP                  February 2008


6.  Security Considerations

   This memo describes the passing of policy and keying material used by
   an RSVP speaker to produce an RFC 2747 INTEGRITY Object.  This policy
   and keying material is protected by the GDOI protocol described in
   [RFC3547].  The security considerations in that memo apply fully to
   this memo as well.












































Weis                     Expires August 25, 2008               [Page 10]


Internet-Draft                  GDOI-RSVP                  February 2008


7.  Acknowledgements

   Francois Le Faucheur originated the idea of using GDOI for RSVP.  He
   also provided text for the Introduction section summarizing key
   distribution issues with RSVP message integrity.














































Weis                     Expires August 25, 2008               [Page 11]


Internet-Draft                  GDOI-RSVP                  February 2008


8.  References

8.1.  Normative References

   [RFC2747]  Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
              Authentication", RFC 2747, January 2000.

   [RFC3097]  Braden, R. and L. Zhang, "RSVP Cryptographic
              Authentication -- Updated Message Type Value", RFC 3097,
              April 2001.

   [RFC3547]  Baugher, M., Weis, B., Hardjono, T., and H. Harney, "The
              Group Domain of Interpretation", RFC 3547, July 2003.

8.2.  Informative References

   [GDOI-REG]
              Internet Assigned Numbers Authority, "Group Domain of
              Interpretation (GDOI) Payload Type Values", IANA Registry,
              December 2004,
              <http://www.iana.org/assignments/gdoi-payloads>.

   [I-D.ietf-tsvwg-rsvp-security-groupkeying]
              Behringer, M. and F. Faucheur, "Applicability of Keying
              Methods for RSVP Security",
              draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in
              progress), November 2007.

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              February 1997.

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

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

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.









Weis                     Expires August 25, 2008               [Page 12]


Internet-Draft                  GDOI-RSVP                  February 2008


Author's Address

   Brian Weis
   Cisco Systems
   170 W. Tasman Drive
   San Jose, California  95134-1706
   USA

   Phone: +1-408-526-4796
   Email: bew@cisco.com









































Weis                     Expires August 25, 2008               [Page 13]


Internet-Draft                  GDOI-RSVP                  February 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Weis                     Expires August 25, 2008               [Page 14]


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