📄 draft-haverinen-pppext-eap-sim-05.txt
字号:
| EAP-Response/SIM/Start | | (Includes AT_IDENTITY and AT_NONCE_MT) | |------------------------------------------------------>| | | If the AT_IDENTITY attribute contains a valid cleartext identity or a pseudonym identity that the EAP server is able to decode to the cleartext identity, then the authentication sequence proceeds as usual with the EAP Server issuing the EAP-Request/SIM/Challenge message. The operation in the case when the AT_IDENTITY attribute contains a pseudonym that the EAP server fails to decode is specified in Section 5. 5. Identity Privacy Support In the very first connection to an EAP server, the client always transmits the cleartext identity (IMSI) in the EAP-Response/Identity packet or in the AT_IDENTITY attribute. In subsequent connections, the optional identity privacy (anonymity) support can be used to hide the IMSI and to make the connections unlinkable to a passive eavesdropper. The EAP-Request/SIM/Challenge message MAY include an encrypted pseudonym in the value field of the AT_ENCR_DATA attribute. The AT_IV and AT_MAC attributes are also used to transport the pseudonym to the client, as described in Section 11. Because the identity privacy support is optional to implement, the client MAY ignore the AT_IV, AT_ENCR_DATA, and AT_MAC attributes and always transmit the Haverinen Expires in six months [Page 6] Internet Draft EAP SIM Authentication June 2002 IMSI in the EAP-Response/Identity packet and in the AT_IDENTITY attribute. On receipt of the EAP-Request/SIM/Challenge, the client verifies the AT_MAC attribute before looking at the AT_ENCR_DATA attribute. If the AT_MAC is invalid, then the client MUST silently discard the EAP packet. If the AT_MAC attribute is valid, then the client MAY decrypt the encrypted data in AT_ENCR_DATA and use the obtained pseudonym used in the next authentication. The EAP server produces pseudonyms in an implementation-dependent manner. Please see [4] for examples on how to produce pseudonyms. Only the EAP server needs to be able to map the pseudonym to the cleartext identity. Regardless of construction method, the pseudonym MUST conform to the grammar specified for the username portion of an NAI. The EAP SIM server MAY produce pseudonyms that begin with a leading "1" character in order to be able to use the leading character as a hint in EAP method negotiation during next authentication. On the next connection to the EAP server, the client MAY transmit the received pseudonym in the first EAP-Response/Identity packet. The client concatenates the received pseudonym with the "@" character and the NAI realm portion. The client MUST use the same realm portion that it used in the connection when it received the pseudonym. If the EAP server successfully decodes the pseudonym received in the EAP-Response/Identity packet to a known client identity (IMSI), the authentication proceeds with the EAP- Request/SIM/Start message as usual. If the EAP server requests the client to include the AT_IDENTITY attribute in the EAP-Response/SIM/Start packet, as specified in Section 4, the client MAY transmit the received pseudonym in the AT_IDENTITY packet. If the EAP server successfully decodes the pseudonym to a known identity, then the authentication proceeds with the EAP-Request/SIM/Challenge packet as usual. If the EAP server fails to decode the pseudonym to a known identity, then the EAP server requests the regular IMSI (non-pseudonym identity) by including the AT_PERMANENT_IDENTITY_REQ attribute (Section 9) in the EAP-Request/SIM/Start message. The EAP server issues the EAP-Request/SIM/Start message also in the case when it received the undecodable pseudonym in AT_IDENTITY included the EAP-Response/SIM/Start packet. In this case, there are two EAP/SIM/Start round trips. The authentication sequence proceeds similarly in both cases. For example, AT_NONCE_MT is always included in the EAP-Response/SIM/Start packet, even if it was already transmitted in the previous EAP-Response/SIM/Start. The first EAP/SIM/Start round trip is ignored. The NONCE_MT value included in the second EAP-Response/SIM/Start packet is used in all calculations. The EAP/SIM client MAY use the same NONCE_MT value in both EAP-Response/SIM/Start packets. Haverinen Expires in six months [Page 7] Internet Draft EAP SIM Authentication June 2002 The value field of the AT_PERMANENT_IDENTITY_REQ does not contain any data but the attribute is included to request the client to include the AT_PERMANENT_IDENTITY attribute (Section 10) in the EAP- Response/SIM/Start message. The AT_PERMANENT_IDENTITY attribute contains the client's identity in the clear. Please note that the EAP/SIM client and the EAP/SIM server only process the AT_PERMANENT_IDENTITY_REQ and AT_PERMANENT_IDENTITY attributes and entities that only pass through EAP packets do not process these attributes. Hence, if the EAP server is not co-located in the authenticator, then the authenticator and other intermediate AAA elements (such as possible AAA proxy servers) will continue to refer to the client with the original pseudonym identity from the EAP-Response/Identity packet regardless if the decoding fails in the EAP server. The figure below illustrates the case when the EAP server fails to decode the pseudonym included in the EAP-Response/Identity packet. Client Authenticator | | | EAP-Request/Identity | |<------------------------------------------------------| | | | EAP-Response/Identity | | (Includes a pseudonym) | |------------------------------------------------------>| | | | +------------------------------+ | | Server fails to decode the | | | Pseudonym. | | +------------------------------+ | | | EAP-Request/SIM/Start | | (Includes AT_PERMANENT_IDENTITY_REQ) | |<------------------------------------------------------| | | | | | EAP-Response/SIM/Start | | (Includes AT_PERMANENT_IDENTITY and AT_NONCE_MT) | |------------------------------------------------------>| | | After the EAP-Response/SIM/Start message, the authentication sequence proceeds as usual with the EAP Server issuing the EAP- Request/SIM/Challenge message. The figure below illustrates the case when the EAP server fails to decode the pseudonym included in the AT_IDENTITY attribute. Haverinen Expires in six months [Page 8] Internet Draft EAP SIM Authentication June 2002 Client Authenticator | | | +------------------------------+ | | Server does not have any | | | Subscriber identity available| | | When starting EAP/SIM | | +------------------------------+ | | | EAP-Request/SIM/Start | | (Includes AT_IDENTITY_REQ) | |<------------------------------------------------------| | | | | |EAP-Response/SIM/Start | |(Includes a pseudonym AT_IDENTITY and AT_NONCE_MT) | |------------------------------------------------------>| | | | | | +------------------------------+ | | Server fails to decode the | | | Pseudonym in AT_IDENTITY | | +------------------------------+ | | | EAP-Request/SIM/Start | | (Includes AT_PERMANENT_IDENTITY_REQ) | |<------------------------------------------------------| | | | | | EAP-Response/SIM/Start | | (Includes AT_PERMANENT_IDENTITY and AT_NONCE_MT) | |------------------------------------------------------>| | | After the latter EAP-Response/SIM/Start message, the authentication sequence proceeds as usual with the EAP Server issuing the EAP- Request/SIM/Challenge message. If the client believes that the server should be able to decode the pseudonym identity, the client MAY refuse to send a clear text identity. In this case, the client silently ignores the EAP- Request/SIM/Start packet that contains AT_PERMANENT_IDENTITY_REQ. This is necessary in some environments to prevent Man-in-the-Middle attackers from claiming to be servers that do not recognize the pseudonym, in an effort to find out the true identity of the user. 6. Message Format The Type-Data of the EAP/SIM packets begins with a 1-octet Subtype field, which is followed by a 2-octet reserved field. The rest of the Type-Data consists of attributes that are encoded in Type, Length, Value format. The figure below shows the generic format of an attribute. Haverinen Expires in six months [Page 9] Internet Draft EAP SIM Authentication June 2002 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Attribute Type Indicates the particular type of attribute. The attribute type values are listed in Section 16. Length Indicates the length of this attribute in multiples of four bytes. The maximum length of an attribute is 1024 bytes. The length includes the Attribute Type and Length bytes. Value The particular data associated with this attribute. This field is always included and it may be two or more bytes in length. The type and length fields determine the format and length of the value field. When an attribute numbered within the range 0 through 127 is encountered but not recognized, the EAP/SIM message containing that attribute MUST be silently discarded. These attributes are called non-skippable attributes. When an attribute numbered in the range 128 through 255 is encountered but not recognized that particular attribute is ignored, but the rest of the attributes and message data MUST still be processed. The Length field of the attribute is used to skip the attribute value in searching for the next attribute. These attributes are called skippable attributes. EAP/SIM packets do not include a version field. However, should there be reason to revise this protocol in the future, new non- skippable or skippable attributes could be specified in order to implement revised EAP/SIM versions in a backward-compatible manner. Unless otherwise specified, the order of the attributes in an EAP/SIM message is insignificant, and an EAP/SIM implementation should not assume a certain order to be used. Attributes can be encapsulated within other attributes. In other words, the value field of an attribute type can be specified to contain other attributes. Haverinen Expires in six months [Page 10] Internet Draft EAP SIM Authentication June 2002 7. Message Integrity and Privacy Protection This section specifies EAP/SIM attributes for attribute encryption and EAP/SIM message integrity protection. Because the K_encr and K_int keys derived from the RAND challenges (as specified in Section 15) are required to process the integrity protection and encryption attributes, these attributes can only be used in the EAP-Request/SIM/Challenge message and any EAP/SIM messages sent after EAP-Requets/SIM/Challenge. For example, these attributes cannot be used in EAP-Request/SIM/Start. 7.1. AT_MAC Attribute The AT_MAC attribute can be used for EAP/SIM message integrity protection. Whenever AT_ENCR_DATA (Section 7.2) is included in an EAP message, it MUST be followed (not necessarily immediately) by an AT_MAC attribute. Messages that do not meet this condition MUST be silently discarded. The value field of the AT_MAC attribute contains two reserved bytes followed by a message authentication code (MAC). The MAC is calculated over the whole EAP packet with the exception that the value field of the MAC attribute is set to zero when calculating the MAC. The reserved bytes are set to zero when sending and ignored on reception. 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 [11] 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 integrity protection key (K_int) used in the calculation of the MAC is specified in Section 15. 7.2. AT_IV and AT_ENCR_DATA Attributes AT_IV and AT_ENCR_DATA attributes can be optionally used to transmit encrypted information between the EAP/SIM client and server. The value field of AT_IV contains two reserved bytes followed by a 16-byte initialization vector required by the AT_ENCR_DATA attribute. The reserved bytes are set to zero when sending and ⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -