Open issues on the Crypto-Agility Requirements draft

["Dave Nelson" <d.b.nelson@comcast.net>]

(1) (Issues 274, 275) What do we need in terms of "hint and accept/reject"
vs. actual negotiation of cipher-suites?

(2) (Issue 274) Better text regarding the security considerations
surrounding key management.

(3) (Issue 275) How much backward compatibility with "legacy" RADIUS do we
need?

(4) (Issue 275) Clarify the text regarding the potential for new commands to
fundamentally change the RADIUS operational model".

We were attempting to prohibit "submarine" revisions to the RADIUS
architecture in the guise of crypto-agility solutions.  Since there seems to
be widespread confusion as to what this really means, we need to craft some
more explicit text.

(5) (Issue 303) Too much of the text is open to multiple interpretations.
Taken outside the context of the WG discussions, this document is hard to
follow.

I suspect that this draft needs a major re-write, paying close attention to
avoiding any implicit assumptions.  It was cobbled together from WG
presentations (slide decks) and list discussions.

(5) (Issue 303) "The document currently considers only "hop-by-hop" security
mechanisms, not any "end-to-end" protection (across proxies). I think this
is OK and perfectly reasonable -- but the document should say this, and
explain what this means for interpreting RFC 4962."

(6) (Issue 303) "Much of RFC 4962 is open to multiple interpretations, and
some parts of it can be read as requiring more than hop-by-hop security.
IMHO exactly the same parts can also be read as saying hop-by-hop can be
sufficient (when done properly), and I think this document should
explicitly say it's interpreting 4962 the latter way."

(7) (Issue 303) "Sometimes RADIUS is used to deliver keys (like EAP MSK)
that will be used (perhaps indirectly via additional key derivation steps)
to encrypt information that may be valuable for a long time.  Given this,
the document needs some discussion about "forward secrecy" (whether
revealing the long-term credential allows decrypting all past
communications), and if the conclusion is that crypto-agility solutions
don't need to support forward secrecy (even as optional-to-use feature),
explain the rationale behind this conclusion."

One of this issues we are facing is carving out a relatively narrow scope
for crypto-agility work in RADIUS as opposed to fixing RADIUS security, or
making RADIUS compliant with current day IETF protocol security
requirements.  A clear scoping statement may avoid some of these comments.

(8) (Issue 303) "Authenticating the RADIUS client and server will require
(manual) configuration of some kinds of credentials (currently, the RADIUS
shared secret). The document should say something about what kinds of
long-term authentication credentials (for RADIUS entities) the
crypto-agility solutions are expected to support."

(9) (Issue 303) "Section 4.2 says "Proposals MUST support replay protection.
The existing mechanisms for replay protection are considered adequate and
should be maintained." I think the latter sentence needs some clarification.
If the intent is to say replay protection provided by the current mechanisms
(i.e., basically none for Access-Request messages) is good enough, I would
disagree with that (or at least would expect to see an explanation why
that's the case for Access-Requests). If the intent is something else, the
text needs to be clearer."

(10) (Issue 303) "The document says proposals MUST support negotiation of
cryptographic algorithms. Does "negotiation" here mean picking which
algorithm to use in the protocol (RADIUS client and server figure out an
algorithm supported by both of them), or would negotiation between system
administrators meet this requirement?

This is the "hint and accept/reject" vs. negotiation issue again.

(11) (Issue 303) " Well... RADIUS certainly requires only O(n) keys, but on
the other hand, the amount of data encrypted with a single key is not
necessarily small (when considering the "value of the data" and time
aspects -- in terms of gigabytes, it's probably small compared to what
decent algorithms can handle)."

<snip>

"So, I think the conclusion here needs at the very least some
qualification and additional explanation."

OK. We need more/better text.

There are a few other elements to Issue 303, but many of them may be
resolved by a narrower/clearer scoping statement.

Also, Bernard has proposed some textr around a phase-in / transition plan
that addresses some of the backwards compatibility and negotiation issues.



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