Subject: [eap] FW: comments on draft-haverinen-pppext-eap-sim-10.txt

From: <[email-masked]>
Date: Wed, 10 Sep 2003 11:18:45 +0300

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

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

---

From: Michael Richardson <[email-masked]>
Date: Wed, 10 Sep 2003 12:32:37 -0400

-----BEGIN PGP SIGNED MESSAGE-----

    glen> General Technical Comments

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

  My feeling is that there isn't really that much state in the protocol,
but rather that none of the state is explicit, so it seems unmanageably
large. 

  Section 5 in particular needs a complete rewrite. The sentences jump from
client requirements to server requirements, without even a paragraph change.
  
  My major comment on -11 is that section 5 should document the client and
the server side seperately. A clear set of states for the client and the
server should be defined.

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

  Yes, I agree.

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

  I'm not convinced that we need the potentially 1024 byte attributes there.
The EAP contents can be split across multiple EAP-Message radius attribues.

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

  It seems to me that as long as the "server" is able to get (IMSI,RAND,SRES)
tuples, it doesn't matter. They may be derived directly, or taken across SS7
or whatever.
  What situation do think this rules out?

]      Out and about in Ottawa.    hmmm... beer.                |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap