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

["David B. Nelson" <dnelson@elbrysnetworks.com>]

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.

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

Yes.

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

OK.

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

As of submission of the -00 draft, the IESG was still deliberating the
re-charter request.  Will be fixed in -01.

> 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

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

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

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

> Given that this is new and presumably desirable functionality,
> why is a simple upgrade path not sufficient?

A "fork-lift" upgrade?  :-)



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