Subject: [http-auth] Pete Resnick's No Objection on draft-ietf-httpauth-basicauth-update-06: (with COMMENT)

From: "Pete Resnick" <[email-masked]>
Date: Wed, 18 Feb 2015 13:49:27 -0800

Pete Resnick has entered the following ballot position for
draft-ietf-httpauth-basicauth-update-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-httpauth-basicauth-update/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

2: I'd at least like to hear an explanation about why this is
unreasonable (if it is):

OLD
   Furthermore, a user-id containing a colon character is invalid, as
   recipients will split the user-pass at the first occurrence of a
   colon character.  Note that many user agents however will accept a
   colon in user-id, thereby producing a user-pass string that
   recipients will likely treat in a way not intended by the user.
NEW
   Furthermore, a user-id MUST NOT contain a colon character, as
   recipients will split the user-pass at the first occurrence of a
   colon character.  Many user agents will accept a colon in user-id,
   but this produces a user-pass string that recipients will likely
   treat in a way not intended by the user.
END

MUST NOT means that not using a colon is required for interoperation.
Which is true. So I don't see why you don't come out and say that.

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Feb 2015 23:27:11 +0100

On 2015-02-18 22:49, Pete Resnick wrote:
> ...
 > -----------------------------------------------------------
> COMMENT:
> ...

I just tested Firefox, Chrome, and IE. All of them accept colons in user 
ids and do exactly what the spec currently says. It seems pointless to 
me to say "MUST NOT" when it's widely implemented that way. In a new 
protocol I'd prefer and mandate "fail early", but this is not a new 
protocol.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Feb 2015 23:27:11 +0100

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 18 Feb 2015 23:38:46 +0100

>Which is true. So I don't see why you don't come out and say that.

The intent is to say that usernames containing colons are not supported
by the scheme because first colon in `user:pass` strings separates the
username from the password and there is no escaping mechanism. It would
be incorrect to phrase that as a "MUST NOT".
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Wed, 18 Feb 2015 23:38:46 +0100

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 16:46:42 -0600

On 2/18/15 4:27 PM, Julian Reschke wrote:

> I just tested Firefox, Chrome, and IE. All of them accept colons in 
> user ids and do exactly what the spec currently says.

You mean all of them simply take the user-id, add a colon, add the 
password, and when the server gets it, the server interprets everything 
before the first colon as the user-id and (almost always) fails? That is 
to say, user-ids with colons simply don't work?

> It seems pointless to me to say "MUST NOT" when it's widely 
> implemented that way. In a new protocol I'd prefer and mandate "fail 
> early", but this is not a new protocol.

I guess I'm lost on the distinction between:

    A user-id containing a colon does not work.

and

    A user-id containing a colon MUST NOT be used.

They are semantically identical, AFAICT.

"MUST NOT" does not mean the Internet Police will come to take you away. 
"MUST NOT" means "this won't work".

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 16:46:42 -0600

and

pr

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Feb 2015 23:54:59 +0100

> to say, user-ids with colons simply don't work?

That's what these UAs do. I don't know why they do it; perhaps it 
"works" (for some definition of "works") with some servers.

>     A user-id containing a colon does not work.

I don't say "does not work", but "Note that many user agents however 
will accept a colon in user-id, thereby producing a user-pass string 
that recipients will likely treat in a way not intended by the user.". I 
think that's an accurate description of reality.

> "MUST NOT" means "this won't work".

Ahem, no, that's not what "MUST NOT" means.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 18 Feb 2015 23:54:59 +0100

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Feb 2015 15:42:58 -0800

> Ahem, no, that's not what "MUST NOT" means.

It is, modulo rhetoric.  It's an interoperability requirement.  "You
MUST NOT do <x>," means that if you do <x>, you will not interoperate
-- something will break.  It seems to me that that's exactly the case
here: If my username is "b:leiba", and a client sends "b:leiba:plugh",
many servers will think the username is "b" and the password is
"leiba:plugh".  That means that allowing ":" in the username breaks
interoperability.  Whether or not it works sometimes, and whether or
not implementations currently *do* this are irrelevant.  The point is
that the right definition of the protocol is that you "MUST NOT have a
colon character in the username."

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Feb 2015 15:42:58 -0800

Barry

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 19 Feb 2015 02:15:57 +0100

>colon character in the username."

So, a browser shows a user a prompt like

  Username: _______________
  Password: _______________

User enters Username $user and Password $pass and the browser sends

  Authorization: Basic base64(utf8_encode(concat($user, ':', $pass)))

And then the server interprets that as Username $u and Password $p.

A couple of scenarios:

  a) Browsers abort the process above if $user contains `:`

  b) Browsers abort the process above if $pass contains `:`

  c) `Authorization` headers does not conform to the draft if
     concat($user, ':', $pass) contains more than one colon

  d) $u != $user

  e) $p != $pass

As it is, the draft does not require a); b) would be non-compliant; c)
is false; d) and e) can happen without violating requirements of the
specification due to colons alone.

The text suggested by Pete Resnick restricts, in the model above, the
contents of `$user`, without clear implications for browsers or servers
or header field value validity. What is it actually that people want
here? Should browsers be required to check user input for colons? Is it
okay that the draft requires support for colons in passwords, but does
not require servers to interpret `b:leiba:plugh` as having a password of
`leiba:plugh`? Perhaps encoded `user:pass` strings in `Basic` headers
should be non-conforming if they contain more than one colon?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 19 Feb 2015 02:15:57 +0100

A couple of scenarios:

  d) $u != $user

  e) $p != $pass

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Feb 2015 17:23:15 -0800

...
> should be non-conforming if they contain more than one colon?

The bottom line here is that we aren't police, and there are no
consequences for "not conforming".  If, in fact, usernames that
contain colons cause interop problems, what we *should do* in writing
the protocol is to say that usernames MUST NOT contain colons.  If,
despite that, browsers don't check user input, and send usernames with
colons, then the answer is that when they do that they're likely not
to get the results they expect, because that's not valid in the
protocol.  And if someone complains that things broke as a result,
everyone can explain why: having the colon in the username is a
protocol violation.

I don't understand what the argument is about here, because I don't
*think* anyone is arguing that colons *should* be allowed.  I think
the only argument is that sometimes colons *are* sent.  I don't see
that that matters.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 18 Feb 2015 17:23:15 -0800

...

Barry

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 08:15:40 +0100

> interoperability.  Whether or not it works sometimes, and whether or

Allowing colons in usernames when usernames are assigned is a problem. 
We already say these names are invalid.

Requiring UAs to reject them is an entirely different story. If a user 
id *did* contain the colon, and did "work" for some UA A and server B, 
implementing the "MUST NOT" in the UA would remove the user's ability to 
log on to the web site. That's a bigger failure.

> colon character in the username."

They are invalid, and we already say that.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 08:15:40 +0100

Best regards, Julian

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Feb 2015 11:20:07 -0500

Hi,

On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke <[email-masked]>
wrote:

> Allowing colons in usernames when usernames are assigned is a problem. We
> already say these names are invalid.
>
> Requiring UAs to reject them is an entirely different story. If a user id
> *did* contain the colon, and did "work" for some UA A and server B,

Pete and Barry are making the point that text in this draft can help clear
this issue up going forward.  If a user id contained a colon, the user
would need a new id if user agents decided this should not work.  Since
browsers do support this now, there must be some instances where this
occurred to change their behavior, moving away from standard specifications
to allow this, is that true?  I haven't seen user ids with :s in them, but
that could just be me being unaware of this practice.

I'm not reading this discussion as resolved yet.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 19 Feb 2015 11:20:07 -0500

Hi,

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 17:45:37 +0100

On 2015-02-19 17:20, Kathleen Moriarty wrote:
> Hi,
>
> On Thu, Feb 19, 2015 at 2:15 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Allowing colons in usernames when usernames are assigned is a
>     problem. We already say these names are invalid.
>
>     Requiring UAs to reject them is an entirely different story. If a
>     user id *did* contain the colon, and did "work" for some UA A and
>     server B, implementing the "MUST NOT" in the UA would remove the
>     user's ability to log on to the web site. That's a bigger failure.
>
>
> Pete and Barry are making the point that text in this draft can help
> clear this issue up going forward.  If a user id contained a colon, the
> user would need a new id if user agents decided this should not work.
> Since browsers do support this now, there must be some instances where
> this occurred to change their behavior, moving away from standard
> specifications to allow this, is that true?  I haven't seen user ids
> with :s in them, but that could just be me being unaware of this practice.
>

True.

The problem here is the "long tail". We simply have no information about 
whether these IDs exist in practice. The fact that all UAs I checked 
indeed accept them at least *hints* that they might be used somewhere. 
Or none of the implementers ever thought about rejecting them.

I don't believe we can find out what the reason for this is.

In RFC 2617, the pseudo-ABNF prose production excluded the colon, but no 
additional prose requirements were present.

In the draft, we have replaced that pseudo-ABNF by prose, and that prose 
not only says "invalid" but also explains what common UAs do, and how 
that might affect results. I hope everybody agrees that this is an 
improvement over what we had before.

The discussion that we're having is whether "MUST NOT use colons" is 
better or worse than "colons are invalid". I don't believe it makes a 
difference. I'll also note that I'm very unhappy to include a "MUST NOT" 
when we know that current implementations actually do it anyway, and 
they are extremely unlikely to stop doing that. In the worst case, a 
user who previously could login now won't, and this might switch to a 
different UA. (And that's what scares UA implementors most :-).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 17:45:37 +0100

True.

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Feb 2015 09:55:37 -0800

A final note form me on this, and then I'm done with the discussion:

> whether these IDs exist in practice. The fact that all UAs I checked indeed
> accept them at least *hints* that they might be used somewhere. Or none of
> the implementers ever thought about rejecting them.

I don't think this matters (but see below).  From the point of view of
protocol definition, it doesn't matter what's done; it matters what
works.  If userids with colons don't work when you send them on the
wire (because servers don't interpret the userid/password field as
intended), then the protocol definition should ban them, even if user
agents are, in fact sending them on the wire and will continue to.

But...

> The discussion that we're having is whether "MUST NOT use colons" is better
> or worse than "colons are invalid". I don't believe it makes a difference.

I have to admit that I don't either, and that's why I'm done with this
discussion.  I don't think that changing "X is invalid" to "MUST NOT
X" is important enough that it's worth further discussion, and I'm
happy to have that left as it is.  We might consider slightly altering
the text to make it clear that what we say is being done in practice
often does not work and is not interoperable (rather than the sort of
vague "will likely treat in a way not intended" text that's there
now).  Meh.  I'll leave that up to Julian and Pete to discuss.

Julian, thanks for the discussion.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 19 Feb 2015 09:55:37 -0800

But...

Barry

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 19 Feb 2015 23:33:13 +0100

>improvement over what we had before.

The current text is:

So if the password contains a colon, and the draft requires support for
that, then what? Are recipients REQUIRED to split the string at the 1st
colon? If so, then I think the current text is not adequate. If not,
then it seems wrong to require support for colons in passwords.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Thu, 19 Feb 2015 23:33:13 +0100

The current text is:

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 23:43:15 +0100

> then it seems wrong to require support for colons in passwords.

I think they are required to split on the first colon; why do you think 
the current text is inadequate?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 19 Feb 2015 23:43:15 +0100

Best regards, Julian

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Feb 2015 00:07:45 +0100

>the current text is inadequate?

It should be something like

  The first colon in a user-pass string separates username and password
  from one another; text after the first colon is part of the password.
  Usernames containing colons cannot be encoded in user-pass strings.
  Note that many user agents produce user-pass strings without checking
  that usernames supplied by users do not contain colons; recipients
  will then treat part of the username input as part of the password.

This would actually define the correct interpretation of the first colon
rather than hinting at what recipients will do, avoid the "will likely"
speculation, and makes it more clear that colons in usernames are not an
option offered by the protocol that then needs to be restricted by a
MUST NOT for interoperability reasons, as far as I am concerned. It is
also more clear that "user agents accept colons" is an UI issue; with
the text in the draft `user-id` is used for both "string entered into
username form field" and "value in Authorization header" which can be
quite different due to colons.
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Fri, 20 Feb 2015 00:07:45 +0100

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Feb 2015 15:12:50 -0800

> quite different due to colons.

+1  (FYI, Apache httpd does exactly that.)

....Roy

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 19 Feb 2015 15:12:50 -0800

....Roy

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 20 Feb 2015 17:24:09 +0900

> Or none of the implementers ever thought about rejecting them.

My guess is that the second answer is the correct one. If there are no 
userids with colons in them, why would the implementers need to reject them?

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 20 Feb 2015 17:24:09 +0900

Regards,   Martin.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 15:15:49 +0100

I changed the text to:

>    the first colon in a user-pass string separates user-id and password
>    User-ids containing colons cannot be encoded in user-pass strings.
>
>    that user-ids supplied by users do not contain colons; recipients

in <http://trac.tools.ietf.org/wg/httpauth/trac/changeset/128>.

Pete, Barry, does this sound good to you?

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 20 Feb 2015 15:15:49 +0100

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Feb 2015 06:31:03 -0800

> Pete, Barry, does this sound good to you?

That looks lovely to me.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Feb 2015 06:31:03 -0800

That looks lovely to me.

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 09:44:55 -0500

> > Pete, Barry, does this sound good to you?

Agreed, that looks much better.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 09:44:55 -0500

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Feb 2015 10:09:31 -0600

> Pete, Barry, does this sound good to you?

It's fine. I will admit to still being a bit mystified about the 
reluctance to use the imperative, because really implementations MUST 
NOT be putting user-ids with colons on the wire if they expect 
interoperation. But the above defines the syntax just fine, and there's 
no reading the above and thinking that it's OK to put a colon in the 
user-id portion of the user-pass string and expect it to work. So go for it.

pr

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Feb 2015 10:09:31 -0600

pr

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 11:51:55 -0500

On Fri, Feb 20, 2015 at 11:09 AM, Pete Resnick <[email-masked]>
wrote:

> reluctance to use the imperative, because really implementations MUST NOT
> be putting user-ids with colons on the wire if they expect interoperation.
> But the above defines the syntax just fine, and there's no reading the
> above and thinking that it's OK to put a colon in the user-id portion of
> the user-pass string and expect it to work. So go for it.

Pete, Ted supported your stance and I'm fine with the MUST NOT as we are
all saying the same thing. This language is better than what was there
before and essentially means the same thing as MUST NOT.  Julian, is there
any reason not to have the MUST NOT as I don't see it.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 11:51:55 -0500

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Feb 2015 09:27:01 -0800

> Pete, Ted supported your stance and I'm fine with the MUST NOT as we are all
> saying the same thing. This language is better than what was there before
> and essentially means the same thing as MUST NOT.  Julian, is there any
> reason not to have the MUST NOT as I don't see it.

Julian's already given his reasons, and I, at least, don't see any
point in discussing it further.  I think the text is fine, and is, as
you say, effectively the same as MUST NOT, so at this point we're just
talking about personal preferences in wording... which, at some point,
ADs need to let go of.  Methinks it's time to let go of it.

At some time it might be good to get community consensus on 2119 key
words not being "conformance language".  I think this isn't that time.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Feb 2015 09:27:01 -0800

Barry

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 12:47:46 -0500

On Fri, Feb 20, 2015 at 12:27 PM, Barry Leiba <[email-masked]>
wrote:

> all

OK, just being thorough for Pete's concern.

Thanks everyone!

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 20 Feb 2015 12:47:46 -0500

Thanks everyone!

-- 

Best regards,
Kathleen