초록

This document describes an EAP method used for extending EAP functionality. The extended functionality includes channel binding and re-authentication. The EAP method also allows sequencing of multiple EAP methods inside it.

대표청구항 ▼

1. A process for authentication of a method between a client and a server, comprising: a) employing a method which has no authentication mechanism between a client and a server; b) having said method rely on an inner authentication method in order to authenticate the client. 2. The process of cl

1. A process for authentication of a method between a client and a server, comprising: a) employing a method which has no authentication mechanism between a client and a server; b) having said method rely on an inner authentication method in order to authenticate the client. 2. The process of claim 1, wherein said method is a first EAP method having no authentication mechanism that carries a second EAP method inside, said second EAP method being used to authenticate the client. 3. A process for an EAP peer and an EAP server to negotiate on capabilities regarding an EAP extended functionality, comprising: employing an EAP extension method (EAP-EXT) that provides capabilities exchange between the server and the client regarding the extended functionality, wherein the extended functionality has no authentication mechanism and wherein at least one inner EAP method is run inside said EAP extension method for authenticating the EAP peer. 4. The process of claim 3, further including having said inner EAP method generate keying material, and protecting messages in said outer EAP extension method with an AUTH TLV. 5. The process of claim 4, wherein AUTH TLVs in outer EAP extension messages are computed using an EAP extension key (EAP-EXT-KEY) generated from EAP keying material of a latest successful inner method. 6. The process of claim 5, wherein said EAP extension key is used for computing AUTH TLVs for integrity protecting EAP-EXT messages. 7. The process of claim 6, wherein said EAP extension key is derived from an EMSK generated by an inner EAP method using a usage specific root key derivation algorithm. 8. The process of claim 3, wherein said EAP extension method defines an EAP-re-authentication key that is used as a pre-shared key required by an EAP method used for a re-authentication mechanism. 9. The process of claim 8, wherein said EAP re-authentication key is derived from an EMSK exported from the EAP extension method using a usage specific root key derivation algorithm. 10. The process of claim 3, wherein said EAP extension method employs a message format including common EAP fields, with a bit that is configured to be set to indicate that it is the last message, with another bit that is configured to be set to indicate an error, with a version field of a plurality of bits, a reserved field of a plurality of bits for future extensions, and a capabilities field of a plurality of bits that each corresponds to a particular capability. 11. The method of claim 3, further including that said capabilities exchange between the server and the client regarding the extended functionality is provided by setting of a capabilities bit. 12. The method of claim 11, wherein said capabilities bit indicates that the sender supports a channel binding mechanism. 13. The method of claim 11, wherein said capabilities bit indicates that the sender supports re-authentication. 14. The method of claim 13, wherein when the capabilities bit indicates that the sender supports re-authentication is set in a final Request/EXT message, and the message includes a Server-ID TLV and a Peer-ID TLV. 15. The method of claim 13, wherein when the capabilities bit indicates that the send supports re-authentication is set in a final Request/EXT and Response/EXT message exchange, the EAP peer and the EAP server generate an EAP re-authentication key, and wherein the Server-ID and the Peer-ID contained in the Server-ID and the Peer-ID TLVs and the EAP re-authentication key are used for a re-authentication EAP method. 16. The process of claim 5, further including employing multiple inner EAP methods that are sequentially run inside the EAP extension method, and generating a new EAP extension key each time an inner EAP method in the sequence generates keying material. 17. The process of claim 3, wherein said process includes: a) said EAP Server transmits an EAP-Request/EXT message with at least one capability bit set; b) said EAP Peer receives said EAP-Request/Ext message and transmits an EAP-Response/EXT message with at least one capability bit set. 18. The process of claim 7, wherein said process includes c) said EAP Server receives said EAP-Response/Ext message and transmits an EAP-Request/EXT message with an F-bit set, at least one capability bit set, a Peer-ID TLV, a Server-ID TLV, and an AUTH TLV; d) said EAP Peer receives said EAP-Request/Ext message in c) above and transmits an EAP-Response/EXT message with an F-bit set, at least one capability bit set and an AUTH TLV; e) said EAP Server receives said EAP-Response/EXT message in d) and transmits an EAP-Success message. 19. The process of claim 3, further including having either said EAP peer or said EAP server send an EAP extension message with a bit set for error indication in the even that said peer or said server detects an error and with an AUTH TLV. 20. The process of claim 3, further including performing protected message exchange after creation of keying material to avoid capabilities information from being attacked by an attacker. 21. The process of claim 20, further including sequencing of multiple EAP methods inside of the EAP extension method. 22. The process of claim 21, further including creating a cryptographic binding by protecting each inner EAP method together with the outer EAP extension method with a key generated by its preceding successful inner method in the sequence and finally exporting EAP keying material generated by the last successful inner EAP method. 23. (canceled) 24. (canceled)