Re: [radext] Proposed charter text based on IETF-115 BoF

[Alan DeKok <[e-mail]>]

On Nov 21, 2022, at 3:03 PM, Paul Wouters <paul.wouters=[e-mail]> wrote:
> Based on the inputs and discussions during the BoF at IETF-115 we have updated the proposed charter text. It can be found at https://datatracker.ietf.org/doc/charter-ietf-radextra/submit//
> 
> I've included it below.
> 
> Thanks to Stephen Farrell, Alan deKok and Margaret Cullen and everyone at the BoF (local and remote!) for their help.
> 
> Please let us know of any issues but also let us know if you believe the proposed charter is ready

  It looks good, but I'll throw out two additional bits for the WG to discuss.

  After the meeting, Karri, Heikki, and I had a long discussion about the documents.  One of the outcomes was that it may be useful to add two items to the charter:

1) Write a document giving guidance on using TLS-PSK with TLS and DTLS.

2) define (or investigate defining) a "hop by hop" signalling packet.

  Right now, the SRADIUS document has a discussion of TLS-PSK, but that text arguably belongs elsewhere.  The "deprecating insecure transports" document could also refer to a TLS-PSK document, to give guidance on migration to TLS.

  The "reverse CoA" document uses Status-Server for hop-by-hop signalling, but that's arguably overloading its semantics.  It may be useful to define a separate packet type.


  Also, RFC 6614 and RFC 7360 are essentially silent on the subject of TLS-PSK.  So NAS vendors have no idea what to do with TLS-PSK.

  Investigation of NAS equipment shows that many don't support RadSec, OR they don't support TLS-PSK, OR they confuse RADIUS shared secrets with TLS-PSK.  It would be best to give clear guidance on this subject.

  Any TLS-PSK document would focus on guidance for NAS vendors, so it is largely independent of updates to TLS and DTLS transport.  Further, a TLS-PSK document would be relatively short as it would focus on guidance, and not on TLS issues.

  It would be preferable to be able to publish both the"deprecating insecure transports" and SRADIUS documents without having normative dependencies on TLS / DTLS updates.

  So these two work items are not strictly new, but it may be worth calling them out as separate work items.  Otherwise their content would get repeated in other documents, which may make those documents less clear.

  Alan DeKok.