Re: What about PSK with TLS and IKEv2?
From: T. Charles Clancy (clancycs.umd.edu)
Date: Mon, 16 Aug 2004 01:30:19 -0400 (EDT)
On Fri, 13 Aug 2004, Mohamad Badra wrote:

> > True, but the TLS resume still requires 2 round trips,
>
> 1.5 RT :)

Due to the challenge-response nature of EAP, we have to round up. :)

> > and as much computation as a full reauthentication.
>
> Correct me if I'm wrong, in the full reauthentication, we authenticate
> using certificates which is not the case of TLS-PSK.

I was comparing a TLS-PSK-Resume to a TLS-PSK-FullAuth with the server
certificate disabled (in order to accurately compare it to PAX).  Both
require 2RT (or 1.5 in theory) and basically the same cryptographic
operations.  Certificates are not used in either case.

>
> > Just because other methods use it doesn't mean it's the right thing to
> > do in the PSK case.
>
> I meant that the TLS-PSK allows us to call back a full TLS sessions...
> Further, almost all methods use TLS to establish the channel. Where the
> TLS-PSK will be used instead of full TLS, these methods will be improved
> a lot (processing time, message flow, MitM attack, etc) and this without
> decrease the security level. So I think that it is the right think in
> our case when the majority of EAP methods use TLS.

So you could authenticate using some other EAP method running over TLS,
and then provision a PSK from that TLS session's master secret?  Then you
could use TLS-PSK for future authentications?  I can see how this might be
useful, for example a company might allow clients to authenticate via
MS-CHAPv2 over PEAP, and provision a PSK from that TLS session.  Keys can
be provisioned using existing AD credentials.

While this seems like a neat idea, "there are too many buttons to push."
Even if completely implemented, I suspect getting it to work properly in a
practical environment would be far from simple.

[ t. charles clancy ]--[ tcc [at] umd.edu ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

Results generated by Tiger Technologies using MHonArc.