Subject: [eap] Proposed resolutions to Greg's comments on EAP SIM and EAP AKA

From: <[email-masked]>
Date: Mon, 24 Nov 2003 15:32:49 +0200

Hi everyone, 

I just forwarded Greg Rose's comments on EAP SIM
to this mailing list. I'm not sure the file will 
be posted because it is quite big. If not, I'll
make it available at some www page.

Most of Greg's comments on EAP SIM are easy to resolve just 
by incorporating them in the document. Most of them are
relevant to EAP AKA too, so we'll update it as well.
Please see below for discussion on the ones that need 
more attention.

The changes are clarifications and corrections on 
the specification language. There won't be any 
technical changes to the protocol.

Regards,
Henry

--

The usage of owlan.org in the NAI realm portion: 
The 3gppnetwork.org realm should be used instead of owlan.org, 
once the the 3GPP spec is stable. I wonder if it already is. 
The owlan.org thing was introduced before the 3GPP standardization. 
It could still be mentioned to inform people that it is 
used by some implementations.
I don't think there are DNS servers at owlan.org, so this realm can
only be used for manually configured AAA routing.

Re-authentication: It is included because it is recommended
in 802.11i. There are good reasons to believe that EAP 
authentication will be performed frequently. It could be OK to use 
the full authentication procedure instead.
The re-authentication procedure is optional, and the operator can 
take into use only once there is evidence that it is needed.

What NAI realm to use with pseudonym usernames and 
re-authentication usernames: We should probably discuss this 
some more in the document. We assume that all servers are
able to map pseudonyms to the permanent identity. So the peer 
can use the same realm name with pseudonyms as it uses
with the permanent identity, and it does not matter if the
server is different. For example, if the 3GPP pseudonym mechanism
is used, then the servers share a pseudonym encryption key which
they can use to decode each other's pseudonyms. (There is
also a mechanism to request for the permanent identity in case
the server fails to map the pseudonym to the permanent identity.)
We have included a realm in the re-authentication identities assigned 
by the server. This should allow the re-authentication requests
to be routed to the same server that performed 
the full authentication.

Encrypting the NONCE_S: it would not be necessary. It is encrypted 
just because it _can_ be, and the encryption doesn't cost anything. 
All parameters in this message are encrypted.

Use of CTR mode instead of CBC: Yes, it would be a lot more convenient. 
We have been avoiding any incompatible changes unless they are
critical. So we think we shouldn't change this for the first versions 
of the protocol, because the CBC mode doesn't have any critical 
problems. But if there are other reasons to break compatibility in 
some later version, we should definitely consider replacing 
the CBC mode too.
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap