On Aug 11, 2020, at 8:40 AM, Terry Burton <terry.bur...@gmail.com> wrote:
>
> On Tue, 11 Aug 2020 at 09:11, Mohit Sethi M <mohit.m.se...@ericsson.com>
> wrote:
>>
>> Section 5.7 "Resumption" says:
>>
>>> When resumption occurs, it is based on cached information at the TLS
>>> layer. To perform resumption in a secure way, the EAP-TLS peer and
>>> EAP-TLS server need to be able to securely retrieve authorization
>>> information such as certificate chains from the initial full
>>> handshake.
Is there more information which needs to be cached? If so, are there
examples?
>> In the second mechanism, the server can avoid storing information. It
>> instead puts that information in the PSK or the session ticket and sends
>> it to the client. However, the client still needs to store information
>> from the original handshake. This is why there is the sentence "Note
>> that the client still needs to cache the information locally.". The
>> client can't obviously read the contents of the ticket or the PSK.
>
> I agree with the sentiment, but the current text seems a bit
> "Sherlock": Once you've eliminated all other possibilities whatever
> remains must be the case. I think it should directly state that the
> client uses the opaque ticket or PSK as a key to identify the cached
> information corresponding to the original session. Whereas the server
> may use the decoded content of the ticket or PSK to achieve the goal
> of remaining stateless.
I agree. It's a minor point, but clarifying it is helpful.
> Aside: The latter part might be obvious since shifting the burden of
> storing the server-side state from the server to the client is the
> whole point of ticket/PSK schemes. However it's not obvious to me that
> the additional goal introduced by this RFC of performing a deep
> revalidation of the authorisation data (resume-time certificate
> checks, etc.) is shared with the RFC5077 or RFC8446 whose concern
> appears to be with lightweight bootstrapping of the connection using
> the original parameters. (Maybe I have missed something?) If that's
> true then as Alan mentions, perhaps it is worth enumerating the types
> of information that should be stored in the ticket to facilitate the
> resume-time authorisation check rather than merely to reestablish the
> crypto parameters required to perform an abbreviated handshake?
Just re-checking 5.7, it should also have a discussion on expiring the
cached data. How long should it be cached for on each side? I'd like to see
some discussion.
My $0.02 is that the cached data MUST expire no later than the expiry time of
any certificate involved. i.e. client, server, or any cert in the CA chain.
Perhaps it would also be good to suggest that expiry times SHOULD be no
longer than 48h?
I also note:
The above requirements also apply if the EAP server expects some
system to perform accounting for the session. Since accounting must
be tied to an authenticated identity, and resumption does not supply
such an identity, accounting is impossible without access to cached
data.
It would be good to add a sentence such as:
Therefore systems which expect to perform accounting for the session
SHOULD cache an identifier which can be used in subsequent accounting.
In RADIUS, this would involve sending back User-Name or CUI in the
Access-Accept.
Alan DeKok.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
