Subject: RE: [ Comments on automated key management and crypto agility

From: Bernard Aboba <[email-masked]>
Date: Sat, 22 Dec 2007 09:56:47 -0800

To clarify --

RADIUS has previously used MD5 as a stream cipher to protect attributes including passwords
(User-Password, Tunnel-Password) and keys (keying attributes within RFC 2548).  

While the use of MD5 for integrity protection has a set of issues (e.g. collisions), the use of MD5
as a stream cipher brings up another set of issues, such as known plaintext attacks.  

Given this, the ability to negotiate alternative "hiding" mechanisms is considered an important part
of RADIUS crypto-agility.   

However, this is logically separate from the need to provide end-to-end protection for key transport. 

So far, the need to solve the end-to-end key transport problem has not been part of RADIUS
crypto-agility requirements.  Should it be? 

Note that it is possible for a crypto-agility solution to solve the "hiding" problem without solving the
end-to-end transport problem. 

With Diameter, it was clear that the IESG expected a solution to both problems -- ciphersuite
negotiation (via TLS/IKE) as well as a mechanism for avoiding key disclosure to proxies 
(e.g. redirect). 

The current RADIUS crypto-agility requirements only appear to require solution to the 
former problem (ciphersuite negotiation), but not the latter (key disclosure).  That said,
there has been some discussion of how the current proposals (RADIUS crypto-agility and 
RADIUS/DTLS) could address the key disclosure problem.

> From: [email-masked]
> To: [email-masked]; [email-masked]
> Date: Thu, 20 Dec 2007 22:44:10 -0500
> Subject: [ Comments on  automated key management and crypto agility
> 
> 
> 
> 
> It's my understanding that you are in the middle or have just finished
> a consensus call regarding automated key management and radius crypto
> agility.
> 
> I gave the chairs some advice on this topic a while ago.  It turns out
> I completely failed to understand the question I was asked.
> 
> 
> I assumed that the crypto agility work was intended to strengthen
> radius's integrity protection and dependence on md5.
> 
> However as I understand now, the scope of the work also includes a
> real solution to the key transport problem.
> 
> So I don't think the advice I gave the WG applies.
> 
> I don't know if this changes any of your deliberations, but I just thought I'd write and let you know that I was confused.
> 
> Here's my current understanding of the situation in this space.
> 
> * RFC 3962 says that we should have a way so that people do not need
>   to expose keys to third parties (proxies).  This is not mandatory to
>   use, but we need to have a solution for that problem.
> 
> * Diameter has the redirect mechanism which handles this need in some
>   deployments.
> 
> * Our protocols don't force you to use proxies, but there are a lot of
>   good reasons why you might want to do so.
> 
> 
> * Hokey may need to have a solution to do key management that meets
>   the RFC 3962 requirements.
> 
> * It may be the easiest place for hokey to solve its problem if it has
>   one is at the radius key transport level.
> 
> * That doesn't inherently make it radext's problem to solve.  We also
>   still haven't   even figured out how much of this is hokey's problem.
> 
> I'm trying to understand this all better and to try and figure out
> what sort of consensus we want to build.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 26 Dec 2007 18:49:08 +0100

> protection for key transport.

  What is "end to end" ?

  Not to be dumb, but there are a number of parties involved:

  supplicant (or end user software)
  NAS (or AP)
  local RADIUS server
  intermediate proxies (0 or more)
  home RADIUS server (may be the same as the local RADIUS server)

  Which ends are we talking about?  The EAP-TLS methods allow the
supplicant and home server to agree on a key.  So any "end to end"
problem would appear to be getting keying material from the supplicant
OR home server to the NAS, without exposing that material to any local
server, or proxy server.

> crypto-agility requirements.  Should it be?

  I don't see how we could do NAS to home server key transport in
RADIUS.  So the answer is (I think) "No".  Any end-to-end key transport
should involve EAP-TLS methods *and* RADIUS, I think.  Just doing it in
one or the other wouldn't work.

  If we tried to do it in RADIUS, we would end up with something that
looked nothing like RADIUS.

> negotiation (via TLS/IKE) as well as a mechanism for avoiding key

  redirects have problems in practical deployments.  Intermediate nodes
often exist for commercial reasons, both for business relationships and
for application of intermediary policies.

  Alan DeKok.

--
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: "Glen Zorn" <[email-masked]>
Date: Wed, 26 Dec 2007 09:59:23 -0800

...

[gwz] 
And, unfortunately, that's just scratching the surface; how that lame scheme
got into an RFC I'll never know... 
[/gwz]

  Alan DeKok.

---

From: <[email-masked]>
Date: Wed, 26 Dec 2007 10:42:20 -0800

>  What is "end to end" ?

I think it means something like "protection of RADIUS attributes from
disclosure to parties other than the NAS and home server".  

> RADIUS.  So the answer is (I think) "No".  

In the AAA WG there were a number of mechanisms investigated by
which a NAS and home server could derive a key that could be
used to protect attributes from disclosure to proxies.  These methods
included Kerberos and CMS.  For example, see:
http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt

So I think the question is not "can it be done?" but rather 
"how does this relate to RADIUS crypto-agility?" and
"should solving this problem be a requirement?"

---

From: <[email-masked]>
Date: Wed, 26 Dec 2007 10:52:31 -0800

>  problems in practical deployments.

Which "practical deployments" are we talking about?

While proxies are widely used today to facilitate inter-domain
roaming, as far as I know, the combination of inter-domain roaming
and EAP is very rare.

While EAP-based technologies such as WiMAX may change the
situation, as I understand it, the use of EAP today is largely confined
to enterprise scenarios.    For example, the vast majority of all
IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP.

In terms of major EAP deployments that support inter-domain roaming
with substantial usage, one deployment (EDUROAM) is several orders of
magnitude larger than any other that I am aware of.

As far as I know, EDUROAM does not use Diameter nor are there any
major deployments of Diameter EAP.

Am I missing something, or are there really any "practical experience" 
here?

---

From: Alan DeKok <[email-masked]>
Date: Wed, 26 Dec 2007 20:31:25 +0100

> Which "practical deployments" are we talking about?

  RADIUS proxies.  There are multiple inter-telco && inter-country
deployments using RADIUS.  I'm not aware of any similar large-scale
deployment of Diameter.  (i.e. everyone I've talked to says "perhaps one
day we'll move to Diameter".)

> roaming, as far as I know, the combination of inter-domain roaming

  The FMCA is trialling exactly this.

> IEEE 802.11 hotspot deployments use Web-based access (e.g. UAM), not EAP.

  Yes.  In fact, the use of EAP *prevents* a large number of business
models for network access.

> magnitude larger than any other that I am aware of.

  UMA leverages EAP and RADIUS, but it's buried deep in the network.

> major deployments of Diameter EAP.

  Yes.

> Am I missing something, or are there really any "practical experience"

  Practical experience with existing AAA servers, proxies, and business
models.  The current technology is RADIUS.  I'm trying to figure out how
 AAA redirection (and avoiding the intermediary proxies) helps anyone.
I don't think it does.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Dec 2007 12:05:16 -0800

>   The FMCA is trialling exactly this.

Is this the Fixed Mobile Covergence Alliance?  

(This seemed the most likely of the expansions provided by Google, the others being:

Family Motor Coach Association
Florida Mosquito Control Association
Florida Marine Contractors Association
Friends of Montgomery County Animals)

>> For example, the vast majority of all

Could you expand on the problems?

>   UMA leverages EAP and RADIUS, but it's buried deep in the network.

Yup.  Doesn't seem like this would require inter-domain proxies.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Dec 2007 12:18:16 -0800

> The FMCA is trialling exactly this. 

It will be interesting to see how well it works.  I have previously been involved in a number of 
inter-domain roaming trials.  When the RADIUS traffic was routed through an exchange point,
the results were not very promising.  With packet loss rates of 1-5%, RADIUS retransmissions
were pretty common and this would often lead to EAP retransmissions.  The overall
authentication times could get pretty long and sometimes authentication wouldn't complete
at all.  Most of the carriers we worked with ended up deploying web portals instead :(

---

From: <[email-masked]>
Date: Wed, 26 Dec 2007 21:34:24 +0100

Hi,

> > > roaming, as far as I know, the combination of 

GSMA trialed (with a number of hotspot & GSM operators mainly in
Europe & Asia) EAP-based 802.11 roaming few years ago. This concentrated
mainly on EAP-SIM and EAP-AKA.

Yes.

[snip]

> >> For example, the vast majority of all IEEE 802.11 hotspot 
> deployments 
> >> use Web-based access (e.g. UAM), not EAP.
> > 

In the existing specs for 3GPP GAN (i.e. the current UMA) inter-operator
roaming is defined and reuses in a carbon-copy fashion 3GPP Interworking
WLAN EAP-based RADIUS roaming interface. However, operator business
models typically do not favor deployments where GAN would need
inter-operator
RADIUS interface.. at least I am not aware of any such deployments.

Jouni

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Dec 2007 05:43:51 +0100

> Is this the Fixed Mobile Covergence Alliance? 

  Yes.  I've been advising on the interconnect.

> Could you expand on the problems?

  A customer wants to buy access.  Right now in WiFi hotspots, they
connect to a walled garden, and type in credit card details.  Once
payment has been processed, they obtain network access.

  If the only way to obtain network access is via EAP, then you have a
bootstrapping problem.  Once the users have signed up, everything is
great.  The users who *haven't* signed up are shut out.  Permanently.

  The issue is less EAP than EAPoL.  Without a real network connection,
it's impossible for a client machine to do much of anything.  EAP could
be used in a walled garden if PANA was widely deployed, for example.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Dec 2007 05:52:19 +0100

Bernard Aboba wrote:
> the results were not very promising.  With packet loss rates of 1-5%,

  I'll track the tests, and see if we can do some measurements under load.

  For existing (non-EAP) proxies, I don't recall seeing loss rates that
high.  I'll go check, but I think latencies and loss have decreased,
while bandwidth has increased in the net.  Plus, most RADIUS
interconnects are now done over Ipsec, which helps with the underlying
reliability.

> RADIUS retransmissions

  WiMAX is standardizing on EAP for authentication.  Discussions are
underway to design a standard interconnect architecture.  So this
appears to be less of a problem now.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Dec 2007 11:23:24 +0100

> disclosure to parties other than the NAS and home server". 

  OK.  I just wanted to be sure.

> http://www.watersprings.org/pub/id/draft-kaushik-radius-sec-ext-06.txt

  i.e. The NAS somehow knows a realm, knows how to talk to a server for
that realm, and can obtain a secret key for that realm.

> So I think the question is not "can it be done?" but rather "how does
> this relate to RADIUS crypto-agility?" and

  I would say that it is a problem we should try to solve.  I'm not sure
how much it affects crypto-agility.

  Back to my earlier question about "end to end", I think the only ends
that matter are the end user and home server.  The NAS is in contact
with both, and can leverage it's relationship with the end user to do
things that are normally impossible in RADIUS.   If we assume that the
end user and home RADIUS server can independently derive keying
material, then the server can supply keying material to the NAS, and the
end user can do the same.  The NAS can then derive keying material,
without it being exposed to anyone else.

  e.g. RADIUS, end-user: derive K', K''
       RADIUS -> NAS: E = ENC(K')         (using key K'')
       end-user -> NAS: K''

  If we assume that each RADIUS hop also encrypts E using the
Tunnel-Password method:

       T = tunnel_encrypt(per-hop-secret, E)

  Then we have the following properties:

  - no RADIUS proxy knows K' (they only know E)
  - The NAS can derive K' from E and K''
  - an attacker watching RADIUS only knows T
  - an attacker watching the end-user traffic only knows K''
  - an attacker watching *both* RADIUS and supplicant traffic knows
    T and K'', which is insufficient to derive K'
  - any intermediary RADIUS proxy that handles tunnel-password
    encryption can transport E.

  For EAP-TLS based methods, the TLS master session key can be used to
derive keying material.  We would need to define one new RADIUS
attribute to transport the keying material E, and update EAPoL to
transport K''.   This capability could be negotiated between the NAS and
supplicant, and advertised to the home RADIUS server by the supplicant,
inside of the TLS tunnel.

  So far as crypto-agility goes, this method needs to be extensible to
multiple key sizes, encryption methods, authentication hashes, etc.  But
it's independent of transport proposals such as DTLS or TLS.

  (insert standard disclaimer here: this proposal has not been vetted by
a crypto expert)

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 27 Dec 2007 11:18:10 -0500

Alan DeKok writes...

> great.  The users who *haven't* signed up are shut out.  Permanently.

So, this is really an enrollment issue, not an authentication issue?

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 27 Dec 2007 11:22:25 -0500

Alan DeKok writes...

> Plus, most RADIUS interconnects are now done over Ipsec, which helps
> with the underlying reliability.

I'm surprised to hear that (IPsec usage).  Is this in selected topologies or
deployment scenarios?  If IPsec were really used for most RADIUS
transmissions, wouldn't we have already solved the Crypto-Agility problem?
:-)

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Dec 2007 19:35:02 +0100

> So, this is really an enrollment issue, not an authentication issue?

  No.  Think of roaming, which I've been spending a lot of time on lately.

  If authentication is required for any IP-based network access, then
how do roaming users know that they can authenticate using the local
network?  Pre-provisioning devices with roaming knowledge doesn't scale,
and it doesn't handle dynamic networks.  802.11af doesn't scale either,
and isn't designed to scale.

  When the user doesn't have any network access, they can't determine
whether or not authentication is possible.  They can't determine which
authentication credentials to use.  So requiring authentication means
*forbidding* network access to a large class of users who could
*potentially* obtain network access.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 27 Dec 2007 19:38:00 +0100

> transmissions, wouldn't we have already solved the Crypto-Agility problem?

  Most roaming providers and large companies do AAA interchange via IPSec.

  IPSec doesn't solve Crypto-Agility because there's no way for the
RADIUS server to discover, or enforce, authentication and encryption
policies.  The only security relationships between the two are
maintained in administrators heads, or in scripts tying the two systems
together.  Neither method is scalable, maintainable, or standardizable.

  Alan DeKok.