Re: [secdir] Security directorate review of draft-ietf-radext-tls-psk-09

[Alan DeKok <[e-mail]>]

On Mar 15, 2024, at 2:48 AM, Hilarie Orman <[e-mail]> wrote:
> The document has advice about using TLS pre-shared keys with RADIUS.
> It addresses the immediate question of "why is anyone using pre-shared
> keys" by pointing out that certificates can be bulky and difficult to
> manage, and then follows with 15 pages of advice on using pre-shared
> keys.  That is wryly amusing.  

  The main advice there is for implementors, and the advice for admins is a small part of that.  By pushing the work from admins (many and less experienced) to implementors (fewer and more experienced), we hope that TLS-PSK will be easily deployed.

> Reuse is the bugaboo of pre-shared keys, so the main message from the
> document is "don't reuse them."  Another PSK vulnerability is the
> symmetry between server and client authentication, and I think that
> could be promoted to an earlier section.

  OK.  I'll make some changes.

> Page 5 has example code for turning random data in human readable
> ascii strings, but it seems overly specific (why use "-" as the
> separator?), and it does not include an example decode routine or
> advice about rejecting malformed strings.

  The intent here was to show how easy it was to create and manage secure PSKs.  The PSKs end up being used in a hash function, so the exact format (string or raw binary) matters somewhat less.

  i.e. the goal wasn't to allow decoding of the keys from a "mandated format".  The document does not suggest that implementations enforce any particular format for PSKs.  I'll add some text clarifying this.

> On page 12, there is the statement:
>   "The intent for TLS-PSK is for it to be used in internal / secured
>   networks, where clients come from a small number of known locations".
> This seems important enough to be included in the introduction.

  OK.

> Section 4.1.1 says:
>   "It is RECOMMENDED that RADIUS clients and servers track all used
>   shared secrets and PSKs, and then verify that the following
>   requirements all hold true:
>   *  no shared secret is used for more than one RADIUS client
>   *  no PSK is used for more than one RADIUS client
>   *  no shared secret is used as a PSK"
> 
> I take this mean that these items should be checked anytime a shared
> secret or PSK is added or changed.  But, a naive implementation might
> create a master list of all such secrets to use for checking, and that
> is an unnecessary security risk.  Perhaps there should be guidance
> about using a hash list for checking?

  Perhaps.  An implementation is required to read and store the PSKs and shared secrets somewhere as clear-text, and use them to verify packets or TLS sessions.  So it doesn't really concern me if that data is stored in the application somewhere.  That storage is required in order for the secrets and PSKs to work.

  That data also needs to be stored somewhere outside of the application in a configuration file or configuration management system.

> The text about checking PSK identities on page 7 has some rules about
> distinguishing different kinds of identities based on whether or not
> they are proper UTF-8 encodings.  That might be practical, but it
> sounds really hokey.  I don't know the probability of random (ascii?)
> strings being legal UTF-8, so I am not even sure that the method is
> sound.

  It's the best we have, and is an issue with TLS itself.  This document can only document that issue, and give guidance for implementors on dealing with it.

  At the minimum, octets of zero (0x00) are invalid UTF-8.  So we know that it is possible to trivially create identities which are distinguishable.

> I'm not sure I understand the discussion of "resumption" on pages 15-16.
> The text says that an identity can change between the initial
> full handshake and the need for resumption.

  That is how TLS works, unfortunately.

>  That could happen if
> a client changed its IP address within an allowed block.  Is
> resumption so important that it must be supported instead of requiring
> a new handshake?

   The issue is less resumption of TLS-PSK sessions, than using TLS-PSK at the same time as certificate authentications.  The resumption for certificate-based sessions will use PSKs.  Since certificate chains are large, it is vital that we support resumption for that case.

  That limitation motivates the discussion of distinguishing resumption from "plain" PSK.  We're not so much interested in resuming TLS-PSK sessions, but instead distinguishing "plain" TLS-PSK from resumptions created by other TLS authentication methods.

  I'll add some text to clarify this.

>  And resumption credentials can last for a full week,
> which seems oddly long.

 That time frame is straight from RFC 8446.

> There is no discussion of key lifetimes or change procedures (other
> than the one week for resumption), so I guess that it is covered by
> administrative practices in RADIUS?

  I'm not sure what to recommend here.  Perhaps adding some text saying that PSKs should be changed.  But it's not clear how often is good enough, or what the change procedures should be.

> 5.2.2. "else the server ignores the session ticker," presumably is "ticket"?

  Fixed, thanks.

  Alan DeKok.