Last Call Review of draft-ietf-radext-tls-psk-09
review-ietf-radext-tls-psk-09-secdir-lc-orman-2024-03-14-00

	      Security review of 
	      RADIUS and TLS-PSK
	     draft-ietf-radext-tls-psk-09

Do not be alarmed.  I generated this review of this document as part
of the security directorate's ongoing effort to review all IETF
documents being processed by the IESG.  These comments were written
with the intent of improving security requirements and considerations
in IETF drafts.  Comments not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last call comments.

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.  

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.

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.

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.

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?

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.

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 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?  And resumption credentials can last for a full week,
which seems oddly long.

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?

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

Hilarie