eap Mailing List: FW: comments on draft-haverinen-pppext-eap-sim-10.txt

[henry.haverinen (henry.haverinen]

Please see Glen's comments on EAP SIM below.
Many comments are relevant to draft-arkko-pppext-eap-aka
as well. I'll post our proposed fixes in another message.

Best regards,
Henry


-----Original Message-----
From: ext Glen Zorn [mailto:gwz [at] cisco.com]


Hi, guys.  Following are my comments on the draft.  I apologize in
advance if I'm commenting on an outdated version; I actually reviewed
the doc before the Vienna IETF but I'm just getting around to typing
them up & currently I have no Internet access & so am unable to check
the IETF site.  


General Technical Comments

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?

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

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


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

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.

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.

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?

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?

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

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?

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?

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?  

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

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.

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?

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?

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


General Editorial Comments

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.

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

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..."
-- Benjamin Franklin, 1759 


"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets."
-- Voltaire