Hi,

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.

The context of this draft lies within the httpauth WG, which was chartered as a short-lived

WG to produce Informational or Experimental status documents on improving user 

authentication schemes beyond plaintext passwords protected by TLS (as per the

charter text at 

https://datatracker.ietf.org/wg/httpauth/charter/

).

This Experimental specification describes a family of HTTP authentication mechanisms 

called the Salted Challenge Response Authentication Mechanism (SCRAM), which claims

to improve on the HTTP Digest authentication method and be more readily deployable.  

I note that the document mentions the ‘deployment obstacles’ of alternative methods, esp. 

HTTP Digest, but doesn’t discuss explicitly what these were, or why it is believed that 

SCRAM Auth will fare better. It may be useful to include a brief summary near the start

of the document (though doing so could delay publication if the WG gas trouble agreeing

on the precise wording for this, so it would likely need to be a high-level statement) . 

The draft has been through a large number (6) of relatively small updates in the past month.

The update from -11 to -12 adds a statement at the end of the Security Considerations 

section stating that SHA-256 is the recommended hashing mechanism, over SHA-1 

(which was the common mechanism described in RFC 5802). I believe a further edit

is required here:

change: "

(e.g., SCRAM with a successor to SHA-1 may be 

preferred over SCRAM with SHA-1)."

to: “(e.g. SCRAM with SHA-256 should be preferred over SCRAM with SHA-1).”

otherwise the “may” and the “should” are in conflict. The final paragraph could then be

moved up to immediately follow this paragraph. 

The update from -12 -13 changed the document status from Standards Track to 

Experimental, as required by the charter. 

The charter implies that mechanisms should be reviewed by the httpbis WG, to avoid

clashes with work elsewhere, so it may be useful for the AD to ensure there is evidence of 

this having happened (obviously not required in the document itself).

The charter also states that drafts produced within the WG should include a description

of the mechanisms applicability, e.g. via use cases. There appears to be no such statement

in the draft, perhaps because the applicability is broad. This could perhaps be clarified at 

the end of the Introduction section.

The Nits tool reports a small number of nits, including an orphaned reference to RFC 5246.

This should probably be cited in the first mention of TLS in the very first paragraph of 

the Introduction.

Other than these minor comments, I believe the document is Ready.




Tim