summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6738.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6738.txt')
-rw-r--r--doc/rfc/rfc6738.txt955
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]
+