The IESG has approved the following document: - 'Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST) ' <draft-zhou-emu-fast-gtc-05.txt> as an Informational RFC This document has been reviewed in the IETF but is not the product of an IETF Working Group. The IESG contact person is Tim Polk. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-zhou-emu-fast-gtc-05.txt Technical Summary The flexible authentication via secure tunneling EAP method (EAP-FAST) enables secure communication between a peer and a server by using Transport Layer Security (TLS) to establish a mutually authenticated tunnel. Within this tunnel a basic password exchange, based on the generic token card method (EAP-GTC), may be executed to authenticate the peer. Working Group Summary This is not the product of any working group. This is part of the ongoing effort to document existing deployed EAP methods. The purpose of this document is to publish existing behavior. Document Quality There are multiple implementations of EAP-FAST password exchange from different vendors that interoperate. A number of implementers have reviewed this specification. Personnel Joe Salowey is the Document Shepherd; Tim Polk is the Responsible Area Director. RFC Editor Note Please make the following two changes. (1) In Section 2, please make the following substitution: OLD TEXT: The input SHOULD be processed according to [RFC5198]. NEW TEXT: The user name and password input SHOULD be processed according to [RFC4282] Section 2.4 and the server challenges SHOULD be processed according to [RFC5198]. (2) Please replace the text in Section 3.1 with the following: NEW This section provides the needed security claim requirement for EAP [RFC3748]. Auth. mechanism: Password based. Ciphersuite negotiation: No. However, such negotiation is provided by EAP-FAST for the outer authentication. Mutual authentication: No. However, EAP-FAST provides server side authentication. Integrity protection: No. However, any method executed within the EAP-FAST tunnel is protected. Replay protection: See above. Confidentiality: See above. Key derivation: Keys are not generated, see Section 2. However, when used inside EAP-FAST, the outer method will provide keys. See [RFC4851] for the properties of those keys. Key strength: See above. Dictionary attack prot.: No. However, when used inside the EAP-FAST tunnel, the protection provided by the TLS tunnel prevents an off-line dictionary attack. Fast reconnect: No. However, EAP-FAST provides a fast reconnect capability which allows reusing an earlier session authenticated by EAP-FAST-GTC. Cryptographic binding: No. Given that no keys are generated, EAP-FAST-GTC or its use within EAP-FAST can not provide a cryptographic assurance that no binding attack has occurred. EAP-FAST-GTC is required to only run within a protected tunnel, but even the use of the same credentials in some other, unprotected context might lead to a vulnerability. As a result, credentials used in EAP-FAST-GTC SHOULD NOT be used in other unprotected authentication mechanisms. Session independence: No. However, EAP-FAST provides session independence. Fragmentation: No. However, EAP-FAST provides support for this. Key Hierarchy: Not applicable. Channel binding: No, though the outer method, EAP-FAST can be extended for this. _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
