Subject: RE: E2E and crypto-agility

From: "Glen Zorn" <[email-masked]>
Date: Thu, 3 Jan 2008 15:04:17 -0800

...

  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.
[gwz] 
It's hard to see how this solves any known problem.  We already know how te
secure the key on the wire; the only problem is with evil proxies.  Since in
the last step the end-user transmits K'' to the NAS (necessarily unencrypted
since the peer & NAS do not yet share any keying material) you have
basically divulged your key-encrypting key to the world, which of course
includes any RADIUS proxies that were in the forwarding path.  So what does
this help?
[/gwz] 

--
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: Fri, 04 Jan 2008 00:22:58 +0100

Glen Zorn wrote:
> secure the key on the wire; the only problem is with evil proxies.

  Um... if you don't trust the proxies, why are you letting them control
access to your network?

  RADIUS authentication routing is *not* IPv4 packet routing.  There are
commercial agreements in place for RADIUS traffic between any two
networks.  This isn't true for IPv4.

>  Since in
> since the peer & NAS do not yet share any keying material)

  The NAS can prove to the peer that it knows the encrypted key.  The
peer can then send the NAS the decryption key, or any other key
derivation function.

> you have

  Giving a key to the NAS is equivalent to giving it to the local AAA
server, because they are run by the same administrative entity.  So
*any* proposal that gives keying material to the NAS is vulnerable to
this attack.

  If the desire is to protect against third-party proxies, such as
roaming or interconnect providers, see my first set of comments.  In
addition, the local NAS (and AAA server) can choose to share that keying
material with anyone else in the world, including RADIUS proxies.  This
is true today.

  The MPPE keys used for 802.1x keying today are shared in the clear
with all RADIUS proxies.  Is there a *real-world* problem we're trying
to solve here, or a theoretical exercise that is made moot by real-world
business realities?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 3 Jan 2008 17:14:06 -0800

Um... if you don't trust the proxies, why are you letting them control
access to your network?
[gwz] 
The only purpose of which I'm aware for e2e encryption in RADIUS is the
hiding of the encrypted things from proxies.
[/gwz]

...

---

From: Stefan Winter <[email-masked]>
Date: Fri, 4 Jan 2008 08:15:53 +0100

Hi,

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

I can confirm taht eduroam is EAP with mutual authentication only, and spans 
some 35 countries right now; approx. 500 universities and other scientific 
institutions. I'm not aware of any larger deployment in the world.

BTW, we do see some shortcomings of EAPoL and 802.1X, most notably the lack of 
properly informing the user what went wrong if something went wrong. But 
that's another story and OT here I guess.

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

We seriously considered it, but since Diameter+NASREQ+EAP + decent backend 
connections didn't manifest implementation-wise, it was never taken further. 
RadSec solved most of the problems we had.

Greetings,

Stefan Winter

-- 
Stefan WINTER

Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de 
la Recherche
Ingenieur Forschung & Entwicklung

6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg
E-Mail: [email-masked]     Tel.:     +352 424409-1
http://www.restena.lu                Fax:      +352 422473

---

From: Stefan Winter <[email-masked]>
Date: Fri, 4 Jan 2008 08:22:17 +0100

> > 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%,
>
>   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.

This is why we dug out RadSec. The network backbone we are using typically 
performs a lot better than 1-5% losses, but still the number of packets 
involved in an EAP auth almost cries for a reliable transport.

IPSec was deployed (maybe still is, I can try to find out), but according to 
the admin there it was a real pain in the ... various parts of the body.

Greetings,

Stefan Winter

--

---

From: Stefan Winter <[email-masked]>
Date: Fri, 4 Jan 2008 08:29:01 +0100

Am Donnerstag, 27. Dezember 2007 19:35:02 schrieb Alan DeKok:
> David B. Nelson wrote:
> >>   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.
> >
> > 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.
>
> --

-- 
Stefan WINTER

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2008 09:01:05 +0100

> hiding of the encrypted things from proxies.

  I trust the people I work with enough to leave my car keys out in
public.  But I don't hand them the keys and say "go ahead, take it."

  For me, e2e encryption in RADIUS is about *increasing* the security,
not *perfecting* it.  The proxies have no business knowing the keys, so
e2e encryption helps increase security.

  If the proxies collude with the local network, then they can gain
information that negates e2e encryption... because they effectively
become one of the "ends" in "end-to-end".

  I see no problem here.  e2e encryption is useful, and there are
multiple methods where this can be done to *improve* security without
making it perfect.

  Alan DeKok.

---

From: <[email-masked]>
Date: Fri, 4 Jan 2008 00:19:11 -0800

> multiple methods where this can be done to *improve* security without

The question that is before the WG is "is support for e2e encryption a 
requirement for RADIUS crypto-agility?"

I think that this question is related to the automated key management 
question, because if we say that it is a requirement, then we have an
n x n problem that would seem to fall into the RFC 4107 requirements
for automated key management.

---

From: <[email-masked]>
Date: Fri, 4 Jan 2008 00:55:35 -0800

> Is there a *real-world* problem we're trying

I think there may be a problem here, but I'm not clear how that problem
is related to "RADIUS crypto-agility" or why it is in the interest of the
RADEXT WG to try to solve it at the present moment. 

For example, using crypto-agility, ciphersuites can be negotiated to 
provide improved integrity protection as well as confidentiality for
a portion or all of the RADIUS packet. 

This would seem to be an orthogonal question to the topology of
RADIUS clients, proxies and servers.  

Or am I missing something? 

Yes, automated key management, if implemented, might make it
possible for untrusted proxies to be bypassed (e.g. the local
proxy might be able to bypass a less trust worthy proxy and
talk to an entity closer to the home server,  assuming that the 
two entities share trust anchors).

And yes, it is possible that somewhere, somehow, someone
might want to implement Kerb/RADIUS or CMS (which were
discussed in AAA WG years ago but which languished for lack of interest). 

However, to me this doesn't seem like a requirement 
in the development of the two proposals that we've been
discussing.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Jan 2008 10:35:14 +0100

> requirement for RADIUS crypto-agility?"

  If the IESG mandates it, yes.  Otherwise, I don't see a need for it.

> for automated key management.

  Yes.

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 4 Jan 2008 08:10:52 -0800

If the proxies collude with the local network, then they can gain
information that negates e2e encryption... because they effectively
become one of the "ends" in "end-to-end".
[gwz] 
No collusion is required, just a hack combined with sniffing the wireless:
barely more effort than w/o this stuff...
[/gwz]

  I see no problem here.  e2e encryption is useful, and there are
multiple methods where this can be done to *improve* security without
making it perfect.
[gwz] 
If that is your goal, I'd suggest trying to find a method that doesn't
involve modifying every L2 in the world...
[/gwz]

  Alan DeKok.