Subject: [eap] EAP-SIM v12 review

From: Florent Bersani <[email-masked]>
Date: Tue, 16 Dec 2003 08:21:38 +0100

Hi Henry,

I've just gone through the latest version of EAP-SIM (v12) -
congratulations for such a clear and exhaustive document that
definitely sets a high-quality standard for EAP method designers! - and
I have a
few comments/questions: please see below.

Of course, apologies in advance for any irrelevant, stupid, wrong or
deja-vu comment/question... which may unfortunately happen though I
tried my best not to make any ;-)

Regards,

Florent

Editorial:

Section 1, page 3: Replace "The 3rd Generation Partnership
Project (3GPP) has specified an enhanced Authentication and Key
Exchange (AKA) architecture for the Universal Mobile Telecommunications
System (UMTS). " with The 3rd Generation Partnership Project (3GPP) has
specified an enhanced Authentication and Key *Agreement* (AKA)
architecture for the Universal Mobile Telecommunications System (UMTS).
"

Section 7.2, page 42: Precise: "The MAC algorithm is
HMAC-SHA1-128 [RFC 2104] keyed hash value. (The HMAC-SHA1-128 value is
obtained from the 20-byte HMAC-SHA1 value by truncating the output to
16 bytes." by saying how effectively the truncation is realized
(leftmost, rightmost bits in big or little endian representation...).

Section 7.3, page 43: Replace "The value field of the
AT_ENCR_DATA attribute consists of two reserved bytes followed by
cipher text bytes encrypted using the Advanced Encryption Standard
(AES) [AES] in the Cipher Block Chaining (CBC) mode of operation using
the initialization vector from the AT_IV attribute." with "The value
field of the AT_ENCR_DATA attribute consists of two reserved
bytes followed by cipher text bytes encrypted using the Advanced
Encryption Standard (AES) [AES] *using a 128 bit key* in the Cipher
Block Chaining (CBC) mode
of operation using the initialization vector from the AT_IV
attribute." Indeed, although it is obvious when you read the draft that
AES is used with a 128 bit key, since the standard allows for 128, 192
and 256 bit keys, a little precision would do no harm IMHO.

Would it be possible to list the attributes in alphabetical
order? This would improve the readability of the document, don't you
think?

Annex B, page 71: is involution the appropriate term for "^"? I'd
say exponentiation but I ain't no native English speaker ;-)

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.

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

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.

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)

Provisioning next_pseudonym: you state in section 9.1 that the
first exchange with the EAP server will have to send the permanent
identity in clear but I do not think this is mandatory since the first
pseudonym may have been provisioned by out-of-band mechanisms (e.g.
provided by a mobile operator on the new SIM it gives to its client for
WLAN access).

Downgrading attacks: this might well more be of an EAP issue than
a method specific issue (I will try to clarify it in another post) but
I feel like there's an "egg and chicken" problem here. The most
reasonable attitude in version negotiation as stated in the draft is
IMHO a static policy decision: both ends should refuse to use versions
below a pre-determined version. However, there are some cases where
version negotiation is useful. This usefulness either comes from new
functionalities or security concerns. If we are in the former case,
protecting the version negotiation is not that important. If we are in
the latter, it might be vital (although static policy should always be
there to save the game): however I'd like to see more of a separation
between the pieces that should remain whatever the version (that
typically include version negotiation) and the pieces that can be
modified without much trouble. To explain my point better: let's take a
protocol A that includes version negotiation mixed with its other
features. If A gets broken after a devastating cryptanalytic attack, it
might be difficult to patch A by releasing a new version since the
version negotiation features could share some pieces with the other
features that are broken. On the contrary, let's take protocol B that
consists of two distinct parts: first a conservative handshake protocol
that includes version negotiation (say with public-key cryptography and
DSS) and then different versions of record protocols (say the first one
with RC4-40 bit, the next one with DES-56 bit and the last one with
AES-128 bit). Then, in case AES is deprecated, there shouldn't be any
problem in releasing a new record protocol (for instance with MARS-128
bit). Of course if the handshake protocol is deprecated (in my example
DSS), then it is obvious that a new (handshake) protocol has to be
developed, which shouldn't allow handshake version negotiation but only
as its predecessor record negotiation. Do you get my point? To go back
to EAP-SIM, my impression is that I don't really know if we are in the
A or B case :-( If we are in the B case, then perhaps we could try to
give it a more modular aspect to facilitate the comprehension and
and relief the implementors that won't fear to have to re-implement
everything in case of bad news (but only the "record" protocol). I'll
try and clarify my point and propose hints of solution in the general
case if you think this is a valid point.

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.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Tue, 16 Dec 2003 17:46:57 +0200

I'm resending this as text only so it won't hit the
size restriction.

-----Original Message-----
From: Haverinen Henry (NES/Jyvaskyla) 
Sent: 16 December, 2003 14:20
To: 'ext Florent Bersani'
Cc: [email-masked]
Subject: RE: [eap] EAP-SIM v12 review

Hello Florent,

Many thanks for reviewing EAP-SIM and for your insightful comments! 
Please see below for my comments.

> -----Original Message-----
> From: ext Florent Bersani [mailto:[email-masked]]
>  

> Editorial: 

Thanks for these editorials. I'll incorporate them in the next version.

I'll try to find a logical order for the attributes, and alphabetical could work for most
of them, except that I'd like to discuss AT_ENCR_DATA, AT_IV and AT_PADDING together.

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

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

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

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.

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

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.

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

> Provisioning next_pseudonym: you state in section 9.1 that the first exchange with 
> the EAP server will have to send the permanent identity in clear but I do not think 
> this is mandatory since the first pseudonym may have been provisioned by out-of-band 
> mechanisms (e.g. provided by a mobile operator on the new SIM it gives to its client for WLAN access).  

OK, we can try to change the language so that it doesn't exclude such operation.

> Downgrading attacks: this might well more be of an EAP issue than a method specific 
> issue (I will try to clarify it in another post) but I feel like there's an "egg and chicken" 
> problem here. The most reasonable attitude in version negotiation as stated in the draft 
> is IMHO a static policy decision: both ends should refuse to use versions below a 
> pre-determined version. However, there are some cases where version negotiation is useful.
> This usefulness either comes from new functionalities or security concerns. 
> If we are in the former case, protecting the version negotiation is not that important. 
> If we are in the latter, it might be vital (although static policy should always be there 
> to save the game): however I'd like to see more of a separation between the pieces that should 
> remain whatever the version (that typically include version negotiation) and the pieces that can 
> be modified without much trouble. To explain my point better: let's take a protocol A that 
> includes version negotiation mixed with its other features. If A gets broken after a devastating 
> cryptanalytic attack, it might be difficult to patch A by releasing a new version since 
> the version negotiation features could share some pieces with the other features that are broken.
> On the contrary, let's take protocol B that consists of two distinct parts: first a conservative 
> handshake protocol that includes version negotiation (say with public-key cryptography and DSS)
> and then different versions of record protocols (say the first one with RC4-40 bit,
> the next one with DES-56 bit and the last one with AES-128 bit). Then, in case AES is deprecated,
> there shouldn't be any problem in releasing a new record protocol (for instance with 
> MARS-128 bit). Of course if the handshake protocol is deprecated (in my example DSS), then 
> it is obvious that a new (handshake) protocol has to be developed, which shouldn't allow handshake 
> version negotiation but only as its predecessor record negotiation. Do you get my point? 
> To go back to EAP-SIM, my impression is that I don't really know if we are in the A or B case :-( 
> If we are in the B case, then perhaps we could try to give it a more modular aspect to facilitate 
> the comprehension and and relief the implementors that won't fear to have to re-implement everything 
> in case of bad news (but only the "record" protocol). I'll try and clarify my point and propose hints 
> of solution in the general case if you think this is a valid point. 

The version negotiation in EAP-SIM is protected (later during the exchange) 
by the mechanisms specified in the selected version. A new EAP-SIM version can re-define 
key derivation, PRF, AT_MAC, AT_ENCR_DATA etc, so we can address the compromize of these 
primitives by specifying a new version. We don't have any separate more conservative portion
to protect the version negotiation.

If key derivation and AT_MAC (or whatever the version uses to protect version negotiation) 
are very badly compromized in some version, then it might be possible for a man-in-the-middle
attacker to circumvent the protection and downgrade the security to the weakest version. 
The protection of version negotiation in version 1 will be sufficient if the man-in-the-middle
is not able to fake the server's very first AT_MAC, even if other parts of version 1 
were compromized.

I don't think that protected version negotiation is relevant to cases that involve a rogue peer 
or a rogue server, because the rogue party can claim support for the weakest version only. 
I wonder if man-in-the-middle attacks (between valid EAP-SIM peer and valid EAP-SIM server)
are in fact the most relevant attacks against EAP-SIM?

At this point, I'd welcome any improvements the future-proofness of the version negotiation 
that do not break compatibility. However, I'd like to avoid any incompatible changes to the protocol,
unless there is a really good reason.

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

Best regards,
Henry

---

From: Florent Bersani <[email-masked]>
Date: Tue, 16 Dec 2003 17:54:37 +0100

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

[email-masked] wrote:

>     *From:* ext Florent Bersani [mailto:[email-masked]]
>      
>
>     Editorial: 
>      
>
>  
>
>  

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

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

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

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

This sounds good to me.I

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

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.

> are you referring to cases when an attacker is replaying an EAP 
> request from an interrupted re-authentication

Correct

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

OK

> don't need to go into very much
I totally agree: just a little mention of the possible problem will do
just fine

---

From: <[email-masked]>
Date: Wed, 17 Dec 2003 17:03:49 +0200

Florent,

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

> exponentiation should be appropriate (http://answermath.com/exp.htm).

OK, thanks!

> 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 

Yes

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

> 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 

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. 

> NONCE_S is to challenge the peer to authenticate itself. 

Yes.

> However, one 
> 3) protect the peer from replays" 

OK

> Moreover, I think the wording of section 4.3.1 leads to 

Thanks, this is a useful clarification.

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

> 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 

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.

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

> won't spoof his MAC address. Thus, he will be easy to track 

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

---

From: Florent Bersani <[email-masked]>
Date: Wed, 17 Dec 2003 20:47:51 +0100

Henry,

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

Please see in-line.

Florent

>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 :-(

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

>Could the keyword be SHOULD instead of MUST?
Yes indeed, I think so: see below

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

>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 [email-masked] 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...

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

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

>it can be "sloppier" with re-auth ids than pseudonyms.
I am afraid I don't quite understand

>two-message re-auth procedure.
Could you please be more precise?

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

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

>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 ?
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: <[email-masked]>
Date: Thu, 18 Dec 2003 10:14:10 +0200

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:[email-masked]]
Sent: 17 December, 2003 21:47
To: Haverinen Henry (NES/Jyvaskyla)
Cc: [email-masked]
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

Florent,

what matters to me is the future (the RFC and the people that 

will read 

[..]

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 :-(

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

seems to me that if the AAA server wanted to resend each time 

the same 

page 26: after, "Re-authentication identities are one-time 

identities": 

"The server MUST provide a fresh new re-authentication 

identity to the 

UMTS AKA too. 

  

re-authentication identity since it says "If the server 

recognizes the 

Perhaps, a little guidance on the potential threats of a 

laxist behavior 

  

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

conclusion that identity protection and reauthentication are 

orthogonal 

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 [email-masked] 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...

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 

identity were

OK, incidentally I am working on this also right now. I'll try and send a separate post on fast reconnect.

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)

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)