| Review of EAP-TTLSv4 | <– Date –> <– Thread –> |
From: Florent Bersani (florent.bersani rd.francetelecom.fr)
|
|
| Date: Wed, 28 Apr 2004 09:19:56 -0400 (EDT) | |
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.
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
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
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
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)?
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)?
- (no other messages in thread)
Results generated by Tiger Technologies using MHonArc.