RE: Comments on "Crypto-Agility Requirements for RADIUS"

["David B. Nelson" <d.b.nelson@comcast.net>]

Glen Zorn writes...

> What documents?

Those defining the cipher suites to be used.  Surely we're not going to
attempt to define them within a RADIUS document?

> Since an Experimental RFC holds no standing as a standard, how can it
> specify _anything_ as mandatory?

Sorry to be repetitive, buy why not?

> The last time I checked (please correct me if I'm wrong), the "hint" was
> from a NAS to a server regarding what the NAS wanted returned.  In many
> cases, these "hints" would not be anything of the sort; instead, they will
> be a simple statement of the algorithm used by the NAS.

How is that not a hint?  Sorry, but I simply don't see where you're going
with this.

> Examples are the User-Password Attribute & request
> authentication/integrity protection.

Eh?

> The only way that I can think of for the server to refuse the
> "hint" would be if we were to hi-jack the Access-Challenge message,
> which in itself constitutes a novel negotiation method for RADIUS.

Well, yes.  We discussed that briefly during an ill-fated attempt to add
generic capabilities negotiation to RADIUS.  So, yes there is no "NAK" and
counter-proposal capability, simply offer and accept or offer and reject.  I
fail to see why that would not allow a rudimentary form of crypto-agility.
The way a server refuses the hint by means of an Access-Reject message.

> > Therefore, it's reasonable to say that "Just use IPSec."
> > is out of scope for RADIUS crypto-agility.
> 
> The text to which I was referring is "Therefore, it is expected that
> proposals will utilize other techniques".

Well, if "Just use IPSec" is out of scope, doesn't it follow that "proposals
will use other methods" [besides IPSec)?  Again, I simply don't see where
you're going with this.

> > > I would _really_ like to see some rationale for this requirement
> > > (aside from "backward compatibility is sacred and must never be
> > > questioned" ;-).
> >
> > Given that the RADIUS protocol doesn't have a protocol version field,
> > maintaining backward compatibility seems pretty basic.
> 
> OK, so that sounds an awful lot like " backward compatibility is sacred
> and must never be questioned" to me.

If you say so...

> > > Given that this is new and presumably desirable functionality,
> > > why is a simple upgrade path not sufficient?
> >
> > A "fork-lift" upgrade?  :-)
> 
> Hardly. New messages and or capabilities can fairly easily be introduced
> in a piece-meal fashion, as long as it is done with care.

Well _that_ sounds a bit like "and a miracle occurs here".  That which is a
simple upgrade path to some is a deployment nightmare to others.  We need to
be a bit more specific, I think.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>