Yoav:
I thought we had clear consensus in IETF 71 WG meeting and instructed by
the AD that while Dan's proposal is an interesting one, but it doesn't
work with the legacy password databases and thus out-of the scope of the
charter. Until we have the proof of security analysis and clear of IPR
issues, the WG is going to work on the tunnel method. I think this is
the use case, legacy password database, the working group is currently
working on and Gene is talking about
Can you also explain why in the three use case you cited, EAP-GTC or MD5
doesn't meet the requirements, as they are all running inside an
authenticated and encrypted tunnel?
________________________________
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Yoav Nir
Sent: Monday, April 28, 2008 8:13 AM
To: emu@ietf.org
Subject: Re: [Emu] EMU charter revision
Gene Chang said:
Dan,
I am not sure I am able to clearly understand the end
result you seek.
It seems there is a clear consensus for a tunneled
method. Are you
pushing for the addition of a tunneled method?
Ok... I am easily baited. What would you like to see to
achieve more
than a snail race? I am assuming we both believe the
term "snail race"
is a pejorative. Thus I ask you, how do we do better?
I clearly hear your comment that there have been a
paucity of comments,
if nothing else, simply to affirm we are on track. I
agree with the
proposed charter. I am open to a discussion to add a
non-tunneled method
if there is sufficient demand. A non-tunneled method
does not seem to
promise enough features for the use cases that interest
me.
Gene
Hi Gene,
You did not specify what the uses that interest you are, and I
don't know about the use cases that interest Dan either, but I can speak
for the use cases that interest me.
EAP has been used in several cases as a magic way to use legacy
credentials in protocols. I'll cite three examples:
1. L2TP/IPsec (RFC 3193) as implemented by Microsoft, Apple,
Cisco and others, where an EAP method is used to authenticate the user.
2. IKEv2 (RFC 4306) where EAP is used to magically authenticate
the initiator using non-cert and non-PSK credentials.
3. TEE (draft-nir-tls-eap-03) where EAP is used to authenticate
the user.
In all three cases EAP is used by a protocol inside an encrypted
tunnel, where the server, which is either trusted by the authenticator
or co-located with it is already authenticated by a certificate or PSK.
IMO EAP was used in all cases an some magical way of making passwords
into a secure authentication mechanism. The problem is that there
really is no publicly available EAP method for passwords.
Tunneled methods don't really make sense here. There's no
benefit in putting a TLS tunnel inside an IKEv2 exchange just to pass
the password. Something like EAP-SRP would be great if it (a) existed
and (b) didn't have all that IPR baggage. The method that Dan is
proposing would also be beneficial here, if we could get a WG behind it
so we can get some solid security review. Instead, what implementors
are doing is EAP-MD5 or EAP-GTC, which don't quite meet the requirements
for any of the above protocols.
Yoav
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
