eap Mailing List: Proposed resolutions to Glen's comments

[henry.haverinen (henry.haverinen]

Hello,

Here are our proposed resolutions to the issues Glen brought up 
in his review of EAP SIM. Many resolutions are relevant to EAP AKA
too. Any comments most welcome.

> There seems to be a huge amount of state being kept on both the client
> and server, raising the question of synchronization issues.  Is there
> any way that the amount of state held can be reduced?

During a full authentication exchange, the server needs to keep 
the triplets, NONCE_MT, client identity and version negotiation values. 
The client has to keep the NONCE_MT and version negotiation
values. Both also need to know which message they are expecting
(the phase of the exchange). The state will take up roughly 
100 bytes plus the client identity, and there doesn't seem to be
any ways to reduce this state.

Between EAP full authentication exchanges, the client needs to
keep the pseudonym, which is a couple of dozen bytes. 
The server needs to be able to resolve pseudonyms, but for example
in the 3GPP solution the pseudonym decoding only requires the server
to keep a single secret key commonly to all users. Pseudonyms are 
resolved to IMSI by decryption.

The re-authentication requires some amount of stuff to be kept, but in
bytes that is not so much if you compare it to other EAP types that
support session resumption. K_aut and K_encr can be derived again
from the Master Key, so actually the MK, counter, next re-auth ID
and the permantent ID only need to be kept. That'll be 22 bytes +
the identities. The state can always be discarded, which will just 
mean that next authentication will be "full".

EAP AKA needs to keep a bit less state than EAP SIM.

It should also be noted that the amount of state kept by EAP SIM
is reduced if EAP SIM is used with PEAP or other tunneling lower layers.
In this case, pseudonyms and re-authentication are not needed, and 
the session resumption state is kept by the PEAP implementation rather 
than EAP SIM.

> 'Silent discard' of messages seems to me to be a major cause of
> interoperability problems in many protocols (most notably RADIUS), but
> this seems to be the standard approach to protocol errors in 
> EAP-SIM, in
> many cases when there appears to be no reason to fear compromising
> information disclosure (the normal reason for such behavior).  More on
> this in the specific comments.

This is a valid comment, and we're planning to specify 
error messages and EAP Failure instead of silent discard for
most of the error cases. In general, if an error occurs, the
EAP exchange will be terminated. For silent discard, we should refer
to 2284bis's definition which includes logging and counter 
increments. 

We can do this change without breaking technical compatibility to 
previous draft versions. Implementations of the old versions will 
silently discard the new error packets, and time out.

We think the client should send an error packet in the
following cases: malformed EAP request packet (incorrect length etc.),
none of the server's versions in AT_VERSION_LIST are supported, 
incorrect AT_MAC, invalid AT_RAND (e.g. insufficient number of challenges),
unrecognized non-skippable attribute, incorrect attribute types 
(mandatory attribute missing or wrong attributes included), 
unrecognized subtype.

Upon receipt of an erroneous EAP response, the server
issues EAP Failure. These error cases include malformed packets,
incorrect AT_MAC, invalid AT_COUNTER, unrecognized non-skippable
attribute, incorrect attribute types and unrecognized subtype.

> The packets seem to have the potential to get very large.  Will
> everything fit into RADIUS messages/attributes?

The currently specified attributes will fit into RADIUS,
but as the protocol is extensible the packets could grow too large.
We'll add discussion about this restriction to future extensions.
If large extensions are specified in the future, then 
a future version will need to specify fragmentation.
 
> Specific Technical comments
> 
> Sect. 3
> The term "Authenticator" is used repeatedly w/o being 
> defined.  I assume
> that the term is used in the same way as it is used in 
> 802.1X, but this
> is not clearly the case e.g. in para. 4 which says "The
> EAP-Request/SIM/Start packet contains the list of EAP/SIM version
> supported by the Authenticator in the AT_VERSION_LIST 
> attribute."  This
> statement is somewhat confusing, since in the 802.1X and general
> pass-through EAP models, the list of supported versions would 
> come from
> the (logical) Authentication Server (AS).

Yes, we need to change the language so that "EAP Server" is used
to denote the network element that terminates EAP SIM.
I don't know if we need to use the term Authenticator at all,
but anyway it should be used as usual in 802.1x and EAP.

The comment may apply to EAP AKA too, so we'll go it over too.

> Sect. 3, Para. 5 says "The client MUST NOT reuse the NONCE_MT 
> value from
> previous sessions but the client MUST choose it freshly for 
> each EAP/SIM
> authentication exchange."  The second constraint ("MUST choose it
> freshly") is easy to satisfy, but the first seems to be impossible to
> satisfy (barring the existence of infinite, instantaneously searchable
> storage on the client ;-).  Also, I think that it would be a good idea
> to insert a reference to RFC 1750 after the last sentence in the
> paragraph.

Yes. The client must choose it freshly with a good random number
generator, but it does not need to guarantee that NONCE_MT is 
not re-used.

This comment does not apply to EAP AKA.

> Sect. 3, Para. 6 says "In this document, we assume that the EAP server
> is implemented on the AAA server and has an interface to the GSM
> network, so it operates as a gateway between the Internet AAA network
> and the GSM authentication infrastructure." but I think that this is a
> poor assumption, not least because EAP itself makes no such 
> assumption.

We don't need to make this assumption. :-)
 
> Sect. 3, Para. 7 says "If the MAC's do not match, then the client
> silently ignores the EAP packet and does not send any authentication
> values to the network. Eventually, if another 
> EAP-Request/SIM/Challenge
> packet with a valid AT_MAC is not received, the connection 
> establishment
> will time out."  Shouldn't the client at least log the MAC failure
> locally?  It's not clear to me to what the words "connection
> establishment" are referring.  Is there a hidden assumption about the
> underlying protocol(s)?  how do you know that anything will time out?
> Could a bug or an attacker keep the conversation active 
> indefinitely by
> just sending bogus challenges?

Instead of "connection establishment" we should to talk about
"EAP exchange". To my knowledge there is a timeout in the
EAP state machine (and another in 802.1x state machine, but
assuming that would be a hidden assumption).

As discussed above, we're planning to specify explicit error
messages instead of silent discard, so we won't need to
rely on underlying timeouts.

> Section 4, Para. 3 says "If AT_VERSION_LIST does not include a version
> that is implemented by the client and allowed in the client's security
> policy, then the client MUST silently ignore the 
> EAP-Response/SIM/Start
> packet."  Why 'MUST silently ignore'?  I don't see the critical nature
> of the versions supported by the client.  The lack of reporting would
> make diagnosing server configuration errors much more difficult,
> however.  At the very least, should problems like this be logged and
> counted on the client-side?

We agree, the client should send an error message that says
the client doesn't support the server's version.

EAP AKA does not have version negotiation so this comment does not
apply to it.

> Section 4, Para. 4 says "...the client will detect that AT_MAC is
> incorrect and discard the EAP-Request/SIM/Challenge packet. The
> authentication procedure will time out."  How and why will 
> the procedure
> time out?  I'm a little nervous about relying upon 
> unspecified time out
> to ensure the correct operation of protocols.  In particular, on one
> hand the server seems to be  assumed to be an attacker in disguise in
> the case of any failure (good assumption) but it is also assumed that
> the rogue server will rather sheepishly abide by the rules of the
> protocol and just allow it to time out (seems like a poor assumption).

We're planning to specify an error code for failed MAC, so this timeout
issue will be resolved.

> The last paragraph of Section 5.1 says "If the client is not able to
> determine whether the MNC is two or three digits long, the client MAY
> use a 3-digit MNC."  Probably just showing my ignorance, but how is it
> possible that the client would be unable to determine the 
> length of the
> MNC?

In GSM the client doesn't need to know which digits of the IMSI belong to 
the MNC except in some cases where it gets help from the network's
broadcast messages. So in the absense of the GSM broadcast messages,
the client doens't necessarily know whether the MNC is 3 or 2 digits
long. The IMSI is just a string of digits without any visible structure.

> Section 5.3, Para. 6 says "The EAP server produces pseudonyms in an
> implementation-dependent manner."  Shouldn't there be some requirement
> for uniqueness mentioned here?

Yes. The pseudonyms must be unique among the servers that the client
can use. In general we assume all the servers to be at home, so
the home operator must ensure this. If visited network servers
were used in some environment, then uniqueness would have to be 
guaranteed in this environment for all servers.

This comment applies to EAP AKA as well.

> Section 5.3, Para. 9 says "If the EAP server successfully decodes the
> pseudonym received in the EAP-Response/Identity packet to a 
> known client
> permanent identity, the authentication proceeds with the
> EAP-Request/SIM/Start message as usual."  What does the term "decodes"
> mean here?  

It means that the server recognizes the pseudonym, the server is
able to map the pseudonym to a client identity. 

This comment applies to EAP AKA as well.

> Section 5.3, Para. 14 says "On receipt of EAP-Request/SIM/Start that
> includes AT_PERMANENT_ID_REQ, the client MAY delay the 
> processing of the
> message for a while in order to wait for another EAP-Request/SIM/Start
> without AT_PERMANENT_ID_REQ."  It seems to me that just sitting &
> waiting is almost never a good idea...

This was changed in the latest version. In the current version
the client is may silently discard the request for
permanent identity in order to wait for another Start request.
The client may accept a retransmission of the original request
later. 

This comment applies to EAP AKA as well.

> Section 6, Para. 6: It's not clear to me that the network "stores"
> anything, let alone that a network can store anything reliably; I also
> don't understand the relation between the reliability of storage media
> and network load.

We need to rephrase this because the network really doesn't need
to maintain any databases for the pseudonyms (see the discussion
above about the 3GPP solution).

Anyway, there are two reasons to have separate pseudonyms and
re-authentication identities:

1. the client can indicate with the choice of identity whether it wants
re-authentication or full authentication

2. the network can handle the re-authentication identities differently
from the pseudonyms. Different servers should be able to resolve each
other's pseudonyms but don't need to be able to do re-authentication
if another server performed the original full authentication.

This comment is relevant to EAP AKA too.

> Section 6, Para. 12 says "In order to use re-authentication, 
> the client
> and the server need to store the following values: Master Key, K_aut,
> K_encr, latest counter value and the next re-authentication identity."
> Doesn't the server also need to store the real identity in some form?

Yes.
 
> Section 8, Para. 2 says "Because the K_encr and K_aut keys 
> derived from
> the RAND challenges (as specified in Section 17) are required 
> to process
> the integrity protection and encryption attributes, these 
> attributes can
> only be used in the EAP-Request/SIM/Challenge message and any EAP/SIM
> messages sent after EAP-Requets/SIM/Challenge."  But can't 
> they also be
> used in the reauth messages?

Yes.

> I have no idea what Para. 3 of Section 8.1 means.

OK, we'll clarify this. 

The message authentication code can be calculated over 
data that is not included in the EAP packet. If such 
additional data is included in the calculation, then 
there is a separate specification for each message. 
For example, for the EAP-Request/SIM/Challenge, the MAC 
is calculated over the EAP packet and NONCE_MT, 
which is not included in the packet, as specified 
in Section 11.

> There must be a specific expiration date given for the draft, both in
> the "Status of this Memo" section and as the last section in 
> the draft.
> -- "Expires in six months" is not good enough.

OK.
 
> In the first page header, "Point-to-Point Extensions Working Group"
> should be "Network Working Group".

OK.