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

From: "McCann, Stephen" <[email-masked]>
Date: Thu, 8 Nov 2001 15:53:55 -0000

Pat,
	Thank you for your mail. I think we're making great progress
with this issue.

> > Alas, we are indeed doing '...something else as well...' 
> > 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?

We have indeed created a new authentication scheme specific to HIPERLAN/2.
We feel EAP does not meet out requirements since EAP is an end-to-end scheme,
 but our authentication algorithm requires inputs from the intermediate nodes.

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

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

The intention is that the mobile's identity is *not* sent in the clear.
(Notwithstanding that the current versions of the HIPERLAN/2 specifications 
attempt to encrypt the mobile's identity but do so *before* the encryption 
has been validated !!)

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

HIPERLAN/2 encrypts at the radio link level; this has to be decrypted 
at the access device.  Thus the EAP packets are available at the access 
device in the clear, although we're not sure about the state of the key encryption
at this point.

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

This is an issue which has never been raised with us before !  I think that's
a question I'll have to send to the Hiperlan/2 gurus.

I'd actually like to know if EAP itself has a means for encrypting mobile identities?

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

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

Great. This is the initial feeling that we had and that is why we're 
asking so many questions.

To some extent we'd like to re-use EAP as
much as possible and we think we can; we just need this extra
pre-authentication message exchange which essentially validates the
network to the Hiperlan/2 access points and vica - versa.

> > As far as we understand this is not a standard mechanism, 
> > 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.

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

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

I'm seperating out some bits you at this moment, which I'll forward just
to your email address if that's ok.

[I will of course send them to anyone else on this list, if anyone wishes]

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

> I believe you are correct.

> PatC

Once again thanks for your help and time.

Kind regards

Stephen McCann
Siemens Roke Manor Research Ltd
Southampton
UK