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

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 12:08:03 -0700 (PDT)

Thanks for responding. It appears that there is interest in proceeding
with Diameter EAP, but potentially not sufficient interest to continue
work on Diameter CMS.  To qualify for continued work, it would be good if
we had at least two potential people interested implementing CMS.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 May 2003 23:28:47 +0300

> we had at least two potential people interested implementing CMS.

The answers to the CMS query might be more interesting if some
of the potential relationships between the documents would be
highlighted ;-) Do you think key transport over DIAMETER EAP will
require CMS?

And if someone answered YES for DIAMETER EAP, is
that someone going to use his implementation in setting up
e.g. link encryption keys for WLAN?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 13:40:52 -0700 (PDT)

> Do you think key transport over DIAMETER EAP will require CMS?

The relevant requirements are here:
http://www.drizzle.com/~aboba/IETF56/AAA/AAA-Key-Mgmt.ppt

Do you think that CMS is needed to meet them?

---

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

> Do you think that CMS is needed to meet them?

Well, it says "select one end-to-end mechanism to protect
the distributed keys" and "maintain confidentiality of
session keys". Does this mean something CMS-like, or
is hbh security also sufficient?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 13:54:01 -0700 (PDT)

> is hbh security also sufficient?

I'll answer your question with another question:

What if only Diameter redirects were present? Then the connections would
always be end-to-end and the distinction would vanish, no?

---

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

> always be end-to-end and the distinction would vanish, no?

I agree that this would be sufficient.

So this would leave us only with the question of
whether someone wants to use the non-redirect
model and transport session keys, and if so,
whether something else is needed to protect
that. Or are we recommending that to transport
session keys, you should use redirects?

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 14:35:45 -0700 (PDT)

> that.

Yes. I would like to understand the deployment scenarios for Diameter EAP,
and whether keys really need to pass through intermediaries, before
doing work to protect keys from intermediaries.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 May 2003 08:18:38 +0300

> doing work to protect keys from intermediaries.

Presumably, Diameter EAP would have to interwork with RADIUS EAP.
This creates a number of interesting questions:

- If the session uses RFC 2548 attributes for carrying EAP keys
   (as I think is commonly done today), can DIAMETER EAP interwork
   with that? Deployment wise, this seems like a requirement.
   Presumably, procedures outlined for standard RADIUS attributes
   in draft-ietf-aaa-diameter-nasreq can be employed even for
   these attributes.

- Also, while we could forbid intermediaries for DIAMETER, it
   seems that for interoperation with DIAMETER, at least one
   intermediate node may be required.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 May 2003 23:26:30 -0700 (PDT)

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

>    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 :(

>    Deployment wise, this seems like a requirement.

Yes.

>    in draft-ietf-aaa-diameter-nasreq can be employed even for

Unfortunately, I don't think so.

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

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.