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 betweenIKEv2 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 20121. 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 Description4.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 20127. 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 201210. 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]