eap Mailing List: (fwd) issue 178: keying review by Hannes

[Jari Arkko (jari.arkko]

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