It should be noted that attributes AT_PERMANENT_ID_REQ, AT_ANY_ID_REQ, and AT_FULLAUTH_ID_REQ are mutually exclusive, so that only one of them can be included at the same time. If one of the attributes AT_IV or AT_ENCR_DATA is included, then both of the attributes MUST be included. Section 4.1. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception. Section 4.1. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception. Section 4.1. The value field only contains two reserved bytes, which are set to zero on sending and ignored on reception.
Section 4.1. The value field of this attribute begins with 2-byte actual identity length, which specifies the length of the identity in bytes. This field is followed by the subscriber identity of the indicated actual length. The identity is the permanent identity, a pseudonym identity or a fast re-authentication identity. The identity format is specified in Section 4.1.1. The same identity format is used in the AT_IDENTITY attribute and the EAP-Response/Identity packet, with the exception that the peer MUST NOT decorate the identity it includes in AT_IDENTITY. The identity does not include any terminating null characters. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the identity with zero bytes when necessary.
TS33.105], the length of the AKA RES can vary between 32 and 128 bits. Because the length of the AT_RES attribute must be a multiple of 4 bytes, the sender pads the RES with zero bits where necessary.
RFC3629]. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute.
Section 5. In environments where a realm portion is required, the fast re-authentication identity includes both a username portion and a realm name portion. The fast re-authentication identity does not include any terminating null characters. Because the length of the attribute must be a multiple of 4 bytes, the sender pads the fast re-authentication identity with zero bytes when necessary. The identity encoding MUST follow the UTF-8 transformation format [RFC3629]. This attribute MUST always be encrypted by encapsulating it within the AT_ENCR_DATA attribute. Section 6.3 specifies the operation if a packet that does not meet this condition is encountered. The sender of the AT_IV attribute chooses the initialization vector at random. The sender MUST NOT reuse the initialization vector value from previous EAP-AKA packets. The sender SHOULD use a good source of randomness to generate the initialization vector. Please see [RFC4086] for more information about generating random numbers for security applications. The format of AT_IV is shown below.
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_IV | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Initialization Vector | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value field of the AT_ENCR_DATA attribute consists of two reserved bytes followed by cipher text bytes. The cipher text bytes are encrypted using the Advanced Encryption Standard (AES) [AES] with a 128-bit key in the Cipher Block Chaining (CBC) mode of operation, which uses the initialization vector from the AT_IV attribute. The reserved bytes are set to zero when sending and ignored on reception. Please see [CBC] for a description of the CBC mode. The format of the AT_ENCR_DATA attribute is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_ENCR_DATA | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . Encrypted Data . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The derivation of the encryption key (K_encr) is specified in Section 7. The plaintext consists of nested EAP-AKA attributes. The encryption algorithm requires the length of the plaintext to be a multiple of 16 bytes. The sender may need to include the AT_PADDING attribute as the last attribute within AT_ENCR_DATA. The AT_PADDING attribute is not included if the total length of other nested attributes within the AT_ENCR_DATA attribute is a multiple of 16 bytes. As usual, the Length of the Padding attribute includes the Attribute Type and Attribute Length fields. The length of the Padding attribute is 4, 8, or 12 bytes. It is chosen so that the length of the value field of the AT_ENCR_DATA attribute becomes a multiple of 16 bytes. The actual pad bytes in the value field are set to zero (00 hexadecimal) on sending. The recipient of the message MUST verify that the pad bytes are set to zero. If this
verification fails on the peer, then it MUST send the EAP-Response/AKA-Client-Error packet with the error code "unable to process packet" to terminate the authentication exchange. If this verification fails on the server, then the server sends the EAP-Response/AKA-Notification packet with an AT_NOTIFICATION code that implies failure to terminate the authentication exchange. The format of the AT_PADDING attribute is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_PADDING | Length | Padding... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_CHECKCODE | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Checkcode (0 or 20 bytes) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The value field of AT_CHECKCODE begins with two reserved bytes, which may be followed by a 20-byte checkcode. If the checkcode is not included in AT_CHECKCODE, then the attribute indicates that no EAP/- AKA-Identity messages were exchanged. This may occur in both full authentication and fast re-authentication. The reserved bytes are set to zero when sending and ignored on reception. The checkcode is a hash value, calculated with SHA1 [SHA-1], over all EAP-Request/AKA-Identity and EAP-Response/AKA-Identity packets exchanged in this authentication exchange. The packets are included in the order that they were transmitted, that is, starting with the first EAP-Request/AKA-Identity message, followed by the corresponding EAP-Response/AKA-Identity, followed by the second EAP-Request/AKA-Identity (if used), etc. EAP packets are included in the hash calculation "as-is" (as they were transmitted or received). All reserved bytes, padding bytes, etc., that are specified for various attributes are included as such, and the receiver must not reset them to zero. No delimiter bytes, padding, or any other framing are included between the EAP packets when calculating the checkcode. Messages are included in request/response pairs; in other words, only full "round trips" are included. Packets that are silently discarded are not included, and retransmitted packets (that have the same Identifier value) are only included once. (The base EAP protocol [RFC3748] ensures that requests and responses "match".) The EAP server must only include an EAP-Request/AKA-Identity in the calculation after it has received a corresponding response with the same Identifier value. The peer must include the EAP-Request/AKA-Identity and the corresponding response in the calculation only if the peer receives a subsequent EAP-Request/AKA-Challenge or a follow-up EAP-Request/ AKA-Identity with a different Identifier value than in the first EAP-Request/AKA-Identity.
The AT_CHECKCODE attribute is optional to implement. It is specified in order to allow protection of the EAP/AKA-Identity messages and any future extensions to them. The implementation of AT_CHECKCODE is RECOMMENDED. If the receiver of AT_CHECKCODE implements this attribute, then the receiver MUST check that the checkcode is correct. If the checkcode is invalid, the receiver must operate as specified in Section 6.3. If the EAP/AKA-Identity messages are extended with new attributes, then AT_CHECKCODE MUST be implemented and used. More specifically, if the server includes any attributes other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet, then the server MUST include AT_CHECKCODE in EAP-Request/ AKA-Challenge or EAP-Request/AKA-Reauthentication. If the peer includes any attributes other than AT_IDENTITY in the EAP-Response/ AKA-Identity message, then the peer MUST include AT_CHECKCODE in EAP-Response/AKA-Challenge or EAP-Response/AKA-Reauthentication. If the server implements the processing of any other attribute than AT_IDENTITY for the EAP-Response/AKA-Identity message, then the server MUST implement AT_CHECKCODE. In this case, if the server receives any attribute other than AT_IDENTITY in the EAP-Response/AKA-Identity message, then the server MUST check that AT_CHECKCODE is present in EAP-Response/AKA-Challenge or EAP-Response/ AKA-Reauthentication. The operation when a mandatory attribute is missing is specified in Section 6.3. Similarly, if the peer implements the processing of any attribute other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ for the EAP-Request/AKA-Identity packet, then the peer MUST implement AT_CHECKCODE. In this case, if the peer receives any attribute other than AT_PERMANENT_ID_REQ, AT_FULLAUTH_ID_REQ, or AT_ANY_ID_REQ in the EAP-Request/AKA-Identity packet, then the peer MUST check that AT_CHECKCODE is present in EAP-Request/AKA-Challenge or EAP-Request/AKA-Reauthentication. The operation when a mandatory attribute is missing is specified in Section 6.3.
The value field of this attribute consists of two reserved bytes, which are set to zero upon sending and ignored upon reception. This attribute is always sent unencrypted, so it MUST NOT be encapsulated within the AT_ENCR_DATA attribute. Section 9 specifies in which messages AT_MAC MUST be included. The value field of the AT_MAC attribute contains two reserved bytes followed by a keyed message authentication code (MAC). The MAC is calculated over the whole EAP packet and concatenated with optional message-specific data, with the exception that the value field of the MAC attribute is set to zero when calculating the MAC. The EAP packet includes the EAP header that begins with the Code field, the EAP-AKA header that begins with the Subtype field, and all the attributes, as specified in Section 8.1. The reserved bytes in AT_MAC are set to zero when sending and ignored on reception. The contents of the message-specific data that may be included in the MAC calculation are specified separately for each EAP-AKA message in Section 9. The format of the AT_MAC attribute is shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | AT_MAC | Length = 5 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MAC | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MAC algorithm is HMAC-SHA1-128 [RFC2104] keyed hash value. (The HMAC-SHA1-128 value is obtained from the 20-byte HMAC-SHA1 value by truncating the output to 16 bytes. Hence, the length of the MAC is 16 bytes.) The derivation of the authentication key (K_aut) used in the calculation of the MAC is specified in Section 7. When the AT_MAC attribute is included in an EAP-AKA message, the recipient MUST process the AT_MAC attribute before looking at any other attributes, except when processing EAP-Request/AKA-Challenge. The processing of EAP-Request/AKA-Challenge is specified in
Section 9.3. If the message authentication code is invalid, then the recipient MUST ignore all other attributes in the message and operate as specified in Section 6.3.
The notification code values listed below have been reserved. The descriptions below illustrate the semantics of the notifications. The peer implementation MAY use different wordings when presenting the notifications to the user. The "requested service" depends on the environment where EAP-AKA is applied. 0 - General failure after authentication. (Implies failure, used after successful authentication.) 16384 - General failure. (Implies failure, used before authentication.) 32768 - Success. User has been successfully authenticated. (Does not imply failure, used after successful authentication.) The usage of this code is discussed in Section 6.2. 1026 - User has been temporarily denied access to the requested service. (Implies failure, used after successful authentication.) 1031 - User has not subscribed to the requested service. (Implies failure, used after successful authentication.) EAP-SIM]. EAP-AKA protocol numbers should be administered in the same IANA registry with EAP-SIM. This document establishes the registries and lists the initial protocol numbers for both protocols.
EAP-AKA and EAP-SIM messages include a Subtype field. The Subtype is a new numbering space for which IANA administration is required. The Subtype is an 8-bit integer. The following Subtypes are specified in this document and in [EAP-SIM]: AKA-Challenge...................................1 AKA-Authentication-Reject.......................2 AKA-Synchronization-Failure.....................4 AKA-Identity....................................5 SIM-Start......................................10 SIM-Challenge..................................11 AKA-Notification and SIM-Notification..........12 AKA-Reauthentication and SIM-Reauthentication..13 AKA-Client-Error and SIM-Client-Error..........14 The messages are composed of attributes, which have 8-bit attribute type numbers. Attributes numbered within the range 0 through 127 are called non-skippable attributes, and attributes within the range of 128 through 255 are called skippable attributes. The EAP-AKA and EAP-SIM attribute type number is a new numbering space for which IANA administration is required. The following attribute types are specified in this document in [EAP-SIM]: AT_RAND.........................................1 AT_AUTN.........................................2 AT_RES..........................................3 AT_AUTS.........................................4 AT_PADDING......................................6 AT_NONCE_MT.....................................7 AT_PERMANENT_ID_REQ............................10 AT_MAC.........................................11 AT_NOTIFICATION................................12 AT_ANY_ID_REQ..................................13 AT_IDENTITY....................................14 AT_VERSION_LIST................................15 AT_SELECTED_VERSION............................16 AT_FULLAUTH_ID_REQ.............................17 AT_COUNTER.....................................19 AT_COUNTER_TOO_SMALL...........................20 AT_NONCE_S.....................................21 AT_CLIENT_ERROR_CODE...........................22 AT_IV.........................................129 AT_ENCR_DATA..................................130 AT_NEXT_PSEUDONYM.............................132 AT_NEXT_REAUTH_ID.............................133 AT_CHECKCODE..................................134 AT_RESULT_IND.................................135
The AT_NOTIFICATION attribute contains a 16-bit notification code value. The most significant bit of the notification code is called the S bit (success) and the second most significant bit is called the P bit (phase). If the S bit is set to zero, then the notification code indicates failure; notification codes with the S bit set to one do not indicate failure. If the P bit is set to zero, then the notification code can only be used before authentication has occurred. If the P bit is set to one, then the notification code can only be used after authentication. The notification code is a new numbering space for which IANA administration is required. The following values have been specified in this document and in [EAP-SIM]. General failure after authentication......................0 User has been temporarily denied access................1026 User has not subscribed to the requested service.......1031 General failure.......................................16384 Success...............................................32768 The AT_VERSION_LIST and AT_SELECTED_VERSION attributes, specified in [EAP-SIM], contain 16-bit EAP method version numbers. The EAP method version number is a new numbering space for which IANA administration is required. Value 1 for "EAP-SIM Version 1" has been specified in [EAP-SIM]. Version numbers are not currently used in EAP-AKA. The AT_CLIENT_ERROR_CODE attribute contains a 16-bit client error code. The client error code is a new numbering space for which IANA administration is required. Values 0, 1, 2, and 3 have been specified in this document and in [EAP-SIM]. All requests for value assignment from the various number spaces described in this document require proper documentation, according to the "Specification Required" policy described in [RFC2434]. Requests must be specified in sufficient detail so that interoperability between independent implementations is possible. Possible forms of documentation include, but are not limited to, RFCs, the products of another standards body (e.g., 3GPP), or permanently and readily available vendor design notes. RFC3748] describes the security vulnerabilities of EAP, which does not include its own security mechanisms. This section discusses the claimed security properties of EAP-AKA as well as vulnerabilities and security recommendations.
Section 4.1.2) to learn the subscriber's IMSI. However, as discussed in Section 4.1.2, the terminal can refuse to send the cleartext IMSI if it believes that the network should be able to recognize the pseudonym. If the peer and server cannot guarantee that the pseudonym will be maintained reliably, and Identity privacy is required then additional protection from an external security mechanism (such as Protected Extensible Authentication Protocol (PEAP) [PEAP]) may be used. The benefits and the security considerations of using an external security mechanism with EAP-AKA are beyond the scope of this document. TS33.102] and [S.S0055-A]. Note that this mutual authentication is with the EAP server. In general, EAP methods do not authenticate the identity or services provided by the EAP authenticator (if distinct from the EAP server) unless they provide the so-called channel bindings property. The vulnerabilities related to this have been discussed in [RFC3748], [EAPKeying], [ServiceIdentity]. EAP-AKA does not provide the channel bindings property, so it only authenticates the EAP server. However, ongoing work such as [ServiceIdentity] may provide such support as an extension to popular EAP methods such as EAP-TLS, EAP-SIM, or EAP-AKA.
malicious EAP-AKA peer may generate a lot of protocol requests to mount a denial-of-service attack. The EAP-AKA server implementation SHOULD take this into account and SHOULD take steps to limit the traffic that it generates towards the AuC, preventing the attacker from flooding the AuC and from extending the denial-of-service attack from EAP-AKA to other users of the AuC. Section 7. The Transient EAP Keys used to protect EAP-AKA packets (K_encr, K_aut), the Master Session Keys, and the Extended Master Session Keys are cryptographically separate. An attacker cannot derive any non-trivial information about any of these keys based on the other keys. An attacker also cannot calculate the pre-shared secret from AKA IK, AKA CK, EAP-AKA K_encr, EAP-AKA K_aut, the Master Session Key, or the Extended Master Session Key. Section 10.1 summarizes which fields are confidentiality protected. It should be noted that the error and notification code attributes AT_CLIENT_ERROR_CODE and AT_NOTIFICATION are not confidential, but they are transmitted in the clear. Identity protection is discussed in Section 12.1.
On full authentication, replay protection of the EAP exchange is provided by RAND and AUTN values from the underlying AKA scheme. Protection against replays of EAP-AKA messages is also based on the fact that messages that can include AT_MAC can only be sent once with a certain EAP-AKA Subtype, and on the fact that a different K_aut key will be used for calculating AT_MAC in each full authentication exchange. On fast re-authentication, a counter included in AT_COUNTER and a server random nonce is used to provide replay protection. The AT_COUNTER attribute is also included in EAP-AKA notifications, if they are used after successful authentication in order to provide replay protection between re-authentication exchanges. The contents of the user identity string are implicitly integrity protected by including them in key derivation. Because EAP-AKA is not a tunneling method, EAP-Request/Notification, EAP-Response/Notification, EAP-Success, or EAP-Failure packets are not confidential, integrity protected, or replay protected. On physically insecure networks, this may enable an attacker to mount denial-of-service attacks by spoofing these packets. As discussed in Section 6.3, the peer will only accept EAP-Success after the peer successfully authenticates the server. Hence, the attacker cannot force the peer to believe successful mutual authentication has occurred before the peer successfully authenticates the server or after the peer failed to authenticate the server. The security considerations of EAP-AKA result indications are covered in Section 12.8 An eavesdropper will see the EAP Notification, EAP_Success and EAP-Failure packets sent in the clear. With EAP-AKA, confidential information MUST NOT be transmitted in EAP Notification packets. Section 8, EAP-AKA allows the protocol to be extended by defining new attribute types. When defining such attributes, it should be noted that any extra attributes included in EAP-Request/AKA-Identity or EAP-Response/AKA-Identity packets are not
included in the MACs later on, and thus some other precautions must be taken to avoid modifications to them. EAP-AKA does not support ciphersuite negotiation or EAP-AKA protocol version negotiation. PEAP-02] was vulnerable to this attack. This specification does not address these attacks. If EAP-AKA is used with a tunneling protocol, there should be cryptographic binding provided between the protocol and EAP-AKA to prevent man-in-the-middle attacks through rogue authenticators being able to setup one-way authenticated tunnels. For example, newer versions of PEAP include such cryptographic binding. The EAP-AKA Master Session Key MAY be used to provide the cryptographic binding. However, the mechanism that provides the binding depends on the tunneling protocol and is beyond the scope of this document.
RFC4086] for more information on generating random numbers for security applications. RFC3748]. Auth. Mechanism: EAP-AKA is based on the AKA mechanism, which is an authentication and key agreement mechanism based on a symmetric 128-bit pre-shared secret. Ciphersuite negotiation: No Mutual authentication: Yes (Section 12.2) Integrity protection: Yes (Section 12.6) Replay protection: Yes (Section 12.6) Confidentiality: Yes, except method-specific success and failure indications (Section 12.1, Section 12.6) Key derivation: Yes Key strength: EAP-AKA supports key derivation with 128-bit effective key strength. Description of key hierarchy: Please see Section 7. Dictionary attack protection: N/A (Section 12.5) Fast reconnect: Yes Cryptographic binding: N/A Session independence: Yes (Section 12.4) Fragmentation: No Channel binding: No Indication of vulnerabilities. Vulnerabilities are discussed in Section 12.
EAP-SIM], and hence this specification incorporates many ideas from EAP-SIM, and many contributions from the reviewer's of EAP-SIM. The attribute format is based on the extension format of Mobile IPv4 [RFC3344]. [TS33.102] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 33.102 V5.1.0: "Technical Specification Group Services and System Aspects; 3G Security; Security Architecture (Release 5)"", December 2002. [S.S0055-A] 3rd Generation Partnership Project 2, "3GPP2 Enhanced Cryptographic Algorithms", September 2003. [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TS23.003] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 23.003 V6.8.0: "3rd Generation Parnership Project; Technical Specification Group Core Network; Numbering, addressing and identification (Release 6)"", December 2005.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [AES] National Institute of Standards and Technology, "Federal Information Processing Standards (FIPS) Publication 197, "Advanced Encryption Standard (AES)"", November 2001, http://csrc.nist.gov/publications/fips/fips197/ fips-197.pdf. [CBC] National Institute of Standards and Technology, "NIST Special Publication 800-38A, "Recommendation for Block Cipher Modes of Operation - Methods and Techniques"", December 2001, http://csrc.nist.gov/publications/ nistpubs/800-38a/sp800-38a.pdf. [SHA-1] National Institute of Standards and Technology, U.S. Department of Commerce, "Federal Information Processing Standard (FIPS) Publication 180-1, "Secure Hash Standard"", April 1995. [PRF] National Institute of Standards and Technology, "Federal Information Processing Standards (FIPS) Publication 186-2 (with change notice); Digital Signature Standard (DSS)", January 2000, http://csrc.nist.gov/publications/ fips/fips186-2/fips186-2-change1.pdf. [TS33.105] 3rd Generation Partnership Project, "3GPP Technical Specification 3GPP TS 33.105 4.1.0: "Technical Specification Group Services and System Aspects; 3G Security; Cryptographic Algorithm Requirements (Release 4)"", June 2001. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [PEAP] Palekar, A., Simon, D., Zorn, G., Salowey, J., Zhou, H., and S. Josefsson, "Protected EAP Protocol (PEAP) Version 2", work in progress, October 2004. [PEAP-02] Anderson, H., Josefsson, S., Zorn, G., Simon, D., and A. Palekar, "Protected EAP Protocol (PEAP)", work in progress, February 2002. [EAPKeying] Aboba, B., Simon, D., Arkko, J., Eronen, P., and H. Levkowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", work in progress, October 2005. [ServiceIdentity] Arkko, J. and P. Eronen, "Authenticated Service Information for the Extensible Authentication Protocol (EAP)", Work in Progress, October 2004. [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [EAP-SIM] Haverinen, H., Ed. and J. Salowey, Ed., "Extensible Authentication Protocol Method for Global System for Mobile Communications (GSM) Subscriber Identity Modules (EAP-SIM)", RFC 4186, January 2006.
SHA-1] Step 3: For j = 0 to m - 1 do 3.1. XSEED_j = 0 /* no optional user input */ 3.2. For i = 0 to 1 do a. XVAL = (XKEY + XSEED_j) mod 2^b b. w_i = G(t, XVAL) c. XKEY = (1 + XKEY + w_i) mod 2^b 3.3. x_j = w_0|w_1
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. 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 implement this standard. Please address the information to the IETF at firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).