eap Mailing List: RE: EAP-SIM v12 review

[henry.haverinen (henry.haverinen]

Hi Florent,

> From: eap-admin [at] frascone.com 
> [mailto:eap-admin [at] frascone.com]On Behalf Of
> ext Florent Bersani

> If I wouldn't fear that my humor be misunderstood, I'd quote 
> you as per 
> your last e-mail:
> "The fact that something else is broken is not an excuse to make the 
> same mistake elsewhere." ;-)

:-)

> To be constructive, if you really don't feel like relabeling 
> the NONCES, 
> may I then suggest to add to the clear statement in the 
> attribute saying 
> that NONCE X must be a random value, that you suggest and 
> that is more 
> or less already there, a paragraph to section 2 defining Nonce and 
> warning the reader to check if the nonce must be random or not.

I agree, and I think the definition in section 2 can already
highlight that the nonces in this protocol are random.
I modified your proposal to reflect this. Do you think 
the following would be OK?

Nonce: a value that is used at most once or that is never repeated 
within the same cryptographic context. In general, a nonce can be predictable 
(e.g. a counter) or unpredictable (e.g. a random value). 
Since some cryptographic properties may depend on the randomness of 
the nonce, attention should be paid to whether a nonce is required 
to be random or not. In this document, the term nonce is only
used to denote random nonces, and it is not used to denote counters.

> OK, I was thinking of something like "If the 
> re-authentication identity 
> presented by the peer matches a valid re-authentication 
> identity for the 
> server" instead of "recognizes, but if I am the only one to feel like 
> changing your wording, I won't be stubborn :-)

Not at all, I think your wording is a lot clearer, so I'll be happy 
to incorporate it. :-)

> I agree that in you current draft wording you can implement 
> re-authentication without identity protection.
> 
> However, you still implement identity protection within your 
> re-authentication scheme because your require a fresh new 
> re-authentication id [we are also discussing this point in 
> this thread, 
> but I'll assume this is our current position] to be used after each 
> re-authentication, the re-auth id that you send encrypted.
> 
> Hence, while wishing to implement only re-authentication, you 
> still have 
> to go in the trouble of managing different identities, which 
> reminds me 
> very strongly of the identity protection hassle ;-)
> 
> I therefore meant, why not use as a reauth-id always the same 
> one: the 
> permanent id (or the pseudonym if is implemented) flagged in 
> a way (it 
> could be something like IMSI.reauth [at] jjj.nnn or decoration of the 
> username, NAI we want) or even the ordinary id but with a 
> flag included 
> elsewhere in the EAP method packet saying "hey I want to fast 
> reconnect"

It would probably be feasible to specify another option to 
start a re-authentication exchange by a client-generated 
re-authentication identity. However, I don't think specifying
a new option would simplify the protocol, but rather to 
ensure interoperability peers and servers would have to implement 
two variants of re-authentication.

AT_NEXT_REAUTH_ID has several purposes. It also works as a capability
flag that indicates the fact that the server supports re-authentication, 
and that the server wants to continue using re-authentication within 
the current context. These indications can save roundtrips, because
the peer won't propose fast re-authentication if the server has indicated
it doesn't want to.

The re-authentication identity also has several purposes. In addition 
to identifying the subscriber and indicating that the peer wants to use 
re-authentication, the re-authentication identity identifies the full
authentication context. So the server should be able to determine whether 
its re-authentication state information comes from the same full authentication 
as the client's state information. In load balancing scenarios, different 
servers 
may have different re-authentication contexts, and the peer only has the most 
recent one, so a context-specific re-authentication identity can help the 
server 
to detect that its state doesn't match the peer's state.
The server-generated re-authentication identity may also include a realm 
to indicate the correct server, and to help the AAA infra route the 
authentication 
to the correct server.

So I think the re-authentication identity should include a random portion
selected by the server, just as 3GPP is specifying. We should mention this 
in the EAP-SIM and EAP-AKA documents too.

I'm not saying there wouldn't be ways to work around these issues
with client-generated re-authentication identities. However, I think
we shouldn't specify such an option, for the sake of simplicity.

> By the way, I think to avoid terminology conflicts we should 
> swap from 
> "re-authentication" to "fast reconnect" or "fast re-authentication" 
> because "re-authentication" may very well mean full 
> re-authentication...

Yes, that's true. 

> >Originally the reasons for having a separate re-authentication 
> >identity were
> >1. peer can choose a suitable identity to indicate it wants 
> to use re-authentication
> >  
> >
> OK but also why not a flag elsewhere in the EAP packet?
> 

The EAP-Response/Identity packet only contains the identity string,
so the flag needs to be part of the identity string.
Similarly, the re-authentication context idenfier
also needs to be part of the identity string. 

> >2. server doesn't need to manage all temporary identities as 
> "carefully" but
> >it can be "sloppier" with re-auth ids than pseudonyms.
> >  
> >
> I am afraid I don't quite understand

If the re-authentication state information expires, or if the server 
doesn't have memory to maintain it, then the server can safely
discard the information. The only consequence is that 
full authentication will be performed next time. In load
balancing scenarios, different servers do not need to synchronize
the re-authentication state information, but if the server changes,
then full authentication can be performed.

However, the server should not simply discard the information
it needs to map pseudonyms to permanent identities, because
losing the pseudonym state information would make the peer
reveal its permanent identity in the next authentication.

> >3. single-use re-auth id's may also improve the security of 
> the very short
> >two-message re-auth procedure.
> >  
> >
> Could you please be more precise?
> 

If re-authentication identities are unpredictable and used
only once, then an attacker should not be able to guess
a valid re-authentication identity, initiate re-authentication, 
get the server's EAP-Request/SIM/Re-authentication packet, 
and later replay that to the real peer. 
But as we discussed, this might not be so important.

> >4. separate identities would allow an intermediate box, 
> located closer to 
> >the access network, to implement fast re-authentication. The 
> AAA server
> >could delegate re-authentications to an intermediate proxy.
> >(I suppose this reason is not relevant currently.)
> >  
> >
> OK, incidentally I am working on this also right now. I'll 
> try and send 
> a separate post on fast reconnect.

OK. In the current 3GPP architecture, EAP-SIM or EAP-AKA 
authentication is performed end-to-end. I also think local
re-authentication shouldn't be specific to any EAP method.
So this rationale does not seem relevant to EAP-SIM or EAP-AKA.

> >The server can generate re-authentication id's for example 
> by concatenating
> >the IMSI and a random number [...]

> Why complicate things with this random number concatenation?
> My point: make it simpler, a constant flag or whatever... unless you 
> have good reasons to want such a heavy mechanisms (not 
> talking about the 
> potential overhead but rather the real pain to stay synchronized)

Please see above. I believe the re-authentication procedure requires
synchronization by definition, because the peer and the server
need to have matching context information. We cannot avoid it. 

> I understand. I'll try and get some feedback from our (some?) 
> testers to 
> see how they found identity protection and fast reconnect in 
> their field 
> trials.

That sounds great! 

> However, I see a compatible way to have the draft comply to 
> my changes: 
> allow the server to always use the same fast-reconnect id for a peer, 
> allow even the peer to derive his fast-reconnect id on his own [i.e 
> define a constant flagging of the permanent and pseudonym 
> identity] (and 
> allow  a server not to resend this fast-reconnect id at each 
> peer's fast 
> reconnect if you care about unnecessary bandwidth consumption)
> 
> What do you think of this ?

To sum up the above, I think we don't need client-generated
fast re-authentication identities. 

My personal preference would be to keep the current specification 
of AT_NEXT_REAUTH_ID. This way the server (= the operator) would 
be able to control the re-use of re-authentication identities. 
I'd welcome any comments from others in this...

I think it could be OK to allow the server to allocate the same fast
re-authentication identity to the peer during a full authentication
context. But the identity should contain something context-specific.
(Of course this would make the re-authentication identity predictable,
so we should discuss the consequences.) 

Best regards,
Henry