Basic Password Exchange within the Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
RFC 5421

[Ballot discuss]
I have cleared my original discuss, thanks for the great improvement
in the new version!

However, there is one remaining issue. My original discuss
called for documenting the security properties for this
method, as required by RFC 3748. This is now done in
the new version, except that I do not think it is completely
correct. Most of the security properties listed are
really properties of FAST, not GTC, and you could argue
how this should be presented. However, one of the items,
cryptographic binding seems downright wrong given that GTC
does not generate keys at all. Therefore prevention of
attacks related to binding is left completely outside the
method's technical means, and for deployment considerations
(just using the credentials inside FAST/GTC and not elsewhere,
for instance).

In the interest of a speedy resolution, I'm sending here a
suggested revision of Section 3.1. I believe this could be
put in via an RFC Editor's note so that the draft can be
approved. Comments and edits from the authors and Pasi would
of course be needed first:

  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 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.

[Ballot discuss]
I have cleared my original discuss, but there is one remaining
issue. My original discuss called for documenting the security
properties for this method, as required by RFC 3748. This is
now done in the new version, except that I do not think it
is completely correct. Most of the security properties listed
are really properties of FAST, not GTC, and you could argue
how this should be presented. However, one of the items,
cryptographic binding seems downright wrong given that GTC
does not generate keys at all. Therefore prevention of
attacks related to binding is left completely outside the
method's technical means, and for deployment considerations
(just using the credentials inside FAST/GTC and not elsewhere,
for instance). Here's a suggested revision of Section 3.1:

  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 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.

[Ballot discuss]
I have cleared my original discuss, but there is one remaining
issue. My original discuss called for documenting the security
properties for this method, as required by RFC 3748. This is
now done in the new version, except that I do not think it
is completely correct. Most of the security properties listed
are really properties of FAST, not GTC, and you could argue
how this should be presented. However, one of the items,
cryptographic binding seems downright wrong given that GTC
does not generate keys at all. Therefore prevention of
attacks related to binding is left completely outside the
method's technical means, and for deployment considerations
(just using the credentials inside FAST/GTC and not elsewhere,
for instance). Here's a suggested revision of Section 3.1:

  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:  Yes. Provided by the EAP-FAST Tunnel.
  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.

[Ballot discuss]
I have cleared my original discuss, but there is one remaining
issue. My original discuss called for documenting the security
properties for this method, as required by RFC 3748. This is
now done in the new version, except that I do not think it
is completely correct. Most of the security properties listed
are really properties of FAST, not GTC, and you could argue
how this should be presented. However, one of the items,
cryptographic binding seems downright wrong given that GTC
does not generate keys at all. Therefore prevention of
attacks related to binding is left completely outside the
method's technical means, and for deployment considerations
(just using the credentials inside FAST/GTC and not elsewhere,
for instance). Here's a suggested revision of Section 3.1:

  This section provides the needed security claim requirement for EAP
  [RFC3748].

  Auth. mechanism:        Password based.
  Ciphersuite negotiation: No, but 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:            Not applicable.
  Dictionary attack prot.: Yes. Provided by the EAP-FAST Tunnel.
  Fast reconnect:          Yes.
  Cryptographic binding:  Yes. Provided by the EAP-FAST Tunnel.
  Session independence:    Yes. Provided by the EAP-FAST Tunnel.
  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.

[Ballot discuss]
This method specification needs to be published.In general, I'm
very supportive of documenting the EAP methods that are in use. And my
understanding is that this particular method is in relatively wide
use, and documenting how it works will improve interoperability and
openness.

However, I have a few concerns with the document as it is
currently written. These are fixable, but require a new
revision:

1. First, I agree with what Pasi's Discuss says about the type number.
  However, the issue is actually even more complicated. EAP-GTC was
  underspecified in RFC 2284. And what do EAP-FAST implementation use
  as a type number, and can this be changed?

  Further discussion of this point is needed before we can resolve
  Pasi's Discuss.

2. Section 2 reference to "additional exchanges" seems underspecified,
  and I do not understand what I would have to do in my implementation
  to support this. Please be more specific.

3. Section 2 says '... where Value is the server challenge, such as
  "please enter your password"' Can you clarify whether there is
  ever any action that the peer needs to take based on the challenge
  value, other than to display it to the user? I'm troubled by the
  use of the term "challenge" whereas your example contains simply
  a displayed, static message. Clarification on what is expected
  from the implementations would be welcome here.

4. Security considerations text that is provided is reasonable, but
  does not contain all parts that RFC 3748 requires from an EAP
  method definition: see Section 7.2.1 of RFC 3748 and please
  provide an explanation for each security property listed therein.

  I realize that the applicability of RFC 3784 rules in this
  case is somewhat unclear, given that one could argue we are
  defining a part of another method (EAP-FAST) or merely clarifying
  another method (EAP-GTC). However, I think the readers would be
  best served by following the same template as regular method
  definitions have.

[Ballot discuss]
This method specification needs to be published.In general, I'm very
supportive of documenting the EAP methods that are use. And my
understanding is that this particular method is in relatively wide
use, and documenting how it works will improve interoperability and
openness.

However, I have a few concerns with the document as it is
currently written. These are fixable, but require a new
revision:

1. First, I agree with what Pasi's Discuss says about the type number.
  However, the issue is actually even more complicated. EAP-GTC was
  underspecified in RFC 2284. And what do EAP-FAST implementation use
  as a type number, and can this be changed?

  Further discussion of this point is needed before we can resolve
  Pasi's Discuss.

2. Section 2 reference to "additional exchanges" seems underspecified,
  and I do not understand what I would have to do in my implementation
  to support this. Please be more specific.

3. Section 2 says '... where Value is the server challenge, such as
  "please enter your password"' Can you clarify whether there is
  ever any action that the peer needs to take based on the challenge
  value, other than to display it to the user? I'm troubled by the
  use of the term "challenge" whereas your example contains simply
  a displayed, static message. Clarification on what is expected
  from the implementations would be welcome here.

4. Security considerations text that is provided is reasonable, but
  does not contain all parts that RFC 3748 requires from an EAP
  method definition: see Section 7.2.1 of RFC 3748 and please
  provide an explanation for each security property listed therein.

  I realize that the applicability of RFC 3784 rules in this
  case is somewhat unclear, given that one could argue we are
  defining a part of another method (EAP-FAST) or merely clarifying
  another method (EAP-GTC). However, I think the readers would be
  best served by following the same template as regular method
  definitions have.

[Ballot comment]
I support Pasi's discuss.  For the point about "appropriate language and
charset", I recommend referencing RFC 5198.  The same issue applies to
the CHALLENGE=.

I'm a bit concerned about having a fixed list of error codes.  This was
a mistake for SMTP, and sites reject passwords for so many reasons,
there's always a new one.  However, there are four general classes
of client behavior in response to an authentication failure here:

1. re-prompt for username/password.
2. give up, typically inviting user to make a support call
3. change password
4. notify user of temporary service outage, suggest they try again later

The distinction between these three can have profound impact on the
cost to operate a service.  While I can identify (1) - 691, several
cases of (2), and (3) - 648, I don't see an error code that means (4).
While 646 is a specific sub-case of (4), you need the general case.

[Ballot discuss]
I think this is a valuable document, as details of how to use EAP with
legacy password databases (which everyone does) have so far been
documented only in expired internet-drafts and vendor documents.

However, I have couple of concerns:

This document basically defines a new EAP method, but uses the the EAP
Type number for GTC (defined in RFC 3748). As the two methods won't
interoperate, they should have different names (maybe "EAP-FAST-GTC"?)
and use different numbers (BTW, this doesn't necessarily require IANA
allocation; just use Cisco's enterprise code + any number).

Section 2 says "The  is human-readable text in the appropriate
character set and language [RFC2484]" -- this might cover the PPP
case (although it introduces a rather complex layer dependency), but
doesn't tell what to do when EAP-FAST is used outside PPP (e.g. 
in 802.1X).


In addition, there's couple of places that probably need
fixing:

The document needs to cite draft-cam-winget-eap-fast-provisioning when
it e.g. talks about validating "the user identity with the I-ID in the
PAC-Opaque" and "Server-Unauthenticated Provisioning Mode" etc.

The packets use "LABEL=Value" format, and the recipient is expected to
ignore unknown labels (for future extensibility, presumably).
However, there's no text saying how the string is split to
"LABEL=Value" pairs (the answer is more complex than "they're
separated by spaces", since some of the values can contain spaces --
something like ABNF would be useful here).

Should there be IANA Considerations for the Labels?

Section 2, "The input should be processed...", upper-case "SHOULD"?

Section 2, "the ISK used for crypto-binding for EAP-FAST will be
filled with all zeros" -- Description of Crypto-Binding calculation in
RFC 4851 (Sections 5.2 and 5.3) doesn't include anything called ISK --
should this say that the MSKi is set to zero?

[Ballot comment]
The document writeup says "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." That doesn't come out in the document at all. I wonder if this should be explicitly called out in the abstract and/or introduction?

Proto write-up for draft-zhou-emu-fast-gtc-03.txt
-------------------------------------------------
(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding
to the IESG for publication?

I ,  Joseph Salowey, am the document shepherd for this document.  I have
reviewed it and I believe it is ready to be forwarded to the IESG for
publishing.

(1.b) Has the document had adequate review both from key members of the
interested community and others? Does the Document Shepherd have any
concerns about the depth or breadth of the reviews that have been
performed?

The document's purpose is to describe existing implementations of the
password exchange used within EAP-FAST. The document has been reviewed
by various different implementers of the EAP-FAST protocol.  Feedback
from their review has been used to make clarifications in the document.


(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization
or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the interested community has discussed
those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

No

(1.e) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

There is interest in the community to document the password protocol
used within EAP-FAST.  A number of vendors have expressed interest in
the publication of this document.  In addition other standards
organizations such as the WiFi Alliance are interested in referencing
the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough;
this check needs to be thorough. Has the document met all formal review
criteria it needs to, such as the MIB Doctor, media type and URI type
reviews?

Yes

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state? If such
normative references exist, what is the strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to support
the Area Director in the Last Call procedure for them [RFC3967].

The references are spit and conformant to RFC3967

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document describes
an Expert Review process has Shepherd conferred with the Responsible
Area Director so that the IESG can appoint the needed Expert during the
IESG Evaluation?

The IANA considerations section is consistent and complete.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

Not Applicable

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Writeup.  Recent
examples can be found in the "Action" announcements for approved
documents.

The approval announcement contains the following sections:

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 part of the ongoing effort to document existing deployed EAP
methods.  The purpose of this document is to publish existing behavior
and it is therefore not part of a working group effort. 

Document Quality

There are multiple implementations of EAP-FAST password exchange from
different vendors that interoperate.  A number of implementers have
reviewed this specification.

IANA Last Call comments:

Upon approval of this document, IANA will create the following
registry at http://www.iana.org/assignments/TBD:

Registry Name: EAP-GTC Error Codes
Reference: [RFC-zhou-emu-fast-gtc-03]
Registration Procedure: Specification Required

Registry:
code | Error Name | Reference
0-645 |Unassigned
646 | ERROR_RESTRICTED_LOGON_HOURS | [RFC-zhou-emu-fast-gtc-03]
647 | ERROR_ACCT_DISABLED | [RFC-zhou-emu-fast-gtc-03]
648 | ERROR_PASSWD_EXPIRED | [RFC-zhou-emu-fast-gtc-03]
649 | ERROR_NO_DIALIN_PERMISSION | [RFC-zhou-emu-fast-gtc-03]
650-690 | Unassigned
691 | ERROR_AUTHENTICATION_FAILURE | [RFC-zhou-emu-fast-gtc-03]
692-708 | Unassigned
709 | ERROR_CHANGING_PASSWORD | [RFC-zhou-emu-fast-gtc-03]
710-754 | Unassigned
755 | ERROR_PAC_I-ID-NO_MATCH | [RFC-zhou-emu-fast-gtc-03]
756-999999999| Unassigned

We understand the above to be the only IANA Actions for this
document.

Proto write-up for draft-zhou-emu-fast-gtc-03.txt
-------------------------------------------------
(1.a) Who is the Document Shepherd for this document? Has the Document
Shepherd personally reviewed this version of the document and, in
particular, does he or she believe this version is ready for forwarding
to the IESG for publication?

I , Joseph Salowey, am the document shepherd for this document. I have
reviewed it and I believe it is ready to be forwarded to the IESG for
publishing.

(1.b) Has the document had adequate review both from key members of the
interested community and others? Does the Document Shepherd have any
concerns about the depth or breadth of the reviews that have been
performed?

The document's purpose is to describe existing implementations of the
password exchange used within EAP-FAST. The document has been reviewed
by various different implementers of the EAP-FAST protocol. Feedback
from their review has been used to make clarifications in the document.


(1.c) Does the Document Shepherd have concerns that the document needs
more review from a particular or broader perspective, e.g., security,
operational complexity, someone familiar with AAA, internationalization
or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or issues
with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the interested community has discussed
those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

No

(1.e) How solid is the consensus of the interested community behind this
document? Does it represent the strong concurrence of a few individuals,
with others being silent, or does the interested community as a whole
understand and agree with it?

There is interest in the community to document the password protocol
used within EAP-FAST. A number of vendors have expressed interest in
the publication of this document. In addition other standards
organizations such as the WiFi Alliance are interested in referencing
the document.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is entered into the ID
Tracker.)

No

(1.g) Has the Document Shepherd personally verified that the document
satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough;
this check needs to be thorough. Has the document met all formal review
criteria it needs to, such as the MIB Doctor, media type and URI type
reviews?

Yes

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that are not
ready for advancement or are otherwise in an unclear state? If such
normative references exist, what is the strategy for their completion?
Are there normative references that are downward references, as
described in [RFC3967]? If so, list these downward references to support
the Area Director in the Last Call procedure for them [RFC3967].

The references are spit and conformant to RFC3967

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body of the
document? If the document specifies protocol extensions, are
reservations requested in appropriate IANA registries? Are the IANA
registries clearly identified? If the document creates a new registry,
does it define the proposed initial contents of the registry and an
allocation procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document describes
an Expert Review process has Shepherd conferred with the Responsible
Area Director so that the IESG can appoint the needed Expert during the
IESG Evaluation?

The IANA considerations section is consistent and complete.

(1.j) Has the Document Shepherd verified that sections of the document
that are written in a formal language, such as XML code, BNF rules, MIB
definitions, etc., validate correctly in an automated checker?

Not Applicable

(1.k) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Writeup. Recent
examples can be found in the "Action" announcements for approved
documents.

The approval announcement contains the following sections:

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 part of the ongoing effort to document existing deployed EAP
methods. The purpose of this document is to publish existing behavior
and it is therefore not part of a working group effort.

Document Quality

There are multiple implementations of EAP-FAST password exchange from
different vendors that interoperate. A number of implementers have
reviewed this specification.