Subject: RE: [AAA-WG]: Novice question about new Diameter command code id.

From: "McCann, Stephen" <[email-masked]>
Date: Wed, 7 Nov 2001 16:54:19 -0000

Bernard, Kevin,
	Thanks for your quick response to my mail.

Alas, we are indeed doing '...something else as well...' 
and are not using just 'vanilla' EAP in this scheme.

Hiperlan/2 attempts to perform authentication and validate 
the encryption simulataneously and so we cannot use EAP to 
do this over the air interface, essentially due to an imbalance
of the key exchange that allows the mobile identity to be 
transmitted to the core network in plain text !!

We've had to introduce an extra pre-authentication stage 
before the EAP message exchange commences, and it is for 
this stage that we need these new messages to be transported 
by Diameter between the AP and the Core entwork.

As far as we understand this is not a standard mechanism, 
nor is it covered by EAP.

I can refer you to some Hiperlan/2 draft specification
documents but I'm not sure if you really want to wade through
them at this point.

As far as I recall there is not the same issue for 802.11
authentication.

Kind regards

Stephen McCann
Siemens Roke Manor Research Ltd

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 8 Nov 2001 06:25:38 -0800

> and are not using just 'vanilla' EAP in this scheme.

I need to make sure that I understand this. EAP is simply a way to signal
and encapsulate your own authentication scheme within a single framework.
Diameter, on the other hand, specifies how it carries the EAP payload from
the access device to the AAAH. 

So when you are stating that you aren't just using 'vanilla' EAP, does this
mean that you need to change EAP, or create a new authentication scheme which
is specific to Hiperlan/2?

> transmitted to the core network in plain text !!

Let me ask some clarifying questions. The sentence above seems to imply
that the authentication scheme is encrypted from the beginning, so the
mobile's identity is never sent in the clear. Is this correct? If so,
how does the peer "decrypt" the mobile's identity? Does this require a
symmetric key? Is it based on a MAC address? Does your scheme force you
to perform decryption at the access device? If so, then Hiperlan/2 doesn't
appear to provide roaming capabilities, since you would have to send
sensitive information to roaming partner's access devices.

> by Diameter between the AP and the Core entwork.

ok, so if this is the case, then perhaps the use of EAP is the
wrong approach. It looks to me like what you need here is really a
way to encapsulate your new authentication scheme within Diameter.
For this, I would propose the use of new Diameter messages since it
breaks current Diameter/EAP behavior.

> nor is it covered by EAP.

As far as I can tell, you are correct. However, without a better 
understanding of the actual process, I can't really provide a 
complete response.

> documents but I'm not sure if you really want to wade through

ahh... you've read my mind :) Perhaps pointing me to specific sections
that describe the actual process (hell, I'd even encourage receiving
via e-mail only the portions I'd care about :)

> As far as I recall there is not the same issue for 802.11

I believe you are correct.

(side note: I'll be out of town for the next couple of days, so my access
will most likely be sporatic - at best)

PatC