Re: [radext] WGLC for draft-ietf-radext-tls-psk-04

[Alan DeKok <[e-mail]>]

On Dec 1, 2023, at 11:17 AM, Fabian Mauchle <[e-mail]> wrote:
> After re-reading -04 and trying to update my implementation:
> 
> 4.2.1.  Security of PSK Identities
> > However, implementations MUST support managing PSK identities as a
> > set of undistinguished octets
> 
> This sentence confuses me (not sure why I didn't trip over it before).
> If I follow the advise (SHOULD) of verifying identities as valid UTF-8, I would now violate above statement as I no longer support just any undistinguished octets.

  I don't think there's any contradiction.  Implementations MUST support identities as random stuff.  But it's generally a good idea to use UTF-8 for humanly-managed identities.

> 6.2.3.  Resumption
> > Implementations MUST support resumption
> 
> I oppose this requirement.
> 
> 1. this draft is about PSK, not resumption, and I see no technical requirements why a PSK client/server would need to support resumption.
> I think this requirement belongs to draft-ietf-radext-radiusdtls-bis, which already states it as SHOULD.

  The difference for me is that certificates can be checked without hitting a database.  In contrast, TLS-PSK will likely require a DB hit.

  This is perhaps more of an issue for EAP-TLS-PSK, so maybe the discussion here can be removed.

> 2. I see PSK as a method for constrained implementations to get something better than Radius/UDP, so the requirements should be kept minimal.

  It's also a good idea to suggest best practices.  There are few downsides to using resumption, so perhaps we should suggest it.

> 3. in light of TLS1.3, resumption and PSK are mutually exclusive. TLS 1.3 PSK already minimizes the handshake to a single round-trip.
> (no sure how this works in TLS1.2)

  Are resumption and PSK really mutually exclusive?  I admit I haven't poked OpenSSL in detail, but in theory it should be possible.

> I fully agree with paragraphs 2-5, stating how implementations should behave if they support both PSK and resumption.

  OK, thanks.

> > Systems supporting TLS-PSK and resumption MUST cache data during the
> > initial full handshake sufficient to allow authorization decisions to
> > be made during resumption.  If cached data cannot be retrieved
> > securely, resumption MUST NOT be done.  The cached data is typically
> > information such as the original PSK identity, along with any
> > policies associated with that identity.
> 
> I presume this applies to TLS1.2 PSK? Maybe it should say so.

  No, it's only for resumption.  The text is taken largely from RFC9190.

  The issue is that with TLS resumption, the original identity / credentials are mostly lost.  i.e. they're not available via TLS.

  So the TLS server has to cache the original identity / etc, and associate them with the resumed session.  When resumption happens, it gets the cached data, and uses that to apply authorization.

> The remainder of section 6.2.3 I fully agree on the content - I think these are some very important provisions - but in my view they belong in draft-ietf-radext-radiusdtls-bis, as they apply to TLS resumption in general, not (just) PSK.

 That section has a lot of text on issues specifically to TLS-PSK.  But yes, the generic "cache data on resumption" really belongs in the main TLS document.

  However, the TLS document won't be available for a while, so I think that text is needed here.

 Alan DeKok.