RE: Issue status update

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

Joseph Salowey [mailto://jsalowey@cisco.com] writes:

> > Bernard Aboba writes...
> >
> > > In going through the open Issues posted on the RADEXT Issues list
> > > (http://www.drizzle.com/~aboba/RADEXT)
> > > I was unclear about the status of the following issues.
> > >
> > > RADIUS Crypto-Agility Requirements
> > >
> > > Issue 274
> > >
> > > Issue 275
> >
> > In think we are waiting form some suggested text that Joe
> > Salowey offered to draft, regarding key management references
> > and security considerations.
> >
> [Joe] Thanks for the reminder.
> 
> > There is also a basic issue with the use of the existing RADIUS
> "hint"
> > mechanism to implement some rudimentary form of capability
> > advertisement.

I don't remember any discussion of capability advertisement.

> >
> > While I'm sympathetic to the limitations of this mechanism,
> > unless the WG thinks we should expand the charter scope to
> > create a more robust form of capabilities negotiation, I
> > think it would be a mistake to add that as a
> > requirement for crypto-agility.   

From the newly updated charter: "This work item will include documentation
of RADIUS crypto-agility requirements,
as well as development of one or more Experimental RFCs providing support
for negotiation of alternative cryptographic algorithms to protect RADIUS."
So, are you saying that it's OK for negotiation to be part of the work item,
but not the requirements? 

> In short, I suggest we reject these
> > comment.
> >
> [Joe] I think most of the comments relating to the negotiation were
> that
> the term "hint and consent" does not represent what is possible in
> RADIUS.  I don't think there was desire to change the behavior, just to
> have the definition reflect the reality of the situation.

As I mentioned before, unless the radext Chairs intend to unilaterally
redefine the English word "negotiation", something needs to change.  There
is no hinting involved in an Access-Request regarding e.g. the protection
method used with a modern analog of the User-Password Attribute, only a
statement of what was done.  If the server can't decrypt an attribute it
finds in an Access-Request, what does it do (apparently some folks seem to
think that issuing an Access-Reject is just fine in this case, without any
indication of the reason for the failure, on the grounds that "that's what
we have" (?!)).  In any case, there doesn't exist a definition of
"negotiation" of which I'm aware that doesn't include discussion (meaning >1
message).

...



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