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

[Michael Richardson (mcr]

-----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[
] mcr [at] sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device 
driver[
] panic("Just another Debian/notebook using, kernel hacking, security guy");  [
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys - custom hacks make this fully PGP2 compat

iQCVAwUBP19SJIqHRg3pndX9AQHAeQQA0N+21Zd/hW4+8WXdYuH6o+1A8UxqpvRD
ZBKIH7p23cib/Xa2+SfKze8ayIUybtlNi1/KNC4QMOND4monDJ8s8VDv13V7oDfU
WoGduEL6FYlWDpoQ9Tw66xwza/gMcQj4IgkJ/yCC+WZwAhvqW4HlQXIX/JU4zQle
pFyS+QhlL38=
=Loci
-----END PGP SIGNATURE-----