Overall
-------

Pretty good draft.  Briefly describes various standards proposals for
Secure First Connect, attempts to find a set of dimensions along which
they could be compared and then makes the comparison, and finally
identifies some scenarios where security of First Connect could be
compromised.

There are some technical inaccuracies which can be easily corrected
(see below).  I would encourage extracting the core of this draft and
submitting it as a paper to a workshop or conference.

Technical
---------

General:
- several times you refer to "comparing random secret numbers".  This
  is not correct.  In the mechanisms involving user comparison, the
  comparison is between two short (eg 6 digits) strings calculated by
  each device.  The strings "look" random to an outsider, but are the
  result of deterministic calculations.  Also, they are checksums, not
  secrets.

  I would suggest using "short checksums"

Section 2
- User-s comparison: see comment above: the user is not asked to
  compare secret PINs
- You could systematically list the security properties of these
  association models.  These properties would restrict the kinds of
  protocols that can be uesd with these association models.
  e.g.,
  - visual/audio channels typically cannot provide secrecy.
  Therefore the pairing protocols used with this model must not rely
  on transferring secret information via them.
  - Portable memory devices can provide secrecy in the short term but
  not in the long term.  Therefore the pairing protocols used withthis
  model must not rely on transferring long-term secrets via them.

Section 3.1
- In the "out-of-band model", in addition to the secret, a commitment
  to the devices own public key is also transferred.

Section 3.2
- Reference [9] is not really about Wi-Fi protected setup.  There is
  no public reference to WPS yet.

Section 3.4
- I assumne the "network membership key" is common to all parties on
  the network.  This is not clear.
  - Are there any pairwise keys used in HomePlug AV?

Section 4.1
- I guess there are two conceptual sections here:
  a) description of the threat model and possibly deriving the
     dimensions along which the comparison is to be done: i.e.,
     security, hardware requiremetns, usability, and extendibility
  b) criteria for evaluating security

- Table 1
  You could point out that w.r.t. passive eavesdropping HomePlugAV
  Secure Mode is definitely weaker than the other mechanisms using
  cryptography (since the key is typically permanent).

  Also, the existence of the "secure mode" seems to suggest that
  passive eavesdropping is an issue in "simple mode"?

Section 4.2.2
- Table 2: In most of these, either device could play either role
  (i.e., in BT SP, ther eis no "new device" and "control device")
  I would suggest using "device 1" and "device 2"

Section 4.3.2
- "This model" (i.e., numeric comparison) " ... has been part of
   devlcies already in earlier Bluetooth devices"
   -> how so?

Table 3
- In WiFi protected setup, the effective security against MitM is half
  the password length: i.e., 1 in 100 (4 digits) to  1 in 10000 (8
  digits)

Section 5
- Good work!

Section 6
- item 1
  I think this solution does not help.  Suppose in Figure 2, the
  device 2 ("control device") really is a headset.  it would have at
  most an LED and a button.  The user will accept pairing on device
  1, assuming that it is with a headset.

  Now the attacker device can do whatever it wants with device 1 (not
  just receiving audio).  The user might reasonably set the access
  control policy so that the headset can connect without user
  confirmation.  In that case, the attacker device can do whatever it
  wants even in the future.

  A more effective solution may to make it visible to the user what
  model the device thinks it is using.  E.g., when "just works" is
  being used, the first device could display "Does the other device
  have a display?" If the user answers yes, then pairing is
  terminated.  Otherwise display "Press the button on the other
  device".

  This also implies other implementation guidelines: pairing requires
  a trusted user path, and that the when a security association is
  stored persistently, the level of security involved in creating it
  (and possibly the purpose for which it was created) should also be
  stored.
   
Editorial
---------

Abstract
- s/of the communication/of communication/
- s/Simple Connect/Simple Pairing/

Section 1
- is "broadband" the right word? If not, just drop it.
- s/in the side of/along with/

Section 2	
- s/short-range radio/short-range wireless/
  (even though you could argue that "infrared" is also "radio", I feel
  "wireless" is a better term)  

- References:
   - "physical connections": refer to the "resurrected duckling" paper
   - "Push button"   refer to Broadcom's "Secure Easy Setup", Atheros
      had something similar ("Jumpstart"?).  Maybe also refer to
      Jan-Erik's seminar paper.
      
Section 3.1
- s/key/checksum/
- s/change/exchange (same correction needed in other places as well)

Section 3.3
- s/does require/does not require/ ?

Section 4.1.2
- s/between/among/ (also other corresponding subsection titles)

Section 4.1.2
- Table 1
	s/physical/out-of-band/
  so that Table entries are consistent

Section 4.3.1
- s/compromize/compromise/
- I am not sure what you mean by "affects to easiness use security
  mechanisms".  Did you mean to say "affects the ease of use of
  security mechanisms"?
- s/short passwords e.g 5 PINs/checksums e.g. 5 digits/