Subject: Fwd: SECDIR review of draft-ietf-httpbis-p7-auth-24

From: Julian Reschke <[email-masked]>
Date: Tue, 29 Oct 2013 22:54:52 +0100

(FYI)

-------- Original Message --------
Subject: 	SECDIR review of draft-ietf-httpbis-p7-auth-24
Date: 	Tue, 29 Oct 2013 15:35:00 -0400
From: 	Stephen Kent <[email-masked]>
To: 	secdir <[email-masked]>, [email-masked],
[email-masked], [email-masked], Barry Leiba
<[email-masked]>, Pete Resnick <[email-masked]>,
"Mankin, Allison" <[email-masked]>

I 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, WG chairs and ADs should treat these
comments just like any other last call comments.

The document obsoletes RFC 2616 and updates 2617. It says that it
“defines HTTP/1.1 access control and authentication.” I have not been
tracking httpbis closely enough to know the specific motivations for
generating this doc, so my review is unbiased by that context.

I see that “ought” is used in two places on page 6, but not in uppercase
as per RFC 6919. The authors should revisit the use of this term here.

Also on page 6 it appears that the phrase “receipt of” was omitted in
two places:

Upon *<> *a request for a protected resource that omits credentials

Likewise, upon *<>* a request that requires authentication by proxies

Later on page 6 the text says:

The HTTP protocol does not restrict applications to this simple

challenge-response framework for access authentication.Additional

mechanisms MAY be used, such as encryption at the transport level or

via message encapsulation, and with additional header fields

specifying authentication information.However, such additional

mechanisms are not defined by this specification.

Encryption is not, per se, an authentication mechanism. Please revise
this text.

In Section 2.2 the text says:

The protection space determines the domain over which credentials can

be automatically applied.If a prior request has been authorized,

the user agent MAY reuse the same credentials for all other requests

within that protection space for a period of time determined by the

authentication scheme, parameters, and/or user preference.

I’m not clear how user preferences fit into this process. It would seem
that the server would decide whether a prior authorization is valid for
later requests, not a user.

The end of Section 2.2 includes the word “might” but not uppercase, as
per RFC 6919. I again suggest that the authors reconsider using this
term in this context.

In Section 4.3, the text says:

A proxy MAY relay

the credentials from the client request to the next proxy if that is

the mechanism by which the proxies cooperatively authenticate a given

request.

If, as stated here, a set of proxies cooperatively authenticate a
request, then isn’t this a MUST vs. a MAY?

In Section 4.4 the text says:

Note: The challenge grammar production uses the list syntax as

well.Therefore, a sequence of comma, whitespace, and comma can

be considered both as applying to the preceding challenge, or to

be an empty entry in the list of challenges.In practice, this

ambiguity does not affect the semantics of the header field value

Should “both” be “either” in the above text? Does the potentially
ambiguous construct ever take on both meanings simultaneously?

Section 5.1.2 uses “ought” when discussing definitions for new
authentication schemes. See comments above re use of this term.The same
section also uses the phrase “need to” twice, where MUST seems appropriate.

The Security Considerations section (6) is about one page in length. It
references the SC sections in two in I-Ds:
draft-ietf-httpbis-p1-messaging-24 and
draft-ietf-httpbis-p2-semantics-24. Both of these I-Ds have non-trivial
SC sections, but one cannot say that this document has an acceptable SC
section until those documents are finalized. They are both normative
references, so this doc will nor progress independently, but there will
still be a need to revisit this SC when those SCs are finalized.

The SC section here addresses only two issues: purging credentials in
clients and user agents, and protection spaces. The discussion of the
former topic does not discuss how credential purging applies to proxies.
Also, it is not clear that a user control for credential purging will
have the desired effect given a potentially complex GUI environment. The
discussion of protection spaces provides useful suggestions on how to
minimize credential exposure.

I was a bit surprised that there was no advice deprecating the use of
passwords as credentials, if only to make a statement on this topic.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 14:09:50 +0100

Stephen,

thanks for the feedback.

On 2013-10-29 20:35, Stephen Kent wrote:
> ...
> ...
> ...
> ...

We use "ought", "might" etc to disambiguate from RFC2119 keywords. As 
such it's intentional that they are not uppercased, and that we do not 
reference RFC 6919 (which, by the way, is dated April 1st).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 14:40:42 +0100

Stephen,

> still be a need to revisit this SC when those SCs are finalized.

These two other documents are in IETF LC as well.

> former topic does not discuss how credential purging applies to proxies.

As per httpbis-p1, a proxy is a client as well ('An HTTP "client" is a 
program that establishes a connection to a server for the purpose of 
sending one or more HTTP requests.' -- 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.2.1>). 
Does this address your comment?

> have the desired effect given a potentially complex GUI environment. The

Any proposal for enhancing the text?

> passwords as credentials, if only to make a statement on this topic.

This document just defines the HTTP authentication framework. It's not 
intended to give general guidelines about the security of new 
authentication schemes. But then, if you have some concrete proposal for 
additional text, we're all ears.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 14:57:46 +0100

On 2013-10-30 14:42, Richard Barnes wrote:
> ...
> Do you mean that your intent was ought==should and might==may?
>
> Why do you feel the need to avoid SHOULD and MAY here?  They don't place
> any more burden on implementors than "ought" and "might".
> --Richard
> ...

I believe in following the guidance in RFC 2119:

> 6. Guidance in the use of these Imperatives
>
>    Imperatives of the type defined in this memo must be used with care
>    and sparingly.  In particular, they MUST only be used where it is
>    actually required for interoperation or to limit behavior which has
>    potential for causing harm (e.g., limiting retransmisssions)  For
>    example, they must not be used to try to impose a particular method
>    on implementors where the method is not required for
>    interoperability.

I also note that there clearly is no community consensus about what the 
right degree of 2119 usage is. Until there is such thing, I recommend 
that we focus on 2119 keywords being used when they are needed, and not 
bike-shed over the other instances as long as the specification is 
consistent with respect to this.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 15:22:14 +0100

> Should “both” be “either” in the above text? Does the potentially

Yes (done)

> ambiguous construct ever take on both meanings simultaneously?

Yes, but these two meanings do not affect the semantics of the header 
field as a whole (it's either an empty entry in the list of auth 
parameters, or an empty challenge value).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 15:45:16 +0100

Hi Stephen,

On 2013-10-30 15:32, Stephen Kent wrote:
> yes, but it might be clearer to note this, parenthetically, in this doc.
> For example, page 5 includes the following text:
>
>     The 407 (Proxy Authentication Required) response message is used by a
>
> proxy to challenge the authorization of a client and MUST include a
>
> Proxy-Authenticate header field containing at least one challenge
>
> applicable to the proxy for the requested resource.
>
>
> The use of the terms "proxy" and "client" here suggest that they are
> distinct notions,
> not that a proxy is also considered a client.

In the context of this paragraph, the proxy is indeed the server.

> User agents that cache credentials are encouraged to provide a
>
> readily accessible mechanism for discarding cached credentials under
>
> user control. *We recognize that this may not be a trivial task.**
> **   Designing a UI that will encourage users to purge credentials when**
> **   appropriate, but not cause them to prematurely do so may be difficult.*

In my experience, the implementers of browsers are very aware of the 
problems with coming up with a good UI. I really don't think that adding 
more prose here will help at all. (But hey, I asked for a proposal and 
you sent one; thanks for that!).

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 30 Oct 2013 11:04:05 -0400

> The key word there, though, is "imperatives".  Nothing we're talking about
> here is an imperative, just a recommendation (or RECOMMENDATION).  Skimming
> through the instances of "ought to" in the document, it seems like they all
> meet the definition of "SHOULD" in 2119, i.e., things that implementations
> should only diverge from if they have a good reason.  (In fact, there are
> some that seem like they should be "MUST", but that's a different topic.)

First: I think it's a good idea, in a document that defines protocol,
to separate the requirements for the protocol from the recommendations
for implementation aspects that speak to quality of implementation and
user experience, but that don't affect protocol operation (and
interoperation).

Second, because the use of "should", "must", "may", and "recommended"
in lower case is controversial (for reasons that I don't agree with,
but never-you-mind that), I think using alternatives (as, for example,
proposed here, which was not intended for 1 April publication:
http://tools.ietf.org/html/draft-hansen-nonkeywords-non2119 ) is a
fine thing.

Third, these situations in the httpbis documents *are* things that
don't affect the protocol.  How should a browser treat [whatever]?
Well, a browser that makes bad choices could be considered a crummy
browser, so giving advice is good and useful.  But the server won't
know nor care, so this isn't a protocol issue.  I don't think,
therefore, that in a protocol document we should use 2119 language for
that.  Save the 2119 language for the protocol.

Fourth, this is starting to get into nitty wordsmithing (the part
about whether "ought" is a good word... not the part about whether
it's normative or not), which I don't think is really appropriate at
this stage of document development.  That is, it's fine to bring it up
editorial things for the editors to consider, but pushing on them at
the expense of time spent on substantive issues doesn't seem wise at
this stage.

Barry

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 17:25:07 +0100

> later requests, not a user.

Of course it's up to the server to accept or reject it. The text you 
cite is about the user agent deciding whether it can try to use the 
credentials.

Does this require a clarification?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 30 Oct 2013 18:59:20 +0100

On 2013-10-30 17:51, Stephen Kent wrote:
> Julian,
>
> Since, as you note, the server ultimately accepts or rejects the
> credentials,
> it was not clear under what circumstances "user preferences" are a valid
> factor
> in deciding when to stop using the same set of credentials. If you could
> elaborate
> that would be useful.

Well, that text was written 14 years ago, so I really don't know exactly 
what the authors had in mind.

That being said, here's an example: a user pref defining how long 
credentials can be sent after a certain time of inactivity.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Oct 2013 14:43:42 +0100

> request, then isn’t this a MUST vs. a MAY?

Maybe. I have no experience with proxy authentication, and this piece of 
text was copied from 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.34>.

Perhaps this is a case where we should drop the RFC2119 keywords and 
just make a statement such as:

"A proxy can relay the credentials from the client request to the next 
proxy if that is the mechanism by which the proxies cooperatively 
authenticate a given request."

?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Oct 2013 14:54:45 +0100

> Encryption is not, per se, an authentication mechanism. Please revise

OK. Maybe:

"HTTP does not restrict applications to this simple challenge-response 
framework. Additional mechanisms can be used, such as additional header 
fields carrying authentication information, or encryption on the 
transport layer in order to provide confidentiality. However, such 
additional mechanisms are not defined by this specification."

?

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 31 Oct 2013 15:30:22 +0100

* Julian Reschke wrote:
>Perhaps this is a case where we should drop the RFC2119 keywords [...]

Ordinarily a proxy is not supposed to forward the `Proxy-Authorization`
header and an implementation that forwards it by accident fails to meet
the requirements of the specification, so use of RFC 2119 keywords seems
appropriate to me. I also see nothing wrong with the proxy offering an
configuration option to, say, relay the credentials for some users, but
not for others, so this cannot be a MUST. I think the text is fine.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 31 Oct 2013 15:44:24 +0100

>additional mechanisms are not defined by this specification."

I think doing s/encryption/authentication/ instead would be better.
There is no reason to discuss confidentiality here. Encryption and other
cryptographic techniques are used in many authentication schemes, like
with client certificates; that may have been the idea behind the text.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Oct 2013 15:48:56 +0100

> with client certificates; that may have been the idea behind the text.

"authentication on the transport layer"?

That wouldn't cover Basic auth (plain text passwords) over https:, which 
I think this paragraph is hinting at...

Best regards, Julian

-- 
<green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
Amtsgericht Münster: HRB5782

---

From: Nico Williams <[email-masked]>
Date: Thu, 31 Oct 2013 09:51:02 -0500

On Thu, Oct 31, 2013 at 02:54:45PM +0100, Julian Reschke wrote:
> "HTTP does not restrict applications to this simple
> challenge-response framework. Additional mechanisms can be used,
> such as additional header fields carrying authentication
> information, or encryption on the transport layer in order to
> provide confidentiality. However, such additional mechanisms are not
> defined by this specification."

Or even -as pretty much all web authentication is done- *above* HTTP.

Nico
--

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 31 Oct 2013 16:05:21 +0100

>"authentication on the transport layer"?

Applying my suggestion would make the text read,

   The HTTP protocol does not restrict applications to this simple
   challenge-response framework for access authentication. Additional
   mechanisms MAY be used, such as authentication at the transport
   level or via message encapsulation, and with additional header fields
   specifying authentication information. However, such additional
   mechanisms are not defined by this specification.

(The MAY might be better as "can".)

>I think this paragraph is hinting at...

Transport Layer Security client certificate authentication is an
additional authentication mechanism at the transport level that
implementations of HTTP actually use. Basic authentication is just
the basic application of the challenge-response framework defined
in the document, so your interpretation seems unlikely.

It might be a good idea to point out that authentication does not
imply confidentiality and that TLS can be used for confidentiality,
but that should be in a separate paragraph.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Julian Reschke <[email-masked]>
Date: Thu, 31 Oct 2013 16:17:57 +0100

"HTTP does not restrict applications to this simple challenge-response 
framework for access authentication. Additional mechanisms can be used, 
such as authentication at the transport level or via message 
encapsulation, and with additional header fields specifying 
authentication information. However, such additional mechanisms are not 
defined by this specification."

WFM.

> implementations of HTTP actually use. Basic authentication is just

Indeed.

> but that should be in a separate paragraph.

Maybe. Text welcome :-)

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 1 Nov 2013 09:59:07 +1100

It entirely depends upon the way that they’re cooperating… sometimes you’d want to forward them, sometimes not. If we were defining a proxy authentication cooperation protocol here, I could understand a MUST here, but as we’re not, I don’t think we want to constrain how one might operate…

Cheers,

On 1 Nov 2013, at 7:01 am, Stephen Kent <[email-masked]> wrote:

> Julian,
> 
> I alos don't have personal experience with the proxy situation. I was just commenting on
> what appeared to be a logical inconsistency in the text.
> 
> I defer to others, who have such experience, on this detail.
> 
> Steve
>> Maybe. I have no experience with proxy authentication, and this piece of text was copied from <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.34>.
>> 
>> Perhaps this is a case where we should drop the RFC2119 keywords and just make a statement such as:
>> 
>> "A proxy can relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively authenticate a given request."
>> 
>> ?
>> 
>> Best regards, Julian
>> 
> 

--
Mark Nottingham   http://www.mnot.net/