Subject: [eap] RE: A few comments on draft-puthenkulam-eap-binding-03.txt

From: "Puthenkulam, Jose P" <[email-masked]>
Date: Fri, 24 Oct 2003 18:53:34 -0700

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: [email-masked] 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

> -----Original Message-----
> From: DongGook Park [mailto:[email-masked]] 
> 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: [email-masked]
> 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?
> 
> 
> 
> 
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "DongGook Park" <[email-masked]>
Date: Mon, 27 Oct 2003 09:59:51 +0900

Dear Jose,

Thanks for your response and answers. 

> performed to compute the MAC is critical for it to work.

I might sound rather splitting hairs...  Of course, there is no need to
say that the additional message "with" the cryptographic binding is a
must for the countermeasure to succeed. What I mean may be rather
subtle. Think about that, in the MITM attack, the attacker was "able" to
derive a cryptographic response from the victim user in spite of "not"
being able to access the required key. In other words, we have the
following two observations:

1) The attacker does "not" know the key; but he is able to get the
necessary message to play the MITM attack (of course in the case of the
original situation not fixed)

2) The attacker does "not" know the key; and hence he is not able to get
the necessary message to complete the attack.

I think, at this point, you have unmistakably read me... 

> at all and early error handling in terms of an unsuccessful

I couldn't agree more! But I think you hit me wrong. :-)  What I meant
is that you are expected to give a specific explanation why the implicit
countermeasure (Stage 2 as in the draft) is needed on top of the more
explicit countermeasure (Sage 1 as in the draft).

Best regards,
DongGook

---

From: "Puthenkulam, Jose P" <[email-masked]>
Date: Mon, 27 Oct 2003 01:38:10 -0800

Dear DongGook,

Thanks for further clarifying. See responses below.

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of DongGook Park
> Sent: Sunday, October 26, 2003 5:00 PM
> To: [email-masked]
> Cc: EAP mailing list
> Subject: [eap] RE: RE: A few comments on 
> draft-puthenkulam-eap-binding-03.txt
> 
> 
> Dear Jose,
> 

So this is the attack success case.

> the necessary message to complete the attack.

So this is the attack failure case.

> I think, at this point, you have unmistakably read me... 

One can always say that one does not need to know the key for the attack
to succeed or fail. But at the sametime, one could say that the attack
can be made to fail if one does know the keys (inner method keys). So we
rely on this reliable test of key knowledge to prove that an (a) attack
never occurred or when there is no proof that (b) an attack might have
occurred or is possible to occur.

(a) is needed to consider the compound authentication to be secure
(b) essentially says that the compound authentication is not secure as a
attack possbility exists without really asserting that a successful
attack is a certainty every single time.

> explicit countermeasure (Sage 1 as in the draft).
Probably I did not address your comments fully :(. I have added the
following text to clarify this in the 04 draft.

"The main reason for Stage 2 is to allow each tunnel packet privacy
protection to also be 
cryptographically bound to the inner methods it carries." 

This essentially helps the per tunnel packet authentication to be based
on all the methods that were part of the compound authentication.

best regards,
jose