Subject: [eap] non-wire related comments on eap-sim-11.txt

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Sep 2003 15:36:13 -0400

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

A1)	please include real packet dumps, including encrypted data
	with keys, to help people.

A2)	There is no per-attribute description/reference.
	     -> AT_VERSION_LIST	  for instance has no reference.

A3)	paragraph 1 of 5.2. This conversation seems totally out of
	place, and very confusing.

A4)	The definitions of the attributes seems to be partially defined
	only in the scenarios of sections 9-15. I would rather the 
	attributes were defined seperately from the messages in which
	they are used. Otherwise, it appears that one has to code per-message
	marshalling/etc. It is hard to tell if this is true or not.

A5)	It was not at all obvious that the AT_MAC is a keyed operation.
	The last sentence of 8.1 says so, but I missed it at least twice,
	thinking, but, it must be keyed, I remembered reading about it.

	Maybe this is just the way that I read the document.

A5b)	Annex A/B might be a little more detailed.
	In particular, I think that you have chosen G to be SHA1, but
	I'm not particularly certain.
	Nor do I understahe what "m" is, or what the "optional user input"
	is in this context.

A6)	split normative and informative references.

A7)	section 3, overview, para 3.
	It seemed that this was the only place that the value of the Start
	subtype was clearly stated.

A8)	section 5.1, page 9, 

	> In this case, the permanent username MUST be of the format "1imsi". 
	
	It took me awhile to understand that the thing in quotes is a
	pattern, not a string. Please remove "", or use another notation.

A9)	section 5.1, page 9, para 4.
	This seems really nebulous.

A10)	section 5.2, first paragraph.
	It seems that you are putting the most complicated "gotcha"
	at the beginning. At this point, I don't even know what you are
	talking about yet!

A11)	time-sequence diagrams. They are simply not useful to me. They just
	seem to take lots of space.
	They are useful when there are more than two parties.

A12)	section 5.1, 5.2 and 5.3 should have *NO* mention of
	re-authentication. Please describe the base protocol first,	
	(including state machines), and then give the version that 
	supports re-authentication.

A13)	section 5.3, page 15, para 7.
	" A received AT_PERMANENT_ID_REQ does not necessarily originate from "

	The advice given seems very complicated and very dubious to me.
	I believe that this must come out from the client state machine.

A14)	section 6.
	Caveat: I read this much less carefully. 
	page 22, para 4:

"
   Re-authentication identities are one-time identities. If the client 
   does not receive a new re-authentication identity, it MUST use 
   either the permanent identity or a pseudonym identity on the next 
   authentication to initiate full authentication. 
"

	Given that the identity is involved in the AT_MACs, are there
	any cryptographic restrictions on the one-time identities?

A15)	section 7. basic format.
	What if length == 0. Malformed packet.
	Then what?

A16)	section 7. 0/127, 128-255 as "skippable".
	I recommend that you adopt the terminology from IKEv2.
	The high bit is the "critical" bit (or in this case, the
	"non-critical" bit). 

A17)	section 8.2. AT_CHECKCODE.
	This whole concept seems very fragile to me.
	In particular, the whole concept of round trips could be much better
	explained. Remember that there are multiple entities that
	re-transimit: 802.11, LCP, Radius, etc.	    
	EAP re-transmits seem to be server driven. 
	Radius re-transmits are client driven.

A18)	Is AT_CHECKCODE cumulative, or does it just protect the SIM/Start
	message?

A19)	What if it is known that the encapsulator provides integrity 
	protection and privacy? I.e. IKEv2?

A20)	section 10.
	I'd like to see real numbers in the entire packet.
	Hex dumps.
	The code/id/Length/etc. break out seems to take way more white
	space that it provides value.

A21)	re: AT_NEXT_PSEUDONYM, and I guess identities in general.
	What about UTF-8? Internationalization?

A22)	section 18.
	This seems to be the only place that there is a table of
	values. I guess that is okay, but I found it hard to find.
	I'd like to see a table with brief explanations of each 
	attribue back in section 10 or earlier.

A23)	security considerations seem very well written. Good work!

A24)	Annex B. I found it to be clear as MUD. I guess I don't
	code very often to FIPS documents, are they all so obtuse?
	C code for this PRF would be welcome, along with test vectors.
	When I get mine working, I'll be happy to contribute them.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Michael Richardson <[email-masked]>
Date: Mon, 15 Sep 2003 15:58:33 -0400

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

>>>>> "Michael" == Michael Richardson <[email-masked]> writes:
    Michael> A12)	section 5.1, 5.2 and 5.3 should have *NO* mention of
    Michael> 	re-authentication. Please describe the base protocol first,
    Michael> 	(including state machines), and then give the version that 
    Michael> 	supports re-authentication.

  I have implemented basic authentication so far. As such, my state machines
are incomplete, but even so, there are a number of holes and questions that
are not easily determined from reading the document.

  In particular, as I'm writing this, I realize that the EAP-business
of dealing with retransmits in IDs is probably best made explicit in
new states.

  Obviously, I have not taken into account any notifications.

  I suggest text based upon what I write here. I.e. in this style.
  I can write similar text for the client.

  The server seems to have three states in my implementation:
      1) START
      2) CHALLENGE
      3) SUCCESS

  0) 

  Upon recognizing the user as an EAP-SIM, the server transitions into
  the START state. This is done upon receipt of an EAP/Identity message
  detailing a user who should be using EAP-SIM.
  (EAP may have other state that it goes through to get here)

  1) START

  The transition into the START state will result in transmitting an 
  EAP-Request/Sim/Start message. 

  When in state "Start", the following messages may be received:
       a) An EAP-Response/Sim/Start.   
	  i) Verify selected version is compatible and presence of NONCE_MT,
	     and transition to 2) CHALLENGE.
	  
****	  ii) upon failure to verify - ????

       b) An EAP/Identity message. Transition to 1) START.

****   c) OTHER MESSAGES - unsure. Transition to 1) START ????

  2) CHALLENGE

  The transition into the CHALLENGE state will result in an
  EAP-Request/Sim/Challenge message being sent. 
  {Existing RAND challenges should be used if this user has not
   completed the state yet. The EAP ID should not be updated}

  When in state "Challenge", the following messages may be received:
       a) an EAP-Response/Sim/Start 
	  i) Verify selected version is compatible and presence of NONCE_MT,
	     and transition to 2) CHALLENGE.
	  
****	  ii) upon failure to verify - ????

       b) an EAP-Response/Sim/Challenge
	  i) verify AT-MAC. If valid, transition to 3) SUCCESS.
****	  ii) If AT-MAC failes then ????

****   c) an EAP/Identity message. Transition to 1) START ????

       d) OTHER MESSAGES - unsure. Drop?

  3) SUCCESS

  The transition into the SUCCESS state will result in an EAP-Success
  message being sent.

  When in state SUCCESS, receipt of any message results in a transition
  back to (0).

]      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");  [