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

[Bernard Aboba <[e-mail]>]

Alan said:

"I'm not sure what conversion is necessary.  SRADIUS is a transport profile
which essentially says "don't use MD5 to encrypt User-Password when sending
packets from client to server".

[BA]  The question is whether the meaning is "when sending packets from
client to server" (e.g. E2E conformance) or "when sending packets on this
hop".  That is, can a proxy receive an SRADIUS packet from a NAS and then
speak RADIUS (or legacy RADIUS over (D)TLS) to the server?  Or does
receiving an SRADIUS packet imply that the next hop MUST speak SRADIUS?

A similar issue came up with respect to meaning of the "SIPS" URL.  It
turned out that there was no easy way to ensure that security services were
uniformly provided on each hop.  Seems like the same might be true here.

On Mon, Nov 28, 2022 at 2:05 PM Alan DeKok <[e-mail]>
wrote:

> On Nov 28, 2022, at 4:52 PM, Bernard Aboba <[e-mail]>
> wrote:
> > "  ALPN is about negotiating which application protocol is inside of
> TLS....   i.e. a hop-by-hop RADIUS packet (inside of TLS) which says "I
> have this capability".
> >
> > [BA] Since TLS ALPN negotiation will be "hop by hop", there could be
> scenarios where the SRADIUS ALPN could be negotiated on one hop, but not
> another.  A RADIUS proxy can do the conversion, but that could yield
> unexpected results.
>
>   I'm not sure what conversion is necessary.  SRADIUS is a transport
> profile which essentially says "don't use MD5 to encrypt User-Password when
> sending packets from client to server".
>
>   Nothing about the content of the User-Password attribute is changed.  It
> can be sent in another packet (SRADIUS or not) without any issue.
>
>   When a RADIUS proxy receives User-Password, it has to decrypt it, and
> then store it in memory as raw text.  When that attribute is sent over the
> next hop, it is (a) encrypted if RADIUS, or (b) not encrypted if SRADIUS.
>
> > For example, say a company requires that new NAS devices support
> SRADIUS, and upgrades the proxy to support SRADIUS.  But because there are
> still some legacy devices left, they still have to maintain a legacy RADIUS
> server in addition to an SRADIUS server.
>
>   Quite likely, yes.  Or, just allow the RADIUS server to negotiate
> protocols on a per-connection basis.
>
>   The main purpose of "SRADIUS only" is for people who want to do
> hard-core FIPS, and remove all references to MD5.
>
> > Is there a way for the company to make sure that SRADIUS NAS devices
> communicate using SRADIUS on each hop?  Or could an SRADIUS NAS
> Access-Request end up being routed to a legacy RADIUS server (or a legacy
> RADIUS over (D)TLS server)? If the proxy negotiates SRADIUS with the NAS,
> but legacy RADIUS or RADIUS over (D)TLS with the server, then even new
> devices supporting SRADIUS might not end up talking SRADIUS end-to-end.
>
>   There's no "end to end" SRADIUS.  It's all hop-by-hop.
>
>   i.e. The SRADIUS draft proposes changes to the packet encoding (MD5
> signature, encryption of some attributes).   The content and meaning of the
> attributes hasn't changed.
>
>   As a hop-by-hop encoding, it's compatible with all RADIUS attributes:
> past, present, and future.  Once attributes are received by one hop, all
> previous transport limitations are lost.  Any "next hop" transport operates
> entirely independently of any previous transport.
>
>   Alan DeKok.
>
>