Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)
draft-funk-eap-ttls-v0-05

[Ballot discuss]
The client initiated EAP authentication described in 11.2.1 would seem
to break the EAP state machine.  At a minimum, the document needs to
describe how an eap-ttls implementation affects the state machine and
(hopefully) why this is safe in the given context/environment.

[Ballot discuss]
I believe this proposal would be significantly improved by adding support
for channel bindings (RFC 5056), and that doing so would not require a
great deal of effort.  Basically, this would define the rules for
extracting channel binding information from EAP-TTLS so that an EAP
mechanism with channel bindings could then use that information.

[Ballot comment]
Section 9.2 indicates that AVPs may be sent in the clear in the
  initial Start packet from the server. Possible uses are indicated
  in the text.  However, it is unclear which AVPs are allowed to
  appear here.

  Joel Halpern suggested in his Gen-ART review an additional sentence
  at the end of the first paragraph of section 11.3: "Multiple
  authentication is only supported by this protocol in conjunction
  with EAP."

[Ballot discuss]
Section 9.2.1 or 14 needs to describe downgrade attacks against
version negotiation (since the EAP-TTLS header is not
integrity-protected).

Section 10 says "Specifically, the AVP Codes used in EAP-TTLS are
semantically equivalent to those defined for Diameter, and, by
extension, RADIUS. Also, the representation of the Data field of an
AVP in EAP-TTLS is identical to that of Diameter."

This statement should be updated to reflect the last paragraph of
Section 16. Something like this:

  "Specifically, although EAP-TTLS uses the same AVP Codes and
  syntax as Diameter, the semantics may differ, and most Diameter
  AVPs do not have any well-defined semantics in EAP-TTLS. A
  separate "EAP-TTLS AVP Usage" registry lists the AVPs that can be
  used within EAP-TTLS and their semantics in this context (see
  Section 16 for details)."

The document also should explicitly say that an EAP-TTLS server
MUST NOT copy AVPs from EAP-TTLS to RADIUS/Diameter messages unless
the server understands that AVP, and its semantics within EAP-TTLS
have been defined. (Copying unknown AVPs could lead to security
problems.)

There seems to be two different ways to encode vendor-specific AVPs
(such as MS-CHAP-Response): setting the V bit and placing Vendor-ID
in the AVP header, or clearing the V bit and using AVP code 26.
Although Section 10.3 seems to say something about this, it falls
short of actually saying which format(s) MUST be used or supported
when e.g. implementing MS-CHAP/MS-CHAPv2 in Sections 11.2.3/11.2.4.
(What do existing implementations do?)

The document should say something about EAP-Message attributes and
fragmentation. Diameter doesn't use >253 byte EAP-Message
attributes; it has a separate EAP-Payload AVP. Does EAP-TTLS
inherit the 253-byte restriction from EAP-Message RADIUS attribute?
Is the recipient required to support reassembly? Or is the EAP-TTLS
server required to do fragmentation/reassembly if passing this to
RADIUS backend? (What do existing implementations do?)

Section 11.2.1 needs some additional text, since EAP (as defined in
RFC 3748) cannot be initiated by the client sending an EAP Response.
You could specify e.g. that an EAP Identity Request (with identifier
0 and empty contents) is sent, but it's "compressed" to zero bytes
on the wire, but the client behaves as if it had received this packet.

Section 11.3 probably needs some more details, since RFC 3748 does
not describe how a sequence of EAP methods would work (and explicitly
forbids such sequences outside tunnels). For example, will there
be several EAP Identity exchanges? Are you required to run a method
to a well-defined point (where normal EAP would allow you to
return EAP Failure and/or EAP Success), or can you abandon a method
in a middle of an exchange?

IANA Last Call comments:

Action 1:

Upon approval of this document, the IANA will make the following
changes in the "Extensible Authentication Protocol (EAP) Registry"
located at
http://www.iana.org/assignments/eap-numbers
sub-registry "Method Types - per [RFC3748]"

OLD:

Value Description Reference
----- ----------- ---------

21 EAP-TTLS [Funk]

NEW:

21 EAP-TTLS [RFC-funk-eap-ttls-v0-04]


Action 2:

Upon approval of this document, the IANA will add the following
new registry to the “Extensible Authentication Protocol (EAP)
Registry” at
http://www.iana.org/assignments/eap-numbers

Registry Name: EAP-TTLS AVP Usage
Reference: [RFC-funk-eap-ttls-v0-04]
Registration Procedures: IETF Consensus

Note: The following table lists whether the AVP may appear in a
packet from server to client ("Request") and/or in a packet from
client to server ("Response"), and whether the AVP MUST be
implemented ("MI").

Name        Request    Response  MI    Reference
----------  -----------  ---------  -----  ----------
User-Name X [RFC-funk-eap-ttls-v0-04]
User-Password X [RFC-funk-eap-ttls-v0-04]
CHAP-Password X [RFC-funk-eap-ttls-v0-04]
Reply-Message X [RFC-funk-eap-ttls-v0-04]
CHAP-Challenge X [RFC-funk-eap-ttls-v0-04]
EAP-Message X X X [RFC-funk-eap-ttls-v0-04]
MS-CHAP-Response X [RFC-funk-eap-ttls-v0-04]
MS-CHAP-Error X [RFC-funk-eap-ttls-v0-04]
MS-CHAP-NT-Enc-PW X [RFC-funk-eap-ttls-v0-04]
MS-CHAP-Domain X [RFC-funk-eap-ttls-v0-04]
MS-CHAP-Challenge X [RFC-funk-eap-ttls-v0-04]
MS-CHAP2-Response X [RFC-funk-eap-ttls-v0-04]
MS-CHAP2-Success X [RFC-funk-eap-ttls-v0-04]
MS-CHAP2-CPW X [RFC-funk-eap-ttls-v0-04]


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

Please find my review below. The review has started from the point of view of trying to ensure that the protocol is adequately described so that others can implement it.

I did not see major problems, but you need to provide a revised draft to address the below issues. The biggest issues relate to making the spec tight enough so that we know what has to be implemented, what extensions would require, make it clearer earlier on what the security properties are, etc.

Please also address any issues resulting from the thread with Bernard.

Technical:

>    The client and access point initiate an EAP conversation to
>    negotiate the client's access to the network. Typically, the access
>    point issues an EAP-Request/Identity to the client, which responds
>    with an EAP-Response/Identity. Note that the client does not include
>    the user's actual identity in this EAP-Response/Identity packet; the
>    user's identity will not be transmitted until an encrypted channel
>    has been established.
This is vague, skips over important detail such as AAA routing, and potentially confusing for implementers. Suggested edit:

... does not include the user's identity other than for routing purposes in this EAP-Response/Identity packet (see Section 7.3 and RFC 3748 Section 5.1); the user's identity ...

>    Keying material for the subsequent data connection between client
>    and access point may be generated based on secret information
>    developed during the TLS handshake between client and TTLS server.
... is generated ...

(Too vague as written now. Later text makes it clear that this key material is only needed in some EAP deployments.)

>    Functions other than authentication MAY also be performed during
>    phase 2. This document does not define any such functions; however,
>    any organization or standards body is free to specify how additional
>    functions may be performed through the use of appropriate AVPs.
This is problematic. Complete freedom to do anything... I would suggest defining in this document the functions that are known and implemented, and then setting rules on how new applications can be defined.

Basically, Section 11 is the definition of the currently supported AVPs. The set of supported AVPs should be summarized and their mandatory-to-implement status, if any, should be listed in the summary table.

Are there others? If yes, please add documentation.

Can we state that setting M bit on a vendor-specific AVP is disallowed?

Finally, I would propose that the IANA considerations section be changed as follows:

  This document specifies how authentication may be performed within
  the secure tunnel established by EAP-TTLS. Other functions MAY also
  be performed within this tunnel; standards bodies and other
  organizations MAY specify how such functions are performed through
  the use of existing or newly defined AVPs.

=>

    Section 11 of this document specifies how certain authentication mechanisms
    the secure tunnel established by EAP-TTLS may be performed within
    the secure tunnel established by EAP-TTLS. New mechanisms and other
    functions MAY also be performed within this tunnel; where such extensions
    use something else than vendor-specific AVPs their semantics needs to be
    specified in new RFCs. That is, there are TTLS specific processing rules
    related to the use of each individual AVP, even when such AVPs have already
    been defined for RADIUS or DIAMETER.

From Section 7.5.1:
>    One strategy to ensure that subsequent EAP-TTLS negotiations are
>    routed to the original TTLS server is for each TTLS server to encode
>    its own identifying information, for example, IP address, in the
>    session IDs that it generates. This would allow any TTLS server
>    receiving a session resumption request to forward the request to the
>    TTLS server that established the original session.

A lot of missing information here. What protocols to use, etc. Suggest deleting this paragraph.

>    Message Length
>      The Message Length field is four octets, and is present only if
>      the L bit is set. This field provides the total length of the raw
>      data message sequence prior to fragmentation.

Can you clarify whether this field is present in other than the first fragment? Ah, clear in the fragmentation section, never mind...

>    Data
>      For all packets other than a Start packet, the Data field
>      consists of the raw TLS message sequence or fragment thereof. For
>      a Start packet, the Data field may optionally contain an AVP
>      sequence.
How do you distinguish between AVP sequence and TLS message sequence content? But I'm reading on... (ah clearer, later).

Section 11.2.1:
> The client places the actual username in this packet;
>    the privacy of the user's identity is now guaranteed by the TLS
>    encryption. This username must be a Network Access Identifier (NAI)
>    [RFC4282]; that is, it must be in the following format:
>
>      username@realm
This is problematic, because you may be specifying here something that overrides the behaviour specified for another EAP method. For instance, TTLS run inside TTLS would be unable to satisfy both the requirement to not send identity and to send the identity.

Suggested rewrite:

Depending on the requirements specified for the inner method, the client MAY now place the actual username ... This username is typically a Network Access Identifier (NAI) [RFC4282]; that is, it is typically in the following format: ...

> Section 11.4

We need to specify what is mandatory to implement for a conforming specification. Otherwise interoperability is not achieved. You do not need to go overboard with the requirements, simply state what common implementations support as MUST requirements. Is  EAP  enough, or do you also need to support some of the other things listed in previous sections?

Can you also state the implicit requirement that EAP-MD5 needs to be supported?

From Section 11.3:

>    In some cases, it is desirable to perform multiple user
>    authentications. For example, a AAA/H may want first to authenticate
>    the user by password, then by token card.
>
>    The AAA/H may perform any number of additional user authentications
>    using EAP, simply by issuing a EAP-Request with a new protocol type
>    once the previous authentication succeeded but prior to issuing an
>    EAP-Success or accepting the user via the AAA carrier protocol.
>
>    For example, an AAA/H wishing to perform MD5-Challenge followed by
>    Generic Token Card would first issue an EAP-Request/MD5-Challenge
>    and receive a response. If the response is satisfactory, it would
>    then issue EAP-Request/Generic Token Card and receive a response. If
>    that response were also satisfactory, it would issue EAP-Success.

This is vague. Are the EAP conversations considered part of the same or different EAP runs? How would this interact with the EAP state machine as defined in RFC 4137? Do you allowed new or changed EAP Identity runs between the methods? If you consider all the EAP runs as part of the same conversation, would there be any keying considerations, such as using keys from all methods? And if yes, how would they be combined?

Is sequencing of non-EAP authentication allowed? Or mixing of EAP and non-EAP?

> Section 13
There should be at least a paragraph of text on each item that has not so far been documented in Section 15.

From Section 5.4:
>
>    As the diagram above indicates, EAP-TTLS allows user identity and
>    password information to be securely transmitted between client and
>    TTLS server, and generates keying material to allow network data
>    subsequent to authentication to be securely transmitted between
>    client and access point.

A bold claim, particularly considering the below comment.

>    Channel binding:          Not at present, though support can be
>                              added in future
This needs to be mentioned and highlighted earlier, already in the introduction. This is a serious vulnerability -- one that we know of, and one that does not prevent publishing this document. But it is one that we need to warn people about, and I would also like the extension document to move through fast. Do we know if the extension has been implemented widely? If yes, that might even be collapsed all into the base. (If not, lets not rewrite history about what the protocol is. In that case lets just document what the issues are.)

Editorial:

From the abstract:
> The secure connection
> established by the handshake may then be used to allow the server to
> authenticate the client using existing, widely-deployed
> authentication mechanisms such as RADIUS.
> 
Technically, its not RADIUS that is the authentication method here, its just a carrier protocol. Suggested rewrite:

/authentication mechanisms such as RADIUS/authentication mechanisms/

The same text appears in Section 1 as well, please change that too.

From the abstract:
>    This document describes EAP-TTLSv0; that is, the original version 0
>    of the EAP-TTLS protocol.

Add ... which has been widely deployed.

From Section 5.1:
>    The client and access point must also agree on an
>    encryption/validation algorithm to be used based on the keying
>    material. In some systems, both these devices may be preconfigured
>    with this information, and distribution of the keying material alone
>    is sufficient. Or, the carrier protocol between client and access
>    point may provide a mechanism to negotiate an algorithm.
Validation? Or authentication? Overall, this paragraph is suspect I would simply delete it.

Note: the document has quite a bit of material that it would not need to have if it simply focused on defining the TTLS method, not the system. I think you should keep the material than attempt a major edit, however. It can be useful for some readers. I'm only commenting on this material when it seems incorrect, as in this case.

From Section 9.1:
> The V bit is set to
The V field is set to ...

Elsewhere in the document this field is called the "V field".

> Section 11.2.1
This section would be clearer if written without assumption that AAA is used. Instead of talking about Access-Rejects, discussion of EAP behaviour within the tunnel would be more appropriate. Please consider rewriting this.

> Section 13, 14, 15
Section 14 is in a funny place, consider moving Section 15 contents to Section 13.

Also, please fix these issues from Laksminath:

> In the abstract, there is a reference to "cryptographic attacks."  We can probably delete "cryptographic."

>
> The text on anonymity (Page 14, Sec 7.3) has a SHOULD.  A MUST may be more appropriate.  As worded, the text says if anonymity is needed; well then, in that case, there is no scope for a mere recommendation.

> Next, inclusion of "realm" is a MAY.  I guess it can go either way.  If the AP has a default TTLS server that

> it connects to, or if the AP itself is the TTLS server, in that case, no realm-based routing is necessary. Perhaps an explanation along those lines would make it clear?

State Change Notice email list have been change to paul@funk.com, sblakewilson@bcisse.com, draft-funk-eap-ttls-v0@tools.ietf.org,ldondeti@qualcomm.com, emu-chairs@tools.ietf.org from paul@funk.com, sblakewilson@bcisse.com, draft-funk-eap-ttls-v0@tools.ietf.org,ldondeti@qualcomm.com