Hi Joe,
Section 3.8 has a MUST for "extensibility" which is explained as:
"One example of a application for extensibility is credential
provisioning. When a peer has authenticated with EAP, this is a
convenient time to distribute credentials to that peer that may be
used for later authentication exchanges."
Now I believe EAP-FAST does this sort of thing for it's PAC provisioning
but it does anonymous TLS then EAP-MSCHAPv2 which has obvious problems.
So the need to do this sort of thing exists.
I know that one can do server-side authentication with some previously
installed certificate (and I know EAP-FAST has this as an option too) but
_in practice_ that doesn't work so well which is why the most popular
desktop and laptop operating system has a "do not verify server cert"
check box on its EAP-TLS configuration GUI.
As I mentioned earlier security is about risk management and if you
try to tell some guy deploying product that no he can't do what he wants
to do because the authors of the IETF standard decided that it wasn't
in his best interests he will find ways around those authors, like instead
of installing a trusted cert he'll check the box to not verify the server
cert that the authors said he has to use if he wants to use this product.
It would be much better to give him a tool that serves his legitimate
needs and is easy for him to deploy and still maintains security (albeit
with a potential loss of privacy).
Would it be possible to add a reference in 4.2.1.1.3 that one SHOULD
optionally implement an anonymous cipher suite?
Dan.
On Thu, March 4, 2010 7:11 am, Joseph Salowey (jsalowey) wrote:
>> Joe, what Dan is proposing is a reasonable way to use a one-time
> password
>> for the initial provisioning of a trust anchor. Initial provisioning
> is
>> important for many types of deployments. Does the document allow an
>> alternative secure way to do that?
>>
> [Joe] Initial provisioning is not currently in the scope of the document
> for the base method. I agree that using anonymous cipher suites in the
> way Dan proposes can be used in a provisioning mechanism, however there
> are other ways provisioning can be achieved with or without the use of
> EAP.
>
>> Dan, I suspect that for this specific use case (one time use, no need
> for
>> confidentiality), resistance against dictionary attack is not very
>> important. So EAP-GPSK inside the tunnel will do just as well.
>>
>> Thanks,
>> Yaron
>>
>> > Date: Wed, 3 Mar 2010 20:05:09 -0800
>> > From: "Joseph Salowey (jsalowey)" <[email protected]>
>> > Subject: Re: [Emu] review of draft-ietf-emu-eaptunnel-req-04
>> > To: "Dan Harkins" <[email protected]>, "Hoeper Katrin-QWKN37"
>> > <[email protected]>
>> > Cc: [email protected]
>> > Message-ID:
>> > <ac1cfd94f59a264488dc2bec3e890de509bd3...@xmb-sjc-
>> > 225.amer.cisco.com>
>> > Content-Type: text/plain; charset="us-ascii"
>> >
>> > Hi Dan,
>> >
>> > The document currently states anonymous cipher suites MUST NOT be
>> > mandatory to implement for the tunnel method. I think the is the
>> > appropriate stance for the document to take for the base tunnel
> method.
>> > I also do not think this prevents a follow-on specification defining
>> > how
>> > to use anonymous tunnel securely.
>> >
>> > Cheers,
>> >
>> > Joe
>> >
>>
>> _______________________________________________
>> Emu mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/emu
> _______________________________________________
> Emu mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/emu
>
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
