[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [radext] #21: Crypto-Agility thoughts
#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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>