Internet DRAFT - draft-hiller-aaa-diamaka
draft-hiller-aaa-diamaka
Authentication, Authorization, and Accounting Tom Hiller
Internet Draft Peter J. McCann
Document: draft-hiller-aaa-diamaka-00.txt Lucent Technologies
Category: Informational February, 2001
DIAMETER Support for Authentication and Key Agreement (AKA)
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
1. Abstract
The Authentication and Key Agreement (AKA) protocol is a widely
used mechanism for authenticating mobile nodes in wireless
networks. This draft proposes new DIAMETER AVPs to carry AKA
parameters, which will enable DIAMETER to serve as an inter-domain
transport mechanism for AKA messages.
Because AKA was designed for a slightly different trust
environment than that likely to be encountered in a DIAMETER-based
network, we also discuss how AKA can be deployed in a DIAMETER
environment to provide additional authenticity guarantees.
2. Conventions used in this document
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 [2].
Hiller, McCann Informational - Expires 8/2001 1
DIAMETER AKA February, 2001
3. Introduction
Authentication and Key Agreement (AKA) is a mutual authentication
algorithm involving a set of message exchanges between mobile node
(MN) and entities in the visited and home network. The basic
Authentication and Key Agreement (AKA) protocol is described in
the 3GPP document 3G TS 33.102 [3]. A by-product of AKA operation
is the generation of integrity and encryption keys. Wireless SDOs
such as 3GPP and 3GPP2 plan to support AKA as the primary means of
authenticating mobile nodes. AKA extensions have already been
proposed for SIP [4].
3GPP2 plans to support authentication and authorization via the
use of DIAMETER. DIAMETER support is being considered in 3GPP.
This contribution proposes extensions to DIAMETER that will allow
it to serve as a transport for AKA parameters during the
authentication procedure. For ease of reading, DIAMETER augmented
with AKA extensions is simply referred to in this contribution as
ôDIAMETER AKAö.
4. Overview of AKA
AKA is a 3-party protocol that takes place between a client, a
service provider, and a home authentication center. For the
explanation below, we assume that the service being used is basic
network access as in todayÆs cellular network; that the service
provider is a visited wireless carrier; and that the home
authentication center is associated with a home network. In this
case the client is a mobile node (MN), which will carry out AKA
negotiation with a visited AAA server (VAAA), which will in turn
communicate with a home AAA server (HAAA). However, the reader
should keep in mind that AKA is a generic authentication and key
agreement mechanism that could be used for other types of
services, as outlined in later sections of this document. In this
section we assume that the protocol used to carry AKA parameters
between the client and service provider is some wireless link
layer, but in other scenarios the particular protocol used may
differ. For all scenarios, we assume that DIAMETER is the
protocol of choice between VAAA and HAAA.
Initially, the MN is given an identity, which in cellular
applications is the IMSI, and a secret K that it shares with HAAA.
Upon connecting to the visited network, the MN transmits this
identity to the VAAA. The VAAA uses the identity to locate the
HAAA and make an authentication data request, which returns a set
of authentication vectors (AVs) from the home network.
Each AV contains a set of parameters (RAND, XRES, CK, IK, AUTN).
RAND is a random number generated by the home network. XRES is
Hiller, McCann Informational - Expires 8/2001 2
DIAMETER AKA February, 2001
the expected response from the MN that would indicate a successful
authentication. CK and IK are the Cipher Key and Integrity Key
that should be used to protect the subsequent link layer data,
assuming authentication was successful. The MN derives CK and IK
by applying a key generating function to RAND, using the shared
secret K known to the MN and HAAA. Finally, AUTN is itself
another vector consisting of the elements (SQN+AK, AMF, MAC).
Here SQN+AK is a monotonically increasing sequence number SQN
XORed with an Anonymity Key AK, which is computed as a secure hash
of RAND. AMF is a key management field that is used during re-
synchronization procedures and for other purposes. Finally, MAC
is a message authentication code computed over SQN, RAND, and AMF.
All secure hashes (key generating and message authentication
functions) are parameterized by the secret key K, so they are
unique to a given mobile node.
Upon receipt of the AV set, the VAAA chooses the next AV and
transmits (RAND, AUTN) from the AV to the MN. Note that CK and IK
are not transmitted to the MN. However, because the MN possesses
the secret key K, it can derive the AK from RAND and hence can
derive the SQN from the SQN+AK present in AUTN. This allows the
MN to compute an expected value for MAC based on the inputs SQN,
RAND, and AMF, and to compare this to the MAC received in AUTN.
If the result matches, and if the sequence number SQN is in an
acceptable range relative to the last authentication that was
performed, the MN can verify that the VAAA did indeed get the AV
from HAAA. This provides some assurance that the MN is
communicating with a legitimate visited network.
Now the MN must prove its identity to the VAAA. It does so by
computing RES, which is a simple message authentication function
applied to RAND. It transmits this value to VAAA, which compares
it to XRES. If the values match, the VAAA can assume that it is
communicating with a legitimate MN that is in possession of the
secret key K used to generate the AV. Also, it is now in agreement
on CK and IK that are used to encrypt and authenticate data to and
from the MN for the link layer session.
5. Trust Model Issues
The AKA protocol provides the proper guarantees for the
environment in which it was designed to operate: that of a fairly
small number of wireless operators communicating over a secure
network, and with a large degree of trust among the various
carriers. However, as we move to an all-IP wireless network,
there are likely to be many more carriers supporting different
types of access networks, and they will be interconnected by a
network of brokers each of whom acts as a manager for many pair-
wise trust relationships. As such, there may not be a direct
Hiller, McCann Informational - Expires 8/2001 3
DIAMETER AKA February, 2001
contractual or trust relationship between the VAAA and HAAA when a
MN roams to a given visited network.
In particular, AKA allows the comparison of RES with XRES to be
performed completely in the VAAA. This gives the HAAA no
assurance that a legitimate MN was actually connected to VAAA.
For this reason we propose that AKA authentication with DIAMETER
proceed in two steps, one which retrieves AUTN but does not expose
XRES to the VAAA, and a second round-trip where the home network
can actually compare RES to XRES. Then the HAAA can return a
DIAMETER Access-Accept or -Reject as appropriate to the VAAA.
This would be in accordance with usual IETF AAA based
authentication models.
This extra step introduces an additional round-trip through the
AAA infrastructure. A potential remedy to this situation would be
to alter AKA protocol such that the MN includes self-contained
authentication credentials, based on a timestamp, sequence number,
and random value. When this request is presented to the HAAA, the
HAAA can immediately verify the identity of the MN and release a
set of standard AKA AV (i.e., including XRES) to the VAAA. The
VAAA then compares RES with XRES in the subsequent response from
the MN. This solution would have improved latency, but it implies
a change to the basic AKA protocol, which may not be possible in a
legacy environment.
6. Application Scenarios
Figures 1-3 identify application scenarios for DIAMETER AKA in an
all-IP wireless network.
Figure 1 shows a mobile using AKA for device level authentication.
Note that in this scenario, the keys IK and CK could be used for
over-the-air encryption and integrity protection of data and
signaling traffic. This is because the HAAA provides CK and IK to
the VAAA via the Authentication Vector (AV), which, in turn,
passes the AV to the link layer access network element.
Figure 2 shows a legacy (circuit voice) mobile node connecting to
a network that supports DIAMETER AKA. This network contains a
VAAA that communicates with an HAAA via DIAMETER. The HAAA may
gateway the AKA parameters to a legacy HLR-based authentication
center to which the mobile node is homed.
Figure 3 shows a mobile with a SIP client being authenticated by a
SIP server. The SIP registrations contain AKA extensions. The SIP
server generates DIAMETER AKA messages directly. The SIP server
could be in a wireless carrier network, private network, or the
network of a third party provider. N.B. The 3GPP and 3GPP2 SDOs
Hiller, McCann Informational - Expires 8/2001 4
DIAMETER AKA February, 2001
place the authenticating SIP server only in the home network. In
this case there might not be a need for an interdomain AAA
protocol. However, we show this scenario to cover other
relationships that might exist between a SIP server and the home
network.
Hiller, McCann Informational - Expires 8/2001 5
DIAMETER AKA February, 2001
+-------------+ +-------------+
| | | |
| VAAA +-------+ HAAA
| | | |
+------+------+ +-------------+
|
|
+----------+ +------+------+
| | | Radio |
| Mobile +---+ Access |
| Station | | Network |
+----------+ +-------------+
Figure 1: Network Access using DIAMETER-AKA
+-------------+ +-------------+
| | | |
| VAAA +-------|HAAA/Gateway |
| | | |
+-----+-------+ +-------\-----+
| \
| +------\------+
+----------+ +------+------+ | |
| Mobile | | Radio Access| | HLR |
| Station +--+ Network | | |
| | | | +-------------+
+----------+ +-------------+
Figure 2: Network Access using Legacy HLR
+-------------+ +-------------+
| | | |
| VAAA +-------+ HAAA
| | | |
+-----+-------+ +-------------+
|
|
+----------+ +------+------+
| Mobile | | SIP |
| Station +--+ Server |
| | | |
+----------+ +-------------+
Figure 3: Application-layer (SIP) access using DIAMETER AKA.
Hiller, McCann Informational - Expires 8/2001 6
DIAMETER AKA February, 2001
In all cases, the following statements apply:
- The mobile and network entity or entities involved mutually
authenticate each other.
- The mobile and some participating entity in the network may use
keys derived from AKA message exchanges (i.e., the AV) for
integrity or encryption purposes. This could apply to data link
layer or application layer protection mechanisms.
7. Protocol Extensions
Section 5 outlined two approaches. The first approach requires two
traversals and places the RES and XRES comparison in the HAAA
(i.e. the HAAA does not send the XRES in the AV to the VAAA). The
second approach requires only one traversal but relies on a
challenge from the VAAA followed by a corresponding response from
the MN.
The AKA Request AVP is given in Figure 4. It is an optional AVP
for use only when the MN supports the response to a global
challenge in its initial request for service. If not then only the
NAI AVP is present in the Access Request, which may require the
HAAA to withhold XRES in its response, forcing a two round trip
authentication procedure.
The AKA Response AVP is given in Figure 5. It is used to supply
the VAAA with the random challenge plus authentication information
to be sent to the MN.
The AKA Keys AVP is given in Figure 6. It is used to supply
encryption and integrity keys to the VAAA after the HAAA has
verified the identity of the MN. It may be included in the first
response if the AKA Request AVP was included in the initial
request from the VAAA. Otherwise it should only be included in a
second response to the VAAA after the HAAA has compared RES with
XRES.
The AKA Request Result AVP is given in Figure 7. This is used
during the two-round AKA protocol to communicate the MN's response
to the HAAA.
Hiller, McCann Informational - Expires 8/2001 7
DIAMETER AKA February, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length |Reserved |P|R|V|R|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ G-RAND +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AUTHR +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: AKA Request AVP
Hiller, McCann Informational - Expires 8/2001 8
DIAMETER AKA February, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length |Reserved |P|R|V|R|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ RAND +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ SQN+AK +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | AMF |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ MAC +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: AKA Response AVP
Hiller, McCann Informational - Expires 8/2001 9
DIAMETER AKA February, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length |Reserved |P|R|V|R|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ XRES +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ CK +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IK +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: AKA Key AVP
Hiller, McCann Informational - Expires 8/2001 10
DIAMETER AKA February, 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| AVP Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AVP Length |Reserved |P|R|V|R|M|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ RES +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: AKA Request Result AVP
8. Security Considerations
This draft provides a basic transport function for the parameters
of AKA, which is itself a protocol designed to authenticate the
identity of a mobile node and to distribute keying material to a
service provider. However, we rely on the DIAMETER infrastructure
itself to guarantee that keying material is not exposed or
tampered with between the VAAA and the HAAA. If one or more
intervening brokers are present on the path between VAAA and HAAA,
then mechanisms for end-to-end security in DIAMETER (which are
outside the scope of this draft) should be applied. In any case
we assume that any two peer DIAMETER servers will make use of IP
Security mechanisms to protect data in transit.
8. References
1 Bradner, S., "The Internet Standards Process -- Revision 3",
BCP 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
rd
3 3G TS 33.102 version 3.4.0 Release 99; 3 Generation
Partnership Project; Technical Specification Group Services and
System Aspecs; 3G Security
Hiller, McCann Informational - Expires 8/2001 11
DIAMETER AKA February, 2001
4 UMTS AKA in SIP; S3-000456; 3GPP TSG SA WG3 Security; S3#14;
August 2-4 2000
9. Acknowledgments
Semyon Mizikovsky provided valuable review and feedback on this
draft.
10. Author's Addresses
Peter J. McCann
Lucent Technologies
Rm 2Z-305
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 713 9359
FAX: +1 630 713 4982
EMail: mccap@lucent.com
Tom Hiller
Lucent Technologies
Rm 2F-218
263 Shuman Blvd
Naperville, IL 60566-7050
USA
Phone: +1 630 979 7673
FAX: +1 630 979 7673
EMail: tom.hiller@lucent.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; neither does it represent
that it has made any effort to identify any such rights.
Information on the IETF's procedures with respect to rights in
standards-track and standards-related documentation can be found
in BCP-11. Copies of claims of rights made available for
publication and any assurances of licenses to be made available,
or the result of an attempt made to obtain a general license or
Hiller, McCann Informational - Expires 8/2001 12
DIAMETER AKA February, 2001
permission for the use of such proprietary rights by implementers
or users of this specification can be obtained from the IETF
Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to practice this standard. Please address the information to the
IETF Executive Director.
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, 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.
Hiller, McCann Informational - Expires 8/2001 13
