Last Call Review of draft-ietf-httpbis-auth-info-04
review-ietf-httpbis-auth-info-04-secdir-lc-meadows-2015-04-09-00
Request | Review of | draft-ietf-httpbis-auth-info |
---|---|---|
Requested revision | No specific revision (document currently at 05) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-04-07 | |
Requested | 2015-03-19 | |
Authors | Julian Reschke | |
I-D last updated | 2015-04-09 | |
Completed reviews |
Genart Last Call review of -04
by Robert Sparks
(diff)
Genart Last Call review of -04 by Robert Sparks (diff) Secdir Last Call review of -04 by Catherine Meadows (diff) Opsdir Last Call review of -04 by David L. Black (diff) |
|
Assignment | Reviewer | Catherine Meadows |
State | Completed | |
Request | Last Call review on draft-ietf-httpbis-auth-info by Security Area Directorate Assigned | |
Reviewed revision | 04 (document currently at 05) | |
Result | Has nits | |
Completed | 2015-04-09 |
review-ietf-httpbis-auth-info-04-secdir-lc-meadows-2015-04-09-00
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft defines the “Authentication-Info” and “Proxy-Authentication-Info” response header fields for use in HTTP authentication. These are used for schemes that need to return information once a client’s authentication credentials have been accepted. The document defines the syntax, and gives instructions on how it should be treated (e.g. proxies forwarding a response are not allowed to modify it). The actual semantics of the fields depend upon the protocols that use them. In the Security Considerations section, the authors note that adding information to HTTP responses sent across an unencrypted channel can affect security and privacy. Indeed the presence of these header fields alone indicate that HTTP authentication is in use. Additional information could be exposed depending on the authentication scheme; but this is something that will need to be addressed in the definition of the schemes. I only have one small question about the Security Considerations section: wouldn’t there be other headers that indicate authentication is being used, such as a header indicating that a message contains the client’s credentials? If so, I don’t see how the introduction of an additional header field adds any further risk. I believe that this ID is ready with nits. Cathy Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows at nrl.navy.mil