Subject: Re: Now a question on legacy authentication

From: Radia Perlman - Boston Center for Networking <[email-masked]>
Date: Wed, 26 Feb 2003 07:04:25 -0500

Ah. I thought about it a bit, and I'll reply
to my own question.
<[email-masked]> wrote:
>It seems like EAP is just sending a string
>to be displayed at the client end, and
>the client (with the help of the human)
>constructs a string to be sent back.
>
>So, why is it necessary to have the legacy
>authentication type sent by Bob in message 4?
>It doesn't look like the client does anything
>different based on the legacy authentication type.
>

It's not true that
EAP just passes strings back and forth.
The client does have
3 distinct types of behavior with the current
EAP payloads:

1) MD5-challenge: has to hash the user's password
and the challenge

2) OTP: perhaps just pass strings back and
forth like 3), but perhaps calculate the nth
hash of the user's password and salt, in which case
it would be a distinct behavior

3) passing strings back and forth.

In answer to my question about sending password (encrypted
with the Diffie-Hellman key), Yoav Nir said:
>>"Generic token card" was intended for those beeper-sized devices that have a
>>little display with number that changes every minute or so.  The user would
>>copy the number from the device to the input field, and this would
>>authenticate him.  Since nothing enforces the use of such a device, you
>>could use this to have generic passwords that would be authenticated by
>>whatever method the gateway uses.  It just seems like a subversion of the
>>original intent.  I am sure other implementations will also use this in a
>>similar way, which is not so bad as long as the so-called clear password is
>>encrypted by IKE.

So, it seems like calling this 3rd method "transparent
string passing" rather than "generic token card" would
have avoided confusing me on both issues.

Any interest on renaming that EAP payload, and
making it clear that a new EAP type is only
required if it changes client behavior?

Radia

---

From: "Andrew Krywaniuk" <[email-masked]>
Date: Wed, 26 Feb 2003 13:27:52 -0500

- Section 2.16 text:

     "The Initiator of an IKE-SA using EAP SHOULD be capable of extending
      the initial protocol exchange to at least ten IKE_AUTH exchanges in
      the event the Responder sends notification messages and/or retries
      the authentication prompt."

  Why ten? Actually, this sounds a bit small to cover all possible
  methods. Is there a reason why we could not just
  wait until a timeout occurs or something like that?

=> Some implementations are likely to rely on hard timeouts for session 
establishment. E.g. If an exchange is not complete within 1 minute then 
consider it failed. Timing conditions are one of the most difficult things 
to get right. Constraining the number of messages is one way to achieve 
predictability.

As for the responder retrying the authentication, clean handling of that 
case was one of the advantages of a phase 1.5. (I guess the phase 1.5 didn't 
add significant complexity after all.)

Andrew
--------------------------------------
The odd thing about fairness is when
we strive so hard to be equitable
that we forget to be correct.

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus