Subject: RE: [AAA-WG]: Re: Call for Interest

From: <[email-masked]>
Date: Fri, 16 May 2003 11:45:06 +0300

Hi Bernard & Jari,

> > Presumably, Diameter EAP would have to interwork with RADIUS EAP.
> > This creates a number of interesting questions:
> 
> Most likely, we're talking about a RADIUS NAS (e.g. 802.11 
> AP) talking to a Diameter server, through a Diameter/RADIUS gateway.

That sounds reasonable.
> 
> > - If the session uses RFC 2548 attributes for carrying EAP keys
> >    (as I think is commonly done today), can DIAMETER EAP interwork
> >    with that?
> 
> The Diameter/RADIUS gateway specification in NASREQ now
> supports the ability to translate RADIUS VSAs to Diameter VSAs. However, I
> don't think it has the ability to translate from standard Diameter
> attributes to RADIUS VSAs and back.  We should file an Issue 
> on that :(

Would this be filed for NASREQ or EAP?  
 
> >    Deployment wise, this seems like a requirement.
> 
> Yes.
> 
> >    Presumably, procedures outlined for standard RADIUS attributes
> >    in draft-ietf-aaa-diameter-nasreq can be employed even for
> >    these attributes.
> 
> Unfortunately, I don't think so.

This sounds like an issue to be handled in EAP, then.
 
> > - Also, while we could forbid intermediaries for DIAMETER, it
> >    seems that for interoperation with DIAMETER, at least one
> >    intermediate node may be required.
> 
> In the case where  there is a Diameter server talking to a Diameter/RADIUS
> gateway, the issue is really untrusted Diameter proxies, not the
> Diameter/RADIUS gateway, which is likely to be run by the same
> administration as the NASes.

I think that we need to figure out how to forbit 'untrusted' proxies,
then.
 
> If the keys are always securely transmitted  between the Diameter Server
> and the gateway no matter how many hops there are, it's a big win.

Agreed.

John

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 16 May 2003 04:53:36 -0700 (PDT)

> Would this be filed for NASREQ or EAP?

Probably for both.

Yes.

> I think that we need to figure out how to forbid 'untrusted' proxies,
> then.

We can say that 'untrusted' agents MUST function as redirects so that they
don't obtain posession of the keys.  During Diameter session setup, if
an agent that is expected to act as a redirect does not do so, then the
session MUST be torn down.  That way, only 'trusted' agents can obtain
keys.

> > and the gateway no matter how many hops there are, it's a big win.

In practice, this seems achievable, at least for Diameter EAP.