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

From: "McCann, Stephen" <[email-masked]>
Date: Wed, 7 Nov 2001 15:52:03 -0000

Hello to you all,
	OK, here comes a novice question from someone who is not familar
with all the current AAA-WG I-Ds. So I do apologise about all this.

I'm currently the editor for the ETSI Hiperlan/2 - 3G interworking 
specification that we're writing here in Europe and I think we need
either a new Diameter message type and corresponding AVPs or an
answer to whether we can re-use something in :-

draft-ietf-aaa-diameter-nasreq-07.txt.

I'm going to try and dive in to specifics here and if I then need
to explain a bit more detail, I'm prepared to discuss it off-list,
so I don't bore you all with weird Hiperlan/2 authentication schemes.

We've created EAP over Hiperlan/2 (EAPOH), which parallels 802.1X
to allow remote authentication of the user to an intergrated WLAN-
Cellular network (e.g. 3G network)

We run the authentication using Diameter between the Wireless Access
Point and the core network, but we feel that we're missing a certain
type of authentication exchange which is specific to Hiperlan/2 and
we're pretty sure this has not been considered before in the AAA-WG.

What we need for EAPOH is the following.

1. A command code to identify a new Hiperlan2-Net-Auth-Request/Answer 
   messages.

2. AVPs to carry the following additional information 
   (the first two are required for Hiperlan2-Net-Auth-Request; the 
    last two for Hiperlan2-Net-Auth-Answer):-

   i) A random "seed" (or "nonce") [H2-Net-Auth-Rand-AP]
   ii) A challenge (to the network) [H2-Net-Auth-Challenge]
   iii) A response (from the network) [H2-Net-Auth-Respone]
   iiii) A validation key [H2-Net-Auth-Validation-Key]

   (I use iiii so as not to upset the vi god - Intercal ;-) )

I guess the question is whether these already fit into the NASREQ 
(or other) application and whether we need extensions to provide 
additional AVP types and/or command codes or whether it's appropriate 
to reuse any existing AVP types and command codes.

It should be noted that we're not using a "standard" authentication 
algorithm here (I can assure you that the Hiperlan/2 scheme is weird)
, so use of some existing AVPs (e.g. "CHAP-Challenge") does not seem 
appropriate.  But there may be other AVPs that are.

If not, should I consider going down the road of a new AAA I-D for
this specialisation.

Any response to all this would be most appreciated.

Kind regards

Stephen McCann
Siemens Roke Manor Research Ltd
Southampton
UK

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 7 Nov 2001 07:58:32 -0800 (PST)

> 1. A command code to identify a new Hiperlan2-Net-Auth-Request/Answer 

Why is a new command code necessary? If you're encapsulating EAP, all you
should need are the existing command codes for NASREQ. 

>    iiii) A validation key [H2-Net-Auth-Validation-Key]

Can you describe why these AVPs are required or site a document? If you
are using EAP, can't you do any required authentication within your
selected EAP method? Why is it necessary to have separate
challenge/response AVPs? 

> to reuse any existing AVP types and command codes.

The NASREQ document should be sufficient for any EAP-based
authentication application. If it is not, then it needs to be fixed so
that it is. If we need to create a new command code for each NASREQ usage
should not be required. 

> appropriate.  But there may be other AVPs that are.

Earlier in the message you said you were using EAP, which is indeed
handled in a standard manner. Are you doing something else as well?