eap Mailing List: RE: EAP-SIM v12 review

[henry.haverinen (henry.haverinen]

 

Florent,

 

Thanks for your note. I'll be mainly out of office until Dec 29th,

so it may take me some time before I can reply in detail.

 

I like your proposal about the definition on nonce. Maybe we could already

state in the definition that in this protocol, all nonces are required to be

random.

 

Best regards,

Henry

 

-----Original Message-----
From: ext Florent Bersani [mailto:florent.bersani [at] francetelecom.com]
Sent: 17 December, 2003 21:47
To: Haverinen Henry (NES/Jyvaskyla)
Cc: eap [at] frasone.com
Subject: Re: [eap] EAP-SIM v12 review

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 ?