Subject: [eap] Updated version of EAP-based network discovery draft

From: "Adrangi, Farid" <[email-masked]>
Date: Thu, 10 Jun 2004 13:39:16 -0700

Hi Bernard & Jari

Thanks again for your review and comments.  I have made an intermediary
update of the draft based on your comments / feedback - the draft can be
found in
http://mng.ctgisp.com/IETF/EAP/Network%20Selection/draft-adrangi-eap-net
work-discovery-011.txt.

On issues (pointed out by Bernard) with the "security considerations"
section, I made some clarification changes:

- Made some clarifications on the information type and what is meant by
a "hint"
- Removed the SSID analogy 
- The "implementation considerations" section contains a text describing
on what conditions an implementation should specify a mediating network
for the AAA routing

As to attack scenarios, we can look at it from both network
advertisement and selection perspectives.

- On network advertisement, I can think of two scenarios

1) client associates with a bogus SSID, starts EAP, and receives some
bogus network information.  In this case, associating with the bogus
SSID is the problem - what ever happens after that obviously is going to
be questionable. 

2) Associating with a valid/legitimate SSID.  In this case, the access
network may advertise only a subset of the mediating networks that it
has roaming agreement with - based on its own preference.  I don't think
this is a security issue - is it?

- On network selection, the access network may route the AAA packets
differently from what specified by the user through the decorated NAI
(described in 2486bis).   In this case, the home network may be able to
detect the problem depending the EAP method.  This was mentioned in the
second paragraph in the "security considerations" section. 

Having said that, we can discuss further if we need more text under
"security considerations".

Please let me know if you have any questions.  Thanks again.

BR,
Farid

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Ruffino Simone <[email-masked]>
Date: Tue, 15 Jun 2004 14:46:38 +0200

Hi Farid,

I've read through the last version of the draft and it seems to me very clear, in the overall. I've some comments regarding the "Implementation considerations" section (Sec. 4), though I realize this is not intended to be a "recommendations" section...

1) (editorial) It states:
"However, delivery mechanism options 1 and 2 are recommended as they are backward-compatible with the currently-deployed APs."

Do you mean here method 2 and 3 ? Method 1 is actually not backward compatible.

2) In "- When Option 3 is used " bullet:

2a) "if the RADIUS proxy/server still cannot route the RADIUS packet the next AAA hop based on the realm portion of the NAI, "

Maybe I'm confusing here, but in step 6. it states that the wireless client either chooses one of the MNs, or it does not connect to the access network. So, why the RADIUS proxy/server could not route the RADIUS packet ? 

2b) "then it MAY route the packet based on its local routing policy, or it MAY discard the packet."

If the mediating network chosen by the user is not available, then the authentication request SHOULD (and maybe MUST) not be forwarded. This because wireless clients, choosing a preferred network, implicitly indicate that they don't want any other network to route their request. If the authentication completed, the wireless client would not be able to know that the chosen network is not available.
So I propose to change the statement in the following way : ", then it SHOULD discard the packet."

Best regards,
Simone

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Adrangi, Farid
> Sent: giovedì 10 giugno 2004 22.39
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: [eap] Updated version of EAP-based network discovery draft
> 
> 
> Hi Bernard & Jari
> 

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
[email-masked]. Thank you
====================================================================
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: "Adrangi, Farid" <[email-masked]>
Date: Tue, 15 Jun 2004 06:50:12 -0700

Hello Ruffino,
Thanks for your comments. Please see my responses below.
BR,
Farid

> I've read through the last version of the draft and it seems 
> to me very clear, in the overall. I've some comments 
> regarding the "Implementation considerations" section (Sec. 
> 4), though I realize this is not intended to be a 
> "recommendations" section...
> 
> "However, delivery mechanism options 1 and 2 are recommended 
> as they are backward-compatible with the currently-deployed APs."
> 
Yes, you are right.  I reversed the order of the options in the this update and forgot to update the numbers here!

> 2a) "if the RADIUS proxy/server still cannot route the RADIUS 
> packet the next AAA hop based on the realm portion of the NAI, "
> 
> Maybe I'm confusing here, but in step 6. it states that the 
> wireless client either chooses one of the MNs, or it does not 
> connect to the access network. So, why the RADIUS 
> proxy/server could not route the RADIUS packet ? 
> 

Because the user may still send an undecorated NAI to AAA proxy.

> If the mediating network chosen by the user is not available, 
> then the authentication request SHOULD (and maybe MUST) not 
> be forwarded. This because wireless clients, choosing a 
> preferred network, implicitly indicate that they don't want 
> any other network to route their request. If the 
> authentication completed, the wireless client would not be 
> able to know that the chosen network is not available.

I see your point and reasoning here -- you are right.  Actually, here "MUST" seems to be more appropriate than "SHOULD" - no?
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of
> > Adrangi, Farid
>