Approval announcement
Draft of message to be sent after approval:
Announcement
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
RFC Editor <rfc-editor@rfc-editor.org>
Subject: Document Action: 'Basic Password Exchange within the
Flexible Authentication via Secure Tunneling Extensible
Authentication Protocol (EAP-FAST)' to Informational RFC
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
Ballot Text
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.