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

From: [email-masked] ([email-masked])
Date: Fri, 11 Oct 2002 13:14:12 +0300

Hello,

Nokia has reserved the owlan.org realm name, just to have=20
a name available for the specification. We don't have any=20
plans to run DNS servers for the realm or (do anything else with
the realm), so for now the realm name can only be used for=20
configured RADIUS routing that is not based on DNS.

However, as it may be very useful to DNS for AAA routing,
we're hoping to find a relevant organization to take up
the owlan.org realm name.=20

Regards,
Henry

> -----Original Message-----
> From: ext Thomas Wieland [mailto:[email-masked]]
> Sent: 10 October, 2002 23:44
> To: Garces, Rodrigo
> Cc: Joseph Salowey; Haverinen Henry (NMP/Tampere); [email-masked]
> Subject: RE: [eap] Issues and Questions
> draft-haverinen-pppext-eap-sim-05
>=20
>=20
>=20
> Rodrigo,
>=20
>   see Chapter 16.  IANA Considerations=20
>=20
>    The realm name "owlan.org" has been reserved for NAI realm names=20
>    generated from the IMSI.=20
>=20
>=20
> Also see:
>=20
> # whois owlan.org
>=20
> Whois Server Version 1.3
>=20
>    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
>=20
> >>> Last update of whois database: Thu, 10 Oct 2002 04:53:24 EDT <<<
>=20
>=20
> So the short answer is: Nokia
>=20
> Regards,
>=20
>   Thomas Wieland
>   Cisco Systems, Inc.
>=20
>=20
> 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=20
> >
> >
> >   If no configured realm name is available, the client MAY=20
> derive the=20
> >   realm name from the MCC and MNC portions of the IMSI. In=20
> this case,=20
> >   the realm name is obtained by concatenating "mnc", the=20
> MNC digits of=20
> >   IMSI, ".mcc", the MCC digits of IMSI and ".owlan.org".=20
> For example,=20
> >   if the IMSI is 123456789098765, and the MNC is three digits long,=20
> >   then the derived realm name is "mnc456.mcc123.owlan.org".=20
> >
> >   If the client is not able to determine whether the MNC is two or=20
> >   three digits long, the client MAY use a 3-digit MNC. If=20
> the correct=20
> >   length of the MNC is two, then the MNC used in the realm=20
> name will=20
> >   include the first digit of MSIN. Hence, when configuring AAA=20
> >   networks for operators that have 2-digit MNC's, the=20
> network SHOULD=20
> >   also be prepared for realm names with incorrect 3-digit MNC's.=20
> >
> >What we are concern is who will be maintaining the DNS entry=20
> for owlan.org?=20
> >Who is in charge of doing so? =20
> >
> >-----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=20
> probably be reduce and=20
> >>still achieve the goal of providing SIM based=20
> authentication using EAP. At=20
> >>the same time EAP-SIM should not required any changes or=20
> minimum changes=20
> >>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=20
> pseudonym=20
> >>grammar beyond what is there today in 3GPP?
> >
> >I don't think there are any restrictions on the Pseudonym=20
> grammar.  I don't=20
> >think the 3GPP restrictions necessarily apply.
> >
> >>3) Is there some protocol that depends upon the=20
> Authenticator knowing the=20
> >>pseudonym?
> >
> >How the authentication server manages the pseudonym is not=20
> defined in this=20
> >document.  Is this what you mean?
> >
> >>4) If the pseudonym is lost in the authentication server,=20
> the supplicant=20
> >>can be locked out of the network for ever as it does not=20
> have to respond=20
> >>to the identity request.  This sounds bad.
> >
> >THis depends upon the implementation. It is possible for the=20
> implementation=20
> >to allow manual intervention so the client knows they are=20
> sending their=20
> >clear IMSI and can choose to accept that risk.  Other=20
> implementations on=20
> >the client are possible.
> >
> >>5) The maximum lengths of the fields in the 'message=20
> format' section is=20
> >>1020  bytes, not 1024.
> >>
> >>6) Is the concatenated "1" in front of the IMSI really=20
> useful?  Will it=20
> >>save any protocol bytes or messages?
> >>If not, let's drop it. I still do not see the usefulness of=20
> having the=20
> >>concatenated "1".
> >
> >Good question.
> >
> >>7) The EAP-SIM seems to imply that there is a need for=20
> owlan,org. Who will=20
> >>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=20
> hash?  Does this=20
> >>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=20
>=20
>=20