The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)
draft-cam-winget-eap-fast-06

[Ballot comment]
> If an inner EAP method is run, then the Peer-Id is obtained from the
> inner method.

What if multiple inner methods are run?

> EAP-FAST packets contain a three bit version field, following the TLS
> Flags field, which

All TLS data comes *after* the EAP-FAST version field. Did you
mean "following the EAP-FAST Flags field"?

[Ballot comment]
There are a couple of places in this document where the vendor-ID is coded in three octets, although a four octets coding could have been used. Is there a reason for doing this? I would not be too much concerned because this should suffice for all practical reasons (8,288,608 enterprises - right now only 27825 codes are allocated) but maybe a note should indicate that we are placing a limitation and what are the reasons.

IANA Last Call Comment:

Upon approval of this document, the IANA will make the following
changes in "Extensible Authentication Protocol (EAP) Registry"
registry located  at

http://www.iana.org/assignments/eap-numbers
subregistry "Method Types:"
OLD:
43 EAP-FAST [Cam-Winget]

NEW:
43 EAP-FAST [RFC-cam-wiget-eap-fast-05]



Action #2:
Upon approval of this document, the IANA will create a
new sub registry in the following registry "Extensible
Authentication Protocol (EAP)  Registry" registry
located at

http://www.iana.org/assignments/eap-numbers
The name of the sub-registry is:
"EAP-FAST TLV types"

Allocation policy: Specification Required as defined
in [RFC2434].
Initial contents of this registry will be:
Id Name Reference
0 Reserved [RFC-cam-wiget-eap-fast-05]
1 Reserved [RFC-cam-wiget-eap-fast-05]
2 Reserved [RFC-cam-wiget-eap-fast-05]
3 Result TLV [RFC-cam-wiget-eap-fast-05]
4 NAK TLV [RFC-cam-wiget-eap-fast-05]
5 Error TLV [RFC-cam-wiget-eap-fast-05]
7 Vendor-Specific TLV [RFC-cam-wiget-eap-fast-05]
9 EAP-Payload TLV [RFC-cam-wiget-eap-fast-05]
10 Intermediate-Result TLV [RFC-cam-wiget-eap-fast-05]
11 PAC TLV [I-D.cam-winget-eap-fast-provisioning]
12 Crypto-Binding TLV [RFC-cam-wiget-eap-fast-05]
18 Server-Trusted-Root TLV [RFC-cam-wiget-eap-fast-05]
19 Request-Action TLV [RFC-cam-wiget-eap-fast-05]
20 PKCS#7 TLV [I-D.cam-winget-eap-fast-provisioning]


Action #3:
Upon approval of this document, the IANA will create a new
sub registry in the following registry "Extensible
Authentication Protocol (EAP)  Registry" registry
located at

http://www.iana.org/assignments/eap-numbers
The name of the sub-registry is:
"EAP-FAST Error-TLV error-codes"
Allocation policy: Specification Required as defined in [RFC2434].
Initial contents of this registry will be:
id Name Reference
2001 Tunnel_Compromise_Error [RFC-cam-wiget-eap-fast-05]
2002 Unexpected_TLVs_Exchanged [RFC-cam-wiget-eap-fast-05]


Action #4:
Upon approval of this document, the IANA will create a new sub
registry in the following registry "Extensible Authentication
Protocol (EAP)  Registry" registry located at

http://www.iana.org/assignments/eap-numbers
The name of the sub-registry is:
"Request-Action TLV action code"
Allocation policy: Specification Required as defined in [RFC2434].
The initial actions defined are:
id Name Reference
1 Process-TLV [RFC-cam-wiget-eap-fast-05]
2 Negotiate-EAP [RFC-cam-wiget-eap-fast-05]



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

-------------------
Question:

In section 4.2.2 the Result TLV has two listed
values in a 16 bit field, Is there a need to create a
registry for status codes other than the two defined in
the document?
The same question applies to section 4.27 Intermediary-Result
TLV and  are the status values the same ?

The authors are incorporating most of the feedback received during Last Call.  They are going to leave the TLS extension in the specification, and they have submitted that portion to the TLS group.

Last Call raised a significant issue.  The document defines a new TLS extension, which by the rules in RFC 3546 requires standards action.  The authors need to decide if they want to move this document to the Standard-Track, separate the TLS extension portion into a Standard-Track document, or abandon publication.