On Mar 6, 2019, at 9:40 PM, Arran Cudbard-Bell <[email protected]> 
wrote:
> 'session tickets for TLS versions 1.2 and below, and [RFC 8446] session 
> tickets in TLS 1.3.'
> 
> I know it's pedantic, but RFC 8446 obsoletes RFC 5077.

  Sure.

>>  Any authorization applied during resumption MUST be done using the
>>  cached data,
> 
> 'or data resolved or obtained using that cached data.'
> 
> authorization doesn't need to performed in a sandboxed environment with only 
> the cached data.

  True.  It can be used to look up data in a database, or to do something else.

> Cross resumption between VPNs and Wired/Wireless infrastructure could be a 
> big issue.
> It might be worth mentioning that explicitly as I think it'll be a blind spot 
> for implementors.
> 
> Out of the box, if someone used our EAP server implementation for 
> authenticating VPN users
> and wired/wireless users, we would allow cross resumption, because the EAP 
> server
> doesn't allocate session tickets based in different contexts by default.

  That depends on the deployment, too.

  To be strictly technical, an HTTPS server and EAP server could share TLS 
session tickets.  It would then be possible for users to authenticate via 
HTTPS, and "resume" via EAP-TLS.

  The only reason resumption works across media types in EAP is that there's 
generally one common EAP server for all media types.  If instead there are 
multiple EAP servers, or the TLS implementations don't share data, then 
cross-method resumption won't work.

>>  When EAP servers make policy decisions based on unauthenticated
>>  information, they MUST then add that information to the cached data
> 
> maybe 'then it MUST be used in combination with the cached data described 
> above'

  Perhaps.

> Took a couple of readings to understand exactly what you meant there.

  It's a difficult subject to explain properly.

> The cached data isn't being updated, but it's being used together with the 
> unauthenticated
> information, right?

  Yes.

  Alan DeKok.

_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu

Reply via email to