Skip to main content

Last Call Review of draft-harkins-owe-05
review-harkins-owe-05-opsdir-lc-jethanandani-2017-01-10-00

Request Review of draft-harkins-owe
Requested revision No specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-13
Requested 2016-12-05
Authors Dan Harkins , Warren "Ace" Kumari
I-D last updated 2017-01-10
Completed reviews Genart Last Call review of -05 by Lucy Yong (diff)
Secdir Last Call review of -05 by Matthew A. Miller (diff)
Opsdir Last Call review of -05 by Mahesh Jethanandani (diff)
Opsdir Telechat review of -06 by Will (Shucheng) LIU (diff)
Assignment Reviewer Mahesh Jethanandani
State Completed
Request Last Call review on draft-harkins-owe by Ops Directorate Assigned
Reviewed revision 05 (document currently at 07)
Result Has nits
Completed 2017-01-10
review-harkins-owe-05-opsdir-lc-jethanandani-2017-01-10-00
I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

Document reviewed:  draft-harkins-owe-04

Status:

Ready with nits.

Summary:

This memo specifies an extension to IEEE Std 802.11 to provide for
opportunistic (unauthenticated) encryption to the wireless media.

The document is informational but does present an extension to a IEEE 802.1
standard, which makes one wonder why is this document informational in nature.

Operational Considerations:

The memo specifies a new encryption mechanism, without specifying an
authentication mechanism. With Opportunistic Wireless Encryption (OWE), the
client and AP perform a Diffie-Hellman key exchange during the access procedure
and use the resulting parities secrets with a 4-way Handshake.  Because it is
an addition to the existing mechanism, it fits into any existing environment,
allowing for a gradual replacement to distribution of a shared and public PSK
used today in the 4-way handshake. As such if anything, the procedure
simplifies the usage from an operational perspective.

It is not clear how the clients can participate in the new encryption
mechanism. Will the client software need to downloaded before it can use the
new encryption mechanism. If so, can the client download the software using
open authentication/open encryption or a shared and public PSK and then switch
to OWE?

Finally, it would be helpful to suggest how a migration path could be provided
for operators as they move from either an open encryption or a shared and
public PSK mechanism, i.e. can two mechanisms coexist for a period of time.

Management considerations:

Can the new mechanism operate “out of the box”, in that the operators do not
need to specify and values or it would work with any configurable values. If
there are values that are configurable, it would be helpful to state what their
default values are.

There would also be a need to support a troubleshooting and a programmatic
interface for monitoring and debugging any problems that might come up in
deployment. These should be similar to existing techniques used to monitor and
debug issues. These interfaces are not mentioned in the document, something
that would be helpful to have.

Is there a management model being considered for this mechanism both from a
configuration and from a monitoring perspective? If so, it would be helpful to
document it here.

Fault management:

The draft should document how any failures or faults are tracked. What are some
of the basic faults that need to be traced. Same for health indicators. For
example, if the client is not able to negotiate the 4-way handshake, how is
that reported?

If notifications are used to alert operators of certain conditions, they need
to be documented, with a mechanism to throttle those notifications if they
happen frequently.

Fault determination:

If a client is not able to connect to the AP, how is an operator supposed to
determine whether the issue is on the client or the server side?

Verifying correct operation:

The draft needs to talk about how the new encryption method can be tested for
correct behavior. For example, if in a migration strategy, how would one know
if the key being used is from the Diffie-Hellman exchange?

Account management:

The draft also needs to consider how to collect usage information related to
the technique, and what information needs to collected. A lot of times usage
information is used to determine capacity, do trend analysis, calculate cost
allocation, auditing and billing.

Monitoring the new mechanism:

It would be helpful to know how many clients are able to both successfully
generate the Diffie-Hellman exchange and which ones are not. A count of how may
client requests were received, and how many keys were generated would helpful
to the operators. Counter definitions that define what is included in the count
and what is not, should be documented.

A run of idnits did not reveal anything in particular.

Thanks.

Mahesh Jethanandani
mjethanandani at gmail.com