Network Working Group Timothy J. Kniveton
Internet Draft Jari T. Malinen
Expires: January 2002 Nokia Research Center
Informational July 2001
SIM Authentication EAP extension over AAAv6 (SIM6)
draft-kniveton-aaa-sim6-00.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
Providing an existing scalable authorization infrastructure for mobile
nodes is needed for IPv6-based mobility. SIM Authentication provides
a protocol for authenticating and authorizing services. It uses an
authorizing home domain defined by the Subscriber Identity Module
(SIM). The protocol is an Internet Control Message Protocol for IPv6
(ICMPv6) extension. It can leverage the existing SIM authorization
infrastructure for automatic bootstrapping of security association
between the mobile node and a service, where the service can be
e.g. authorized last-hop VPN setup for network access or Mobile IPv6
mobile-home security association setup.
Kniveton, Malinen Expires January 2002 [Page 1]
Internet Draft SIM Authentication over AAAv6 July 2001
Contents
Status of This Memo 1
Abstract 1
1. Introduction 3
2. Terms 5
3. Protocol Operation 6
3.1. Access Link Signaling . . . . . . . . . . . . . . . . . . 6
3.2. Core Network Signaling . . . . . . . . . . . . . . . . . 7
3.3. Signaling diagram of SIM authentication over AAAv6 . . . 9
4. New requirements for IPv6 Nodes 10
4.1. Mobile node requirements . . . . . . . . . . . . . . . . 10
4.2. Attendant requirements . . . . . . . . . . . . . . . . . 11
4.3. Authentication Gateway requirements . . . . . . . . . . . 11
5. Protocol Messages 11
5.1. Router Advertisement / AAAv6 local challenge . . . . . . 11
5.2. AAAv6 request/EAP response/SIM/Start . . . . . . . . . . 14
5.3. AAAv6 reply/EAP request/SIM/Challenge . . . . . . . . . . 19
5.4. AAAv6 request/EAP response/SIM/Challenge . . . . . . . . 22
5.5. AAAv6 reply with key SPI . . . . . . . . . . . . . . . . 25
6. Local Attendant Operation 27
6.1. Sending Local Challenge to the Mobile Node . . . . . . . 27
6.2. Receiving SIM/Start from the Mobile Node . . . . . . . . 27
6.3. Sending SIM/Challenge to the Mobile Node . . . . . . . . 28
6.4. Receiving SIM/Challenge from the Mobile Node . . . . . . 28
6.5. Sending Key Reply to the Mobile Node . . . . . . . . . . 29
7. Mobile Node Operation 29
7.1. Receiving Local Challenge from the Attendant . . . . . . 29
7.2. Sending SIM/Start to the Attendant . . . . . . . . . . . 30
7.3. Receiving SIM/Challenge from the Attendant . . . . . . . 30
7.4. Sending SIM/Challenge to the Attendant . . . . . . . . . 30
7.5. Receiving Key Reply from the Attendant . . . . . . . . . 31
8. Authentication Gateway Operation 31
8.1. Receiving SIM/Start from the mobile node via the Attendant 31
8.2. Sending SIM/Challenge to the mobile node via the Attendant 32
8.3. Receiving SIM/Challenge from the mobile node via the
Attendant . . . . . . . . . . . . . . . . . . . . . . . . 33
Kniveton, Malinen Expires January 2002 [Page 2]
Internet Draft SIM Authentication over AAAv6 July 2001
8.4. Sending Key Reply to the mobile node via the Attendant . 33
9. Applications of SIM Authentication over AAAv6 34
9.1. SIM Authentication for Network Access . . . . . . . . . . 34
9.2. SIM Authentication for Services . . . . . . . . . . . . . 34
10. Protocol Constants 35
11. Security Considerations 36
12. IPv4 Considerations 36
13. Intellectual Property Right Considerations 36
14. Acknowledgements 36
Authors' Addresses 38
Full Copyright Statement 38
1. Introduction
This document considers authorization of services in IPv6 for a mobile
node, using a Subscriber Identity Module (SIM). The existence of a
large number of SIM modules with an associated trust infrastructure
provides a widespread existing mechanism for scalable trust delegation.
Introduction of totally new mechansims for IP-based trust delegation
is expensive. Leveraging an existing SIM-based mechanism for IPv6 [8]
can be achieved by a simple extension to the AAAv6 [2] protocol,
defined in this document. The mode is an optional extension to AAAv6
functionality. Its requirements are listed in RFC2989, and it also
provides revocation, as described in Section 9.
When using a hardware-based mechanism, such as a SIM module, for
authorizing and authenticating client with a service, bootstrapping of a
dynamic trust relationship can be automated so that little or no manual
configuration is needed. Services like Mobile IPv6 [15] can benefit
from such a mechanism in that, for example, no static mobile-home
security association configuration is needed. The presented protocol is
applicable to bootstrapping a security association between mobile node
and home agent, or mobile node and an access link router. It can also
be used for bootstrapping other services.
The protocol uses a network topology reference model as presented in
Figure 1. Authorization comes from a domain [A] separate from those of
access [B] and from the domain using the authorization [C]. Usually, the
authorizing domain is the network of the issuing operator, operator who
issued the SIM module.
Kniveton, Malinen Expires January 2002 [Page 3]
Internet Draft SIM Authentication over AAAv6 July 2001
+-------------------------+
| [A] |
| +--------+ |
| | | |
| +-----+ AAAH | |
| | | | |
| | +--------+ |
| +--------+ |
| | | |
+---| AGW |------------+
| |
+---+----+
|
+------|-------+
| +---+----+ |
| | | |
| | AAAL | |
| | | |
| +---+----+ |
| [B] | |
+--------+ | +---+----+ | +--------+
| | | | | | | [C] |
| MN |---------| AR/LA |------------+ Peer |
| | | | | | |e.g. HA |
+--------+ | +--------+ | +--------+
+--------------+
Figure 1: Network Reference for SIM Authentication over AAAv6
The protocol does not require changes to network entities neither
in the IPv6 network nor in the cellular network nor to existing SIM
authentication principles used there. Exceptions are the access
router's local attendant functionality, the AAAv6 signaling in the
mobile node (MN), and the gateway connecting a cellular network with the
IPv6 network. New functional elements are the SIM6 functionality in the
mobile node, access router, and in the authentication gateway, at the
border of the IP network and the cellular domain. The AGW is capable of
communicating with the authorization center in the cellular network of
the issuing operator.
SIM Authentication uses Extensible Authentication Protocol (EAP) [3]
messages as a modular key distribution extension to AAAv6. The use of
EAP allows for adding other similar extensions over AAAv6.
In SIM authentication, an access router provides a local challenge which
is returned by the mobile node in the first key request. Then, a mobile
Kniveton, Malinen Expires January 2002 [Page 4]
Internet Draft SIM Authentication over AAAv6 July 2001
node transmits its International Mobile Subscriber Identifier (IMSI) [9]
in a key request to an authentication gateway (AGW). It returns a SIM
challenge to the mobile node which responds with a SIM response in the
second message, computed locally by the SIM module. The key request,
SIM challenge, and SIM response are EAP messages inside AAAv6.
If the response matches that locally known by the authentication
gateway, a session key is finally returned in a key reply. While mobile
node has a local SIM-generated session key, the other instance of the
session key is provided in the key reply to its user. This user is
called the peer. It can be the access router, for example. Since the
mobile node locally creates its copy of the session key, no key material
is transported over the access link.
The protocol provides a temporary session key pair. Its application
can be authentication with the access router, last hop encryption, or
authentication with Mobile IPv6 [15] home agent (Section 9), depending
on the purpose of authorization, negotiated between MN and AGW.
Signaling using the session key, e.g. Mobile IPv6 binding update, can
take place parallel to the key distribution, so that a minimal number of
signaling roundtrips is achieved.
Since current authentication using a SIM module typically only produces
a key 64 bits long, the mechanism uses a set of n SIM challenges,
responses, and session keys. Thus, the generated session key can be
longer, n times 64 bits. A recommended value for n is 2.
A session key is a value K, computed from the SIM-generated n session
keys Kn, by pseudo-random function PRF(n*Kc, n*RAND | IMSI | NONCE_MT).
This way the original SIM-generated Kc keys are not exposed while using
them. Also, the client who generates a random number NONCE_MT can
know that the information leading to the generation of K was properly
replay-protected. Currently, HMAC-MD5-96 [16] and HMAC-SHA-1-96 [17]
are the suggested pseudo-random functions used. Protocol version
1 uses the former while protocol version 2 uses the latter. These
pseudo-random functions are also used in the message authentication code
(MAC) fields, as specified in Section 5.
2. Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
In addition, this document uses the following terms:
Challenge
A random number provided by the initiator to verify that
Kniveton, Malinen Expires January 2002 [Page 5]
Internet Draft SIM Authentication over AAAv6 July 2001
a message containing the returned challenge is sent by
recipient of the challenge. Randomness in the challenge
provide freshness to ensure that the returned message
cannot be replayed.
GSM Authentication
Authentication procedures in the Global System for Mobile
communications (GSM) [10].
IMSI International Mobile Subscriber Identifier, used in GSM
to identify subscribers.
EAP Extensible Authentication Protocol [19], an
authentication protocol used with PPP[14] to have a
flexible enough authentication extension for multiple
authentication methods.
SIM Subscriber Identity Module, a chip usually found in
cellular phones identifying the user to the operator and
containing credentials and algorithms for authentication.
This terminology is intended to conform to those that have been used in
IPv6, Mobile IPv6, AAA, and other Internet protocols [8, 15, 6].
3. Protocol Operation
The protocol is an application of AAAv6 where an AAAv6 Embedded Data
option contains EAP options for SIM Authentication as described in the
EAP SIM Authentication [13]. The protocol signaling is illustrated in
Figure 2.
3.1. Access Link Signaling
The access router sends a local challenge in an unsolicited or
solicited router advertisement. This is an option added to the router
advertisement when AAAv6 local attendant functionality in the access
router is enabled. A local challenge is used for replay protection in
the first request by the mobile node.
After receiving a router advertisement with a local challenge, the
mobile node returns an AAAv6 request. This contains the challenge,
together with a registration identity of the mobile node and a SIM
key request. The identity is an ID option of AAAv6. The ID contains
a Network Access Identifier (NAI) in a format user@realm where the
user part is an International Mobile Subscriber Identifier (IMSI),
and the realm part enables the AAA cloud to route the signal to the
Kniveton, Malinen Expires January 2002 [Page 6]
Internet Draft SIM Authentication over AAAv6 July 2001
authentication gateway (AGW/AAAH). A special realm GSMSIM_NAI_REALM is
used to find the first available authentication gateway.
The SIM key request is an Embedded Data option in the AAA request which
contains an EAP Response/SIM/Start. This provides a signal to the
local attendant function in the access router to propagate this request
together with the NAI to the SIM-aware authentication gateway. The SIM
key request also contains a parameter to negotiate lifetime for the
session key.
When the local attendant receives a SIM challenge (nRAND) from the
authentication gateway, it sends an AAAv6 reply back to the mobile node
with the SIM challenge embedded to an EAP Request/SIM/Challenge. The
NAI option containing the IMSI is included in the subsequent messages to
identify the authentication dialogue in progress.
When the mobile node receives the first AAAv6 reply, it invokes the SIM
algorithm with the included n random numbers (nRAND) from the message.
This generates the n SRES values and a local session key. How big n is
depends on how long key is needed. SIM authentication produces a short
key of 64 bits but an application may need a longer key.
The second AAAv6 request from the mobile node to the local attendant
then contains a hash of the generated SRES, mSRES, computed as the
MAC_SRES. This conveys the SRES values back to the authentication
gateway in a format from which an eavesdropper can not extract the
actual RAND/SRES value pairs. The AAAv6 request also contains the NAI
option.
When receiving the second AAAv6 request, the local attendant forwards
the signal to the authentication gateway which verifies the mSRES. If
correct, the local attendant will receive a key reply with a success
status and potentially with the generated session key. If incorrect,
the key reply will contain a failure status.
Finally, the local attendant sends a second AAAv6 reply, which contains
NAI and a key reply. When receiving the second AAAv6 reply, the
mobile node will know whether the SIM authentication succeeded and also
contains the chosen purpose for the generated session key.
3.2. Core Network Signaling
The local attendant will eventually use DIAMETER [6] NASREQ [5] as the
core network signaling with the authentication gateway. Meanwhile, the
core network signaling can use e.g. Radius, or directly SIM6 messages.
A proxy authentication gateway (Section 8) provides for multi-hop
core network signaling as a fallback or for interoperation. Each
Kniveton, Malinen Expires January 2002 [Page 7]
Internet Draft SIM Authentication over AAAv6 July 2001
hop can use its own protocol so that a proxy authentication gateway
translates between different core network signaling protocols, useful
for transition and migration scenarios.
Kniveton, Malinen Expires January 2002 [Page 8]
Internet Draft SIM Authentication over AAAv6 July 2001
3.3. Signaling diagram of SIM authentication over AAAv6
Below, signaling of the SIM authentication over AAAv6 and core
signaling, e.g. DIAMETER, uses key distribution from AGW in the signals
left of the AGW/AAAH while signaling with HA is optionally possible, if
key distribution to HA is requested.
Client Router System AAAL AAAH Peer
(e.g.MN) +........+ | (AGW) (e.g.HA)
| .UCP CP . | | |
| LC,aID . | | . | | |
5.1.|<--------------------| | . | | |
| . | | . | | |
| ARq#1:LC,cID,Start. | | . | | |
5.2.|-------------------->| AHR#1:aID,cID,Start | | |
| . |-------------------->| AHR#1 | |
| . | | . |------>| |
| . | | . | | |
| . | | . | AHA#1 | |
| . | AHA#1:cID,nRAND |<------| |
| ARp#1:LC,cID,nRAND. |<--------------------| | |
5.3.|<--------------------| | . | | |
GKm | . | | . | | |
| ARq#2:LC,cID,mSRES. | | . | | |
5.4.|-------------------->| | . | | |
| . | AHR#2:aID,cID,mSRES | | |
| . |-------------------->| AHR#2 | |
| . | | . |------>| |
| . | | . | | (KR) |
| . | | . | |---------->|
| . | | . | | SKn|
| . | | . | | (KR) |
| . | | . | AHA#2 |<----------|
| . | | . |<------| |
| . | AHA#2:cID,KR | | |
| . |<--------------------| | |
| . | | . | | |
| . |UPD | . | | |
| ARp#2:status,KR . |--->| . | | |
5.5.|<--------------------| | . | | |
| . | | . | | |
+........+
Figure 2: Signaling of SIM Authentication EAP extension over AAAv6
and core network AAA signaling
Kniveton, Malinen Expires January 2002 [Page 9]
Internet Draft SIM Authentication over AAAv6 July 2001
Acronyms:
AHR#n - AAA Client Request (using an AAA protocol) number n
AHA#n - AAA Client Answer (using an AAA protocol) number n
aID - Attendant Identifier (IPv6 source address)
ARq#n - AAAv6 Request number n
ARp#n - AAAv6 Reply number n
MN - Mobile IPv6 Mobile Node [15]
AAAL - Local AAA Server [2]
AGW/AAAH - Authentication Gateway/AAA Home Server [2]
HA - Mobile IPv6 Home Agent [15]
CN - Mobile IPv6 Correspondent Node [15]
CP - Controlled part of a router system [2]
RTSOL - ICMPv6 Router Solicitation [18]
LC - Local Challenge [2]
cID - Client (MN) Network Access Identifier [1]
CR - Credentials (EAP/SIM Start) [2]
nRAND - EAP/SIM Challenge [13]
mSRES - EAP/SIM Response [13]
Start - EAP/SIM Start [13]
status - Returned status of authorization [2]
KR - AAAv6 Key Reply [2]
GKm - Generate locally MN instance of session key from SIM
SKn - Store the received network instance of the session key
UCP - Uncontrolled part of a router system [2]
UPD - Update controlled part of a router system with session
key
4. New requirements for IPv6 Nodes
Functionality introduced by SIM6 affect the mobile node, attendant, and
authentication gateway. They need to understand the EAP extensions
to AAAv6 and how to pass them over the access link and core network
protocols. AAAv6 requires two new subtypes of the Embedded Data
extension. The core network protocol, e.g. DIAMETER need to be able
to pass an identifier together with the key material in its messages.
The key material is passed either in the EAP messages or in a key reply
extension.
4.1. Mobile node requirements
The mobile node is required to have an extension to its router discovery
understanding the local challenge, and an extension to AAAv6 signaling
which recognizes the SIM6 EAP types and protocol stages. Mobile node
maintains an autentication session context state.
Kniveton, Malinen Expires January 2002 [Page 10]
Internet Draft SIM Authentication over AAAv6 July 2001
4.2. Attendant requirements
The attendant is required to be able to extend a local challenge to
the router advertisement. The attendant needs no specific knowledge
of the EAP data passed through it, however, the capacity to forward
EAP embedded data options is needed. The attendant maintains an
authentication session context state for each mobile node as well as a
most recently sent local challenge cache for replay protection.
4.3. Authentication Gateway requirements
The authentication gateway is required to understand the EAP extension
and key reply extension to the core network protocol. It maintains an
authetication session context state for each mobile node and is able to
query the RAND, SRES, and session key elements for a received IMSI from
a local authorization database, from the GSM network, or from another
authentication gateway.
5. Protocol Messages
This section shows the messages exchanged in a SIM6 authentication
procedure. The messages are shown in their entirety with references
to the documents describing the components. Section numbers for the
messages are also shown in Figure 2.
The messages shown are generic AAAv6 [2] (i.e. special ICMPv6 [7])
messages, and as such could be contained in Radius [11] messages, or
could be sent over a secure channel as simple ICMPv6 packets. Access
link can use non-secure channels, but with plain ICMPv6 packets, a
secure communication channel is assumed from LA to AGW.
5.1. Router Advertisement / AAAv6 local challenge
When the mobile node arrives at the visited network, it receives
a router advertisement as specified by Neighbor Discovery [18] and
modified by Mobile IPv6 [15] from the local router. This router
advertisement contains a ``challenge,'' which is essentially a random
number used as a nonce for replay protection.
The entire message appears as follows:
{1} IPv6 Header [8]
{2} Router Advertisement [8, 15]
{3} Router Advertisement Options
Kniveton, Malinen Expires January 2002 [Page 11]
Internet Draft SIM Authentication over AAAv6 July 2001
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| |
| IPv6 Header... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H| Reserved| Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retrans Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Router Advertisement Options |
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Router Advertisement / AAAv6 local challenge
May include Target Link-layer address, Prefix Information Options,...
{4} AAAv6 Challenge Option in the router advertisement
This additional option is the only change from the normal
router advertisements the access router/AAAv6 Attendant would
already be sending.
Type
9 = ICMPv6 Router Advertisement Local Challenge Option
Length
1 = Length in 8 octets including the type and length fields
Reserved
0 = Ignored on reception
Kniveton, Malinen Expires January 2002 [Page 12]
Internet Draft SIM Authentication over AAAv6 July 2001
Challenge
This is a 32-bit random number generated by the access router
and used to prevent replay attacks.
Kniveton, Malinen Expires January 2002 [Page 13]
Internet Draft SIM Authentication over AAAv6 July 2001
5.2. AAAv6 request/EAP response/SIM/Start
This section describes the message the mobile node sends to initiate the
SIM authentication procedure.
This message is a AAAv6 request containing an embedded data option,
which is an EAP response packet. This EAP packet is a ``response''
because this SIM authentication procedure is extracted from a larger
Kniveton, Malinen Expires January 2002 [Page 14]
Internet Draft SIM Authentication over AAAv6 July 2001
message flow which would include the PPP-EAP signaling sending an
earlier message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| |
| IPv6 Header... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{5}| Type |WH |Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5b}| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Version | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime Proposal |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| NONCE_MT |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer NAI (optional)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: AAAv6 request/EAP response/SIM/Start
{1} IPv6 Header
SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6)
{2} ICMPv6 Header [7]
Kniveton, Malinen Expires January 2002 [Page 15]
Internet Draft SIM Authentication over AAAv6 July 2001
Type
151 (97h) [TBD] = AAAv6 Request
Code
0 - For AAA request, not defined
Checksum
Calculated as defined in [7].
{3} AAA Client Identifier Option [2]
Type
1 (unskippable) = Client Identifier Option.
Subtype
0 = NAI
Length
Length of Identifier (NAI) in octets.
Identifier
The NAI [1] is constructed using the GSM's assigned IMSI and a
special realm as specified in Section 3.2 of [12].
{4} AAAv6 Challenge Option [2]
Type
3 (unskippable) = Challenge option.
Subtype
0 = Local Challenge
Length
4 = Length of the challenge in octets.
Challenge
The actual challenge data, as picked from the router
advertisement (Section 5.1).
Kniveton, Malinen Expires January 2002 [Page 16]
Internet Draft SIM Authentication over AAAv6 July 2001
{5} AAAv6 Embedded Data Option [2]
Type
8 (unskippable) = Embedded Data Option
WH
binary 10 = AAAH
Subtype
3 = EAP Response
Length
28 (+ size of Peer NAI) = Length of Embedded Data {5b} in
octets.
{5b} EAP-Response/SIM/Start [13]
Embedded in the AAAv6 option above is the EAP packet signifying the
start of the SIM authentication procedure.
Code
2 = Response
Identifier
0 - The identifier field is one octet and aids in matching
responses with requests [3], not used here.
Length
28 (+ size of Peer NAI) = Length of the whole EAP extension in
octets.
Type
18 = EAP type for EAP/SIM authentication.
Subtype
1 = SIM/Start.
Version
1 = The EAP/SIM protocol version.
Kniveton, Malinen Expires January 2002 [Page 17]
Internet Draft SIM Authentication over AAAv6 July 2001
Reason
bitmask: 001 (Client-Attendant authentication), 010
(Client-Attendant encryption) , 100 (MN-HA authentication) , or
any combination thereof, depending on the scope desired for the
session key provided by SIM authentication. (see [13]).
Key Lifetime Proposal
Client's key lifetime proposal in seconds (four bytes).
NONCE_MT
A random number generated by the client (16 bytes), which is
used as a seed value for the new key.
Peer NAI
This optional field can be used to describe service to
authorize. When the authentication gateway receives this
field, it sends two key replies, one without the key towards
the client, and another with the key, towards the peer node
where realm of the Peer NAI encodes routing of the key reply to
the peer node over the core signaling protocol.
Kniveton, Malinen Expires January 2002 [Page 18]
Internet Draft SIM Authentication over AAAv6 July 2001
5.3. AAAv6 reply/EAP request/SIM/Challenge
This message is the SIM authentication challenge providing n random
numbers to the mobile node, protected by message authentication code.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| |
| IPv6 Header... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{5}| Type |WH |Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5b}| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC_RAND |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n*RAND ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AAAv6 reply/EAP request/SIM/Challenge
{1} IPv6 Header
SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6)
{2} ICMPv6 Header [7]
Kniveton, Malinen Expires January 2002 [Page 19]
Internet Draft SIM Authentication over AAAv6 July 2001
Type
153 (99h) [TBD] = AAAv6 Reply
{3} AAA Client Identifier Option
See Section 5.2.
{4} AAAv6 Challenge Option [2]
Type
3 (unskippable) = Challenge option.
Subtype
0 = Local Challenge
Length
4 = Length of the challenge in octets.
Challenge
The actual challenge data, randomized in the router from the
same generator as for router advertisement (Section 5.1).
{5} AAAv6 Embedded Data Option
Type
8 = Embedded Data Option
WH
binary 00 = Recipient of AAA Protocol message (client or
attendant) should process embedded data.
Subtype
2 = EAP Request
Length
60 (3ch) = Length of Embedded Data {4b} in octets.
{5b} EAP-Request/SIM/Challenge [13]
Kniveton, Malinen Expires January 2002 [Page 20]
Internet Draft SIM Authentication over AAAv6 July 2001
Code
1 = Request
Identifier
The identifier field is one octet and aids in matching
responses with requests [3].
Length
28 + n*16 octets, where n is the number of RAND challenges
given in this EAP Request, now 60.
Type
18 = EAP type for EAP/SIM authentication.
Subtype
2 = SIM/Challenge.
Version
1 = the EAP/SIM protocol version.
Lifetime
Remaining key lifetime in seconds (4 bytes), decided by the
AAA Server. The AAA Server may, but it doesn't have to, take
into account the client's key lifetime proposal from EAP-
Response/GSMSIM/Start. The key lifetime must be greater than
zero.
MAC_RAND
A message authentication code for n*RAND and Key
Lifetime, defined by a pseudo-random function
PRF(n*Kc, n*RAND | NONCE_MT | Lifetime) [13], 16 octets, where
n*Kc are the n session keys.
N*RAND
N GSM RANDs (16 bytes each), now n=2, 32 octets.
Kniveton, Malinen Expires January 2002 [Page 21]
Internet Draft SIM Authentication over AAAv6 July 2001
5.4. AAAv6 request/EAP response/SIM/Challenge
This message is a response to the SIM authentication challenge. Naming
both as SIM/Challenge follows the convention of EAP to give same name to
a request and its response. The response MAC_SRES is provided as a hash
of the responses produced by the SIM module so the original responses
are not explicit in the message. AGW can still take the same hash to
check validity of the response.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| |
| IPv6 Header... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Challenge |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{5}| Type |WH |Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5b}| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Subtype | Version | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| MAC_SRES |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: AAAv6 request/EAP response/SIM/Challenge
{1} IPv6 Header
SRC = mobile node; DEST = AAAv6 Attendant; NxtHDR = 58 (ICMPv6)
{2} ICMPv6 Header [7]
Kniveton, Malinen Expires January 2002 [Page 22]
Internet Draft SIM Authentication over AAAv6 July 2001
Type
151 (97h) [TBD] = AAAv6 Request
{3} AAA Client Identifier Option
See Section 5.2.
{4} AAAv6 Challenge Option [2]
Type
3 (unskippable) = Challenge option.
Subtype
0 = Local Challenge
Length
4 = Length of the challenge in octets.
Challenge
The actual challenge data, as received in the first AAAv6 reply
(Section 5.3).
{5} AAAv6 Embedded Data Option
Type
8 = Embedded Data Option
WH
binary 10 = AAAH should process embedded data.
Subtype
3 = EAP Response
Length
24 (18h) = Length of Embedded Data {4b} in octets.
{5b} EAP-Response/SIM/Challenge [13]
Kniveton, Malinen Expires January 2002 [Page 23]
Internet Draft SIM Authentication over AAAv6 July 2001
Code
2 = Response
Identifier
The identifier field is one octet and aids in matching
responses with requests [3].
Length
24 = Length of the whole EAP extension in octets.
Type
18 = EAP type for EAP/SIM authentication.
Subtype
2 = SIM/Challenge.
Version
1 = the EAP/SIM protocol version.
MAC_SRES
The response calculated by the client defined by a
pseudo-random function PRF(n*Kc, n*SRES | IMSI | NONCE_MT) [13],
16 octets, where n*Kc are the n session keys, n*SRES the n
system responses obtained from the SIM card in the mobile node,
IMSI its identifier, and NONCE_MT the nonce randomized by the
mobile node.
Kniveton, Malinen Expires January 2002 [Page 24]
Internet Draft SIM Authentication over AAAv6 July 2001
5.5. AAAv6 reply with key SPI
This message originates at the authentication gateway, but the AAA
Attendant removes and keeps any key info distributed with this message.
When this message arrives at the mobile node, it is used to indicate the
success or failure of the SIM authentication session (for the indicated
NAI), and the SPI which should be used in the mobile node's SPD. No
session key is carried over the last hop since the mobile node already
has the session key, generated locally by the SIM algorithm. AAAv6 key
reply option thus has no key field, it only conveys the status to the
mobile node.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{1}| |
| IPv6 Header... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{2}| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{3}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
{4}| Type | Subtype | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AAAH SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key SPI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: AAAv6 reply with key SPI
{1} IPv6 Header
SRC = AAAv6 Attendant; DEST = mobile node; NxtHDR = 58 (ICMPv6)
{2} ICMPv6 Header [7]
Type
153 (99h) [TBD] = AAAv6 Reply
Kniveton, Malinen Expires January 2002 [Page 25]
Internet Draft SIM Authentication over AAAv6 July 2001
Code
Indicates success or failure of the protocol as specified
in [2], Section 7.2. Currently, the following diagnostic
states are used.
SUCCESS: 0 - Authorization succeeded
INVALID_CREDENTIAL: 50 - Bad MAC_SRES
Checksum
Calculated as defined in [7].
{3} AAA Client Identifier Option
See Section 5.2.
{4} AAA Generalized Key Reply Option [2]
Type
4 (unskippable) = Generalized Key Reply Option.
Subtype
Depending on the scope of the key established, this field will
contain a bitmask value; see Section 5.2, message part 5b,
Reason codes.
Length
12 = Length of the option in octets except the first four
octets.
Lifetime
This is the key lifetime passed in the key reply back to the
cmobile node as well as to the receiver of the network instance
of the session key.
AAAH SPI
Not used. Ignored by mobile node.
Key SPI
This field indicates the security association between the
mobile node and AAAH which should be used by the client to
interpret the generated key.
Kniveton, Malinen Expires January 2002 [Page 26]
Internet Draft SIM Authentication over AAAv6 July 2001
Note that the Encoded Key field is not sent with this message, as the
key has already been generated at the mobile node.
6. Local Attendant Operation
The attendant modifies its router advertisement. Further, it is
involved in two message exchanges with the mobile node where it first
receives an AAAv6 request and then replies with an AAAv6 reply.
6.1. Sending Local Challenge to the Mobile Node
The attendant randomizes a local challenge as a value extracted
from a good random generator. It then attaches that to each router
advertisement and stores the sent local challenge. The attendant
SHOULD maintain a local challenge cache of three recently advertised
challenges.
When the local challenge cache has reached its size three first router
advertisements after initialization, the attendant starts to delete
oldest challenges together with their associated state from the local
challenge cache each time a new challenge is stored.
6.2. Receiving SIM/Start from the Mobile Node
When the attendant receives an AAAv6 request from the mobile node
containing a SIM/Start EAP object, it does the following. First, the
attendant creates an AAAv6 context where it stores the identifier of
the mobile node as well as the local challenge. Then it compares the
received challenge against those in the set of recently sent challenges
to see if a mobile node already has used the challenge.
If the challenge is not found or has already been used by the mobile
node, the attendant silently drops the packet and deletes the context,
to counter a possible replay attack. If the challenge was found and
still unused for this mobile node, the attendant marks the challenge as
used and proceeds.
The attendant then creates and attaches to the per-mobile node AAAv6
context a per-mobile node SIM6 context where it stores the following
items: version of the protocol, key lifetime proposal, reason for the
key exchange, and the NONCE_MT created by the mobile node.
If all the needed data elements were present in the message received,
the attendant forwards the identifier and credentials of the mobile node
towards an AGW. This AGW MAY be chosen from a priority list of AGWs,
keyed by the realm part of the identifier. Configuration of this list
Kniveton, Malinen Expires January 2002 [Page 27]
Internet Draft SIM Authentication over AAAv6 July 2001
is out of scope of the protocol, but may represent administratively
configured cross-domain trust relationships, e.g. roaming agreements.
The credentials in the message include elements in the EAP object. The
core protocol SHOULD carry the unmodified EAP object, associated with
the identifier, to the AGW.
The attendant then waits for a reply from the AGW for SIM6_TIMEOUT_AGW
seconds. If no reply is received in time, or an error is received,
the attendant deletes the context for the mobile node. In case of
failure, prior to deleting the context, the attendant SHOULD try to
repeat sending the message SIM6_MAX_RETRIES times. It MAY repeat this
for each member in the priority list of AGWs. In case a lower-priority
AGW replies, its priority on the list MAY be temporarily elevated above
those of the failed AGWs.
If the attendant receives a reply containing nRAND for the mobile node,
it sends a SIM/Challenge to the mobile node.
6.3. Sending SIM/Challenge to the Mobile Node
After receiving the nRAND from AGW, the attendant searches for the
mobile node's context based on the identifier received from the AGW. If
no context is found, the packet is discarded.
In case a context was found, the attendant creates a SIM/Challenge EAP
packet and sends it to the mobile node in an AAAv6 reply. The AAAv6
reply first contains the identifier, then a fresh local challenge, after
which it contains the EAP object with the nRAND and the key lifetime
decided by the authorizing AGW. The EAP object is protected by the
MAC_RAND field which covers the nRAND, the NONCE_MT in the mobile node's
context, and the lifetime. The core protocol SHOULD get this EAP object
unmodified, together with the identifier, from the AGW.
The attendant sets a timer SIM6_TIMEOUT_MOBILE for the mobile node's
context in expectation of a second AAAv6 request with SIM/Challenge
back from the mobile node. If no request is received in time, the
mobile node's context is deleted. In case of failure, prior to deleting
the context, the attendant SHOULD try repeat sending the message
SIM6_MAX_RETRIES times.
6.4. Receiving SIM/Challenge from the Mobile Node
After receiving the second AAAv6 request with a SIM/Challenge from the
mobile node, the attendant checks validity of the local challenge the
same way as when receiving a SIM/Start. Then, the attendant searches
Kniveton, Malinen Expires January 2002 [Page 28]
Internet Draft SIM Authentication over AAAv6 July 2001
for the mobile node's context based on the identifier received from the
mobile node. If no context is found, the packet is discarded.
In case a context was found, the attendant creates a message to the AGW
where it inserts the identifier and the information received in the EAP
object.
The attendant then waits for a reply from the AGW for SIM6_TIMEOUT_AGW
seconds. If no reply is received in time, or an error is received,
the attendant deletes the context for the mobile node. In case of
failure, prior to deleting the context, the attendant SHOULD try repeat
sending the message to the AGW SIM6_MAX_RETRIES times. If the attendant
receives a message containing a key reply for the mobile node, it sends
an AAAv6 Key Reply to the mobile node.
In case the generic key reply also contained a session key for access
link authentication or encryption, the attendant extracts this key and
stores it to its security database.
6.5. Sending Key Reply to the Mobile Node
The attendant finally sends an AAAv6 reply containing a Key Reply back
to the mobile node inserting the success status into the Code ICMPv6
field, and the key SPI to the key field, as received from the AGW. After
this, the authentication session is completed and the mobile node's
context is deleted.
7. Mobile Node Operation
The mobile node receives a modified router advertisement from a SIM6
capable access router. Then it is involved in two message exchanges
with the attendant and AGW where it first sends an AAAv6 request and
then receives an AAAv6 reply.
7.1. Receiving Local Challenge from the Attendant
When the randomized local challenge is recognized in a router
advertisement, the mobile node recognizes that the router supports
the local attendant functionality. The mobile node can then at any
suitable time start a SIM6 authentication procedure, e.g. when network
access authorization is needed. Recognition when such a need exists is
out of scope of this document, but this may be triggered e.g. by some
capability flag in the router advertisement combined with mobile node's
internal state.
Kniveton, Malinen Expires January 2002 [Page 29]
Internet Draft SIM Authentication over AAAv6 July 2001
7.2. Sending SIM/Start to the Attendant
When the mobile node starts a SIM6 authentication procedure, it creates
a SIM6 context into which it extracts its IMSI from the SIM card
hardware as a user part of a NAI identifier. The mobile node then
gets an administratively configured realm part for the NAI by which an
AGW, which understands the IMSI, can be reached. The mobile node then
adds to the context a reason for the session key requested, a lifetime
suggestion for it, and a NONCE_MT from a good random source.
The mobile node then creates a SIM/Start EAP packet and sends it to the
attendant in an AAAv6 request. The AAAv6 request first contains the
returned local challenge, the identifier, and the EAP object with the
key lifetime proposal and the NONCE_MT.
The mobile then sets a timer SIM6_TIMEOUT_MOBILE for the context in
expectation of the first AAAv6 reply with SIM/Challenge back from
the attendant. If no request is received in time, the mobile node's
context is deleted and the authentication is considered failed.
Prior to deleting the context, the mobile node SHOULD try repeat the
authentication SIM6_MAX_RETRIES times starting from the beginning of the
procedure, that is, resetting the context, except an increased failure
count, and sending a SIM/Start.
In the repeated attempts, a new local challenge MUST be obtained every
time. If the router advertisement frequency is too low, a router
solicitation SHOULD be issued prior to every repeated attempt.
7.3. Receiving SIM/Challenge from the Attendant
After receiving the first AAAv6 reply with a SIM/Challenge from the
attendant, the mobile node stores the local challenge just like when
receiving a router advertisement with such a challenge.
Then, the mobile node searches for the contex based on the identifier
received in the message from the attendant. If no context is found, the
packet is discarded.
If the context was found, the mobile node extracts the n RANDs from the
received message, and applies these to the SIM hardware. It then stores
the n session keys and SRES responses to n triplets into the context.
7.4. Sending SIM/Challenge to the Attendant
The mobile node then creates a SIM/Challenge EAP packet and sends it to
the attendant in an AAAv6 request. The AAAv6 request first contains
Kniveton, Malinen Expires January 2002 [Page 30]
Internet Draft SIM Authentication over AAAv6 July 2001
the identifier, after which it contains the previously stored local
challenge, and then the EAP object with the MAC_SRES.
The mobile then sets a timer SIM6_TIMEOUT_MOBILE for the context in
expectation of the Key Reply back from the attendant. If no message
is received in time, the mobile node's context is deleted and the
authentication is considered failed. Prior to deleting the context, the
mobile node SHOULD try repeat the authentication SIM6_MAX_RETRIES times
starting from the beginning of the procedure, that is, resetting the
context, except an increased failure count, and sending a SIM/Start.
7.5. Receiving Key Reply from the Attendant
When receiving a key reply from the attendant, the mobile node searches
for the contex based on the identifier received in the message from
the attendant. If no context is found, the packet is discarded.
Also, if the status received in the ICMPv6 Code field is other than
AAAV6_STATUS_SUCCESS, the authentication is considered failed.
In case of failure, prior to deleting the context, the mobile node
SHOULD try repeat the authentication SIM6_MAX_RETRIES times starting
from the beginning of the procedure, that is, resetting the context,
except an increased failure count, and sending a SIM/Start.
8. Authentication Gateway Operation
The Authentication Gateway (AGW) is considered a proxy AGW if it
communicates with another AGW, otherwise it is considered an authorizing
AGW. The latter may communicate with an AAAH in the GSM network, or
locally authorize the session making it also an AAAH.
The AGW is involved in two message exchanges with the mobile node via
the attendant. The AGW first receives a request message and then
responds with a reply message.
8.1. Receiving SIM/Start from the mobile node via the Attendant
When the AGW receives a message from the mobile node via the attendant
containing a SIM/Start EAP object, it does the following. First, the
AGW creates a per-mobile node context where it stores the IP address
from which the message was received, the identifier of the mobile node,
version of the protocol, key lifetime proposal, reason for the key
exchange, and the NONCE_MT created by the mobile node.
If all the needed data elements were present in the message received,
the authorizing AGW requests n triplets for the given IMSI from the
Kniveton, Malinen Expires January 2002 [Page 31]
Internet Draft SIM Authentication over AAAv6 July 2001
GSM network or from a local database. If the triplets are succesfully
received, the authorizing AGW stores them to the mobile node's context
and sends a message with a SIM/Challenge to the mobile node.
If all the needed data elements were present in the message received,
the proxy AGW forwards the mobile node's identifier and credentials
towards another AGW. This AGW MAY be chosen from a priority list of
next level AGWs. Configuration of this list is out of scope of the
protocol, but may represent administratively configured cross-domain
trust relationships, e.g. roaming agreements.
The credentials in the message include elements in the EAP object. The
core protocol SHOULD carry the unmodified EAP object, associated with
the identifier, to the next level AGW.
The proxy AGW then waits for a reply from the AGW for SIM6_TIMEOUT_AGW
seconds. If no reply is received in time, or an error is received, the
proxy AGW deletes the context for the mobile node. In case of failure,
prior to deleting the context, the proxy AGW SHOULD try repeat sending
the message SIM6_MAX_RETRIES times. It MAY repeat this for each member
in the priority list of next level AGWs. In case a lower-priority
next-level AGW replies, its priority on the list MAY be temporarily
elevated above those of the failed next-level AGWs.
If the proxy AGW receives a reply containing nRAND for the mobile node,
it sends a SIM/Challenge to the mobile node.
8.2. Sending SIM/Challenge to the mobile node via the Attendant
First, the AGW creates a message with the identifier and a SIM/Challenge
EAP packet. The AGW then sends it to the mobile node via the node whose
IP address was stored to the context as sender of the request message
with SIM/Start.
The created message first contains the identifier, after which it
contains the EAP object with the nRAND and the key lifetime decided by
the AGW as a function of the key lifetime proposal received from the
mobile node. The EAP object is protected by the MAC_RAND field which
covers the nRAND, the NONCE_MT in the mobile node's context, and the
lifetime.
The AGW sets a timer SIM6_TIMEOUT_AGW for the mobile node's context in
expectation of a second message with SIM/Challenge back from the mobile
node. If no request is received in time, the mobile node's context is
deleted.
Kniveton, Malinen Expires January 2002 [Page 32]
Internet Draft SIM Authentication over AAAv6 July 2001
8.3. Receiving SIM/Challenge from the mobile node via the Attendant
After receiving the second request message with a SIM/Challenge from the
mobile node via the attendant, the AGW searches for the mobile node's
context based on user part of the identifier (NAI) received from the
mobile node. If no context is found, the packet is discarded.
The authorizing AGW then calculates the MAC_SRES locally based on the
n session keys, SRES values, IMSI, and NONCE_MT, found in the mobile
node's context. If the computed PRF-value matches that of the one
received in the EAP object, a success status is stored to the context,
otherwise, an invalid-credentials status is stored.
A proxy AGW then forwards identifier of the mobile node together with
its credentials towards another AGW. This AGW MAY be chosen from a
priority list of next level AGWs. Configuration of this list is out of
scope of the protocol, but may represent administratively configured
cross-domain trust relationships, e.g. roaming agreements.
The credentials in the message include elements in the EAP object. The
core protocol SHOULD carry the unmodified EAP object, associated with
the identifier, to the next level AGW.
The proxy AGW then waits for a reply from the AGW for SIM6_TIMEOUT_AGW
seconds. If no reply is received in time, or an error is received, the
proxy AGW deletes the context for the mobile node. In case of failure,
prior to deleting the context, the proxy AGW SHOULD try repeat sending
the message SIM6_MAX_RETRIES times. It MAY repeat this for each member
in the priority list of next level AGWs. In case a lower-priority
next-level AGW replies, its priority on the list MAY be temporarily
elevated above those of the failed next-level AGWs.
8.4. Sending Key Reply to the mobile node via the Attendant
The authorizing AGW finally sends a generic key reply back to the mobile
node via the attendant inserting the success status into the message.
After this, the authentication session is completed and the mobile
node's context may be deleted.
In case the mobile node's context also contained a reason for sending
a key to the attendant, this key is added to the message as well as a
generated key SPI.
The proxy AGW propagates a key reply towards the IP address in the
context. Finally, the context SHOULD be deleted after 2*TIMEOUT_AGW
seconds.
Kniveton, Malinen Expires January 2002 [Page 33]
Internet Draft SIM Authentication over AAAv6 July 2001
9. Applications of SIM Authentication over AAAv6
Applications of SIM Authentication use the Reason Subtypes of the SIM
Start and AAAv6 Key Reply extensions. Numbering of differen reasons
is such that any combination of reasons can be indicated in a single
extension. This enables distribution of the same session key for
multiple purposes with one authorization message exchange.
9.1. SIM Authentication for Network Access
When using Reason Subtype 1 or 2, SIM Authentication distributes
a session key for the access router to be used either for access
authentication or access link encryption.
9.2. SIM Authentication for Services
When using Reason Subtype 4, SIM Authentication distributes a session
key to a peer. This signaling will make AGW/AAAH to distribute the
network copy of the session key to the host and service identified in
the Peer NAI. An example service would be authentication of Mobile IPv6
Home Registration.
A service MAY be identified in a Peer NAI in a SIM Start option. The
NAI encodes location of the peer node in the realm part, and the service
in the user part. An example encoding would be ``HA@host.domain.com''
for identifying mobile-home security association creation to home agent
at DNS name host.domain.com.
Another example could be ``unlock@door101.company.com'' for providing
authorization and a session key to securely use service ``unlock'' at
host identified by DNS name door101.company.com. This way, only a light
IPv6 protocol stack with ICMPv6 but without upper layers is needed
e.g. in control devices implementing only a simple application such as
opening and closing of a lock.
When an authentication gateway sends a key reply message to the peer
node, this key reply message contains the peer identifier option
with the NAI, and the peer MUST respond to this key reply with a
key acknowledgement. The authentication gateway MUST delay sending
of the key reply towards the mobile node until it receives the key
acknowledgement. The format and protection of the key reply and key
acknowledgement are provided by the core network signaling protocol.
With direct ICMPv6 messaging as the core network signaling, the key
reply is an AAAv6 request message with an identifier and a key reply
option. The identifier contains the Peer NAI sent by the mobile node.
The key reply contains the encoded session key in a key field.
Kniveton, Malinen Expires January 2002 [Page 34]
Internet Draft SIM Authentication over AAAv6 July 2001
The acknowledgement is an empty key reply back to the authentication
gateway with the success status encoded into this message. The format
is the same as in key reply specified in Section 5.5. The identifier
for the acknowledgement would have a NAI encoding as in the Peer NAI.
The acknowledgement could either get back to the AGW relying on IPv6
address stored in peer attendant or proxy AGW states, or alternatively,
by using NAI-based routing back where the realm part would be one
routing the packet back to the authorizing AGW.
In the latter case, the acknowledgement routing would be more robust
while not relying on session state in intermediate nodes. An example
acknowledgement encoding could be ``user_peer%realm_peer@realm_AGW'',
e.g. for the second example ``unlock%door101.company.com@AGW.domain.com''.
Interpretation of this key reply is: door101 acknowledges to
authorizing AGW that the authorization was received with success and
door101 requests AGW to forward an ack to the requesting MN. Hence,
this is a generalization of MN-HA temporary key push for an arbitrary
NAI-encoded service.
Revocation of services can be achieved from the authorizing AGW by
sending the acknowledgement as in Section 5.5 any time to both the peer
and the mobile node, with code AAAV6_INVALID_CREDENTIALS. The peer
can also initiate revocation by sending this message to the mobile
node via the authorizing AGW. The authorizer would either forward the
peer-initiated revocation, or block it, depending on authorizing policy.
The NAI encodings for the above messages would follow the rules above.
The realm part of the NAI in a key reply MUST be the realm of the
destination for it.
10. Protocol Constants
The protocol uses the following constants
SIM6_MAX_RETRIES
6 = maximum number of retries in case of various fault cases.
SIM6_TIMEOUT_AGW
4 = timeout in seconds for core signaling problems.
SIM6_TIMEOUT_MOBILE
2 = timeout in seconds for access link signaling problems.
Kniveton, Malinen Expires January 2002 [Page 35]
Internet Draft SIM Authentication over AAAv6 July 2001
11. Security Considerations
The presented extension does not weaken the security provided by AAAv6
and cellular SIM authentication. The presented extension uses existing
protocols so much that its security characteristics are directly
inherited from those protocols.
Secret algorithm or permanent key material for SIM authentication does
not get distributed to the IP network. AGW controlled by an operator is
assumed to have trust relationship with the authorizing operators via
roaming agreements.
12. IPv4 Considerations
This protocol applies to IPv4 by simply reserving two ICMP types and
replicating the protocol as is on IPv4. A specification for local
challenges in IPv4 router advertisements exist among AAA proposals.
13. Intellectual Property Right Considerations
On IPR related issues, Nokia refers to its statement on patent
licensing. Please see http://www.ietf.org/ietf/IPR/NOKIA.
14. Acknowledgements
Authors of the document would like to thank N. Asokan and Henry
Haverinen, for their contributions to the ideas used in this draft, as
well as Jarno Rajahalme and Vijay Devarapalli for comments.
References
[1] B. Aboba and M. Beadles. The Network Access Identifier.
Request for Comments (Proposed Standard) 2486, Internet
Engineering Task Force, January 1999.
[2] N. Asokan, Patrik Flykt, C. Perkins, and Thomas Eklund. AAA
for IPv6 Network Access (work in progress). Internet Draft,
Internet Engineering Task Force, March 2000.
[3] L. Blunk and J. Vollbrecht. PPP Extensible Authentication
Protocol (EAP). Request for Comments (Proposed Standard) 2284,
Internet Engineering Task Force, March 1998.
Kniveton, Malinen Expires January 2002 [Page 36]
Internet Draft SIM Authentication over AAAv6 July 2001
[4] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997.
[5] P. Calhoun, W. Bulley, A. Rubens, and J. Haag. DIAMETER
NASREQ extensions (work in progress). Internet Draft, Internet
Engineering Task Force, December 1999.
[6] P. Calhoun, A. Rubens, H. Akhtar, and E. Guttman. DIAMETER
base protocol (work in progress). Internet Draft, Internet
Engineering Task Force, December 1999.
[7] A. Conta and S. Deering. Internet Control Message Protocol
(ICMPv6) for the Internet protocol version 6 (ipv6)
specification. Request for Comments (Draft Standard) 2463,
Internet Engineering Task Force, December 1998.
[8] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6)
Specification. Request for Comments (Draft Standard) 2460,
Internet Engineering Task Force, December 1998.
[9] GSM Technical Specification GSM 03.03 (ETS 300 523). Digital
cellular telecommunication system (Phase 2); Numbering,
addressing and identification. Technical report, European
Telecommunications Standards Institute, April 1997.
[10] GSM Technical Specification GSM 03.03 (ETS 300 534). Digital
cellular telecommunication system (Phase 2); Security,
related network functions. Technical report, European
Telecommunications Standards Institute, August 1997.
[11] T. Hastings and C. Manros. Internet Printing Protocol/1.0:
Implementer's Guide. Request for Comments (Informational) 2639,
Internet Engineering Task Force, July 1999.
[12] H. Haverinen. GSM SIM Authentication and Key Generation
for Mobile IP (work in progress). Internet Draft, Internet
Engineering Task Force, November 2000.
[13] H. Haverinen. EAP SIM Authentication (Version 1) (work in
progress). Internet Draft, Internet Engineering Task Force,
February 2001.
[14] R. Hinden, R. Fink, and J. Postel deceased). IPv6 Testing
Address Allocation. Request for Comments (Experimental) 2471,
Internet Engineering Task Force, December 1998.
Kniveton, Malinen Expires January 2002 [Page 37]
Internet Draft SIM Authentication over AAAv6 July 2001
[15] D. Johnson and C. Perkins. Mobility support in IPv6 (work in
progress). Internet Draft, Internet Engineering Task Force,
November 1998.
[16] C. Madson and R. Glenn. The Use of HMAC-MD5-96 within ESP and
AH. Request for Comments (Proposed Standard) 2403, Internet
Engineering Task Force, November 1998.
[17] C. Madson and R. Glenn. The Use of HMAC-SHA-1-96 within ESP and
AH. Request for Comments (Proposed Standard) 2404, Internet
Engineering Task Force, November 1998.
[18] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for
IP Version 6 (ipv6). Request for Comments (Draft Standard)
2461, Internet Engineering Task Force, December 1998.
[19] J. Vollbrecht and L. Blunk. PPP extensible authentication
protocol (EAP) (work in progress). Internet Draft, Internet
Engineering Task Force, January 1998.
Authors' Addresses
Timothy J. Kniveton Jari T. Malinen
Communications Systems Lab Communications Systems Lab
Nokia Research Center Nokia Research Center
313 Fairchild Drive 313 Fairchild Drive
Mountain View, California 94043 Mountain View, California 94043
USA USA
Phone: +1-650 625-2025 Phone: +1-650 625-2355
EMail: Timothy.Kniveton@Nokia.com EMail: jmalinen@iprg.nokia.com
Fax: +1 650 625-2502 Fax: +1 650 625-2502
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations,
Kniveton, Malinen Expires January 2002 [Page 38]
Internet Draft SIM Authentication over AAAv6 July 2001
except as needed for the purpose of developing Internet standards
in which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
Kniveton, Malinen Expires January 2002 [Page 39]