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

[DongGook Park (dgpark6]

Dear Jose,

Thanks for your response and answers. 

>> 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.

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... 


>> 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.

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