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

[henry.haverinen (henry.haverinen]

Michael,

Thanks for your comments. I agree we need to clarify 
Section 5 in the next draft version.

Regarding the architectural assumptions, I agree with Glen
on that this draft doesn't need to discuss the network architecture
beyond the EAP server. The document should specify the EAP method only,
and for the purposes of this document it should be
sufficient to know that the EAP server has some mechanism
to obtain triplets. 

Regards,
Henry

> -----Original Message-----
> From: ext Michael Richardson [mailto:mcr [at] sandelman.ottawa.on.ca]
> Sent: 10 September, 2003 19:33
> To: eap [at] frascone.com
> Cc: gwz [at] cisco.com
> Subject: Re: [eap] FW: comments on 
> draft-haverinen-pppext-eap-sim-10.txt
> 
> 
> 
> 
> *** PGP Signature Status: unknown
> *** Signer: Unknown, Key ID = 0xE99DD5FD
> *** Signed: 10.09.2003 7:32:36 PM
> *** Verified: 11.09.2003 10:48:02 AM
> *** BEGIN PGP VERIFIED 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");  [

*** END PGP VERIFIED MESSAGE ***
_______________________________________________
eap mailing list
eap [at] frascone.com
http://mail.frascone.com/mailman/listinfo/eap