draft-arkko-pppext-eap-aka-14.txt
来自「linux 下通过802.1认证的安装包」· 文本 代码 · 共 1,459 行 · 第 1/5 页
TXT
1,459 行
Network Working Group J. Arkko
Internet-Draft Ericsson
Expires: May 25, 2005 H. Haverinen
Nokia
November 24, 2004
Extensible Authentication Protocol Method for 3rd Generation
Authentication and Key Agreement (EAP-AKA)
draft-arkko-pppext-eap-aka-14.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on May 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and session key distribution using the
Authentication and Key Agreement (AKA) mechanism used in the 3rd
generation mobile networks Universal Mobile Telecommunications System
(UMTS) and cdma2000. AKA is based on symmetric keys, and runs
Arkko & Haverinen Expires May 25, 2005 [Page 1]
Internet-Draft EAP-AKA Authentication November 2004
typically in a Subscriber Identity Module (UMTS Subscriber Identity
Module USIM, or (Removable) User Identity Module (R)UIM), a smart
card like device.
EAP-AKA includes optional identity privacy support, optional result
indications, and an optional fast re-authentication procedure.
Table of Contents
1. Introduction and Motivation . . . . . . . . . . . . . . . . . 5
2. Terms and Conventions Used in This Document . . . . . . . . . 6
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1 Identity Management . . . . . . . . . . . . . . . . . . . 15
4.1.1 Format, Generation and Usage of Peer Identities . . . 16
4.1.2 Communicating the Peer Identity to the Server . . . . 22
4.1.3 Choice of Identity for the EAP-Response/Identity . . . 23
4.1.4 Server Operation in the Beginning of EAP-AKA
Exchange . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.5 Processing of EAP-Request/AKA-Identity by the Peer . . 24
4.1.6 Attacks against Identity Privacy . . . . . . . . . . . 25
4.1.7 Processing of AT_IDENTITY by the Server . . . . . . . 26
4.2 Message Sequence Examples (Informative) . . . . . . . . . 27
4.2.1 Usage of AT_ANY_ID_REQ . . . . . . . . . . . . . . . . 27
4.2.2 Fall Back on Full Authentication . . . . . . . . . . . 28
4.2.3 Requesting the Permanent Identity 1 . . . . . . . . . 29
4.2.4 Requesting the Permanent Identity 2 . . . . . . . . . 30
4.2.5 Three EAP/AKA-Identity Round Trips . . . . . . . . . . 31
5. Fast Re-authentication . . . . . . . . . . . . . . . . . . . . 33
5.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Comparison to AKA . . . . . . . . . . . . . . . . . . . . 34
5.3 Fast Re-authentication Identity . . . . . . . . . . . . . 35
5.4 Fast Re-authentication Procedure . . . . . . . . . . . . . 36
5.5 Fast Re-authentication Procedure when Counter is Too
Small . . . . . . . . . . . . . . . . . . . . . . . . . . 38
6. EAP-AKA Notifications . . . . . . . . . . . . . . . . . . . . 40
6.1 General . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.2 Result Indications . . . . . . . . . . . . . . . . . . . . 41
6.3 Error Cases . . . . . . . . . . . . . . . . . . . . . . . 42
6.3.1 Peer Operation . . . . . . . . . . . . . . . . . . . . 42
6.3.2 Server Operation . . . . . . . . . . . . . . . . . . . 43
6.3.3 EAP-Failure . . . . . . . . . . . . . . . . . . . . . 44
6.3.4 EAP-Success . . . . . . . . . . . . . . . . . . . . . 44
6.4 Key Generation . . . . . . . . . . . . . . . . . . . . . . 45
7. Message Format and Protocol Extensibility . . . . . . . . . . 47
7.1 Message Format . . . . . . . . . . . . . . . . . . . . . . 47
7.2 Protocol Extensibility . . . . . . . . . . . . . . . . . . 49
8. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Arkko & Haverinen Expires May 25, 2005 [Page 2]
Internet-Draft EAP-AKA Authentication November 2004
8.1 EAP-Request/AKA-Identity . . . . . . . . . . . . . . . . . 49
8.2 EAP-Response/AKA-Identity . . . . . . . . . . . . . . . . 50
8.3 EAP-Request/AKA-Challenge . . . . . . . . . . . . . . . . 50
8.4 EAP-Response/AKA-Challenge . . . . . . . . . . . . . . . . 51
8.5 EAP-Response/AKA-Authentication-Reject . . . . . . . . . . 52
8.6 EAP-Response/AKA-Synchronization-Failure . . . . . . . . . 52
8.7 EAP-Request/AKA-Reauthentication . . . . . . . . . . . . . 52
8.8 EAP-Response/AKA-Reauthentication . . . . . . . . . . . . 52
8.9 EAP-Response/AKA-Client-Error . . . . . . . . . . . . . . 53
8.10 EAP-Request/AKA-Notification . . . . . . . . . . . . . . . 53
8.11 EAP-Response/AKA-Notification . . . . . . . . . . . . . . 54
9. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 54
9.1 Table of Attributes . . . . . . . . . . . . . . . . . . . 54
9.2 AT_PERMANENT_ID_REQ . . . . . . . . . . . . . . . . . . . 55
9.3 AT_ANY_ID_REQ . . . . . . . . . . . . . . . . . . . . . . 56
9.4 AT_FULLAUTH_ID_REQ . . . . . . . . . . . . . . . . . . . . 56
9.5 AT_IDENTITY . . . . . . . . . . . . . . . . . . . . . . . 56
9.6 AT_RAND . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.7 AT_AUTN . . . . . . . . . . . . . . . . . . . . . . . . . 57
9.8 AT_RES . . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.9 AT_AUTS . . . . . . . . . . . . . . . . . . . . . . . . . 58
9.10 AT_NEXT_PSEUDONYM . . . . . . . . . . . . . . . . . . . . 58
9.11 AT_NEXT_REAUTH_ID . . . . . . . . . . . . . . . . . . . . 59
9.12 AT_IV, AT_ENCR_DATA and AT_PADDING . . . . . . . . . . . . 60
9.13 AT_CHECKCODE . . . . . . . . . . . . . . . . . . . . . . . 62
9.14 AT_RESULT_IND . . . . . . . . . . . . . . . . . . . . . . 64
9.15 AT_MAC . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.16 AT_COUNTER . . . . . . . . . . . . . . . . . . . . . . . . 65
9.17 AT_COUNTER_TOO_SMALL . . . . . . . . . . . . . . . . . . . 65
9.18 AT_NONCE_S . . . . . . . . . . . . . . . . . . . . . . . . 66
9.19 AT_NOTIFICATION . . . . . . . . . . . . . . . . . . . . . 66
9.20 AT_CLIENT_ERROR_CODE . . . . . . . . . . . . . . . . . . . 67
10. IANA and Protocol Numbering Considerations . . . . . . . . . 68
11. Security Considerations . . . . . . . . . . . . . . . . . . 70
11.1 Identity Protection . . . . . . . . . . . . . . . . . . . 70
11.2 Mutual Authentication . . . . . . . . . . . . . . . . . . 70
11.3 Flooding the Authentication Centre . . . . . . . . . . . . 70
11.4 Key Derivation . . . . . . . . . . . . . . . . . . . . . . 71
11.5 Brute-Force and Dictionary Attacks . . . . . . . . . . . . 71
11.6 Protection, Replay Protection and Confidentiality . . . . 71
11.7 Negotiation Attacks . . . . . . . . . . . . . . . . . . . 72
11.8 Protected Result Indications . . . . . . . . . . . . . . . 73
11.9 Man-in-the-middle Attacks . . . . . . . . . . . . . . . . 73
11.10 Generating Random Numbers . . . . . . . . . . . . . . . 73
12. Security Claims . . . . . . . . . . . . . . . . . . . . . . 74
13. Acknowledgements and Contributions . . . . . . . . . . . . . 74
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 75
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 75
Arkko & Haverinen Expires May 25, 2005 [Page 3]
Internet-Draft EAP-AKA Authentication November 2004
14.2 Informative References . . . . . . . . . . . . . . . . . . . 76
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 77
A. Pseudo-Random Number Generator . . . . . . . . . . . . . . . . 77
Intellectual Property and Copyright Statements . . . . . . . . 79
Arkko & Haverinen Expires May 25, 2005 [Page 4]
Internet-Draft EAP-AKA Authentication November 2004
1. Introduction and Motivation
This document specifies an Extensible Authentication Protocol (EAP)
mechanism for authentication and session key distribution using the
3rd generation Authentication and Key Agreement mechanism, specified
for Universal Mobile Telecommunications System (UMTS) in [TS 33.102]
and for cdma2000 in [S.S0055-A]. UMTS and cdma2000 are global third
generation mobile network standards that use the same AKA mechanism.
Second generation mobile networks and third generation mobile
networks use different authentication and key agreement mechanisms.
The Global System for Mobile communications (GSM) is a 2nd generation
mobile network standard, and EAP-SIM [EAP-SIM] specifies an EAP
mechanism that is based on the GSM authentication and key agreement
primitives.
AKA is based on challenge-response mechanisms and symmetric
cryptography. AKA typically runs in a UMTS Subscriber Identity
Module (USIM) or a cdma2000 (Removable) User Identity Module
((R)UIM). In this document, both modules are referred to as identity
modules. Compared to the 2nd generation mechanisms such as GSM AKA,
the 3rd generation AKA provides substantially longer key lengths and
mutual authentication.
The introduction of AKA inside EAP allows several new applications.
These include the following:
o The use of the AKA also as a secure PPP authentication method in
devices that already contain an identity module.
o The use of the third generation mobile network authentication
infrastructure in the context of wireless LANs
o Relying on AKA and the existing infrastructure in a seamless way
with any other technology that can use EAP.
AKA works in the following manner:
o The identity module and the home environment have agreed on a
secret key beforehand. (The "home environment" refers to the home
operator's authentication network infrastructure.)
o The actual authentication process starts by having the home
environment produce an authentication vector, based on the secret
key and a sequence number. The authentication vector contains a
random part RAND, an authenticator part AUTN used for
authenticating the network to the identity module, an expected
result part XRES, a 128-bit session key for integrity check IK,
and a 128-bit session key for encryption CK.
o The RAND and the AUTN are delivered to the identity module.
Arkko & Haverinen Expires May 25, 2005 [Page 5]
Internet-Draft EAP-AKA Authentication November 2004
o The identity module verifies the AUTN, again based on the secret
key and the sequence number. If this process is successful (the
AUTN is valid and the sequence number used to generate AUTN is
within the correct range), the identity moduleproduces an
authentication result, RES and sends this to the home environment.
o The home environment verifies the correct result from the identity
module. If the result is correct, IK and CK can be used to
protect further communications between the identity module and the
home environment.
When verifying AUTN, the identity module may detect that the sequence
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?