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

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

David B. Nelson <mailto://dnelson@elbrysnetworks.com> writes:

> Glen Zorn writes...
> 
> > The WG Charter states that all of the existing crypto-agility
> > proposals are to be published as Experimental RFCs.  In that case,
> > how can the requirement that " at least one mandatory to implement
> > algorithm will be defined" (section 1.2) be fulfilled?
> 
> Why not?  The algorithms are defined in existing documents.

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

...

> > Technical comments:
> >
> > Section 2, paragraph 2 states:
> >
> >    In the specific context of the RADIUS protocol and RADIUS
> >    implementations, crypto-agility may be better defined as the
> ability
> >    of RADIUS implementations to negotiate cryptographic algorithms
> for
> >    use in RADIUS exchanges, including the cryptographic algorithms
> used
> >    to protect RADIUS packets and to hide RADIUS Attributes.  This
> >    capability covers all RADIUS message types: Access-
> Request/Response,
> >    Accounting-Request/Response, and CoA/Disconnect-Request/Response.
> >
> > Since RADIUS has no negotiation method of I'm aware (hint &
> > accept/ignore is hardly a negotiation mechanism)...
> 
> Yeah, but it's what we've got.
> 
> >... I find these statements very curious, especially in light of the
> > earlier statement (section 2, paragraph 3) that the password-hiding
> > function will be negotiable.  Basically, what is being called for is
> > impossible in the context of the RADIUS protocol, implying that the
> > negotiations would take place outside of RADIUS (e.g., in TLS).
> 
> That wasn't what I understood when I transcribed that text.  It's true
> that
> "hint and consent" is a bit crude, but I'd like to see a more in-depth
> technical exploration of why you think it makes crypto-agility
> impossible
> within RADIUS

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.  Examples are the
User-Password Attribute & request authentication/integrity protection.  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.

> 
> > Section 4.1:
> > Once again, assuming a solution.  State the requirements that a
> solution
> > must meet, not your personal assumptions about the form which the
> solution
> > will take.  I say "personal" because a fair subset of the active WG
> (of
> > which this document is purportedly a product) _does not_ share the
> > expectation that " proposals will utilize other techniques".
> 
> I take that text to means that RADIUS over IPSec has already been
> defined,
> and therefore proposing RADIUS over IPSec is not what we're looking for
> to
> address RADIUS crypto-agility.  After all, if an existing solution
> needs
> everyone's needs, why waste time on a requirements document, never mind
> a
> solution document?  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".

> 
> > Section 4.2, paragraph 2 states:
> >
> >    Included in negotiation techniques are "hint and consent"
> mechanisms
> >    where the NAS provides a list of algorithms and the server selects
> >    one.
> >
> > If the server is required to select from the list it can hardly be
> > called a hint.  Once again, I can't see at all how this mechanism
> > could be made to work in the case of the Access-Request message.
> 
> Please explain.

See above.

> 
> > Section 4.3, paragraph 1 states:
> >
> >    Solutions to the problem MUST demonstrate backward compatibility
> >    with existing RADIUS implementations.
> >
> > 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.  

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



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