Last Call Review of draft-harkins-salted-eap-pwd-06
review-harkins-salted-eap-pwd-06-opsdir-lc-jethanandani-2016-10-05-00

[If my signature is missing at the end of this message, it means the mail got
truncated. Please let me know if that is the case]

I have reviewed the above 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-salted-eap-pwd-06

Status:

Ready with comments.

Summary:

This document defines a method to add support for salted passwords in their use
with EAP-pwd. Salted passwords are passwords that are stored after they have
been “salted” with a “salt” to prevent passwords from being guessed.

The document is informational but does present ways that require the existing
mechanism for password authentication to be changed. Specifically, salting of a
password is treated as an additional password pre-processing technique of
EAP-pwd. There is discussion around how the payload would need to be modified.
It even uses language from RFC 2119 like SHOULD, SHOULD NOT, SHALL, MUST NOT
etc. which makes you wonder why the document is informational in nature.

In the authors defense, the document it is updating is also informational in
nature.

Management considerations:

The draft talks briefly about the protocol modifications that need to happen to
deploy the solution. In particular, it refers to how multiple salt digests can
be supported simultaneously; essentially by having multiple password databases.
But it the refers to a “routable portion of client identity”, but is not clear
on what that client identity could be. If the references are derived from
another document, they need to stated where the terms are being derived from.

Similarly, the draft talks about client indicating its acceptance of the
password pre-processing technique. What it does not talk about is what happens
if the client does not accept any of the techniques? What does it send back? If
this is part of the base EAP-pwd protocol, can it be stated so?

The draft talks about when the client and server can start fixing the password
element. Specifically, it says that the client cannot start fixing the password
element till it receives a EAP-pwd-Commit/Request. It appears that the client
cannot send any data till that message is received. What happens if it never
gets that message. Does it disconnect and retry, or can it poke the server to
send the message again? Again, if this is described somewhere else, it would be
helpful to know where.

Fault management:

The draft should document how any failures or faults are tracked. For example,
if the salt length does not meet the requirements, how is that reported?
Similarly, if the client drops a session because it could not come to an
agreement with the server on password pre-processing technique, how is that
information propagated?

Fault determination:

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

Configuration management:

How are the new password pre-processing techniques configured on the server?

Verifying correct operation:

The draft needs to talk about how the new technique can be tested for correct
behavior. While the client able to communicate with the server is certainly one
indication, it would be helpful to know that it is because of the new technique.

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.

Impact:

Finally, the draft should talk about the impact of deploying the new
techniques. For example, what would be the impact of choosing and computing for
this requirement both in terms of any specialized hardware that might be needed
and/or if done in software, the impact on CPU for the new technique.

A run of idnits revealed one issue that might need to be addressed:

  ----------------------------------------------------------------------------

  == The 'Updates: ' line in the draft header should list only the _numbers_

     of the RFCs which will be updated by this document (if approved); it

     should not include the word 'RFC' in the list.

Thanks

Mahesh Jethanandani

mjethanandani at gmail.com