> -----Original Message-----
> From: Emu <emu-boun...@ietf.org> On Behalf Of Michael Richardson
> Sent: Saturday, March 9, 2019 3:51 PM
> To: 'EMU WG' <emu@ietf.org>
> Subject: Re: [Emu] Notes on session resumption with TLS-based EAP
> methods
>
>
> Jim Schaad <i...@augustcellars.com> wrote:
> > I am finally getting caught up on this thread and I have found it to
be very
> > frustrating because it appears to make an assumption which I do not
> believe
> > is warranted.
>
> > I do not see any problems with allowing TLS session to be used
across
> > different types of EAP assuming that EAP correctly checks the output
of
> TLS
> > before continuing. When a session ticket is issued for a TLS
session it
> > contains the authentication done by that TLS authentication session.
It
> > does not contain any of the containing EAP authentication
information
> that
> > has been done.
>
> I have been following along the discussion, and I think that I missed the
use
> case.
> Why are we having this discussion?
>
> alan> i.e. a user starts with EAP-TLS, and then tries to "resume" his
> alan> session, but this time uses TTLS. It's not clear that anything in
> alan> the spec forbids or prevents this.
>
> What's in it for the user?
For the user, the win is that the TLS handshake is much smaller and
therefore runs both faster and more reliably.
> Is this an attack?
Depends on what you think session resumption gives you. From my point of
view there is absolutely no attack as the server still needs to check that
the client certificate credentials are acceptable. Whether this is none or
specific trust anchors.
> Does it avoid an interaction with a human?
Yes - this would be cached locally in some way. The assumption is that you
would not do this on a kiosk type situation or make sure that they are
strongly protected to the user.
> Does it enable mobility between different networks?
Yes - The resumption credential is on the user's device and on the TLS
server. If the user's device moves then things are just fine. Again, the
TLS server would need to check the credentials from the cached session
against the new network to make sure that nothing bad is happening and the
client can operate on that new network.
> Does this avoid some interaction with a two-factor authenticator?
That depends on how the two-factor authentication is being done. If both
factors are some how bound up in the TLS protocol itself, then it boils
down to single factor authentication. If the two factors are a client
certificate - using TLS - and some type of pass phrase which is being passed
in EAP or over the application protocol - then there is nothing that is
being released. One assumes that the same type of access to the private key
is still needed for running TLS and then the second factor is going to be
required to be entered in some manner and sent as part of
EAP or the application.
Jim
>
> --
> Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
> -= IPv6 IoT consulting =-
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
