Subject: [eap] (fwd) issue 178: keying review by Hannes

From: Jari Arkko <[email-masked]>
Date: Fri, 03 Oct 2003 17:31:42 +0300

Hannes has reviewed the keying framework document.
You can see his comments from :

   http://www.levkowetz.com/ietf/rfcmarkup.cgi?url=http://www.levkowetz.com/ietf/drafts/eap/keying/review_hannes-aboba-pppext-key-problem-07.txt&comments=hannes:

Thanks Hannes for the review, its very helpful!

Here are some comments to your comments:

- The target audience of the document is what you listed,
   but an important additional audience is security reviewers
   (e.g. ADs) who would like to ensure that the whole system
   comprised of EAP, methods, 1X, fast handoffs and whatnot
   is reasonably secure.

- I agree that the document should not be 802.11i/1X specific.
   These can be used in examples, however, and as such I'd
   still keep the examples in the body of the document and
   not in an appendix. But the examples should be short
   and if more material is needed for 11i/1X then it should
   be in an appendix.

- I agree that the requirements should come before the
   solution.

- Agree about your terminology comments.

- Agree about your unilateral auth comment. Suggested
   clarified text: "Depending on the used method, EAP provides either
   one-way authentication (in which the peer authenticates to the EAP
   server), or mutual authentication (in which the peer and EAP server
   mutually authenticate). A mutually authenticating method is required
   where keying based on EAP is needed."

- Agree that treatment of fast handoff issues probably
   deserves its own section.

- In Sect. 3.2, I agree binding to a port is too application specific
   (and vague). Bound to the used Calling/Called-Station-Ids?

- In the text

     However, the failure
     to mutually prove possession of the AAA-Key during the unicast secure
     association protocol exchange (phase 2a) is grounds for removal of a
     AAA-Key SA by both parties.

   you said:

     this sounds like a possibility for a denial of service attack.

   I would agree, though it is probably easy to deal with by not
   removing the SAs immediately after getting a bad message, but
   after a timeout.

- Agree with your proposed key naming term definition.

- Do not agree with all editorial comments on removing
   extra explanations; this is a complex issue and we
   have to give examples, and explain some of the environment
   where EAP operates (e.g. discovery phase).

- Diameter CMS can't be used as an alternative to redirects, as that work
   has been dropped by the IETF.

--Jari

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