Subject: [AAA-WG]: AAA WG Roadmap

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Feb 2003 15:01:15 -0800 (PST)

I've gotten a number of questions relating to the AAA WG roadmap over the
last few weeks, so that it's probably worthwhile to review where we are.

As many of you know, Diameter Base and Transport specifications have
passed IESG review and are now awaiting publication by the RFC Editor.

Diameter MIPv4 has completed IESG review, but is currently blocked pending
resolution of IESG comments on MIPv4/AAA keys. My expectation is that this
will get unblocked at some point in the next few months (don't have more
precise info to impart at the moment).

NASREQ has completed AAA WG last call, and is being revised for what we
hope is the one of the final times before sending that to the IESG. Expect
to see NASREQ-11 show up on the IETF archive within the next week.

Next on the agenda is Diameter EAP. Now that RFC 2869bis has gone to IETF
last call, we have a roadmap to completing this, which is as follows:

a. Make sure that RFC 2869bis is carefully reviewed before publication
as an RFC.

b. Incorporate the fixes from RFC 2869 into Diameter EAP.

c. Bring Diameter EAP to AAA WG last call.

As noted below, IETF last call has begun on RFC 2869bis and will complete
by 3-11-03. So a) is underway.

An important goal is to get an EAP-01 draft out, incorporating the items
in b) for discussion at IETF 56, so that we can move forward on c) by
June 2003, roughly synchronous with the EAP Keying Framework document.

By then, the goal is to have completed the lions share of the current WG
charter, so that additional WG work items can be considered, such as the
ones that 3GPP has been asking for.

So the overall message is that we have some very short term goals to keep
focussed on, namely finishing NASREQ and EAP. We are expecting substantial
progress on both those items in the next few weeks. And once those items
have progressed, we will be able to move on to the next phase.

================================================================================

Last Call: RADIUS Support For Extensible Authentication Protocol (EAP) to
Informational
--------------------------------------------------------------------------------

To: IETF-Announce: ;
Subject: Last Call: RADIUS Support For Extensible Authentication Protocol
(EAP) to Informational
From: The IESG <[email-masked]>
Date: Wed, 12 Feb 2003 13:39:41 -0500
Reply-to: [email-masked]
Sender: [email-masked]

--------------------------------------------------------------------------------

The IESG has received a request to consider RADIUS Support For
Extensible Authentication Protocol (EAP)
<draft-aboba-radius-rfc2869bis-09.txt> as an Informational RFC.  This
has been reviewed in the IETF but is not the product of an IETF
Working Group.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2003-3-11.

Files can be obtained via
http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt

---

From: Jari Arkko <[email-masked]>
Date: Thu, 13 Feb 2003 08:03:07 +0200

> c. Bring Diameter EAP to AAA WG last call.

Sounds good.

> June 2003, roughly synchronous with the EAP Keying Framework document.

That reminds me: does the final Diameter EAP contain the key transport
attributes? Or will they be done separately? Will CMS be required at some
point?

Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 12 Feb 2003 22:01:44 -0800 (PST)

> attributes? Or will they be done separately? Will CMS be required at some

That is a good question. My personal advice would be to handle the
definition of the Diameter Keying AVPs in a separate document, which would
be referenced non-normatively in Diameter EAP. My take is that we could
get Diameter EAP done by June 2003 if we did that, without a lot of risk.

Since there *are* some issues to work through in Diameter EAP outside of
keys (witness the discussion on RFC 2869bis), I believe this would allow
us to focus on the protocol aspects of Diameter EAP and bring it to
completion quickly. Then once RFC 2869bis, Diameter EAP and RFC 2284bis
are done, we can move our attention to the EAP Keying Framework and the
corresponding Diameter Keying AVPs (I believe they go together because the
first will justify the second).

At this point, after the analysis of the "rogue NAS" attack in RFC
2869bis, I believe we have a better handle on the binding problem that
Jesse Walker was talking about. The problem is most apparent
when fast handoff is involved and a rogue NAS can cause MSKs to be
generated and sent anywhere at will. However, this will only result in
leaking of information on the MK if the MSK derivation mechanism is weak
in some way.

While we have some functionality in Diameter that isn't present in RADIUS
that is relevant to the problem (Route-Record AVP), if there is an
untrusted proxy in the system, then keys can be compromised. Fixing this
requires both CMS as well as the right Grouped Key AVP, binding the MSK to
parameters relating to its use. The construction also needs to be live so
as to protect against cut and paste attack.

However, I don't believe that this issue exists for direct NAS-AAA server
scenarios, and so one could argue that IPsec or TLS key wrap w/mutual
authentication is sufficient. If there is a counter-example, I would like
to see it -- but I haven't been able to come up with one, after a year of
trying.