eap Mailing List: Re: EAP-SIM v12 review

[Florent Bersani (florent.bersani]

Henry,

Thanks for taking the time to consider my contents :-) and happy/sorry 
that your answer triggers some more ;-)

Please see in-line.

Florent

henry.haverinen [at] nokia.com wrote:

> Florent,
>
>  
>
> > Well, I'd rather have the relabeling to Random_MT and Random_S since 
> > what matters to me is the future (the RFC and the people that 
> > will read 
> > it and download it for years ;-)) 
> > [..]
> >    
>
> Pasi Eronen reminded me that the term "nonce" is quite widely
> used to denote a random number. Perhaps "nonce" does not have
> any commonly recognized clear meaning, but different documents
> use it to denote different things.
>  
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." ;-)

I agree that nonce is sometimes (often :-( ) misused and that its 
meaning (and translation, for instance I don't know any appropriate in 
French) may seem quite obscure. I also understand your reluctance to 
relabel your random nonces.

However, although you probably do know, let me point out, to be more 
concrete, a precise cryptographic result which holds when the nonces are 
random and doesn't when they aren't (i.e. when the nonces are 
implemented as a counter): the theorem 4.4 of "Entity Authentication and 
Key Distribution" by Mihir Bellare and Phillip Rogaway, abridged version 
published at Crypto'93, full version available on Mihir's homepage 
(http://www-cse.ucsd.edu/users/mihir/papers/key-distribution.html). This 
theorem does not hold, as discussed immediately after it being stated in 
the paper, if the nonce are predictable (not random).

Therefore my fear on the confusion between ordinary nonces and random 
values :-(

> For example the IKEv2 terminology is similar to ours. So I'm inclined 
> to think we can keep these terms Nonce_MT and Nonce_S, especially 
> if we make sure they are referred to as random nonces, and the attribute 
> specifications clearly require choosing them randomly. 
> I don't think that would leave any excuses for an implementation that 
> uses a counter value as the Nonce_MT. :-)
>  
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.

Here's my proposed text:
"Nonce: a value that is used at most once [or that is never repeated] 
within the same cryptographic context. 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."

> > First, I do not see any recommendation stating that the server MUST 
> > provide a fresh new re-auth identity for each re-authentication. It 
> > seems to me that if the AAA server wanted to resend each time 
> > the same 
> > reauth id, he could do so (thus I recommend to add to Section 4.3.3, 
> > page 26: after, "Re-authentication identities are one-time 
> > identities": 
> > "The server MUST provide a fresh new re-authentication 
> > identity to the 
> > peer different from the previous ones used within a same 
> > reauthentication sequence"). 
> >    
>
> I suppose this depends on how seriously we want to take 
> the potential replay of EAP-Request/SIM/Reauthentication.
> As we noted before, the same problem is always present in 
> UMTS AKA too. 
>
> Anyway, I agree with your proposal. In this case there shouldn't be 
> any problems in adding such a statement, but using fresh identities 
> only seems to bring advantages.
> Could the keyword be SHOULD instead of MUST?
>  
Yes indeed, I think so: see below

>  
>
> > Moreover, I tend to think that, as it is 
> > written, the document authorizes the server to accept an old 
> > re-authentication identity since it says "If the server 
> > recognizes the 
> > re-authentication identity and agrees on using re-authentication". 
> > Perhaps, a little guidance on the potential threats of a 
> > laxist behavior 
> > of the server, could help.
> >    
>
> I agree we should explicitly require the server to only accept 
> the most recently issued re-authentication ID.
>
> I don't think the quoted sentence authorizes the server
> to accept an old re-authentication identity, but it only aims
> at describing the operation in case the peer uses a valid
> re-authentication identity. 
>
>  
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 :-)

> > Anyway, after thinking a little bit about the matter, I came to the 
> > conclusion that identity protection and reauthentication are 
> > orthogonal 
> > matters. Reauthentication can easily be implemented without identity 
> > protection, what do you think?
> >    
>
> I agree, and the draft even doesn't require you to implement
> pseudonym support if you only want to support re-authentication.
>  
Hmmm, I think you got my point (this impression is confirmed later on in 
your reply) but a little bit partially perhaps: let me try and clarify 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"

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...

>  
>
> > Since there seems to be no consensus on the necessity of identity 
> > protection whereas there should be one on reauthentication, 
> >    
>
> I think there is demand for both features. TS 33.234 also includes
> identity privacy. Perhaps not everyone wants to use both features, but
> I wouldn't call that lack of consensus. Both features are optional and 
> they can be disabled if they are not considered necessary. 
> So I don't see any problems in having both features included in 
> the protocol as optional features.
>  
As said above, I do think you oblige someone wanting to implement only 
fast reconnect to also implement much of the identity protection 
mechanisms...

>  
>
> > why not try 
> > to provide a simple solution for reauthentication, a separate 
> > solution 
> > for identity protection and authorize the mixture of both solutions.
> >    
>
> 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?

> 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

> 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?

> 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.

> The server can generate re-authentication id's for example by concatenating
> the IMSI and a random number, which would work as a flag to request for
> re-authentication, so the overhead associated with identity privacy 
> management can be avoided. (The server needs to maintain some re-authentication
> state information in any case if it wants to support re-authentication.)
>  
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)

> In my opinion, the current design works fine. I suppose
> there aren't any big problems that we must solve. We should avoid
> making incompatible changes if they are not absolutely necessary.
>  
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.

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 ?