eap Mailing List

View Index by: Date - Thread - Author
Re: EAP-SIM v12 review
From: Florent Bersani (florent.bersanifrancetelecom.com)
Date: Tue, 16 Dec 2003 10:55:22 -0600 (CST)
Henry,

Thanks for such a quick and detailed response and sorry for the html
encoding (I hope I fixed the problem with my mail client and that it
will be plain text this time)!

A few more comments in-line., essentially regarding identity protection
and reauthentication

Regards,
Florent

henry.haverinen [at] nokia.com wrote:





-----Original Message-----
*From:* ext Florent Bersani [mailto:florent.bersani [at] francetelecom.com]


Editorial:



I also wonder what the correct term for "^" is. Maybe
we could simply say x^y denotes x to the power of y? 

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

`

Technical:

* Nonces and Random values: as stated in a previous post to
the list (on EAP-Archie), I feel quite uncomfortable with
the IMHO confusing language regarding nonces and random
values. It is to me all the more important to clarify these
issues that some cryptographic results hold only for random
values. Therefore I would recommend rechecking the document
to see in each case if the nonces are allowed to be only
nonces or have to be random values. Here's my quick try at
it - further study is of course needed: Nonce_MT should be
random, AT_IV should be random, Nonce_S should be random. The only "nonce" that I see is the AT_Counter ;-). Of
course, we have a terminology collision with the GSM RANDs,
still I would rather have the Nonces relabeled Random when
appropriate.


I agree with your quick try :-).
At least we should avoid using the term nonce and refer to these values as random numbers.
But I wonder if we should keep the labels Nonce_MT and Nonce_S so we wouldn't confuse people
who are familiar with the current language, or should we relabel Nonce_MT to Random_MT and
Nonce_S to Random_S... 

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 ;-)) and not the present (the draft and the
early adopters, that should have the technical level to adapt to
terminology changes ;-)), but that's my opinion.

With Random_MT, there will be no excuse for the implementor that has
implemented a counter whereas with NONCE_MT, he has to read the
draft/RFC in detail to understand that it is a random nonce.



* Limiting the number of Nonce-MTs: if the client chooses to
send a new NONCE-MT in each of his EAP-Response/SIM/Start,
this might be either risky if he has not implemented a good
(pseudo)random generation source of costly if on the
contrary he has. However, I have the feeling that you allow
a peer to change the NONCE_MT he includes in his
EAP-Response/SIM/Start (see page 32) . If so, could you
please give a rationale. I personally do think it is not a
good idea from a security and performance point of view. I'd
also suggest a change to section 4.2.2, page 16, add: "The
peer MUST NOT respond to more than three
EAP-Request/SIM/Start within an EAP session" and something
like "He MUST verify that the sequence of
EAP-Request/SIM/Start he receives querying his identity
comply to the sequencing rules defined in this document"
(this last point is already more or less stated like the
first one but I guess I'd like to have it a little bit
clarified - why not a SIM Identity request state machine?)

Section 7.6 reads: "The peer MUST choose the NONCE_MT value freshly for each EAP-SIM
authentication exchange. If an EAP-SIM exchange includes several EAP/SIM/Start rounds, then the
peer MAY use the same NONCE_MT value in all EAP-Response/SIM/Start packets."
So it is true that the draft allows both changing the NONCE_MT value and re-using it in this case.
The peer and the server both ignore the first NONCE_MT, so there should be no interoperability
problems in either implementation.
We also recommend that the peer should use a good random number generator.
I think we have used MAY rather than MUST or SHOULD mainly because we didn't see any big problems
in doing this either way. Do you think changing the keyword to "SHOULD" would address your
concern?

Yes, definitely.

My concern was either unnecessary performance consumption on the client
side (although 3*16 bytes of pseudorandom data should not be too
difficult to generate) or pseudorandom generation fingerprinting i.e. a
way for an attacker to try and guess how the pseudorandom data is
generated in poor implementations (although there again 3*16 bytes
shouldn't help much as a fingerprint).

About the second issue (section 4.2.2.) I agree with your proposed addition. That's a good clarification, thanks!


* Identity protection and Re-authentication: though I
understand why these functionalities are implemented, I tend
to think like Greg Rose that the pain they cost to implement
hardly balances their benefits - except in the EAP-SIM case
for re-authentication because obtaining GSM triplets can be
costly even for the Home-AAA and re-authentication could be
done by the Visited-AAA in some cases. Anyway, after reading
the draft, it is not clear at all to me how the next
pseudonym or the next-reauth-id (I understood that even if
the counter does not require it, a new reauth-id can be sent
by the AAA for the next reauths) are managed in tricky
situations. For instance, an attacker (or a network
malfunction) can cause on one hand, the peer to divulgate
his next pseudonym or next reauth-id, and this divulgated
next-id can be used on the other hand to start an EAP-SIM
exchange with the network: this exchange may proceed without
any problem until the network sends the encrypted next-id
(pseudonym or reauth). What happens then? Which identity
does the network keeps apart from the permanent one: the
last one it has exchanged during a successful EAP
authentication or the new one it sent during the
authentication that aborted half-way through? If I am right
- in my difficulties to understand the draft, this could be
clarified by explicitly stating when and how the AAA and
peer temporary-id state should be updated.

Yes, it's very good to clarify this. 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

In my opinion, the basic rule is to update the identities upon successful authentication. I agree there are
corner cases, for example the server might think the exchange was successful while the peer lost the connectivity
before receiving EAP Success.

Indeed

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

But as discussed above, the 3GPP implementation should maintain practically all the old
pseudonyms.
The document requires that the peer must not re-use a re-authentication id. A re-authentication id can only
be used once. 

I guess you are referring to section 4.3.3, page 26 "Re-authentication
identities are one-time identities.".

Therefore I'll have two more comments:

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

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. 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" - the third point is stated section
4.3.1, page 24 but I do not see a consolidated statement about
AT_COUNTER. 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"

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?

Since there seems to be no consensus on the necessity of identity
protection whereas there should be one on reauthentication, why not try
to provide a simple solution for reauthentication, a separate solution
for identity protection and authorize the mixture of both solutions.

The client could use a flag or whatever mechanism (decoration of his
identity) to indicate that he wishes a reauth and not a full auth.

Before proposing more changes, I'd appreciate having your view on the
idea of separating reauthentication from identity protection.

Do you think we should add a clarifying statement about the corner cases. For example,
we could further require that:
"If the peer uses a re-authentication identity in an EAP exchange, then the peer MUST discard
the re-authentication state information and not re-use the re-authentication identity in
the next authentication attempt, even if the authentication exchange was not completed."

This sounds good to me.I

If there is a mismatch in the storage of the re-authentication state information, then the parties
will fall back to full authentication. I'm inclined to think both peer and server should only maintain one instance
of the re-authentication state information, and let the fall-back procedure take care of mismatches.


* Re-authentication: I feel a little bit dizzy with the
cryptographic mechanism involved (though confident since
Kaisa reviewed it ;-)). Indeed, building on Greg Rose's
comments, why is the AT_counter encrypted? Wouldn't its
integrity protection with AT_MAC suffice? Similarly would it
be possible to explain why Nonce_S is encrypted? I also
noticed that the network is the only side to choose the
"randomness" or "freshness" to be included in the reauth
(AT_Counter and AT_Nonce_s). Although, I do not currently
think of any attack based on this point, I think it should
be mentioned that an attacker is able to impersonate the
network leading to a successful EAP authentication and that
this impersonation will only be detected during what is
referred to as the "unicast secure association" (phase 2a).
This comes more from my personal paranoia than from a
rational justification but I think this should be explicitly
stated (an attacker seem to be able to "replay" the
network's frame without the peer detecting that it isn't
fresh :-( - unless we get the re-auth id management point
clearer (see my point above)


There is no cryptographic need to encrypt the counter or the nonce_S value, and the protocol would work
fine even though these two attributes were transmitted in the clear. We simply decided to
put all attributes of these messages within the AT_ENCR_DATA because that was a simple thing
to do. There is a (weak) anonymity-related rationale for doing this in cases when very many re-authentications
are used between full authentication exchanges. Here the counter could enable an adversary to link
the re-authentication exchanges together. 

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 seems to me
indeed weak.

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.
Therefore, I tend to think that identity protection is much ado about
nothing, but again it is my opinion and I guess, I'll have to see if the
folks in 3GPP or GSMA thinks the same.

The re-authentication exchange is quite similar to the UMTS AKA exchange. The counter corresponds to
the UMTS AKA sequence number, Nonce_S corresponds to RAND, and AT_MAC in EAP-Request/SIM/Re-authentication
corresponds to AUTN, the AT_MAC in EAP-Response/SIM/Re-authentication corresponds to
RES, AT_COUNTER_TOO_SMALL corresponds to AUTS, and encrypting the counter corresponds
to the usage of the Anonymity Key.
Also the generation of random or fresh material is similar to UMTS AKA -- the server generates
these values, and the peer only verifies that the counter value is fresh. The peer is required
to check that the counter value is big enough.
When you say an attacker could impersonate the network and perform a successful EAP authentication,
are you referring to cases when an attacker is replaying an EAP request from an interrupted re-authentication
exchange? I suppose this is not possible if the peer _never_ re-uses a re-authentication id.

Correct

Does the same problem apply to UMTS authentication in general, and the full authentication
exchange of EAP AKA? It's probably sufficient to document this problem, rather than try to solve it.

I agree



* Interconnexion with the AuC/GSM network: would it possible
to add to the security sections a paragraph about the severe
issues this might raise. Indeed, to give a trivial example,
with a supplicant flooding an AuC through an AAA through an
AP seems to be quite possible (we have implemented one
issuing EAPoL-starts and then replying with valid EAP-SIM
identities - with or without @MAC spoofing - that could
exert a pretty heavy load on an AuC, which has not been
designed and dimensioned to handle the new requests due to
EAP-SIM WLAN access - indeed the GSM authentication traffic
is quite under the operator's control whereas this is not
the case for WLANs). We could also imagine more
sophisticated attacks that would aim at taking some control
on the HLR via the AAA. I guess this issue should be
addressed within 3GPP (I'll try and check whether this has
yet been treated there or not) but it seems to me worth
mentioning it in the draft as you mention other issues
related to GSM/GPRS.

This is an important concern, and I agree it's a good idea to mention that the server
implementation should take this into account and should take steps to prevent flooding the AuC.

OK

However I think this issue is probably not exactly in the scope of EAP-SIM, because it is related
to the protocol between the EAP server and the AuC, so we probably don't need to go into very much
detail in this.

I totally agree: just a little mention of the possible problem will do
just fine

Best regards,
Henry



Results generated by Tiger Technologies using MHonArc.