doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6738.txt b/doc/rfc/rfc6738.txt
new file mode 100644
index 0000000..f594720
--- /dev/null
+++ b/doc/rfc/rfc6738.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        V. Cakulev
+Request for Comments: 6738                                Alcatel Lucent
+Category: Standards Track                                        A. Lior
+ISSN: 2070-1721                                      Bridgewater Systems
+                                                           S. Mizikovsky
+                                                          Alcatel Lucent
+                                                            October 2012
+
+
+  Diameter IKEv2 SK: Using Shared Keys to Support Interaction between
+                   IKEv2 Servers and Diameter Servers
+
+Abstract
+
+   The Internet Key Exchange Protocol version 2 (IKEv2) is a component
+   of the IPsec architecture and is used to perform mutual
+   authentication as well as to establish and to maintain IPsec Security
+   Associations (SAs) between the respective parties.  IKEv2 supports
+   several different authentication mechanisms, such as the Extensible
+   Authentication Protocol (EAP), certificates, and Shared Key (SK).
+
+   Diameter interworking for Mobile IPv6 between the Home Agent (HA), as
+   a Diameter client, and the Diameter server has been specified.
+   However, that specification focused on the usage of EAP and did not
+   include support for SK-based authentication available with IKEv2.
+   This document specifies the IKEv2-server-to-Diameter-server
+   communication when the IKEv2 peer authenticates using IKEv2 with SK.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6738.
+
+
+
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                    [Page 1]
+
+RFC 6738                    Diameter IKEv2 SK               October 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Requirements Notation ...........................................4
+      2.1. Abbreviations ..............................................4
+   3. Application Identifier ..........................................5
+   4. Protocol Description ............................................5
+      4.1. Support for IKEv2 and Shared Keys ..........................5
+      4.2. Session Management .........................................7
+           4.2.1. Session-Termination-Request/Answer ..................7
+           4.2.2. Abort-Session-Request/Answer ........................7
+   5. Command Codes for Diameter IKEv2 with SK ........................7
+      5.1. IKEv2-SK-Request (IKESKR) Command ..........................8
+      5.2. IKEv2-SK-Answer (IKESKA) Command ...........................9
+   6. Attribute-Value Pair Definitions ...............................10
+      6.1. IKEv2-Nonces ..............................................10
+           6.1.1. Ni .................................................10
+           6.1.2. Nr .................................................10
+      6.2. IKEv2-Identity ............................................10
+           6.2.1. Initiator-Identity .................................10
+           6.2.2. Responder-Identity .................................11
+   7. AVP Occurrence Tables ..........................................12
+   8. AVP Flag Rules .................................................13
+   9. IANA Considerations ............................................14
+      9.1. Command Codes .............................................14
+      9.2. AVP Codes .................................................14
+      9.3. AVP Values ................................................14
+      9.4. Application Identifier ....................................14
+   10. Security Considerations .......................................15
+   11. References ....................................................16
+      11.1. Normative References .....................................16
+      11.2. Informative References ...................................16
+
+
+
+
+Cakulev, et al.              Standards Track                    [Page 2]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+1.  Introduction
+
+   The Internet Key Exchange Protocol version 2 (IKEv2) [RFC5996] is
+   used to mutually authenticate two parities and to establish a
+   Security Association (SA) that can be used to efficiently secure the
+   communication between the IKEv2 peer and server, for example, using
+   Encapsulating Security Payload (ESP) [RFC4303] and/or Authentication
+   Header (AH) [RFC4302].  The IKEv2 protocol allows several different
+   mechanisms for authenticating an IKEv2 peer to be used, such as the
+   Extensible Authentication Protocol (EAP), certificates, and SK.
+
+   From a service provider perspective, it is important to ensure that a
+   user is authorized to use the services.  Therefore, the IKEv2 server
+   must verify that the IKEv2 peer is authorized for the requested
+   services, possibly with the assistance of the operator's Diameter
+   servers.  [RFC5778] defines the home agent as a Diameter-client-to-
+   Diameter-server communication when the mobile node authenticates
+   using the IKEv2 protocol with the Extensible Authentication Protocol
+   (EAP) [RFC3748] or using the Mobile IPv6 Authentication Protocol
+   [RFC4285].  This document specifies the IKEv2-server-to-Diameter-
+   server communication when the IKEv2 peer authenticates using IKEv2
+   with SK.
+
+   Figure 1 depicts the reference architecture for this document.
+
+                                       +--------+
+                                       |Diameter|
+                                       |Server  |
+                                       +--------+
+                                           ^
+                                  Back-End | IKEv2 Server<->HAAA Server
+                                  Support  | Interaction
+                                  Protocol | (this document)
+                                           v
+   +---------+                      +---------------+
+   | IKEv2   |  Front-End Protocol  |IKEv2 Server/  |
+   | Peer    |<-------------------->|Diameter Client|
+   +---------+       IKEv2          +---------------+
+
+                      Figure 1: Architecture Overview
+
+   An example use case for this architecture is Mobile IPv6 deployment
+   in which the Mobile IPv6 signaling between the Mobile Node and the
+   Home Agent is protected using IPsec.  The Mobile node acts as the
+   IKEv2 peer and the Home Agent acts as an IKEv2 server.  In this use
+   case, IKEv2 with SK-based initiator authentication is used for the
+   setup of the IPsec SAs.  The HA obtains the SK using the Diameter
+   application specified in this document.
+
+
+
+Cakulev, et al.              Standards Track                    [Page 3]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+   This document assumes that the SK provided to the IKEv2 peer as well
+   as the SK delivered to the IKEv2 server by the Diameter server are
+   established or derived using the same rules.  Furthermore, it assumes
+   that these rules are agreed to by the external protocol on a peer
+   side providing the key to the IKEv2 peer, and on the Diameter server
+   side providing the key to the IKEv2 server.  This document allows for
+   the SK to be obtained for a specific IKEv2 session and exchanged
+   between IKEv2 server and the Home Authentication, Authorization, and
+   Accounting (HAAA) server.  The protocol provides IKEv2 attributes to
+   allow the HAAA to compute the SK specific to the session if desired
+   (see Section 10).  This is accomplished through the use of a new
+   Diameter application specifically designed for performing IKEv2
+   authorization decisions.  This document focuses on the IKEv2 server,
+   as a Diameter client, communicating to the Diameter server, and it
+   specifies the Diameter application needed for this communication.
+   Other protocols leveraging this Diameter application MAY specify
+   their own SK derivation scheme.  For example see [X.S0047] and
+   [X.S0058].  This document specifies the default procedure for
+   derivation of the SK used in IKEv2 authentication when protocols
+   leveraging this Diameter application do not specify their own
+   derivation procedure.  Selection of either default or other SK
+   derivation procedure is done by the external protocol between the
+   Peer and the Diameter Server, and is outside the scope of this
+   document.
+
+2.  Requirements Notation
+
+   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].
+
+2.1.  Abbreviations
+
+   AH        Authentication Header
+
+   AVP       Attribute-Value Pair
+
+   EAP       Extensible Authentication Protocol
+
+   ESP       Encapsulating Security Payload
+
+   HAAA      Home Authentication, Authorization, and Accounting
+
+   IKEv2     Internet Key Exchange Protocol version 2
+
+   NAI       Network Access Identifier
+
+   PSK       Pre-Shared Key
+
+
+
+Cakulev, et al.              Standards Track                    [Page 4]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+   SA        Security Association
+
+   SK        Shared Key
+
+   SPI       Security Parameter Index
+
+3.  Application Identifier
+
+   This specification defines a new Diameter application and its
+   respective Application Identifier:
+
+      Diameter IKE SK  (IKESK)  11
+
+
+   The IKESK Application Identifier is used when the IKEv2 peer is to be
+   authenticated and authorized using IKEv2 with SK-based
+   authentication.
+
+4.  Protocol Description
+
+4.1.  Support for IKEv2 and Shared Keys
+
+   When IKEv2 is used with SK-based initiator authentication, the
+   Diameter commands IKEv2-SK-Request/Answer defined in this document
+   are used between the IKEv2 server and a Home AAA (HAAA) server to
+   authorize the IKEv2 peer for the services.  Upon receiving the
+   IKE_AUTH message from the IKEv2 peer, the IKEv2 server uses the
+   information received in IDi [RFC5996] to identify the IKEv2 peer and
+   the SPI, if available, to determine the correct SK for this IKEv2
+   peer.  If no SK associated with this IKEv2 peer is found, the IKEv2
+   server MUST send an Authorize-Only (Auth-Request-Type set to
+   "Authorize-Only") Diameter IKEv2-SK-Request message to the HAAA to
+   obtain the SK.  If the IDi payload extracted from the IKE_AUTH
+   message contains an identity that is meaningful for the Diameter
+   infrastructure, such as a Network Access Identifier (NAI), it SHALL
+   be used by the IKEv2 server to populate the User-Name AVP in the
+   Diameter message.  Otherwise, it is out of scope of this document how
+   the IKEv2 server maps the value received in the IDi payload to the
+   User-Name AVP and whether or not the User-Name AVP is included in the
+   IKEv2-SK-Request message.  In the same Diameter message, the IKEv2
+   server SHALL also include the IKEv2-Nonces AVP with the initiator and
+   responder nonces (Ni and Nr) exchanged during initial IKEv2 exchange.
+   Finally, the IKEv2 server SHALL include the IKEv2-Identity AVP in the
+   IKEv2-SK-Request message.  The Initiator-Identity AVP SHALL be
+   populated with the IDi field extracted from the IKE_AUTH message.  If
+   the IDr payload was included in the IKE_AUTH message received from
+   the IKEv2 peer, the IKEv2 server SHALL also include a Responder-
+   Identity AVP populated with the received IDr.
+
+
+
+Cakulev, et al.              Standards Track                    [Page 5]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+   The IKEv2 server sends the IKEv2-SK-Request message to the IKEv2
+   peer's HAAA.  The Diameter message is routed to the correct HAAA per
+   [RFC6733].
+
+   Upon receiving a Diameter IKEv2-SK-Request message from the IKEv2
+   server, the HAAA SHALL use the User-Name AVP (if present) and/or
+   Initiator-Identity AVP to retrieve the associated keying material.
+   When the default SK-generation procedure specified in this document
+   is used, the peer side that provides the SK to the IKEv2 peer, as
+   well as the Diameter server, SHALL use the same SK derivation that
+   follows the methodology similar to that specified in Section 3.1 of
+   [RFC5295], specifically:
+
+   SK = KDF(PSK, key label | "\0" | Ni | Nr | IDi | length)
+
+   Where:
+
+   o  KDF is the default key derivation function based on HMAC-SHA-256
+      as specified in Section 3.1.2 of [RFC5295].
+
+   o  Pre-Shared Key (PSK) is the key available to the protocol
+      leveraging this Diameter application, e.g., the long-term shared
+      secret, or the Extended Master Session Key (EMSK) as the result of
+      prior EAP authentication, etc.  Selection of this value is left up
+      to the protocol leveraging this Diameter application.
+
+   o  Key label is set to 'sk4ikev2@ietf.org'.
+
+   o  | denotes concatenation
+
+   o  "\0" is a NULL octet (0x00 in hex)
+
+   o  Length is a 2-octet unsigned integer in network byte order of the
+      output key length, in octets.
+
+   When applications using this protocol define their own SK-generation
+   algorithm, it is strongly RECOMMENDED that the nonces Ni and Nr be
+   used in the computation.  It is also RECOMMENDED that IDi be used.
+   IDr SHOULD NOT be used in the SK generation algorithm.  Applications
+   that want to use IDr in the computation should take into
+   consideration that the IDr asserted by the IKEv2 peer may not be the
+   same as the IDr returned by the IKEv2 responder.  This mismatch will
+   result in different SKs being generated.  The HAAA returns the SK to
+   the IKEv2 server using the Key AVP as specified in [RFC6734].
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                    [Page 6]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+   Once the IKEv2 server receives the SK from the HAAA, the IKEv2 server
+   verifies the IKE_AUTH message received from the IKEv2 peer.  If the
+   verification of AUTH is successful, the IKEv2 server sends the IKE
+   message back to the IKEv2 peer.
+
+4.2.  Session Management
+
+   The HAAA may maintain Diameter session state or may be stateless.
+   This is indicated by the presence or absence of the Auth-Session-
+   State AVP included in the answer message.  The IKEv2 server MUST
+   support the Authorization Session State Machine defined in [RFC6733].
+
+4.2.1.  Session-Termination-Request/Answer
+
+   In the case where the HAAA is maintaining session state, when the
+   IKEv2 server terminates the SA, it SHALL send a Session-Termination-
+   Request (STR) message [RFC6733] to inform the HAAA that the
+   authorized session has been terminated.
+
+   The Session-Termination-Answer (STA) message [RFC6733] is sent by the
+   HAAA to acknowledge the notification that the session has been
+   terminated.
+
+4.2.2.  Abort-Session-Request/Answer
+
+   The Abort-Session-Request (ASR) message [RFC6733] is sent by the HAAA
+   to the IKEv2 server to terminate the authorized session.  When the
+   IKEv2 server receives the ASR message, it MUST delete the
+   corresponding IKE_SA and all CHILD_SAs set up through it.
+
+   The Abort-Session-Answer (ASA) message [RFC6733] is sent by the IKEv2
+   server in response to an ASR message.
+
+5.  Command Codes for Diameter IKEv2 with SK
+
+   This section defines new Command Code values that MUST be supported
+   by all Diameter implementations conforming to this specification.
+
+   +------------------+---------+------+-----------------+-------------+
+   |   Command Name   | Abbrev. | Code |     Section     | Application |
+   |                  |         |      |    Reference    |             |
+   +------------------+---------+------+-----------------+-------------+
+   | IKEv2-SK-Request |  IKESKR |  329 |   Section 5.1   |    IKESK    |
+   |                  |         |      |                 |             |
+   |  IKEv2-SK-Answer |  IKESKA |  329 |   Section 5.2   |    IKESK    |
+   +------------------+---------+------+-----------------+-------------+
+
+                          Table 1: Command Codes
+
+
+
+Cakulev, et al.              Standards Track                    [Page 7]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+5.1.  IKEv2-SK-Request (IKESKR) Command
+
+   The IKEv2-SK-Request message, indicated with the Command Code set to
+   329 and the 'R' bit set in the Command Flags field, is sent from the
+   IKEv2 server to the HAAA to initiate IKEv2 with SK authorization.  In
+   this case, the Application-Id field of the Diameter header MUST be
+   set to the Diameter IKE SK Application-Id (11).
+
+   Message format
+
+         <IKEv2-SK-Request> ::= < Diameter Header: 329, REQ, PXY >
+                                 < Session-Id >
+                                 { Auth-Application-Id }
+                                 { Origin-Host }
+                                 { Origin-Realm }
+                                 { Destination-Realm }
+                                 { Auth-Request-Type }
+                                 [ Destination-Host ]
+                                 [ NAS-Identifier ]
+                                 [ NAS-IP-Address ]
+                                 [ NAS-IPv6-Address ]
+                                 [ NAS-Port ]
+                                 [ Origin-State-Id ]
+                                 [ User-Name ]
+                                 [ Key-SPI ]
+                                 { IKEv2-Identity }
+                                 [ Auth-Session-State ]
+                                 { IKEv2-Nonces }
+                               * [ Proxy-Info ]
+                               * [ Route-Record ]
+                                 ...
+                               * [ AVP ]
+
+   The IKEv2-SK-Request message MUST include an IKEv2-Nonces AVP
+   containing the Ni and Nr nonces swapped during initial IKEv2
+   exchange.  The IKEv2-SK-Request message MAY contain a Key-SPI AVP
+   (Key-SPI AVP is specified in [RFC6734]).  If included, it contains
+   the SPI that HAAA SHALL use, in addition to the other parameters
+   (e.g., Initiator-Identity), to identify the appropriate SK.  The
+   IKEv2-SK-Request message MUST include IKEv2-Identity AVP.  The
+   Initiator-Identity AVP SHALL contain IDi as received in IKE_AUTH
+   message.  The Responder-Identity AVP SHALL be included in the IKEv2-
+   SK-Request message, if IDr payload was included in the IKE_AUTH
+   message received from the IKEv2 peer.  If included, the Responder-
+   Identity AVP contains the received IDr.
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                    [Page 8]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+5.2.  IKEv2-SK-Answer (IKESKA) Command
+
+   The IKEv2-SK-Answer (IKESKA) message, indicated by the Command Code
+   field set to 329 and the 'R' bit cleared in the Command Flags field,
+   is sent by the HAAA to the IKEv2 server in response to the IKESKR
+   command.  In this case, the Application-Id field of the Diameter
+   header MUST be set to the Diameter IKE SK Application-Id (11).
+
+   Message format
+
+           <IKEv2-SK-Answer> ::= < Diameter Header: 329, PXY >
+                                  < Session-Id >
+                                  { Auth-Application-Id }
+                                  { Auth-Request-Type }
+                                  { Result-Code }
+                                  { Origin-Host }
+                                  { Origin-Realm }
+                                  [ User-Name ]
+                                  [ Key ]
+                                  [ Responder-Identity ]
+                                  [ Auth-Session-State ]
+                                  [ Error-Message ]
+                                  [ Error-Reporting-Host ]
+                                * [ Failed-AVP ]
+                                  [ Origin-State-Id ]
+                                * [ Redirect-Host ]
+                                  [ Redirect-Host-Usage ]
+                                  [ Redirect-Max-Cache-Time ]
+                                * [ Proxy-Info ]
+                                * [ Route-Record ]
+                                  ...
+                                * [ AVP ]
+
+   If the authorization procedure is successful, then the IKEv2-SK-
+   Answer message SHALL include the Key AVP as specified in [RFC6734].
+   The value of the Key-Type AVP SHALL be set to IKEv2 SK (3).  The
+   Keying-Material AVP SHALL contain the SK.  If the Key-SPI AVP is
+   received in IKEv2-SK-Request, the Key-SPI AVP SHALL be included in
+   the Key AVP.  The Key-Lifetime AVP may be included; if so, then the
+   associated key SHALL NOT be used by the receiver of the answer if the
+   lifetime has expired.  Finally, the Responder-Identity AVP may be
+   included.
+
+
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                    [Page 9]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+6.  Attribute-Value Pair Definitions
+
+   This section defines new AVPs for IKEv2 with SK.
+
+6.1.  IKEv2-Nonces
+
+   The IKEv2-Nonces AVP (Code 587) is of type Grouped and contains the
+   nonces exchanged between the IKEv2 peer and the IKEv2 server during
+   IKEv2 initial exchange.  The nonces are used for SK generation.
+
+               IKEv2-Nonces ::= < AVP Header: 587 >
+                                {Ni}
+                                {Nr}
+                               *[AVP]
+
+6.1.1.  Ni
+
+   The Ni AVP (AVP Code 588) is of type OctetString and contains the
+   IKEv2 initiator nonce as contained in Nonce Data field.
+
+6.1.2.  Nr
+
+   The Nr AVP (AVP Code 589) is of type OctetString and contains the
+   IKEv2 responder nonce as contained in Nonce Data field.
+
+6.2.  IKEv2-Identity
+
+   The IKEv2-Identity AVP (Code 590) is of type Grouped and contains the
+   Initiator and possibly Responder identities as included in IKE_AUTH
+   message sent from the IKEv2 peer to the IKEv2 server.
+
+               IKEv2-Identity ::= < AVP Header: 590 >
+                                {Initiator-Identity}
+                                [Responder-Identity]
+                               *[AVP]
+
+6.2.1.  Initiator-Identity
+
+   The Initiator-Identity AVP (AVP Code 591) is of type Grouped and
+   contains the identity type and identification data of the IDi payload
+   of the IKE_AUTH message.
+
+               Initiator-Identity ::= < AVP Header: 591 >
+                                {ID-Type}
+                                {Identification-Data}
+                               *[AVP]
+
+
+
+
+
+Cakulev, et al.              Standards Track                   [Page 10]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+6.2.1.1.  ID-Type
+
+   The ID-Type AVP (AVP Code 592) is of type Enumerated and contains the
+   ID type value of IDi payload of the IKE_AUTH message.
+
+6.2.1.2.  Identification-Data
+
+   The Identification-Data AVP (AVP Code 593) is of type OctetString and
+   contains the Identification Data field of IDi payload of the IKE_AUTH
+   message.
+
+6.2.2.  Responder-Identity
+
+   The Responder-Identity AVP (AVP Code 594) is of type Grouped and
+   contains the identity type and identification data of the IDr payload
+   of the IKE_AUTH message.
+
+               Responder-Identity ::= < AVP Header: 594 >
+                                {ID-Type}
+                                {Identification-Data}
+                               *[AVP]
+
+6.2.2.1.  ID-Type
+
+   The ID-Type AVP (AVP Code 592) is of type Enumerated and contains the
+   ID type value of IDr payload of the IKE_AUTH message.
+
+6.2.2.2.  Identification-Data
+
+   The Identification-Data AVP (AVP Code 593) is of type OctetString and
+   contains the Identification Data field of IDr payload of the IKE_AUTH
+   message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                   [Page 11]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+7.  AVP Occurrence Tables
+
+   The following tables present the AVPs defined or used in this
+   document and their occurrences in Diameter messages.  Note that AVPs
+   that can only be present within a Grouped AVP are not represented in
+   this table.
+
+   The table uses the following symbols:
+
+   0:       The AVP MUST NOT be present in the message.
+
+   0+:      Zero or more instances of the AVP MAY be present in the
+            message.
+
+   0-1:     Zero or one instance of the AVP MAY be present in the
+            message.
+
+   1:       One instance of the AVP MUST be present in the message.
+
+                                     +-------------------+
+                                     |   Command Code    |
+                                     |---------+---------+
+      AVP Name                       | IKESKR  | IKESKA  |
+      -------------------------------|---------+---------+
+      Key                            |    0    |   0-1   |
+      Key-SPI                        |   0-1   |    0    |
+      IKEv2-Nonces                   |    1    |    0    |
+      IKEv2-Identity                 |    1    |    0    |
+      Responder-Identity             |    0    |   0-1   |
+                                     +---------+---------+
+
+                   IKESKR and IKESKA Commands AVP Table
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                   [Page 12]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+8.  AVP Flag Rules
+
+   The following table describes the Diameter AVPs, their AVP Code
+   values, types, and possible flag values.  The Diameter base protocol
+   [RFC6733] specifies the AVP Flag rules for AVPs in Section 4.5.
+
+                                                 +---------+
+                                                 |AVP Flag |
+                                                 |  Rules  |
+                                                 +----+----+
+                       AVP  Section              |    |MUST|
+    Attribute Name     Code Defined   Value Type |MUST| NOT|
+   +---------------------------------------------+----+----+
+   |Key                 581  Note 1   Grouped    |  M | V  |
+   +---------------------------------------------+----+----+
+   |Keying-Material     583  Note 1   OctetString|  M | V  |
+   +---------------------------------------------+----+----+
+   |Key-Lifetime        584  Note 1   Integer64  |  M | V  |
+   +---------------------------------------------+----+----+
+   |Key-SPI             585  Note 1   Unsigned32 |  M | V  |
+   +---------------------------------------------+----+----+
+   |Key-Type            582  Note 1   Enumerated |  M | V  |
+   +---------------------------------------------+----+----+
+   |IKEv2-Nonces        587  6.1      Grouped    |  M | V  |
+   +---------------------------------------------+----+----+
+   |Ni                  588  6.1.1    OctetString|  M | V  |
+   +---------------------------------------------+----+----+
+   |Nr                  589  6.1.2    OctetString|  M | V  |
+   +---------------------------------------------+----+----+
+   |IKEv2-Identity      590  6.2      Grouped    |  M | V  |
+   +---------------------------------------------+----+----+
+   |Initiator-Identity  591  6.2.1    Grouped    |  M | V  |
+   +---------------------------------------------+----+----+
+   |ID-Type             592  6.2.1.1  Enumerated |  M | V  |
+   +---------------------------------------------+----+----+
+   |Identification-Data 593  6.2.1.2  OctetString|  M | V  |
+   +---------------------------------------------+----+----+
+   |Responder-Identity  594  6.2.2    Grouped    |  M | V  |
+   +---------------------------------------------+----+----+
+
+                           AVP Flag Rules Table
+
+   Note 1: The Key, Keying-Material, Key-Lifetime, Key-SPI, and Key-Type
+   AVPs are defined in [RFC6734].
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                   [Page 13]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+9.  IANA Considerations
+
+9.1.  Command Codes
+
+   IANA has allocated a Command Code value for the following new command
+   from the Command Code namespace defined in [RFC6733].
+
+      Command Code                     | Value
+      ---------------------------------+------
+      IKEv2-SK-Request/Answer          | 329
+
+9.2.  AVP Codes
+
+   This specification requires IANA to register the following new AVPs
+   from the AVP Code namespace defined in [RFC6733].
+
+   o  IKEv2-Nonces - 587
+
+   o  Ni - 588
+
+   o  Nr - 589
+
+   o  IKEv2-Identity - 590
+
+   o  Initiator-Identity - 591
+
+   o  ID-Type - 592
+
+   o  Identification-Data - 593
+
+   o  Responder-Identity - 594
+
+   The AVPs are defined in Section 6.
+
+9.3.  AVP Values
+
+   IANA is requested to create a new value for the Key-Type AVP.  The
+   new value 3 signifies that IKEv2 SK is being sent.
+
+9.4.  Application Identifier
+
+   This specification requires IANA to allocate one new value "Diameter
+   IKE SK" from the Application Identifier namespace defined in
+   [RFC6733].
+
+   Application Identifier         | Value
+   -------------------------------+------
+   Diameter IKE SK (IKESK)        | 11
+
+
+
+Cakulev, et al.              Standards Track                   [Page 14]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+10.  Security Considerations
+
+   The security considerations of the Diameter base protocol [RFC6733]
+   are applicable to this document (e.g., it is expected that Diameter
+   protocol is used with security mechanism and that Diameter messages
+   are secured).
+
+   In addition, the assumption is that the IKEv2 server and the Diameter
+   server, where the SK is generated, are in a trusted relationship.
+   Hence, the assumption is that there is an appropriate security
+   mechanism to protect the communication between these servers.  For
+   example, the IKEv2 server and the Diameter server would be deployed
+   in the same secure network or would utilize transport-layer security
+   as specified in [RFC6733].
+
+   The Diameter messages between the IKEv2 server and the HAAA may be
+   transported via one or more AAA brokers or Diameter agents.  In this
+   case, the IKEv2 server to the Diameter server AAA communication is
+   hop-by-hop protected; hence, it relies on the security properties of
+   the intermediating AAA inter-connection networks, AAA brokers, and
+   Diameter agents.  Furthermore, any agents that process IKEv2-SK-
+   Answer messages can see the contents of the Key AVP.
+
+   To mitigate the threat of exposing a long-lived PSK, this
+   specification expects that the HAAA derive and return the associated
+   SK to the IKEv2 server.  Given that SK derivation is security-
+   critical, for the SK derivation, this specification recommends the
+   use of short-lived secrets, possibly based on a previous network
+   access authentication, if such secrets are available.  To ensure key
+   freshness and to limit the key scope, this specification strongly
+   recommends the use of nonces included in the IKEv2-SK-Request.  The
+   specifics of key derivation depend on the security characteristics of
+   the system that is leveraging this specification (for example, see
+   [X.S0047] and [X.S0058]); therefore, this specification does not
+   define how the Diameter server derives required keys for these
+   systems.  For systems and protocols that leverage this Diameter
+   application but do not specify the key derivation procedure, this
+   document specifies the default key derivation procedure that
+   preserves expected security characteristics.
+
+
+
+
+
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                   [Page 15]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+11.  References
+
+11.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
+              December 2005.
+
+   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
+              RFC 4303, December 2005.
+
+   [RFC5295]  Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri,
+              "Specification for the Derivation of Root Keys from an
+              Extended Master Session Key (EMSK)", RFC 5295,
+              August 2008.
+
+   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
+              "Internet Key Exchange Protocol Version 2 (IKEv2)",
+              RFC 5996, September 2010.
+
+   [RFC6733]  Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
+              "Diameter Base Protocol", RFC 6733, October 2012.
+
+   [RFC6734]  Zorn, G., Wu, W., and V. Cakulev, "Diameter Attribute-
+              Value Pairs for Cryptographic Key Transport", RFC 6734,
+              October 2012.
+
+11.2.  Informative References
+
+   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
+              Levkowetz, "Extensible Authentication Protocol (EAP)",
+              RFC 3748, June 2004.
+
+   [RFC4285]  Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
+              Chowdhury, "Authentication Protocol for Mobile IPv6",
+              RFC 4285, January 2006.
+
+   [RFC5778]  Korhonen, J., Tschofenig, H., Bournelle, J., Giaretta, G.,
+              and M. Nakhjiri, "Diameter Mobile IPv6: Support for Home
+              Agent to Diameter Server Interaction", RFC 5778,
+              February 2010.
+
+   [X.S0047]  3GPP2: X.S0047, "Mobile IPv6 Enhancements", February 2009.
+
+   [X.S0058]  3GPP2: X.S0058, "WiMAX-HRPD Interworking: Core Network
+              Aspects", June 2010.
+
+
+
+Cakulev, et al.              Standards Track                   [Page 16]
+
+RFC 6738                    Diameter IKEv2 SK               October 2012
+
+
+Authors' Addresses
+
+   Violeta Cakulev
+   Alcatel Lucent
+   600 Mountain Ave.
+   3D-517
+   Murray Hill, NJ  07974
+   US
+
+   Phone: +1 908 582 3207
+   EMail: violeta.cakulev@alcatel-lucent.com
+
+
+   Avi Lior
+   Bridgewater Systems
+   303 Terry Fox Drive
+   Ottawa, Ontario  K2K 3J1
+   Canada
+
+   Phone: +1 613-591-6655
+   EMail: avi.ietf@lior.org
+
+
+   Semyon Mizikovsky
+   Alcatel Lucent
+   600 Mountain Ave.
+   3C-506
+   Murray Hill, NJ  07974
+   US
+
+   Phone: +1 908 582 0729
+   EMail: Simon.Mizikovsky@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cakulev, et al.              Standards Track                   [Page 17]
+