📄 draft-arkko-pppext-eap-aka-15.txt
字号:
generated using the synchronized sequence number. For a specification of the AKA mechanisms and how the cryptographic values AUTN, RES, IK, CK and AUTS are calculated, see [TS 33.102] for UMTS and [S.S0055-A] for cdma2000. In EAP-AKA, the EAP server node obtains the authentication vectors, compares RES and XRES, and uses CK and IK in key derivation. In the third generation mobile networks, AKA is used both for radio network authentication and IP multimedia service authentication purposes. Different user identities and formats are used for these; the radio network uses the International Mobile Subscriber Identifier (IMSI), whereas the IP multimedia service uses the Network Access Identifier (NAI) [RFC2486].2. Terms and 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 [RFC2119]. The terms and abbreviations "authenticator", "backend authentication server", "EAP server", "peer", "Silently Discard", "Master Session Key (MSK)", and "Extended Master Session Key (EMSK)" in this document are to be interpreted as described in [RFC3748]. This document frequently uses the following terms and abbreviations. The AKA parameters are specified in detail in [TS 33.102] for UMTS and [S.S0055-A] for cdma2000. AAA protocolArkko & Haverinen Expires June 21, 2005 [Page 6] Internet-Draft EAP-AKA Authentication December 2004 Authentication, Authorization and Accounting protocol AKA Authentication and Key Agreement AuC Authentication Centre. The mobile network element that can authenticate subscribers in the mobile networks. AUTN AKA parameter. AUTN is an authentication value generated by the AuC which together with the RAND authenticates the server to the peer, 128 bits AUTS AKA parameter. A value generated by the peer upon experiencing a synchronization failure, 112 bits. EAP Extensible Authentication Protocol [RFC3748] Fast re-authentication An EAP-AKA authentication exchange that is based on keys derived upon a preceding full authentication exchange. The 3rd Generation AKA is not used in the fast re-authentication procedure. Fast Re-authentication Identity A fast re-authentication identity of the peer, including an NAI realm portion in environments where a realm is used. Used on re-authentication only. Fast Re-authentication Username The username portion of fast re-authentication identity, ie. not including any realm portions. Full authentication An EAP-AKA authentication exchange that is based on theArkko & Haverinen Expires June 21, 2005 [Page 7] Internet-Draft EAP-AKA Authentication December 2004 3rd Generation AKA procedure. GSM Global System for Mobile communications. NAI Network Access Identifier [RFC2486] Identity module Identity module is used in this document to refer to the part of the mobile device that contains authentication and key agreement primitives. The identity module may be an integral part of the mobile device or it can be an application on a smart card distributed by a mobile operator. USIM and (R)UIM are identity modules. Nonce A value that is used at most once or that is never repeated within the same cryptographic context. In general, a nonce can be predictable (e.g. a counter) or unpredictable (e.g. a random value). Since some cryptographic properties may depend on the randomness of the nonce, attention should be paid to whether a nonce is required to be random or not. In this document, the term nonce is only used to denote random nonces, and it is not used to denote counters. Permanent Identity The permanent identity of the peer, including an NAI realm portion in environments where a realm is used. The permanent identity is usually based on the IMSI. Used on full authentication only. Permanent Username The username portion of permanent identity, ie. not including any realm portions. Pseudonym Identity A pseudonym identity of the peer, including an NAI realm portion in environments where a realm is used. Used on full authentication only.Arkko & Haverinen Expires June 21, 2005 [Page 8] Internet-Draft EAP-AKA Authentication December 2004 Pseudonym Username The username portion of pseudonym identity, ie. not including any realm portions. RAND An AKA parameter. Random number generated by the AuC, 128 bits RES Authentication result from the peer, which together with the RAND authenticates the peer to the server, 128 bits (R)UIM cdma2000 (Removable) User Identity Module. (R)UIM is an application that is resident e.g. on smart cards which may be fixed in the terminal or distributed by cdma2000 operators (when removable) SQN An AKA parameter. Sequence number used in the authentication process, 48 bits SIM Subscriber Identity Module. The SIM is traditionally a smart card distributed by a GSM operator. SRES The authentication result parameter in GSM, corresponds to the RES parameter in 3G AKA, 32 bits. UAK UIM Authentication Key, used in cdma2000 AKA. Both the identity module and the network can optionally generate the UAK during the AKA computation in cdma2000. UAK is not used in this version of EAP-AKA. UIM Please see (R)UIMArkko & Haverinen Expires June 21, 2005 [Page 9] Internet-Draft EAP-AKA Authentication December 2004 USIM UMTS Subscriber Identity Module. USIM is an application that is resident e.g. on smart cards distributed by UMTS operators.3. Protocol Overview Figure 1 shows the basic successful full authentication exchange in EAP-AKA, when optional result indications are not used. The authenticator typically communicates with an EAP server that is located on a backend authentication server using an AAA protocol. The authenticator shown in the figure is often simply relaying EAP messages to and from the EAP server, but these back end AAA communications are not shown. At the minimum, EAP-AKA uses two roundtrips to authenticate and authorize the peer and generate session keys. As in other EAP schemes, an identity request/response message pair is usually exchanged first. On full authentication, the peer's identity response includes either the user's International Mobile Subscriber Identity (IMSI), or a temporary identity (pseudonym) if identity privacy is in effect, as specified in Section 4.1. (As specified in [RFC3748], the initial identity request is not required, and MAY be bypassed in cases where the network can presume the identity, such as when using leased lines, dedicated dial-ups, etc. Please see also Section 4.1.2 for specification how to obtain the identity via EAP AKA messages.) After obtaining the subscriber identity, the EAP server obtains an authentication vector (RAND, AUTN, RES, CK, IK) for use in authenticating the subscriber. From the vector, the EAP server derives the keying material, as specified in Section 6.4. The vector may be obtained by contacting an Authentication Centre (AuC) on the mobile network; for example per UMTS specifications, several vectors may be obtained at a time. Vectors may be stored in the EAP server for use at a later time, but they may not be reused. In cdma2000, the vector may include a sixth value called the User Identity Module Authentication Key (UAK). This key is not used in EAP-AKA. Next, the EAP server starts the actual AKA protocol by sending an EAP-Request/AKA-Challenge message. EAP-AKA packets encapsulate parameters in attributes, encoded in a Type, Length, Value format. The packet format and the use of attributes are specified in Section 7. The EAP-Request/AKA-Challenge message contains a RAND random number (AT_RAND) and a network authentication token (AT_AUTN), and a message authentication code AT_MAC. The EAP-Request/AKA-Challenge message MAY optionally contain encrypted data, which is used forArkko & Haverinen Expires June 21, 2005 [Page 10] Internet-Draft EAP-AKA Authentication December 2004 identity privacy and fast re-authentication support, as described in Section 4.1. The AT_MAC attribute contains a message authentication code covering the EAP packet. The encrypted data is not shown in the figures of this section. The peer runs the AKA algorithm (typically using an identity module) and verifies the AUTN. If this is successful, the peer is talking to a legitimate EAP server and proceeds to send the EAP-Response/AKA-Challenge. This message contains a result parameter that allows the EAP server in turn to authenticate the peer, and the AT_MAC attribute to integrity protect the EAP message. The EAP server verifies that the RES and the MAC in the EAP-Response/AKA-Challenge packet are correct. Because protected success indications are not used in this example, the EAP server sends the EAP-Success packet, indicating that the authentication was successful. (Protected success indications are discussed in Section 6.2.) The EAP server may also include derived keying material in the message it sends to the authenticator. The peer has derived the same keying material, so the authenticator does not forward the keying material to the peer along with EAP-Success.⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -