Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)
draft-cam-winget-eap-fast-provisioning-10

[Ballot discuss]
Version -10 addresses all my concerns except one minor detail: the
text in Section 4.1.3 says that the User Authorization PAC is sent to
the server in a PAC TLV -- but which attribute? I guess it's
PAC-Opaque -- but then the text in Section 4.2.3 needs to be updated
(it says the PAC-Opaque attribute is sent by the server; here it would
be sent by the client).

[Ballot discuss]
Its good that we finally get the provisioning spec out. I think
the spec is in reasonable shape but needs one more revision to
clarify a number of details. I also agree with Pasi's issues,
and they should be fixed. Here are the additional things that I
found:

> Since the server is not authenticated in the Server-Unauthenticated
> Provisioning Mode, it is possible that an attacker may intercept the
> TLS tunnel.  When using this mode, an inner, phase 2, EAP method
> SHOULD be used to provide authentication and man-in-the-middle
> detection as described in Section 6.  If an anonymous tunnel is used
> then the peer and server MUST negotiate and successfully complete an
>  EAP method supporting mutual authentication and key derivation.

It seems that the SHOULD and the MUST in conflict. They seem to
be acting on the same condition (unauthenticated tunnel), but have
a different keyword and different actions. Or am I missing something
obvious?

Also, Section 3.2 says "Once a protected tunnel is established, the
peer and server MAY wish to execute additional authentication and
perform checks on the integrity of the TLS tunnel."

> 4 - A-ID
> 
>    A-ID is the identity of the authority that issued the PAC.
>    The A-ID is intended to be unique across all issuing servers
>    to avoid namespace collisions.  The A-ID is used by the peer
>    to determine which PAC to employ.  This attribute MUST be
>    included in the PAC-Info attribute.  The A-ID MUST match the
>    A-ID the server used to establish the tunnel.  Since many
>    existing implementations expect the A-ID to be 16 octets in
>    length, it is RECOMMENDED that length of an A-ID be 16
>    octets for maximum interoperability.
> 
> 5 - I-ID
> 
>    Initiator identifier (I-ID) is the peer identity associated
>    with the credential.  The server employs the I-ID in the
>    EAP-FAST Phase 2 conversation to validate that the same peer
>    identity used to execute EAP-FAST Phase 1 is also used in at
>    minimum one inner EAP method in EAP-FAST Phase 2.  If the
>    server is enforcing the I-ID validation on inner EAP method,
>    then I-ID MUST be included in PAC-Info, to enable the peer
>    to also enforce a unique PAC for each unique user.  If I-ID
>    is missing from the PAC-Info, it is assumed that the Tunnel
>    PAC can be used for multiple users and peer will not enforce
>    the unique Tunnel PAC per user policy.

It is unclear what formats these must be in, other than that
the length of the A-ID is 16 octets. Is A-ID an opaque octet
string, or does it have something to do with the server's
certificate's subjAltNames? Is I-D something that can be
given in an EAP Response/Identity packet, something that fits
various method-specific identity exchanges, or what?

Please clarify.

[Ballot discuss]
In general, the document is in good shape, but there are couple
of places that need some clarification (probably the intent is
correct, but the text isn't exactly saying what was intended).

Most important things first:

Section 3.1.1 says "it is highly RECOMMENDED that the peer validate
the server's certificate chain when performing server-side
authentication". If the certificate chain is not validated, it's not
obvious how it's different from not authenticating the server at
all. Rest of the document (e.g. 6.1.1) also assumes the server was
really authenticated.

Section 6.1.2 says "In Server-Unauthenticated Provisioning Mode the
TLS handshake does not assure protected communications with the server
because either an anonymous handshake is negotiated or the peer lacks
the necessary information to complete the authentication of the
server." The part "or the peer lacks.." suggests that you could do
Server-Unauthenticated mode with RSA ciphersuites (instead of
DH_anon), and just omit verifying the certificate. In most places that
use TLS, that would be indeed fine -- but not here. (The cryptographic
binding doesn't work for RSA cipher suites, because a MitM can do an
attack where both the valid client, attacker, and valid server end up
having the same master secret value. This can't happen with DH_anon
cipher suites.) I guess this indeed noted in last paragraph of Section
6.1 (which incorrectly talks about *authenticated* ephemeral DH,
although the section is about Server-Unauthenticatd mode), but rest of
the document isn't fully consistent.

Section 4.1.3: How is the User Authorization PAC sent to the server?
(It's inside the TLS tunnel, but e.g. the description of the
PAC-Opaque TLV says it's sent by the server).  Also, apparently User
Authorization PAC is not associated with a key, although it's not
clear, since Section 1.2 says "it does not typically contain a
key". If it *does* contain a key, how is that used?

Section 6.4: If this section intends to profile TLS by saying that the
generator MUST be 2, and clients are required only to support the
groups in RFC3526, it needs to be clearer.

Section 6.4: I'm not sure everyone would agree that computing new
random groups actually improves security (it brings in complexity that
may decrease security, and it's not really needed -- e.g. IKEv2
doesn't support it at all).

Section 3.5 provides two different ways to run another EAP-FAST
exchange (either send new ClientHello/etc. in clear, or send them
encrypted using the currently active cipher). Are both of these
mandatory to support?



Other clarifications and/or nits:

Section 2 (paragraph beginning "Since the server..") first says
an inner EAP method SHOULD be used in server-unauthenticated mode;
then in the next sentence this is a MUST -- which is it?

Section 3.3, the key block partitioning doesn't match RFC 4346
(which doesn't have client_write_IV/server_write_IV here).

Section 3.1/3.3, "The ServerChallenge and ClientChallenge are only
used for the MSCHAPv2 exchange when Diffie-Hellman anonymous key
agreement is used in the EAP-FAST tunnel establishment."  This part
needs some clarification. Does this mean that when anything else
except DH_anon key exchange is used in TLS, the challenges are just
generated randomly (instead of derived from master secret)? (Some
text with clear "MUSTs" would be good here.)

Section 4.2.1...4.2.6: It would be clearer if these things were called
"PAC-Sub-TLVs" or something, since they e.g. use a different TLV
header format than the normal (top-level) TLVs in EAP-FAST.

Section 4.2.4, "A-ID is intended to be unique across all issuing
servers": is there some guidance on how to make this intent happen?
(I.e., how servers should select their A-ID)?

Section 4.2.4 says PAC-Type is a mandatory TLV, but including it is
not mandatory. This is confusing (and these "Sub-TLVs" don't have a
"Mandatory" bit like the "normal TLVs", so that can't be meant here
either)

Section 4.2.4, "UNIX UTC time" probably should be something like "the
number of seconds, excluding leap seconds, after midnight UTC, January
1, 1970" (quoted from RFC 4049).

Section 4.3.2: PKCS#7 (old version of CMS) allows a lot of different
signed, encrypted, etc. data structures. The text needs to be clearer
about what is meant; I'd guess it's a DER-encoded ContentInfo
structure, with contentType set to signedData, and content set to a
SignedData structure containing the following: (*note* somebody should
check that these are actually correct)

- version is 1
- digestAlgorithmIdentifiers is an empty set
- contentInfo.contentType is pkcs7-data
- contentInfo.content is not present
- certificates contains the certificate or certificate chain
  using the "Certificate" syntax (not ExtendedCertificate)
- crls is not present
- signerInfos is an empty set

(*NOTE* these are my guesses based on RFC 2315 and the output of
OpenSSL's crl2pkcs7/asn1parse tools -- if we can't find a reference
where these are specified, someone needs to check that this is
correct.)

Section 5, "Values from 11 to 63 are reserved" (and similar text later):
does this mean "are managed by Cisco instead of IANA"? (I'd be fine
with that, but "Reserved" has quite different meaning)

Section 5: RFC 2434 has been obsoleted by RFC 5226; the new document
also requires e.g. giving names to registries, etc.

[Ballot comment]
When defining a registry, it's helpful to give a title for the registry
as this is the only way readers of the document can find the IANA registry.

For example, "EAP-FAST PAC Attribute Types" registry, or
"PAC Attribute Type" sub-registry of the "EAP-FAST" registry.

[Ballot comment]
Vijay Gurbani did a Gen-ART Review of -08 and -09 of this document.
  Please consider the two comments that he raised:

  1/ In S4.1.{2,3}, there is a term "PAC opaque".  I think you
    mean "PAC-Opaque", the opaque data that was defined in S4.1.1.

  2/ In S6.3, first paragraph: should the "should" on line 3 be
    normative?  More so especially since the "MAY" seven lines
    down is normative.

[Ballot comment]
Vijay Gurbani did a Gen-ART Review of -08 and -09 of this document.
  Please consider the two comments that he raised:

  1/ In S4.1.{2,3}, there is a term "PAC opaque".  I think you
    mean "PAC-Opaque", the opaque data that was defined in S4.1.1.

  2/ In S6.3, first paragraph: should the "should" on line 3 be
    normative?  More so especially since the "MAY" seven lines
    down is normative.

[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?

IANA Last Call comments:

Action #1:

Upon approval of this document, the IANA will create the following
registry in the "EAP-FAST Registry" page to be located at
http://www.iana.org/assignments/TBD

Registry Name: PAC Attribute types
Reference: [RFC-cam-winget-eap-fast-provisioning-08]
Registration Procedure: Specification Required

Registry:
Value | Description | Reference
----------+-------------------------------------+-----------
0 | ??? | [RFC-cam-winget-eap-fast-provisioning-08]
1 | PAC-Key | [RFC-cam-winget-eap-fast-provisioning-08]
2 | PAC-Opaque | [RFC-cam-winget-eap-fast-provisioning-08]
3 | PAC-Lifetime | [RFC-cam-winget-eap-fast-provisioning-08]
4 | A-ID | [RFC-cam-winget-eap-fast-provisioning-08]
5 | I-ID | [RFC-cam-winget-eap-fast-provisioning-08]
6 | Reserved | [RFC-cam-winget-eap-fast-provisioning-08]
7 | A-ID-Info | [RFC-cam-winget-eap-fast-provisioning-08]
8 | PAC-Acknowledgement | [RFC-cam-winget-eap-fast-provisioning-08]
9 | PAC-Info | [RFC-cam-winget-eap-fast-provisioning-08]
10 | PAC-Type | [RFC-cam-winget-eap-fast-provisioning-08]
11-64 | Reserved | [RFC-cam-winget-eap-fast-provisioning-08]
65-255 | Unassigned |

**QUESTION: Is value 0 reserved or available for assignment?


Action #2:

Upon approval of this document, the IANA will create the following
registry in the "EAP-FAST Registry" page to be located at
http://www.iana.org/assignments/TBD

Registry Name: PAC-Type values used in the PAC-Type TLV
Reference: [RFC-cam-winget-eap-fast-provisioning-08]
Registration Procedure: Specification Required

Registry:
Value | Description | Reference
----------+-------------------------------------+-----------
0 | ???? | [RFC-cam-winget-eap-fast-provisioning-08]
1 | Tunnel PAC | [RFC-cam-winget-eap-fast-provisioning-08]
2 | Machine Authentication PAC | [RFC-cam-winget-eap-fast-provisioning-08]
3 | User Authorization PAC | [RFC-cam-winget-eap-fast-provisioning-08]
11-64 | Reserved | [RFC-cam-winget-eap-fast-provisioning-08]
65-255 | Unassigned |

**QUESTION: Is value 0 reserved or available for assignment?


Action #3:

Upon approval of this document, the IANA will create the following
registry in the "EAP-FAST Registry" page to be located at
http://www.iana.org/assignments/TBD

Registry Name: Credential-Format
Reference: [RFC-cam-winget-eap-fast-provisioning-08]
Registration Procedure: Specification Required

Registry:
Value | Description | Reference
----------+-------------------------------------+-----------
0 | ???? | [RFC-cam-winget-eap-fast-provisioning-08]
1 | PKCS#7-Server-Certificate-Root | [RFC-cam-winget-eap-fast-provisioning-08]
2-64 | Reserved | [RFC-cam-winget-eap-fast-provisioning-08]
65-255 | Unassigned

**QUESTION: Is value 0 reserved or available for assignment?


Action #4:

Upon approval of this document, the IANA will make the following
changes in the "Extensible Authentication Protocol (EAP) Registry"
registry at http://www.iana.org/assignments/eap-numbers
Registry Name: EAP-FAST TLV Types (Value 43)

OLD:
Value Description Reference
----- ----------------
11 PAC TLV [draft-cam-winget-eap-fast-provisioning]
18 Server-Trusted-Root TLV [draft-cam-winget-eap-fast-provisioning]
20 PKCS#7 TLV [draft-cam-winget-eap-fast-provisioning]

NEW:
Value Description
----- ----------------
11 PAC TLV [RFC-cam-winget-eap-fast-provisioning-08]
18 Server-Trusted-Root TLV [RFC-cam-winget-eap-fast-provisioning-08]
20 PKCS#7 TLV [RFC-cam-winget-eap-fast-provisioning-08]


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

Proto write-up for draft-cam-winget-eap-fast-provisioning-08
--------------------------------------------------------------
(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
EAP-FAST provisioning protocol. 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 provisioning aspects
of 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 summarize 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. EAP-FAST also enables the provisioning credentials or other
information through this protected tunnel. This document describes the
use of EAP-FAST for dynamic provisioning.


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 provisioning from
different vendors that interoperate. A number of implementers have
reviewed this specification.