eap Mailing List: RE: A few comments on draft-puthenkulam-eap-binding-03.txt

[Puthenkulam, Jose P (jose.p.puthenkulam]

Dear DongGook Park,

Apologies for not being able to respond to you sooner:

Here are some responses on your comments.

> 1. [Comment]  On page 15, the draft describes the Binding 
> Phase Exchange
> with compound keyed MACs. The draft reads "... The validation of the
> compound protects against the MITM attack, as the attacker is 
> unable to
> get any of the inner method keys. ..."  This description seems to be
> rather misleading... As far as I understand, the attack cannot succeed
> not because the attacker is not able to access the inner method keys,
> but because the new additional message exchange of "Binding Phase" is
> not expected message from the viewpoint of the victim entity. For the
> victim entity has simply executed a legacy authentication 
> protocol (not
> as an inner protocol of the tunneled authentication protocol) 
> which does
> not include the additional Binding Phase exchange. 
> 

If an additional message exchange without any crypto binding was added,
it would not protect from an attacker that can actually also replicate
the expected additional message exchange. So the cryptographic binding
performed to compute the MAC is critical for it to work.

> 2. [Comment]  On page 18, before the start of Section 3,4, the authors
> argue that "Stage 2" is REQUIRED for additional protection on top of
> "Stage 1" protection. Strangely, however, the draft does not 
> explain why
> it is the case, but rather they only emphasize the importance 
> of "Stage
> 1" countermeasure and the insufficiency of "Stage 2" being 
> used alone...
> I think, rather, readers would expect why the additional 
> countermeasure
> "Stage 2" is used on top of the essential protection "Stage 1". By the
> way, I don't see why Stage 2 is necessary in addition to 
> Stage 1 as far
> as the man-in-the-middle attack is concerned. IMHO, each stage can be
> considered as a selective countermeasure; Stage 1 as a 
> full-blown costly
> fix (due to additional messages and hence some relevant
> addition/modification to existing EAP protocols), and Stage 2 as a
> lightweight solution which does not entail message
> addition/modification, a penalty of which is some delayed detection of
> whether a MITM attack has occurred or not.

I agree with you on this one partially, from pure protection view point.
But from a practical implementation viewpoint, typically policy
decisions for authorization are made after a successful authentication.
So when a late detection occurs due to decrypt operations failing, it
relies on some upper layer to detect such a failure, which is sometimes
hard. While an early detection allows authorizations to be not provided
at all and early error handling in terms of an unsuccessful
authentication.

> 
> 3. [Question]  On page 17, Section 3.5 "Solution approaches", 
> the first
> proposed approach for accommodation of Stage 1 or 2 (the 
> draft, in fact,
> describes only the case with "Stage 1") is to "implement the binding
> phase exchange as a new EAP method". Does this mean that we 
> need to have
> something like EAP-BindingPhaseExchange in addition to e.g. EAP-TTLS? 

Yes, but as one of the EAP types within EAP itself like Identity or
Notification etc.

> 
> 4. [Question]  On page 13, Section 3.2 "Solution Concepts", the
> description headed by "[S1]" argues that cryptographic 
> binding solution
> will not work for "non-key-deriving methods" without breaking at least
> one of the solution criteria given in the draft. Most probably,
> password-based authentication protocols such as CHAP will 
> correspond to
> the non-key-deriving methods. But why? Are we not allowed to use the
> password instead of the inner method key in the case of the situation
> where any inner key is not available from the inner protocol?

One could do this if the password is accessible to the key binding
process. But at first glance developing a general solution may not be
easy. However as you have raised it, I would like to think more about
any possibilities here :)

Thanks for reviewing the draft. Really appreciate your comments,

best regards,
jose

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Jose Puthenkulam 
   Staff Network Architect 
   Communications Technology Lab 
   Intel R & D 
   Intel Corporation 
   2111 NE 25th Avenue, JF2-58 
   Hillsboro, OR 97124 
   Tel: (503) 264 6121 
   Fax: (503) 264 8154 
   Email: jose.p.puthenkulam [at] intel.com 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 



> -----Original Message-----
> From: DongGook Park [mailto:dgpark6 [at] kt.co.kr] 
> Sent: Monday, September 15, 2003 1:56 AM
> To: Puthenkulam, Jose P
> Cc: EAP mailing list
> Subject: A few comments on draft-puthenkulam-eap-binding-03.txt
> 
> 
> Dear Jose Puthenkulam,
> 
> I have some comments and questions with regard to your recent 
> IETF draft
> entitled " The Compound Authentication Binding Problem"
> (draft-puthenkulam-eap-binding-03.txt), which you can find 
> below in this
> mail. 
> 
> Best regards,
> DongGook Park
> 
> =====================================
> Information Security Research Division
> Korea Telecom
> 17 WooMyeon-Dong SeoCho-Gu Seoul 137-792 
> Korea, South
>  
> Telephone: +82 2 526 6173
> Email: dgpark6 [at] kt.co.kr
> Homepage: http://home.naver.com/dgpark6/
> =====================================
> 
> 
> 
> ######  A few comments on 
> draft-puthenkulam-eap-binding-03.txt  #######
> 
> This draft describes MITM attacks against tunneled authentication
> protocols, and proposes some countermeasures. I've found a bit
> misleading descriptions from the draft:
> 
> 1. [Comment]  On page 15, the draft describes the Binding 
> Phase Exchange
> with compound keyed MACs. The draft reads "... The validation of the
> compound protects against the MITM attack, as the attacker is 
> unable to
> get any of the inner method keys. ..."  This description seems to be
> rather misleading... As far as I understand, the attack cannot succeed
> not because the attacker is not able to access the inner method keys,
> but because the new additional message exchange of "Binding Phase" is
> not expected message from the viewpoint of the victim entity. For the
> victim entity has simply executed a legacy authentication 
> protocol (not
> as an inner protocol of the tunneled authentication protocol) 
> which does
> not include the additional Binding Phase exchange. 
> 
> 2. [Comment]  On page 18, before the start of Section 3,4, the authors
> argue that "Stage 2" is REQUIRED for additional protection on top of
> "Stage 1" protection. Strangely, however, the draft does not 
> explain why
> it is the case, but rather they only emphasize the importance 
> of "Stage
> 1" countermeasure and the insufficiency of "Stage 2" being 
> used alone...
> I think, rather, readers would expect why the additional 
> countermeasure
> "Stage 2" is used on top of the essential protection "Stage 1". By the
> way, I don't see why Stage 2 is necessary in addition to 
> Stage 1 as far
> as the man-in-the-middle attack is concerned. IMHO, each stage can be
> considered as a selective countermeasure; Stage 1 as a 
> full-blown costly
> fix (due to additional messages and hence some relevant
> addition/modification to existing EAP protocols), and Stage 2 as a
> lightweight solution which does not entail message
> addition/modification, a penalty of which is some delayed detection of
> whether a MITM attack has occurred or not.
> 
> 3. [Question]  On page 17, Section 3.5 "Solution approaches", 
> the first
> proposed approach for accommodation of Stage 1 or 2 (the 
> draft, in fact,
> describes only the case with "Stage 1") is to "implement the binding
> phase exchange as a new EAP method". Does this mean that we 
> need to have
> something like EAP-BindingPhaseExchange in addition to e.g. EAP-TTLS? 
> 
> 4. [Question]  On page 13, Section 3.2 "Solution Concepts", the
> description headed by "[S1]" argues that cryptographic 
> binding solution
> will not work for "non-key-deriving methods" without breaking at least
> one of the solution criteria given in the draft. Most probably,
> password-based authentication protocols such as CHAP will 
> correspond to
> the non-key-deriving methods. But why? Are we not allowed to use the
> password instead of the inner method key in the case of the situation
> where any inner key is not available from the inner protocol?
> 
> 
> 
>