Subject: [eap] Issues and Questions draft-haverinen-pppext-eap-sim-05

From: [email-masked] (Chaudhary, Mayank)
Date: Thu, 10 Oct 2002 14:47:48 -0700

Hi All,
 I think it is in the  best interest of all operators and WISPs involved to have the domain registered with a third-party "neutral" vendor. Could IESG or 3GPP take ownership of this domain ? We dont want to be in a position where RADIUS messages being routed thru the 
top-level RADIUS domain server are under the control of a single entity.

thanks
-mayank

> -----Original Message-----
> From:	Thomas Wieland [SMTP:[email-masked]]
> Sent:	Thursday, October 10, 2002 1:44 PM
> To:	Garces, Rodrigo
> Cc:	Joseph Salowey; [email-masked]; [email-masked]
> Subject:	RE: [eap] Issues and Questions   draft-haverinen-pppext-eap-sim-05
> 
> 
> Rodrigo,
> 
>   see Chapter 16.  IANA Considerations 
> 
>    The realm name "owlan.org" has been reserved for NAI realm names 
>    generated from the IMSI. 
> 
> 
> Also see:
> 
> # whois owlan.org
> 
> Whois Server Version 1.3
> 
>    Domain Name: OWLAN.ORG
>    Registrar: MELBOURNE IT, LTD. D/B/A INTERNET NAMES WORLDWIDE
>    Whois Server: whois.melbourneit.com
>    Referral URL: http://www.melbourneit.com
>    Name Server: NS.NOKIA.COM
>    Name Server: NS2.NOKIA.COM
>    Name Server: NSHK.EXT.NOKIA.COM
>    Name Server: NSDA.EXT.NOKIA.COM
>    Updated Date: 01-mar-2002
> 
> >>> Last update of whois database: Thu, 10 Oct 2002 04:53:24 EDT <<<
> 
> 
> So the short answer is: Nokia
> 
> Regards,
> 
>   Thomas Wieland
>   Cisco Systems, Inc.
> 
> 
> At 12:49 10-10-02 -0700, Garces, Rodrigo wrote:
> >Getting back to point 7, in section 5 of the draft  v6, it is stated 
> >
> >
> >   If no configured realm name is available, the client MAY derive the 
> >   realm name from the MCC and MNC portions of the IMSI. In this case, 
> >   the realm name is obtained by concatenating "mnc", the MNC digits of 
> >   IMSI, ".mcc", the MCC digits of IMSI and ".owlan.org". For example, 
> >   if the IMSI is 123456789098765, and the MNC is three digits long, 
> >   then the derived realm name is "mnc456.mcc123.owlan.org". 
> >
> >   If the client is not able to determine whether the MNC is two or 
> >   three digits long, the client MAY use a 3-digit MNC. If the correct 
> >   length of the MNC is two, then the MNC used in the realm name will 
> >   include the first digit of MSIN. Hence, when configuring AAA 
> >   networks for operators that have 2-digit MNC's, the network SHOULD 
> >   also be prepared for realm names with incorrect 3-digit MNC's. 
> >
> >What we are concern is who will be maintaining the DNS entry for owlan.org? 
> >Who is in charge of doing so?  
> >
> >-----Original Message-----
> >From: Joseph Salowey [mailto:[email-masked]]
> >Sent: Thursday, October 10, 2002 11:45 AM
> >To: Garces, Rodrigo
> >Cc: [email-masked]; [email-masked]
> >Subject: Re: [eap] Issues and Questions
> >draft-haverinen-pppext-eap-sim-05
> >
> >
> >At 11:23 AM 10/10/2002 -0700, Garces, Rodrigo wrote:
> >
> >>Here are some issues and concerns with EAP-SIM
> >>
> >>
> >>1) It seems to me that the number of messages could probably be reduce and 
> >>still achieve the goal of providing SIM based authentication using EAP. At 
> >>the same time EAP-SIM should not required any changes or minimum changes 
> >>to the operators for it to be accepted as a standard.
> >
> >What do you have in mind?
> >
> >>2) Why should there be any restrictions or additions to the pseudonym 
> >>grammar beyond what is there today in 3GPP?
> >
> >I don't think there are any restrictions on the Pseudonym grammar.  I don't 
> >think the 3GPP restrictions necessarily apply.
> >
> >>3) Is there some protocol that depends upon the Authenticator knowing the 
> >>pseudonym?
> >
> >How the authentication server manages the pseudonym is not defined in this 
> >document.  Is this what you mean?
> >
> >>4) If the pseudonym is lost in the authentication server, the supplicant 
> >>can be locked out of the network for ever as it does not have to respond 
> >>to the identity request.  This sounds bad.> 
> >
> >THis depends upon the implementation. It is possible for the implementation 
> >to allow manual intervention so the client knows they are sending their 
> >clear IMSI and can choose to accept that risk.  Other implementations on 
> >the client are possible.
> >
> >>5) The maximum lengths of the fields in the 'message format' section is 
> >>1020  bytes, not 1024.
> >>
> >>6) Is the concatenated "1" in front of the IMSI really useful?  Will it 
> >>save any protocol bytes or messages?
> >>If not, let's drop it. I still do not see the usefulness of having the 
> >>concatenated "1".
> >
> >Good question.
> >
> >>7) The EAP-SIM seems to imply that there is a need for owlan,org. Who will 
> >>be running the .owlan.org service?
> >
> >What do you mean by owlan.org service?
> >
> >>8) Why is the message subtype included in the MAC_SRES hash?  Does this 
> >>provide any further security?
> >
> >See changes in draft 6 which is now available
> >
> >
> >>regards,
> >>
> >>Rodrigo Garces
> >>Mobility Networks
> >>_______________________________________________
> >>eap mailing list
> >>[email-masked]
> >>http://mail.frascone.com/mailman/listinfo/eap
> >
> >_______________________________________________
> >eap mailing list
> >[email-masked]
> >http://mail.frascone.com/mailman/listinfo/eap 
> 
> _______________________________________________
> eap mailing list
> [email-masked]
> http://mail.frascone.com/mailman/listinfo/eap