[radext] #21: Crypto-Agility thoughts

["radext issue tracker" <trac@tools.ietf.org>]

#21: Crypto-Agility thoughts
-----------------------------------+----------------------------------------
 Reporter:  Pasi.Eronen@â          |       Owner:  bernard_aboba@â          
     Type:  defect                 |      Status:  new                      
 Priority:  blocker                |   Milestone:  milestone1               
Component:  Crypto-Agility         |     Version:  1.0                      
 Severity:  Active WG Document     |    Keywords:                           
-----------------------------------+----------------------------------------
 Date first submitted:   February 18, 2009
 Reference: http://ops.ietf.org/lists/radiusext/2009/msg00086.html

 At Dan Romascanu's request, I've taken an early look at draft-ietf-
 radext-crypto-agility-requirements-01. This was probably a good idea
 from Dan, since if I had sent a DISCUSS this long at IESG evaluation
 time, the WG might have (somewhat justifiably) suggested doing some
 rubber-hose discuss clearing on a dark San Francisco back alley :-)

 Overall comment:

 Currently, much of the text in this draft seems to be open to multiple
 interpretations. It's possible that the WG members agree on the
 interpretation (but it's also possible that they only *think* they
 agree...), but someone who hasn't participated in the WG discussions
 will be somewhat confused.

 Personally, I'm not really a big fan of requirements RFCs (and would
 rather spend the energy in getting the solutions right)... but the
 AAA space certainly has some history of requirements open to multiple
 interpretations (including the infamous "Housley criteria" that became
 RFC 4962), and a special branch of hermeneutics devoted to interpreting
 them in ways that were not always very productive :-) [and BTW -- I've
 certainly done some of that myself...]

 The outcome I'd really like to avoid is having IESG first approve
 these requirements, and then getting a solution draft that in WG's
 opinion meets the requiremnts, but is very different from how IESG
 understood the requirements. So, the main intent of the remaining
 comments is reducing the likelihood of this happening.

 Hop-by-hop/end-to-end:

 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

 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. (And once the
 document has this explanation, you might want to run it by some other
 ADs, too -- e.g. Tim and Russ)

 Forward secrecy:

 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.

 Authentication/long-term credentials:

 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.

 Presumably, they MUST support pair-wise shared secrets. Other
 possibilities for long-term credentials could include e.g. X.509
 certificates with PKI, public keys without certification
 infrastructure (generate keypair + configure fingerprint of peer's
 key), or Kerberos. Even if the conclusion is that nothing else than
 pairwise shared secrets is needed, that should be said in the document
 (with rationale explaining why).

 Replay protection:

 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.

 Meaning of negotiation:

 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?

 I assume the WG has rough consensus about what this means, and
 ordinarily, I would have automatically assumed it's the former.  But
 some earlier proposals in this space have supported only the latter
 kind (which does provide some kind of algorithm agility -- it's better
 than hardcoding MD5 -- but could mean synchronized manual work for
 every transition)...

 Automated Key Management:

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

 And if you anyway support negotiating the algorithms (in the
 protocol), generating a fresh session key may not be that much extra
 effort, and may be needed anyway since the key can depend on the
 selected algorithm (if you negotiate 256-bit AES, you need a 256-bit
 key; if it's 3DES, 168 bits, etc.).  And the solutions should avoid
 using the same cryptographic key with multiple algorithms (and the
 easiest way to ensure this would probably be fresh session keys).

 Generating a fresh session key probably also simplifies replay
 protection (it's the obvious time to e.g. reset counters to zero), but
 other approaches to replays are certainly feasible.

 And obviously, forward secrecy and supporting any other types of
 long-term credentials than shared secrets requires automated key
 management of some kind.

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

 *If* a solution not supporting forward secrecy and not supporting
 other types of credentials is acceptable, *and* replay protection is
 solved in certain way, *and* the solution can ensure that the
 negotiated algorithms get keys appropriate for them, *and* the
 solution can ensure that two algorithms don't use the same key, then
 you might get away with no AKM. But even then, AKM might be less work.

 Compromise of legacy shared secret:

 Section 4.2 says "Crypto-agility solutions MUST avoid security
 compromise, even in situations where the existing cryptographic
 algorithms utilized by RADIUS implementations are shown to be weak
 enough to provide little or no security (e.g. in event of compromise
 of the legacy RADIUS shared secret).  Included in this would be
 protection against bidding down attacks."

 If interpreted literally, this requirement could be very difficult
 to meet (perhaps impossible).

 It seems to assume that for this particular peer, the administrator
 has configured two different shared secrets (one for the current
 security mechanisms, another for the new ones), but has not configured
 whether to use the old or new mechanisms (with this particular peer),
 and instead, that is negotiated somehow.

 If the attacker knows the legacy shared secret, and has complete
 control over the communication channel (and in particular, can drop
 messages going from A to B), then it seems the attacker will be
 indistinguishable from a valid peer that supports only the legacy
 mechanisms (and does not know the new shared secret), and detecting
 bidding down will not be possible.

 Preventing bidding down in less extreme cases of compromise is of
 course both possible and desirable (e.g. if the algorithms are just
 weak but not breakable in real time, or if the attacker doesn't have
 complete control over the communications). And the administrator could
 always configure just the "new shared secret", if he/she knows that
 the peer supports it.

 Backward compatibility/negotiation:

 Section 4.3 says "Solutions to the problem MUST demonstrate backward
 compatibility with existing RADIUS implementations.  That is, a
 crypto-agility solution needs to be able to send packets that a legacy
 RADIUS client or server will receive and process successfully.
 Similarly, a crypto-agility solution needs to be capable of receiving
 and processing packets from a legacy RADIUS client or server."

 The intent of this paragraph is probably right, but currently, it's
 somewhat open to multiple interpretations. Would something like this
 capture the intent?

 "Solutions to the problem MUST demonstrate backward compatibility with
 existing RADIUS implementations.  That is, an implementation that
 supports both the crypto-agility solution and legacy mechanisms MUST
 be able to talk with legacy RADIUS clients and servers (using the
 legacy mechanisms). Acceptable solutions to determining which set of
 mechanisms is used (with a particular peer) include some kind of
 negotiation, and manual configuration."

 Note that *not* meeting this requirement would actually be quite
 difficult... if the intent of this paragraph was to require some kind
 of negotiation (interpreted loosely -- anything more automatic than
 manual configuration), the text should say so.

 "Operational model"?

 Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes
 to the RADIUS operational model, such as the introduction of new
 commands or maintenance of [additional] state on the RADIUS server."

 I'm not sure what "operational" means here -- at first I thought it
 might mean "operations and management" (so the requirement would be
 basically "SHOULD not complicate life for administrators"), but the
 two examples given don't seem to fit that very well. And it seems any
 solution that e.g. derives fresh session keys will involve some small
 (but greater than zero) amount of additional state on clients and
 servers.

 If the intent was really operations and management, perhaps the should
 be rephased something like "When using long-term shared secrets for
 authentication, crypto-agility solutions SHOULD NOT require more
 operations and management work than the current solutions."

 "RADIUS service?"

 Section 4.3 says "For example, proposals SHOULD NOT [..] include
 definition of new RADIUS services."

 What's a RADIUS service -- i.e. what types of proposals this
 definition would disqualify? (In RFC 2865, "service" is defined as the
 service provided by the NAS to the user, but that definition doesn't
 seem applicable here.)
 [David Nelson]
 > The outcome I'd really like to avoid is having IESG first approve
 > these requirements, and then getting a solution draft that in WG's
 > opinion meets the requiremnts, but is very different from how IESG
 > understood the requirements. So, the main intent of the remaining
 > comments is reducing the likelihood of this happening.

 Exactly!

 I can propose some text to resolve the editorial issues -- lack of clarity
 because of poor wording.  I'll need assistance from the WG in resolving
 the
 substantive issues, such as whether RADIUS should have a true negotiation
 mechanism for cipher-suites and whether RADIUS needs forward secrecy or to
 be retrofitted with Automated Key Management.

 WG members, please comment on the issues that Pasi has raised in his
 review,
 ASAP.  If we get some good discussion going, we could have a -02 version
 of
 the draft prior to IETF 74 (coming up real soon now).

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/radext/trac/ticket/21>
radext <http://tools.ietf.org/radext/>


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