Subject: Open issues on the Crypto-Agility Requirements draft

From: "Dave Nelson" <[email-masked]>
Date: Wed, 10 Jun 2009 11:56:43 -0400

(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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jun 2009 08:54:36 +0200

> requirements.  A clear scoping statement may avoid some of these comments.

  My $0.02: the crypto-agility work can be put into two rough classes.

1) Minor changes to RADIUS

2) TLS methods

  The goal with RadSec && DTLS is to fix RADIUS security.  RadSec can
address the inter-organization security, for organizations that find
IPSec too problematic.  DTLS can address intra-organization security, so
that we have an upgrade path for when MD5 is broken completely.

  The alternative to TLS methods is something like the following
(created after about 10 minutes of thought).

  1) Change MD5 to SHA-256
  2) Set the high bit in the RADIUS "code" field.

  i.e. packets with the high bit set use SHA-256 for security, rather
than MD5.  We would need a new "SHA-only" secret, too.  Everything else
in RADIUS is unchanged.

  This would provide a *simple* upgrade path, with minimal amounts of
work for all parties involved.  It will not address the issue that 100's
of 1000's of legacy devices don't support the new system.  It won't
address the issue that many vendors won't upgrade their firmware.

  I think TLS is a better solution.  It requires more work, but many
vendors already rely on OpenSSL for HTTPS traffic, so the code exists,
and is largely already on the machines.

  The alternative to SHA-256 or TLS would be public shame and
humiliation for this WG.  Once MD5 is broken, we would be responsible
for a security protocol that has *zero* security.  A much better
approach is to have a solution in place before the break.

  The onus then gets pushed back to the vendors.  Once MD5 is broken,
vendors will be subject to shame for not implementing this WG's solution
to the problem.  The vendors that care will upgrade.  The vendors that
don't care will knowingly accept the consequences of shipping broken
equipment.

  Let's also not forget that the majority of the AAA server market is
provided by only 5-6 vendors.  Those vendors are largely on this list,
and can choose to have an upgrade path available for when MD5 is broken.

> that addresses some of the backwards compatibility and negotiation issues.

  See also the DTLS document, which addresses some of this.  It assumes
that the people running the NAS communicate with the people running the
AAA server.  It assumes that the upgrade path is negotiated *once*.
After that, the NAS is marked as "DTLS enabled", and the server refuses
to talk legacy RADIUS with the NA.  Changing the flag back requires
administrator intervention.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Thu, 11 Jun 2009 10:00:07 -0400

Alan DeKok writes...

>   2) Set the high bit in the RADIUS "code" field.

Well, the term "crypto-agility" implies that the protocol is not bound to
any *single* cipher-suite.  Substituting SHA-256 for MD5 would not be a
crypto-agility solution, IMO.  It would be a "fix" for internal RADIUS
security until such time as SHA-256 becomes ineffective.

One *could* make the argument that RADIUS doesn't need to be crypto-agile,
all we need is a "fix" for the internal security mechanisms to tide us over
until the transport wrapper security mechanisms are widely deployed.

In terms of revising the RADIUS Crypto-agility Requirements draft, it would
be helpful to know whether the WG still thinks that RADIUS needs internal
security that is indeed crypto-agile.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jun 2009 16:31:11 +0200

> security until such time as SHA-256 becomes ineffective.

  Yes.

> until the transport wrapper security mechanisms are widely deployed.

  That's my opinion.  Everyone who has tried to fix RADIUS, or add
negotiation has gotten nowhere.

> security that is indeed crypto-agile.

  Nothing.  Give up on ad-hoc security, and wrap the entire protocol in TLS.

  It makes the "wiretap via RADIUS" issue more difficult.  But I've
never understood we can securely allow third-parties to insert arbitrary
traffic into an AAA exchange, and *without* having one of the parties
notice that the traffic exists.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Jun 2009 22:05:23 +0700

Alan DeKok [mailto://[email-masked]] writes:

...
 
> notice that the traffic exists.

It's not; fortunately, that's not necessary.

...

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 11 Jun 2009 22:17:41 +0700

> security until such time as SHA-256 becomes ineffective.

Right.

> until the transport wrapper security mechanisms are widely deployed.

As I mentioned in the meeting, this is making a rather huge assumption about
deployment issues over which the IETF has no control; in addition, the
experience WRT Diameter security deployment is not especially encouraging.

> security that is indeed crypto-agile.

I think that it would make the protocol much more useful; OTOH, that seems
to be a non-goal of the WG & so is likely irrelevant.  As far as providing
simple, hop-by-hop security in a better way DTLS (presupposing that its
usage is properly specified _and_ it is widely deployed) is certainly more
than adequate.

...

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Jun 2009 08:37:04 -0700

I would remind people that the focus here is on the requirements, not
the solution. 

One of the reasons we do requirements documents is to determine when
we are done. 

The requirements document has already taken so long that we are now in
danger of finishing work on solutions that may not meet the requirements. 

So we need to ratchet up the rate of progress, so as to finish this document
in the next few months. 

One big issue that we need to close on his the requirements with respect
to downgrade attacks. 

Assuming that legacy RADIUS is still supported in a NAS deployment 
(likely to be true for a long time), then it is possible for an attacker 
to attempt to convince the RADIUS server (which we presume has been 
upgraded) to utilize legacy RADIUS with MD5 security. 

It seems to me that the only way to completely address this is by having
the NAS indicate support *within RADIUS*.  

Use of dynamic discovery doesn't help without DNSSEC, since an attacker
can forge the RRs to force a downgrade. 

Use of transport wrappers can't address it either if we assume that 
attackers have the ability to cause arbitrary packets to be lost, and that
the NAS will drop down to ordinary RADIUS in the situation that transmission
layer security doesn't generate a response. 

However, if we assume that MD5 hasn't yet been cracked, then even if the
attacker convinces the NAS to use legacy RADIUS, if there is an attribute
that annouces what the NAS is capable of, when the server receives the
Access-Request, it can determine that something has gone wrong (e.g.
client claims to support crypto-agility, but the Access-Request didn't
use it). 

As Glen pointed out, if sensitive information is provided in the Access-Request,
you still have a problem (e.g. User-Password attribute could expose the user
password).  But at least the issue can be discovered after the fact.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 11 Jun 2009 08:43:39 -0700

> experience WRT Diameter security deployment is not especially encouraging.

My understanding is that many Diameter deployments use no security at all, 
making them much *less* secure than RADIUS. 

And these deployments are with NASes that are considerably more expensive
than a mass market access point.  

I'm not sure whether the issue is operational (too hard to configure) or 
with the implementation.  

But something, somewhere, appears to have gone very wrong.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 11 Jun 2009 17:55:24 +0200

> making them much *less* secure than RADIUS.

  I've seen that, too.

> But something, somewhere, appears to have gone very wrong.

  It's harder to insert traffic into a TCP connection than to forge UDP
packets.  But it's not impossible.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Jun 2009 10:26:18 +0200

> upgraded) to utilize legacy RADIUS with MD5 security.

  Not if the RADIUS server has an administrative flag saying "this NAS
supports better security".

  Once that flag is set, then any down-grade attack disappears.

> the NAS indicate support *within RADIUS*. 

  Use an insecure protocol to negotiate a secure one... hmmm...

  My suggestion in the DTLS document is for the NAS to simply start
using the better security method.  Once the NAS has been authenticated,
the "NAS supports better security" flag is set, and legacy RADIUS
becomes impossible.

> can forge the RRs to force a downgrade.

  Legacy RADIUS doesn't use RR's.  If the client is found via RR's, it
MUST use the newer, more secure, solution.

> layer security doesn't generate a response.

  The server can keep a flag saying "NAS uses secure RADIUS".  If it
sees a legacy RADIUS packet from the NAS, it knows something is wrong.
It can return an Access-Reject, or simply discard the packet.  This
protects the server.

  The client should also have a per-server flag saying "negotiated
secure RADIUS".  Once that flag is set, it refuses to use legacy RADIUS.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 12 Jun 2009 02:40:52 -0700

>   Once that flag is set, then any down-grade attack disappears.

In a very large deployment (e.g. thousands of NASes) keeping track of
which ones support the new capabilities is non-trivial.

> secure RADIUS".  Once that flag is set, it refuses to use legacy RADIUS.

This requires that the RADIUS client population can be enumerated and
clearly identified.  In a deployment that has a list of RADIUS clients at
fixed IP addresses, that requirement can be met.   In other situations,
that's not as obvious. 

>   Use an insecure protocol to negotiate a secure one... hmmm...

For this purpose, MD5 is not "insecure" until it is possible to forge
RADIUS messages in near real-time.  Even with all the attacks against
WEP, the progression from cracking it in weeks to minutes took place
over a significant time period.  

> the "NAS supports better security" flag is set, and legacy RADIUS

That represents the end state where all legacy NASes have been
replaced.

> MUST use the newer, more secure, solution.

But that doesn't imply that the RRs are retrieved securely, so dynamic
discovery doesn't address the downgrade issue.  In fact, one could argue
that the introduction of (insecure) dynamic discovery complicates the security 
analysis considerably.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Jun 2009 12:06:32 +0200

> which ones support the new capabilities is non-trivial.

  I'm not sure I understand this.  A server can't track 1 bit of
information for each NAS that connects to it?

> fixed IP addresses, that requirement can be met.   In other situations,

 No.  It requires that the *current* NAS population be permitted to talk
to the server.  Which it is.  It then requires that the server be
upgrade to support the above flag.  It then permits each NAS to be
upgraded to use the new security measures.

  Once the server sees a NAS use a new security system, it flips a bit
in a database for that NAS from "false" to "true".  This doesn't affect
any of the other NASes.

> That represents the end state where all legacy NASes have been

  No.  The flag is *per* NAS.  It's not global.

> discovery doesn't address the downgrade issue.

  If a server sees an unknown client connect, it will be either (a) an
attacker, or (b) a client that discovered the server via RR's.  It
doesn't know until it validates the identity of the client.  And it MUST
use a secure method to do so.  It MUST NOT use the legacy RADIUS shared
secret, because the entire reason it's an unknown client is that it
doesn't have a legacy RADIUS secret for the client.

  At that point, the server opens itself up to SSL connection exhaustion
attacks.  But there are no *RADIUS* issues with that.  Once the server
has used TLS to validate that the client is known, it uses TLS to
transport the legacy RADIUS packets.

  If a client uses RR's to discover a server, it MUST use a TLS-based
method to communicate with that server.

  If a client has a fixed IP to communicate with a server, it SHOULD be
configurable as to whether or not it uses TLS.  If the admin says "no,
don't use TLS", then there's no downbidding attack.  If the admin says
"yes, use TLS", then there's no downbidding attack: the NAS refuses to
speak legacy RADIUS, because it's been told to *not* speak legacy RADIUS.

> In fact, one could argue
> that the introduction of (insecure) dynamic discovery complicates the
> security analysis considerably.

  Yes, that's true.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 12 Jun 2009 19:31:22 +0700

My guess is that it's a matter of "security by assertion and assumption",
the assertion being that  our internal network is totally secure from
external attack with the assumption that all employees are both trustworthy
& incorruptible.