Subject: Re: [AAA-WG]: Diameter EAP: Are Redirects sufficient?

From: William Bulley <[email-masked]>
Date: Thu, 15 May 2003 19:38:01 -0400

According to Bernard Aboba <[email-masked]>:
> As a hypothetical, what if Diameter EAP were to strongly discourage use of
> proxies, and encourage use of redirects instead.  Would any important
> usage scenarios be compromised by such an approach?  The advantage of only
> using redirects if that the Diameter connections would be end-to-end and
> therefore keys would not be available to intermediaries.  This would
> simplify the security analysis enormously and would allow us to avoid a
> dependency on CMS, which seems to lack much interest in the WG.

I may be out of line here, but I believe that discouraging the use
of proxies for Diameter EAP would greatly limit the flexibility in
which Diameter might be deployed.  Admitedly I am thinking with my
RADIUS hat on here, but in trying to generalize to Diameter and in
a wireless scenario here in Michigan, I wouldn't want to restrict
or discourage the use of proxies in Diameter EAP.  My $0.02 worth.

Regards,

web...

-- 
William Bulley                     Email: [email-masked]
Merit Network Inc.                 Ann Arbor, Michigan

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 16:34:18 -0700 (PDT)

> which Diameter might be deployed.

Can you demonstrate a real-life situation in which this would be true?

> Admitedly I am thinking with my RADIUS hat on here

Diameter isn't RADIUS. One of the reasons that Diameter development was
approved to begin with was to be able to handle these scenarios more
securely than RADIUS.  If it turns out that Diameter in fact offers no
advantages beyond RADIUS in terms of security, then in the immortal words
of Ronald Reagan -- "we've been flimflammed".

> but in trying to generalize to Diameter and in a wireless scenario here
> in Michigan, I wouldn't want to restrict or discourage the use of
> proxies in Diameter EAP.  My $0.02 worth.

Are you deploying Diameter in a wireless network now in Michigan? If so,
can you share with us the deployment scenario that requires a Diameter
proxy?  Please don't respond with hypotheticals here -- I'm looking for
real deployment plans.

To everyone else who is planning deployments of Diameter EAP -- can you
live with only Diameter redirects?  If not, are you willing to move deploy
Diameter CMS?

---

From: Pat Calhoun <[email-masked]>
Date: 16 May 2003 05:25:34 -0700

> Can you demonstrate a real-life situation in which this would be true?
http://www.cometanetworks.com/services.html

So if 802.11 goes the way dial-up has, enterprise customers will want
their users to authenticate against their own authentication
infrastructure.

> proxy?  Please don't respond with hypotheticals here -- I'm looking for
I can't state that Cometa will make use of Diameter, in fact their most
likely looking at RADIUS since that's all there is out there. However,
if security is an issue for them, or their customers, then we need to
have something to offer.

PatC

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 May 2003 06:29:32 -0700 (PDT)

> http://www.cometanetworks.com/services.html

My understanding is that Cometa is in the business of being an access
wholesaler, no? Wouldn't that scenario be covered by the picture that John
provided?

> their users to authenticate against their own authentication

That doesn't imply use of untrusted proxies.  A Diameter/RADIUS gateway
at the wholesaler could forward between 802.11 APs running RADIUS and
enterprise AAA servers running Diameter.

> if security is an issue for them, or their customers, then we need to

There are quite a few useful features in Diameter Base that could be used
to provide improved security beyond what is in RADIUS.  This includes
things like Redirect support, support for certificate-based
authentication, etc.  So the question in my mind is why those features
cannot be used to solve the problem -- rather than relying on a technology
(CMS) which the WG seems to have little interest in developing.

Either:

1) the security features of Diameter Base don't improve security
sufficiently in key scenarios beyond  what is in RADIUS, so that CMS is
needed.  In this case if we don't do CMS, Diameter will not be
more secure than RADIUS in key uses.

OR:

2) Diameter Base provides the security features needed to support
major deployment scenarios more securely than RADIUS can, so that CMS
is not needed in addition, except perhaps in some specialized situations.

I'm asking the WG to try #2 on for size, and see if the major deployment
scenarios of Diameter EAP can be handled securely based on the
functionality in the Diameter Base protocol alone, with no dependencies on
CMS.

It is quite possible that for #2 to be true that some changes are needed
in thinking -- Diameter is not RADIUS, after all.  But it seems to me that
we're much more likely to succeed if #2 is true than if #1 is closer to
reality.

---

From: Pat Calhoun <[email-masked]>
Date: 16 May 2003 07:13:52 -0700

> (CMS) which the WG seems to have little interest in developing.
That wasn't the point I was making. You asked for real-life inter-domain
802.1x deployments. I provided you one. Whether they need proxies, or
not, or even whether they deploy Diameter or not, I can't answer.

> functionality in the Diameter Base protocol alone, with no dependencies on
Maybe #2 is sufficient. My understanding was the IESG would not let
Diameter out w/o CMS... of course, this is a while ago.

PatC

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 May 2003 17:44:00 +0300

> (CMS) which the WG seems to have little interest in developing.

Cool. Lets work this out...

 > enterprise AAA servers running Diameter.

It would be useful to try to understand how the CAs are setup in this
usage. So in your example, the wholesaler would maintain a CA that would
sign certs for all of its gateways as well as the enterprise AAA
servers (or for the CAs of the enteprises which in turn would sign certs
for their servers).

So, upon trying to perform EAP over the AAA infrastructure, the
gateway would get a Redirect from a proxy, and the session would
be directed to the particular enterprise AAA server. A Diameter
connection would be setup, protected by TLS using the CA mentioned
earlier as the trust root.

Looks simple enough, though I worry a bit that we have forgotten
something that causes problems in this scenario. But one good
thing is that multi-roundtrip EAP methods don't have to pass
through a large number of proxies.

One issue is that if even the APs are starting to implement DIAMETER,
the CA has to sign a lot of nodes. What is, by the way, the status
of public domain software for manufacturing certs? Is everyone who
has an SSL server implementation running on their unix box capable
of generating certs?

Also, I guess Redirect-Host-Usage = REALM_AND_APPLICATION so that only
EAP stuff gets redirected, and accounting not?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 May 2003 07:40:11 -0700 (PDT)

> earlier as the trust root.

Exactly.

> through a large number of proxies.

Yes. This should result in considerably better performance. Also, use of
TLS is considerably simpler than IKE would be in that scenario, since
the certification authorities for network access are
likely to be very different than that of other applications (such as Web
service).  In TLS it's possible to define a different set of trust anchors
for each application.

> has an SSL server implementation running on their unix box capable

I'm not very knowledgeable about this but perhaps someone else can
respond.

> EAP stuff gets redirected, and accounting not?

Yes. Accounting data still needs to go the intermediaries.

---

From: Barney Wolff <[email-masked]>
Date: Fri, 16 May 2003 12:38:51 -0400

> I'm not very knowledgeable about this but perhaps someone else can

Openssl can do this and is widely available.  mod_ssl for Apache uses
it to generate and sign a cert on installation.

That's of course quite different from setting up a fully-secured CA.

-- 
Barney Wolff         http://www.databus.com/bwresume.pdf
I'm available by contract or FT, in the NYC metro area or via the 'Net.

---

From: "Glen Zorn" <[email-masked]>
Date: Wed, 21 May 2003 21:37:35 -0700

Jari Arkko <mailto:[email-masked]> writes:

> Bernard Aboba wrote:
> 
>> There are quite a few useful features in Diameter Base that could be
>> used to provide improved security beyond what is in RADIUS.  This
>> includes things like Redirect support, support for certificate-based
>> authentication, etc.  So the question in my mind is why those
>> features cannot be used to solve the problem -- rather than relying
>> on a technology (CMS) which the WG seems to have little interest in
>> developing. 
> 
>  >>So if 802.11 goes the way dial-up has, enterprise customers will
> want  >>their users to authenticate against their own authentication 
> >>infrastructure.  >  >  > That doesn't imply use of untrusted
> proxies.  A Diameter/RADIUS gateway  > at the wholesaler could
> forward between 802.11 APs running RADIUS and  > enterprise AAA
> servers running Diameter.     
> 
> usage. So in your example, the wholesaler would maintain a CA that
> would sign certs for all of its gateways as well as the enterprise
> AAA servers (or for the CAs of the enteprises which in turn would
> sign certs for their servers).    
> 
> gateway would get a Redirect from a proxy, and the session would be
> directed to the particular enterprise AAA server. 

I'm confused.  Where is this proxy?  Who owns it?  Why is it even
necessary?  Given the certification scheme you describe above, why are
redirects even necessary?

> A Diameter
> something that causes problems in this scenario. 

In this limited scenario, since the wholesaler and enterprise appear to
have a direct trust relationship I don't see any problem at all.  OTOH,
what about the case where the enterprise has 50 wholesalers?  

> But one good thing
> is that multi-roundtrip EAP methods don't have to pass through a
> large number of proxies.   
> 
> the CA has to sign a lot of nodes. What is, by the way, the status of
> public domain software for manufacturing certs? Is everyone who has
> an SSL server implementation running on their unix box capable of
> generating certs?    
> 
> Also, I guess Redirect-Host-Usage = REALM_AND_APPLICATION so that
> only EAP stuff gets redirected, and accounting not? 
> 
> --Jari

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 

-- Benjamin Franklin, 1759

I've stopped 25,199 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 May 2003 13:30:29 +0300

> redirects even necessary?

Lets draw a picture and use different terms. Here are the domains
involved:

<access provider>----<consortium>-----<service provider>----<company>

At least the consortium and service provider have proxies, optionally
both the access provider and company have ones as well. (Access provider
is likely to have a proxy if it has more than one NAS/AP.)

The cert relationships required for redirect are as follows:
- access provider trusts all consortium CAs it is a part of
- same for company
- consortium needs to sign certs for the CAs of the access provider,
   service provider, and company.

The intention with the redirect idea is that the EAP messaging would
go directly from the first DIAMETER-capable node in the access provider
(perhaps even the AP) to the last DIAMETER-capable node (perhaps the
company AAA server). But the rest of the messaging related to authz
would still pass through all proxies.

> what about the case where the enterprise has 50 wholesalers?  

If an enterprise has multiple service providers, then the keys
of its NASes must have multiple certs, one from each service
provider. I'm not an expert enough in TLS to know if this
will cause a problem.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 May 2003 05:55:22 -0700 (PDT)

> would still pass through all proxies.

I'm not sure it is a requirement the EAP packets go directly, since
they're presumably protected by the EAP method. Of course, if they do go
directly, the latency will be improved considerably and that might be
an important benefit in EAP exchanges that can take as much as 20
roundtrips. The thing that needs to go directly (in the absence of CMS)
are the keys.

> provider. I'm not an expert enough in TLS to know if this

Not sure I parse this.  The NAS only needs to be configured with trust
anchors sufficient for the Diameter peers that it talks to.  The TLS
server (the AAA server) can communicate which trust anchors it supports
via the cert request payload.  Presumably the NAS can find a certificate
that matches.

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 22 May 2003 19:41:04 -0700

...

>> necessary?  Given the certification scheme you describe above, why
>> are redirects even necessary?
> 

Which of these is The Entity Fomerly Known As Wholesaler?

> both the access provider and company have ones as well. 

But Bernard's original note said "As a hypothetical, what if Diameter
EAP were to strongly discourage use of proxies, and encourage use of
redirects instead."  You seem to be saying that proxies are virtually
everywhere...

> (Access provider is likely to have a proxy if it has more than one
NAS/AP.)  
> go directly from the first DIAMETER-capable node in the access
> provider (perhaps even the AP) to the last DIAMETER-capable node
> (perhaps the company AAA server). But the rest of the messaging
> related to authz would still pass through all proxies.   

OK, so it sounds like a) redirects are superfluous after the first (for
any given node pair) since an NAI -> server mapping can be stored on the
NAS/gateway/whatever and b) any and all authorization/accounting data is
deemed insufficiently valuable to warrant protection from malicious
proxies; a) sounds great, b) sounds very dangerous.

> 
>> In this limited scenario, since the wholesaler and enterprise appear
>> to have a direct trust relationship I don't see any problem at all.
>> OTOH, what about the case where the enterprise has 50 wholesalers?
> 
> If an enterprise has multiple service providers, then the keys of its
> NASes must have multiple certs, one from each service provider. 

Sorry, can't parse this statement.

> I'm not an expert enough in TLS to know if this will cause a problem.

~gwz

I've stopped 25,248 spam messages. You can too!
Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/