Re: Now a question on legacy authentication

[Radia Perlman - Boston Center for Networking <Radia.Perlman@sun.com>]

Ah. I thought about it a bit, and I'll reply
to my own question.
<radia.perlman@sun.com> 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