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

["Glen Zorn" <glenzorn@comcast.net>]

David B. Nelson <mailto://d.b.nelson@comcast.net> writes: 

> 
> 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?

Define what?  Whether the algorithm is mandatory to implement for use in
RADIUS?  I sincerely hope so!

> 
> > 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?  

Some definitions of "hint":

an indirect suggestion
a slight indication
a clue

What about any of those suggests a declarative statement?

...

> > 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.

And the client knows that this is a refusal of this particular hint (instead
of the multiple other conditions that might elicit an Access-Reject how,
exactly?  Parsing the Reply-Message Attribute that may or may not be
present?

...

> 
> > > > 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".  

I guess miracles really do happen every day then ;-): support for EAP,
dynamic authorization, 802.11...

...



--
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/>