1 / 13

Comments to FIA PAR & 5C

Comments to FIA PAR & 5C. Authors:. Date: 2010-07-12. Abstract. Summary of comments to FIA PAR & 5C. Rev 0: Responses to R05 of PAR & 5C as of July 10, 2010. Introduction. Comments are grouped into “topics” and not per commenter Responses by the TG are directly included in italics .

ania
Télécharger la présentation

Comments to FIA PAR & 5C

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Comments to FIA PAR & 5C Authors: Date: 2010-07-12 Marc Emmelmann, FOKUS

  2. Abstract Summary of comments to FIA PAR & 5C. Rev 0: Responses to R05 of PAR & 5C as of July 10, 2010 Marc Emmelmann, FOKUS

  3. Introduction • Comments are grouped into “topics” and not per commenter • Responses by the TG are directly included in italics. • Comments and responses are directly copied from the FIA e-mail reflector or based on discussion during the FIA telephone conferences. Marc Emmelmann, FOKUS

  4. Security • Francois Simon, Aric: • I am assuming that the FIA capability is an additional amendment for authentication and not a "replacement" for the current authentication process. • SG response: The intention is to add an additional authentication scheme and not to replace the existing one. • Adrian Stephens, Intel: • We absolutely need a security review from those acclaimed by the security community to be experts.  A statement that this review will take place (before sponsor ballot) in the PAR additional information should be added. • It is unclear what requirements there are for security.  Is speed to be gained at the expense of security?   Add a statement in Scope or Purpose saying that the new mechanism will achieve the same level of security as RSNA • Are new authentication schemes supposed to fit in the 802.1x framework,  or is there a new framework required?  The amount of work required is significantly different if 802.1x is not re-used,  as is the lack of the ability to use EAP authentication protocols.   Add a statement indicating whether the changes are intended to be a replacement of 802.1x/EAP,  or to operate using 802.1x/EAP Marc Emmelmann, FOKUS

  5. Security (cont.) • Andrew Myles, Cisco: • Is it possible to reduce the initial link time sufficiently while maintaining security? • Response by Paul Lambert: Yes (IMHO).  There are several worked examples of protocols with just a few exchanges that provide military grade security.  Since this is just the PAR - we obviously can not do a detailed specific security analysis, but clearly good security is possible.  Perhaps adding something in the technical feasibility section for security - or some words indicating that any security mechanisms should be already approved and in use or have a specific review process. Andrew - can you be more specific on why security would not be possible in fewer exchanges.In looking at the security - there are some well worked analyzed examples of very secure protocol exchanges that have only a couple of messages exchanged (between authenticator and supplicant). One good set of documentation for this and other such mechanisms is: http://www.lsv.ens-cachan.fr/Software/spore/yahalom.html . Good security is clearly possible with fewer protocol exchanges, but the interesting technical work for the group is the total solution. It does make sense to add some text that would describe that the group will provide some level of analysis (hopefully just a reference versus new crypto). Marc Emmelmann, FOKUS

  6. Security (cont.) • Andrew Myles, Cisco: •  It appears that you are proposing a solution based on the  MIS protocol.   It is claimed that this mechanism is "secure" because it has been published in conferences/journals.   Unfortunately,  "publication" is not sufficient to show security.   Instead, I believe we need to get agreement from at least some of those that developed 802.11i (after the WEP debacle) that your proposal has some chance of being secure and practical. • A positive review from someone like Jesse Walker (intel) would probably have sufficient weight. • At this point all the security experts I am talking to have severe doubts. [see mail from Hiroshi Mano on Jul 5 to FIA Reflector including Adrew‘s detailed remarks]  main concerns regarding MIA Marc Emmelmann, FOKUS

  7. Scope • Adrian Stephens, Intel • The scope is unnecessarily narrow.  What we care about at this point should be usage models,  requirements and proofs of concept.  By calling the group FIA you have already built in an assumption that the main bottleneck to achieving the usage models you care about is the authentication exchange.   I believe there may be other bottlenecks such as in scanning and network/service discovery.  I would suggest that the par be for "Fast Link Setup". Marc Emmelmann, FOKUS

  8. Scope (cont.) • Andrew Myles, Cisco: • Given the current focus in the PAR on 802.11 security mechanisms, an associated question is can the initial link time be reduced sufficiently by only addressing 802.11 security mechanisms? Or is additional work required within 802.11 related to scanning and service discovery, and outside 802.11related to DCHP, etc • Response by Paul Lambert: Is this a suggestion to expand the scope? The group could also make some small fixes to the initial association time.  While the group clearly has a scope of " Having selected an AP within a new ESS .." it would be useful to ensure that the appropriate AP was selected.  These will not be new mechanisms (11u has plenty), but some guidance or clarifications on this discovery might be useful. Andrew - what specific changes in the PAR would make you vote for this activity? • The agreed problem is that it takes too long for a device to connect to an AP the first time and start doing useful stuff. The time of interest is from when the client is in range of the AP to when application level packets are sent to/from the AP   This time includes scanning though to IP address allocation.   However, the proposed project, by focusing on the 802.11 authentication part of the problem,  only appears to reduce this time by an insignificantly small amount, which does not justify the project.   I would like to see an explanation at to how the project would significant reduce the time defined above Marc Emmelmann, FOKUS

  9. Feasibility • Andrew Myles, Cisco: • The current section on feasibility merely notes that someone has hacked somecode, but not that the result is secure in any way or solves the realproblem. • Since the justification for the necessity of this work is that current methods take 48.4ms of air time to complete, the technical feasibility in the 5C MUST show how reducing this airtime is possible, with sufficient detail for folks outside of 802.11 to understand.  The technical feasibility MUST also show that the authentication protocol claimed to be demonstrated already (in 17.5.4a of the PAR & 5C) is at least as secure as the EAP methods it will replace.  The current EAP methods do not have extra round trips just for the heck of it.  Each transit between authenticator/server and supplicant is there to prevent or avoid an attack against the authentication (provided by Andrew on behalf of an anonymous commenter) • 17.5.4c of the PAR addresses "reliability" in only the most general terms.  For a PAR dealing with security, reliability means a security analysis, so that we don't end up with WEP again. (provided by Andrew on behalf of an anonymous commenter) Marc Emmelmann, FOKUS

  10. General • Francois Simon, Arinc: • In the section "Type of Project", I do not know if  it is allowed, but I would replace "802.11-2007" with  "the latest IEEE Std 802.11".  By the time the amendment is approved, the base standard will be updated. • Subclauses 5.2 and 5.4:  It is assumes that the procedures would also apply for BSS that may not be using or connected to a distribution system.  The BSS, in this case, would have an AP supporting just the coordination functions. Marc Emmelmann, FOKUS

  11. General (cont.) • Andrew Myles, Cisco: • Since the latest version of the PAR (rev 4) claims compatibility with 802.1X and 802.1X is defined to only carry EAP packets, the authentication method to be standardized by the eventual FIA TG MUST be an EAP protocol.  This means that the IETF is the proper standards body for this work, not 802.11 or even 802. (provided by Andrew on behalf of an anonymous commenter) • Creating a new authentication protocol in 802 MUST get the approval of 802.1, since that is where this work is defined to take place (provided by Andrew on behalf of an anonymous commenter) • Response by Dan Harkins (during July 12 ad-hoc session): A similar discussion took place for 802.11s and the 802 as well as 802.11 leadership agreed that this is well within the scope of 802.11 • Section 7.1 of the PAR is untrue. There is at least one other standards body with similar scope, the EAP WG of IETF.  If the authors continue to make this claim, they cannot also claim compatibility with 802.1X in 17.5.2. (provided by Andrew on behalf of an anonymous commenter) •  Having amateurs play at security is only going to get us back into the mindset that we know what we are doing, just as we did with WEP. This work should be done by security professionals.  They generally do not meet at the 802.11 meetings, but at the IETF. (provided by Andrew on behalf of an anonymous commenter) Marc Emmelmann, FOKUS

  12. Support of PAR as it is • Carl Kain, Noblis • General support for PAR, ITS as additional use case (see mail to FIA reflector on June 15, 2010) Marc Emmelmann, FOKUS

  13. Summary • Security • Add statement to PAR that review by security experts is done before sponsor ballot • Add statement that security is at least as good as for given scheme (need to find proper wording) • Be specific if 802.1x framework will be re-used; add statement if new scheme will replace existing framework, provide an alternative one, or re-use it. • Scope • The “big problem” consist of three phases: (1) network discovery, (2) initial secure authentication / association, (3) exchange of higher layer protocol messages to get ready for application data exchange • Phases (1) and (2) are directly the concern of 802.11; phase (3) involves IETF. • Optimization might be done at (1) and (2) with a clear separation to optimization at (3)  no dependency • Remaining question: Should the TG be created regardless if optimization is of phase (3)? Should the scope be extended to include phase (1) ? Should the SG draft a liaison letter informing IETF about the activity? Marc Emmelmann, FOKUS

More Related