Subject: Re: [radext] #21: Crypto-Agility thoughts

From: "radext issue tracker" <[email-masked]>
Date: Thu, 03 Mar 2011 23:51:32 -0000

#21: Crypto-Agility thoughts

Changes (by bernard_aboba@…):

  * status:  new => assigned

Comment:

 Here is a proposed resolution to this issue:

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

 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.

 [BA] The document already incorporates most of the security advice in
 RFC 4962 relevant to AAA protocols.  However, there appear to be a
 few requirements that are not included.  To clarify their interpretation,
 it is recommended that we add the following text to Section 4.2:

 In addition to the above goals, [RFC4962] Section 2 describes
 the following additional security requirements for AAA protocols:

 1.      Strong, fresh session keys.  RFC 4962 Section 2 states:

          "The AAA protocol MUST ensure that the keying material supplied
 as
          an input to session key derivation is fresh...  The mechanism
 used
          to generate session keys MUST ensure that the disclosure of one
          session key does not aid the attacker in discovering any other
          session keys."`

          RADIUS crypto-agility solutions are REQUIRED to generate fresh
          session keys for use between the RADIUS client and server.
          In order to prevent the disclosure of one session key from aiding
          an attacker in discovering other session keys,
          RADIUS crypto-agility solutions are
          RECOMMENDED to support Perfect Forward Secrecy (PFS) with
          respect to session keys negotiated between the RADIUS client
          and server.

 2.     Limit key scope.  RFC 4962 Section 2 states:

          "Following the principle of least privilege, parties MUST NOT
          have access to keying material that is not needed to perform
          their role."

          In order to enable a NAS and RADIUS server to transmit
          keying material directly between each other, it is RECOMMENDED
 that
          a RADIUS crypto-agility solution be compatible with NAI-based
          Dynamic Peer Discovery [RADYN] as well as that it support the
          use of public key credentials for authentication between the
          NAS and RADIUS server.  For compatibility with existing
          operations, RADIUS crypto-agility solutions SHOULD also support
          pre-shared key credentials.

 3.     Prevent the Domino effect.  RFC 4962 Section 2 states:

          "Likewise, compromise of a single
          authenticator MUST NOT compromise keying material held by any
          other authenticator within the system."

          In order to prevent the domino effect, RADIUS crypto-agility
          solutions MUST enable each RADIUS client and server pair to
          authenticate utilizing unique credentials.

 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.

 [BA] The need to support PFS derives from the
 RFC 4962 requirements, so it is proposed that this be added to
 the Section 4.2 requirements as a recommendation.

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

 [BA] The need to support public-key credentials derives
 from the requirement for direct transport of keys and the need
 for pair-wise shared secrets derives from current operational
 practice.  So it is proposed that recommendations relating to
 support for these credential types
 be added to Section 4.2.

 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.

 [BA] The proposal is that the following text within Section 4.2:

    Proposals MUST support replay protection.  The existing mechanisms
    for replay protection are considered adequate and should be
    maintained.

 be changed to the following:

    Proposals MUST support per-packet replay protection for all
    RADIUS message types.

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

 [BA] The proposal is that the following text in Section 2:

    "of RADIUS implementations to negotiate cryptographic algorithms"

 be changed to:

    "of RADIUS implementations to automatically negotiate cryptographic
 algorithms"

 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.

 [BA] The requirement for a fresh session key derives from RFC 4962,
 Since a fresh session key can be derived from a pre-shared key
 via the exchange of nonces, this doesn't necessarily imply AKM.

 However, the requirement for PFS  as well as for direct key
 transport between a NAS and RADIUS server do effectively imply
 AKM.

 The proposal is to change Section 4.6 to the following:

 4.6. Applicability of Automated Key Management Requirements

    [RFC4107]  provides guidelines for when automated key management is
    necessary.  At the IETF-70 meeting, and leading up to that meeting,
    the RADEXT WG debated whether or not RFC 4107 would require a RADIUS
    Crypto-Agility solution to feature Automated Key Management (AKM).
    The working group determined that AKM was not inherently required for
    RADIUS based on the following points:

    o  RFC 4107 requires AKM for protocols that involve O(n^2) keys.
       This does not apply to RADIUS deployments, which require O(n) keys.

    o  Requirements for session key freshness can be met without AKM,
       for example, by utilizing a pre-shared key along with an exchange
       of nonces.

    o  RADIUS does not require the encryption of large amounts of data in
       a short time.

    o  Organizations already have operational practices to manage
       existing RADIUS shared secrets to address key changes required
       through personnel changes.

    o  The crypto-agility solution can avoid use cryptographic modes of
       operation such as a counter mode cipher that require frequent key
       changes.

    However, the same time, it is recognized that features recommended
    in Section 4.2 such as support for PFS and direct transport of keys
    between a NAS and RADIUS server, can only be provided by a solution
    supporting AKM.  As a result, support for Automated Key Management
    is RECOMMENDED within a RADIUS crypto-agility solution.

 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.

 [BA] Propose that the following text in Section 4.2:

    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.

 be changed to:

    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.  In analyzing the resilience of a crypto-agility
    solution, it can be assumed that the RADIUS server can be configured
    to require the use of new secure algorithms in the event of a
 compromise of
    existing cryptographic algorithms or the legacy RADIUS shared
    secret.

 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.

 [BA] Recommend that the following text in Section 4.3:

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

 be changed to:

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

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

 [BA] Proposal is to change the following text in Section 4.3:

    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.  Similarly, a
    proposal SHOULD focus on the crypto-agility problem and nothing else.
    For example, proposals SHOULD NOT require new attribute formats or
    include definition of new RADIUS services.

 to the following:

 "Crypto-agility solutions SHOULD NOT require
 changes to the RADIUS operational model as defined in
 "RADIUS Design Guidelines" [RFC 6158] Section 3.1 and
 Appendix A.4.  Similarly, a proposal SHOULD focus on the
 crypto-agility problem and nothing else.  For example, proposals
 SHOULD NOT require new attribute formats and SHOULD be compatible
 with the guidance provided in [RFC 6158] Section 2.3."

-- 
-----------------------------------+----------------------------------------
 Reporter:  Pasi.Eronen@…          |       Owner:  bernard_aboba@…          
     Type:  defect                 |      Status:  assigned                 
 Priority:  blocker                |   Milestone:  milestone1               
Component:  Crypto-Agility         |     Version:  1.0                      
 Severity:  Active WG Document     |    Keywords:                           
-----------------------------------+----------------------------------------

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

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "radext issue tracker" <[email-masked]>
Date: Fri, 04 Mar 2011 06:15:18 -0000

* status:  assigned => closed
  * resolution:  => fixed

-- 
-----------------------------------+----------------------------------------
 Reporter:  Pasi.Eronen@…          |        Owner:  bernard_aboba@…          
     Type:  defect                 |       Status:  closed                   
 Priority:  blocker                |    Milestone:  milestone1               
Component:  Crypto-Agility         |      Version:  1.0                      
 Severity:  Active WG Document     |   Resolution:  fixed                    
 Keywords:                         |  
-----------------------------------+----------------------------------------

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