Subject: [eap] Review of EAP-TTLSv4

From: Florent Bersani <[email-masked]>
Date: Wed, 28 Apr 2004 15:33:31 +0200

Hi Paul and Simon,

Please find below a quick review of EAP-TTLSv4: I have only very minor 
(rather editorial) remarks IMHO.

Many thanks for posting this nice work.

Hope this helps,
BR,

Florent

Page 1

*"Category: Standards Track"*

FMOI, is it that you really wish that EAP-TTLS become standards track? 
If so, I have two cents questions like: do you intend to proceed as an 
individual submission or wait till a WG is chartered/rechartered to 
draft EAP methods? or what would then be the relationship to PEAP - 
since these two protocols have many common points and I do not believe 
that it makes sense to have two standards track protocol so close? (BTW 
I intend to sum up the existing docs on common points/differences - and 
possibly add some if I find something relevant ;-) - between PEAP and 
EAP-TTLS, your feedback on this will be most appreciated)

Page 2

*"11. Key Distribution......................Error! Bookmark not defined.
11.1   AVPs for Key Distribution.........Error! Bookmark not defined.
11.1.1     XXX-Data-Cipher-Suite.........Error! Bookmark not defined.
11.1.2     XXX-Data-Keying-Material......Error! Bookmark not defined."*

Typos in the table of contents: update the table of contents

Page 3

*"Extensible Authentication Protocol (EAP) [2]"*

Perhaps would it be worth to start referencing EAP's revision... all the 
more that new IANA rules have been included in the revision (which makes 
the sentence "EAP may be extended with additional authentication 
protocols by registering such protocols with IANA" somewhat 
oversimplisitic).

Perhaps, taking some part of EAP's revision IANA considerations section 
would be fine, e.g.: "EAP methods may be allocated after the advice of a 
Designated Expert, with Specification Required or by IETF standards action".

*"In EAP-TTLS, the TLS handshake may be mutual; or it may be one-way, in 
which only the server is authenticated to the client."*

This remark applies to this sentence and the rest of the document: why 
not capitalize the "may" and include the standard Specification of 
Requirements section, e.g.: "In this document, several words are used to 
signify the requirements of the specification.  These words are often 
capitalized.  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]."?

Page 4

*"While this vulnerability has long been understood"*

To get things even clearer for the profane, why not include references 
like http://www.schneier.com/paper-pptpv2.pdf and 
http://mopo.informatik.uni-freiburg.de/pptp_mschapv2/pptp_mschapv2.html?

As far as I know, with PAP, CHAP and MS-CHAP, there is also the problem 
of mutual authentication: these protocols only identify the client and 
not the network, which is IMHO as serious a vulnerability as dictionary 
attacks... perhaps worth mentioning? and adding mutual authentication to 
the list of  authentication requirements at the end of page 5?

Page 9

*"In the most general case, however, it may be necessary for both client 
and access point to communicate their algorithm preferences to the TTLS 
server, and for the TTLS server to select one and communicate its choice 
to both parties. This information would be transported between access 
point and TTLS server via the AAA protocol, and between client and TTLS 
server via EAP-TTLS in encrypted form. "*

Could you please give an example of such a case? I believe this sentence 
is indeed not true (the general case is IMHO IEEE 802.11i that has its 
own mechanism to negotiate the ciphersuites and protect against 
downgrading attacks). Perhaps this went along with the section on keying 
information that was in version 3 and that you removed in this 
version... TBD(eleted)?

*"the user's identity will not be transmitted until an encrypted channel 
has been established. "*

... unless mutual authentication is used with TLS?

Page 10

*"to perform additional functions such as [...] and key distribution for 
the subsequent data connection. "*

Perhaps this went along with the section on keying information that was 
in version 3 and that you removed in this version... TBD?

Page 11

Generally, I would await the protocol stacks to show the upper layers at 
the top and the lower at the bottom, whereas you put it the other way 
round :-(

Page 12

*"These might include user authentication, negotiation of data 
communication security capabilities, key distribution, communication of 
accounting information, etc.."*

While I am convinced that is a very nice feature to have an extensible 
protected channel, I am concerned that "negotiation of data 
communication security capabilities, key distribution" might create some 
serious confusion as such features are definitely not trendy ;-)

*"EAP-TTLS is also intended for use in key distribution"*

Here also, to avoid confusion (I am easily confused ;-)), why not stick 
to the standard wording "key derivation"

*"Instead, a general model for key distribution is suggested"*

Where? Perhaps this went along with the section on keying information 
that was in version 3 and that you removed in this version... TBD?

Page 15

*"The client must, however, send other required AVPs, in particular key 
distribution AVPs, that are not associated with tunneled
   authentication in its first EAP-TTLS packet to the server that is 
capable of containing phase 2 TLS messages. The TTLS server does not
   retain client AVPs or key distribution preferences as part of session 
state, and the client is expected to resend those AVPs in
   each negotiation. 
   Thus phase 2 of a resumed session proceeds just as would a new 
session, minus tunneled authentication AVPs. For example, the client 
would send its key distribution preferences, and the TTLS server would 
respond with its key distribution selection. "

Perhaps all the key distribution stuff went along with the section on 
keying information that was in version 3 and that you removed in this 
version... TBD? However, it could be nice for the sake of clarity to 
precisely describe how new keying material (MSK and EMSK in EAP 
terminology) is derived when session resumption is used.

*"A TTLS server must not permit a session to be resumed if that session 
did not result in a successful authentication of the user during phase 2. "*

Right... unless authentication in phase 1 was mutual and there wasn't 
any phase 2. Indeed, I am asking myself if trying to have EAP-TTLS be a 
superset of EAP-TLS is a reasonable idea. For the sake of simplicity, 
when two parties know that they both have certificates, they should 
probably directly use EAP-TLS. Or do you intend to allow both types of 
clients (those with personal certificates and those with passwords) use 
the same method and consider that when a client is unable to respond to 
the server CERTREQ, the TLS handshake should still proceed (I am not 
sure TLS allows that, I'll have to check) and a phase mandatory phase 2 
occur? I think this "unifying question" is an interesting one... but I 
am not sure what the answer is... maybe keep things simple and separate, 
what do you reckon? Perhaps, you want to stick with the unified approach 
as you say later in the draft page 20 "however, in certain cases it may 
be desired to perform certificate authentication of the client during 
the TLS handshake as well as tunneled user authentication afterward. " 
FMOI, could you give me an example of such a case?

Page 17

*"For example, during session resumption, the client sends its Finished 
message first, then the TTLS server replies with its Finished message. 
The TTLS server cannot piggyback key distribution AVPs within the Record 
Layer in the same EAP-TTLS packet containing its Finished message, 
because it
      must wait for the client to indicate its key distribution 
preferences. But it is possible that the client has no preferences, and 
thus has no AVPs to send. The client simply sends a EAP-TTLS packet with 
no data, to allow the server to continue the negotiation by sending its 
key distribution selection. "*

Perhaps this went along with the section on keying information that was 
in version 3 and that you removed in this version... TBD?

Page 19

*"AVP Length

      The AVP Length field is three octets, and indicates the length of
      this AVP including the AVP Code, AVP Length, AVP Flags, Vendor-ID
      (if present) and Data."*

Although this may seem trivial to Diameter fans and clever people, 
perhaps would it be worth explicitly saying that this length is in bytes 
(some other protocols, e.g. EAP-SIM, use length in multiple of 4 bytes).

Page 20

*"Tunneled Authentication"*

Although I tend to agree with Glen's POV on the "crypto binding" 
problem, perhaps it would be worth to mention that you know of this 
alleged problem (e.g. draft-puthenkulam-eap-binding-04.txt) and state 
your opinion on it which may have guided design choices for EAP-TTLS

*"If the client were able to create both challenge and response, anyone 
able to observe a CHAP or MS-CHAP exchange could pose as that user, even 
using EAP-TTLS. "*

Could you please clarify, Do you mean that if an attacker has listened 
to a victim's CHAP or MS-CHAP authentication in clear (that is outside 
an EAP-TTLS channel) and is able to choose the challenge used within an 
EAP-TTLS channel, he is able to successfully authenticate (the simplest 
form is a mere replay attack)? If this is the case, I would rather say 
that the main problem is that the victim performed a CHAP or MS-CHAP in 
clear!!! Because of the security flaws of these protocols, this is a 
very bad idea!!! (In addition, this would make you subject to some kind 
of crypto binding related threat :-().

Section 10.2.1

*This process continues until the AAA/H issues an Access-Accept or 
Access-Reject, at which point the TTLS server completes the negotiation 
by sending an EAP-Success or EAP-Failure to the access point using the 
AAA carrier protocol. "*

Could you please clarify, Do we have two EAP-Success/Failure that are 
sent: one within the EAP-TTLS channel and the other one outside (in case 
EAP is used within EAP-TTLS)? BTW, this more generally raises IMHO the 
issue of EAP-TTLS providing protected result indications or not, which 
would be worth explaining? For instance, you may consider to have 
protected result indication in section 10.2.4 "Upon receipt of the 
MS-CHAP2-Success AVP, the client is able to authenticate the AAA/H. If 
the authentication succeeds, the client sends an EAP-TTLS packet to the 
TTLS server containing no data. Upon receipt of the empty EAP-TTLS 
packet from the client, the TTLS server now issues an EAP-Success. "...

Section 10.2.2

What is the point in transferring the Challenge material if the server 
has to calculate it by himself?

Section 10.2.5

A very naive question about "Normally, in RADIUS, User-Password is 
padded with nulls to a multiple of 16 octets, then encrypted using a 
shared secret and other packet information. An EAP-TTLS client, however, 
does not RADIUS-encrypt the password since no such RADIUS variables are 
available; this is not a security weakness since the password will be 
encrypted via TLS anyway. The client should, however, null-pad the 
password to a multiple of 16 octets, to obfuscate its length." How does 
the AAA/H recover the unpadded password? by discarding all the nulls 
because a password is not allowed to contain nulls? Also, although it is 
nice that the client directly craft the RADIUS USer-Password attribute 
(thus the EAP-TTLS only has to copy/encrypt this attribute while 
communicating with AAA/H) and not only nice but mandatory due to the AVP 
chosen format, I was wondering if you hadn't padding mechanisms in TLS 
that also would obfuscate the length of the password. I'll try to figure 
that out by myself but in case you have the answer, I would definitely 
appreciate that :-)

Section 10.3

Perhaps worth discussing with the protected result indication and the 
crypto binding in mind

Section 10.4

"One open question in the area of PKI on which the authors would like
   to promote discussion is the following:

   -  Should EAP-TTLS enforce rules on name matching regarding the EAP-
      TTLS server? For example, EAP-TTLS could mandate that
      radius.xyz.realm or diameter.xyz.realm be used as the name in the
      EAP-TTLS server's certificate, and that the client must match
      this name with the realm it sent in the initial EAP-
      Response/Identity. "

My answer is that at least the client should have precise rules so as 
which server certificate to accept. Accepting a valid certificate 
(meaning not revoked and really issued by a trusted CA) is probably not 
enough! Regarding the question whether there should be a global naming 
scheme or not of EAP-TTLS server certificates, I think that such a 
global scheme may rather be utopian though its potential benefits have 
to be investigated. Although I see a usage scenario where it could be 
useful (a potential client is waiting in a foreign airport and wants to 
connect to a Hot-Spot. he doesn't know the Hot-Spot provider but is 
ready to buy some prepaid account possibly by entering his credit card 
number during an EAP-TTLS authentication. He sees that the Hot-Spot 
provider has a valid certificate but would like to be sure that this is 
indeed a decent Hot-Spot provider), I think that this problematic is a 
general one for certificates (you have the same problem while browsing 
on the web, the only difference is that you can have a correlation 
between the DNS name of the site and some field in the certificate) and 
is not easily solved :-( I also think that some possibly related work 
has been going on at IETF within the PKIX WG (e.g. 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-wlan-extns-05.txt) 
and I remember presentations at IEEE 802 on the matter 
(11-02-401r0-I-Certificate-Hierarchy-WLAN-Industry.ppt). But that's very 
old stuff and somebody must have fresh news to share :-)

Section 12

You still have mentions of XXX-Data-Cipher suites. Perhaps this went 
along with the section on keying information that was in version 3 and 
that you removed in this version... TBD?

Wouldn't it be nice to provide a message sequence where mutual 
authentication via TLS is performed?

Section 13 and general

Wouldn't it be nice to align this draft with EAP's revision and EAP key 
management framework 
(http://ietf.levkowetz.com/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-10.d.txt 
and 
http://ietf.levkowetz.com/drafts/eap/keying/draft-ietf-eap-keying-02.b.txt)? 
To check compliance or not to IEEE 802 requirements 
(http://www.drizzle.com/~aboba/IEEE/draft-walker-ieee802-req-01.txt)?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap