Comments on "Crypto-Agility Requirements for RADIUS"

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

Questions:

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?


Editorial comments:

Front page header:
Since the source of the document is stated in section 1.1 to be the radext
WG, David's role should probably be "Editor".

Section 1.2:
s/propose one of more Internet Drafts/propose one or more Internet-Drafts/

Section 2:
s/Crypto-Agility is the ability for/Crypto-agility is the ability of/

Section 4.5, paragraph 5 states:

   Editorial Note: With the expected acceptance of the proposed RADEXT
   WG Charter revision, some of the issues raised in the preceding
   paragraphs become moot, and this section ought to be revised to
   reflect the revised charter.

Haven't those charter revisions already taken place?


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) 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).  I
think that it is at least inappropriate in a requirements document, in that
it assumes a solution.

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

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.

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 this is new and presumably desirable functionality, why is a simple
upgrade path not sufficient?

Section 4.5, paragraph 3 states:

   Crypto-agility solutions SHOULD NOT require fundamental changes to
   the RADIUS operational model, such as the introduction of new
   commands or maintenance of state on the RADIUS server.  

OK, I'll bite: how, exactly, does the introduction of a new command
fundamentally change the RADIUS operational model?



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