eap Mailing List: FW: [eap] EAP-SIM v12 review

[henry.haverinen (henry.haverinen]

Florent,

Many thanks for your response. Please see my comments in line.

> This is OK for me though a quick search tends to confirm that 
> exponentiation should be appropriate (http://answermath.com/exp.htm).

OK, thanks!

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

> > [..]  I don't think there are any 
> > problems in practice, at least in the 3GPP architecture,
> > because pseudonyms and re-authentication id's are generated 
> > cryptographically so that the server will be able
> > to map very many previous id's to the permanent identity. 
> The server 
> > will map these identities to the permanent
> > identity by decrypting the embedded permanent identity.
> 
> I assume you are referring to section 6.4.1 of 3GPP TS 33.234
> 

Yes

> > Therefore we should recommend the server to also maintain some old
> > pseodonyms.I think we currently recommend the server to 
> maintain one 
> > pseudonym in addition to the most
> 
> > recently issued.
> 
> I am not sure but have nothing better to propose: I guess we 
> should use 
> a probabilistic model to choose our tradeoff between state 
> maintenance 
> load and fallback to permanent id ;-)...
> 

In the light of the above-mentioned 3GPP TS, I think
it is sufficient just to point out that the server should
take this into account and be prepared to map at least one or
preferably a couple of old pseudonyms in addition to the most 
recently issued. Perhaps there could be a reference to TS 33.234 too.

I'm not saying probabilistic modelling wouldn't be nice... :-)

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

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

> Second, this misinterpretation is somehow confirmed IMHO by the 
> conjugate use of the AT_COUNTER and NONCE_S. Indeed, if I am 
> right, the 
> three main goals of the AT_COUNTER are first to limit the number of 
> successive reauths without full_auth (2^16 in our case), second to 
> provide new keying material (it is included in the key derivation via 
> the XKEY') and third to protect the peer from replays. The 
> main goal of 
> NONCE_S is to challenge the peer to authenticate itself. 

Yes.

> However, one 
> could naively and erroneously think that the counter is here to limit 
> the reauths with the same identity :-( Hence, why not include 
> clarification like:
> Section 7.14, page 49: "AT_COUNTER has three goals :
> 1) limit the number of successive reauthentication without 
> full-authentication
> 2) help in providing new keying material
> 3) protect the peer from replays" 

OK

> Moreover, I think the wording of section 4.3.1 leads to 
> believe that the peer chooses the counter - which is not the case: 
> something like "Both the peer and the AAA server maintain a 
> counter to 
> track the number of successive reauthentication without full 
> reauthentication. The AAA server sends its counter value to the peer. 
> The peer's counter value MUST be less or equal than the value sent by 
> the AAA server to protect from replay attacks"

Thanks, this is a useful clarification.

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

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

> 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
2. server doesn't need to manage all temporary identities as "carefully" but
it can be "sloppier" with re-auth ids than pseudonyms.
3. single-use re-auth id's may also improve the security of the very short
two-message re-auth procedure.
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.)

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

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.

> Since the incrementation of the counter does not seem to be 
> mandated/specified at each reauthentication (except it must become 
> strictly greater) and that you provide different reauthentication 
> identities at each reauthentication, the anonymity rationale 
> [to encrypt AT_COUNTER] seems to me indeed weak.

I agree. And as discussed, we simply decided to put everything
within AT_ENCR_DATA just because we could and the cost is
negligible. There is no harm done in sending
these values encrypted.

> Furthermore, why do we get into so much trouble : the client probably 
> won't spoof his MAC address. Thus, he will be easy to track 
> by an attacker.

I know the MAC address is currently a more serious identity problem
than the AAA identity, not to mention the counter. 
I personally think MAC address privacy should be fixed too,
and random addresses should be used, but let's not get into that
discussion... The fact that something else is broken
is not an excuse to make the same mistake elsewhere.

Best regards,
Henry