Call for adoption: draft-reschke-httpauth-auth-info-00

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Call for adoption: draft-reschke-httpauth-auth-info-00

Mark Nottingham-2
Julian has proposed that <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be adopted by this WG, with the aim of getting to LC quickly so that it can be referenced by other efforts.

I've discussed it with Barry and he agrees that it's a reasonable thing for us to do.

Please discuss; we'll make a decision about adoption on 1 Feb 2015.

Regards,


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


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Martin Thomson-3
On 28 January 2015 at 14:45, Mark Nottingham <[hidden email]> wrote:
> Julian has proposed that <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be adopted by this WG, with the aim of getting to LC quickly so that it can be referenced by other efforts.

I'd like to see the fact that this is a *response* header field more
prominent in the document.  The word "return" is used, but in this
context, that's fairly ambiguous.

More fundamentally, I see a correlation issue if clients provide
multiple *Authorization header fields.  The response they receive will
contain some unaggregated name-value pairs in this header field.

  "Its semantics are defined by the applicable authentication scheme."

I don't know how that can be interpreted in the general sense since
there isn't a way of identifying the corresponding scheme.

And doesn't it need anti-collision machinery for the parameters?

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Yutaka OIWA
2015-01-29 9:21 GMT+09:00 Martin Thomson <[hidden email]>:
> More fundamentally, I see a correlation issue if clients provide
> multiple *Authorization header fields.  The response they receive will
> contain some unaggregated name-value pairs in this header field.

RFC7235 says that HTTP clients can send only one
"credentials" set in the Authorization: or Proxy-authorization: header,
as defined in Sections 4.2 and 4.4.
One "credentials" belongs to a single scheme.
So, "the applicable authentication scheme" means that
the unique scheme which the client has included in the corresponding request.

Of course, I've wished if the existing Digest authentication scheme had
included an "auth-scheme" in the existing Authentication-Info: header.
If it had a syntax like "Authentication-Info: Digest ...", it would be
self-contained and more clearer.
It's already in use (as a Digest-scheme specific header), and
it cannot be changed without inter-op issues.

--
Yutaka OIWA, Ph.D.
           Senior Researcher, Research Institute for Secure Systems (RISEC)
    National Institute of Advanced Industrial Science and Technology (AIST)
                      Mail addresses: <[hidden email]>, <[hidden email]>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Amos Jeffries-2
On 29/01/2015 2:25 p.m., Yutaka OIWA wrote:

> 2015-01-29 9:21 GMT+09:00 Martin Thomson:
>> More fundamentally, I see a correlation issue if clients provide
>> multiple *Authorization header fields.  The response they receive will
>> contain some unaggregated name-value pairs in this header field.
>
> RFC7235 says that HTTP clients can send only one
> "credentials" set in the Authorization: or Proxy-authorization: header,
> as defined in Sections 4.2 and 4.4.
> One "credentials" belongs to a single scheme.
> So, "the applicable authentication scheme" means that
> the unique scheme which the client has included in the corresponding request.
>
> Of course, I've wished if the existing Digest authentication scheme had
> included an "auth-scheme" in the existing Authentication-Info: header.
> If it had a syntax like "Authentication-Info: Digest ...", it would be
> self-contained and more clearer.
> It's already in use (as a Digest-scheme specific header), and
> it cannot be changed without inter-op issues.
>

Theres nothing stopping a scheme=Digest parameter being specified or
sent in that header. It just wont be used by legacy implementations is all.

Would be worth bringing up to teh httpauth WG before they seal the next
Digest version in stone if its that important to you.

Amos


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Mark Nottingham-2
In reply to this post by Martin Thomson-3
So, you support adopting it?

Regards,


> On 29 Jan 2015, at 11:21 am, Martin Thomson <[hidden email]> wrote:
>
> On 28 January 2015 at 14:45, Mark Nottingham <[hidden email]> wrote:
>> Julian has proposed that <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be adopted by this WG, with the aim of getting to LC quickly so that it can be referenced by other efforts.
>
> I'd like to see the fact that this is a *response* header field more
> prominent in the document.  The word "return" is used, but in this
> context, that's fairly ambiguous.
>
> More fundamentally, I see a correlation issue if clients provide
> multiple *Authorization header fields.  The response they receive will
> contain some unaggregated name-value pairs in this header field.
>
>  "Its semantics are defined by the applicable authentication scheme."
>
> I don't know how that can be interpreted in the general sense since
> there isn't a way of identifying the corresponding scheme.
>
> And doesn't it need anti-collision machinery for the parameters?

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


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Julian Reschke-2
In reply to this post by Martin Thomson-3
On 2015-01-29 01:21, Martin Thomson wrote:
> On 28 January 2015 at 14:45, Mark Nottingham <[hidden email]> wrote:
>> Julian has proposed that <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be adopted by this WG, with the aim of getting to LC quickly so that it can be referenced by other efforts.
>
> I'd like to see the fact that this is a *response* header field more
> prominent in the document.  The word "return" is used, but in this
> context, that's fairly ambiguous.

Will do.

(Which reminds me that in the list of considerations for new header
fields in 7231, most apply to request header fields; we may want to
restructure that text in the future)

> More fundamentally, I see a correlation issue if clients provide
> multiple *Authorization header fields.  The response they receive will
> contain some unaggregated name-value pairs in this header field.
>
>    "Its semantics are defined by the applicable authentication scheme."
>
> I don't know how that can be interpreted in the general sense since
> there isn't a way of identifying the corresponding scheme.
>
> And doesn't it need anti-collision machinery for the parameters?

See Yutaka's answer.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

RUELLAN Herve
I think it's a good thing to have a common mechanism that could be
reused by several authentication schemes (at least DIGEST and SCRAM for
now).

I find that the definition of the Authentication-Info header field is
fuzzier in this draft than it was in DIGEST. In DIGEST this header field
is intended to be used for "information regarding the successful
authentication of a client response".
I'd tweak the wording in the draft to put back this precision. I think
it would alleviate Martin's concerns. Or did I miss something?

Regards,

Hervé.

On 01/29/2015 08:41 AM, Julian Reschke wrote:

> On 2015-01-29 01:21, Martin Thomson wrote:
>> On 28 January 2015 at 14:45, Mark Nottingham <[hidden email]> wrote:
>>> Julian has proposed that
>>> <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be
>>> adopted by this WG, with the aim of getting to LC quickly so that it
>>> can be referenced by other efforts.
>>
>> I'd like to see the fact that this is a *response* header field more
>> prominent in the document.  The word "return" is used, but in this
>> context, that's fairly ambiguous.
>
> Will do.
>
> (Which reminds me that in the list of considerations for new header
> fields in 7231, most apply to request header fields; we may want to
> restructure that text in the future)
>
>> More fundamentally, I see a correlation issue if clients provide
>> multiple *Authorization header fields.  The response they receive will
>> contain some unaggregated name-value pairs in this header field.
>>
>>    "Its semantics are defined by the applicable authentication scheme."
>>
>> I don't know how that can be interpreted in the general sense since
>> there isn't a way of identifying the corresponding scheme.
>>
>> And doesn't it need anti-collision machinery for the parameters?
>
> See Yutaka's answer.
>
> Best regards, Julian
>

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Julian Reschke
On 2015-01-30 13:34, Hervé Ruellan wrote:

> I think it's a good thing to have a common mechanism that could be
> reused by several authentication schemes (at least DIGEST and SCRAM for
> now).
>
> I find that the definition of the Authentication-Info header field is
> fuzzier in this draft than it was in DIGEST. In DIGEST this header field
> is intended to be used for "information regarding the successful
> authentication of a client response".
> I'd tweak the wording in the draft to put back this precision. I think
> it would alleviate Martin's concerns. Or did I miss something?
>
> Regards,
>
> Hervé.

No, you didn't miss anything. Sounds like a good point (to stick with
what 2617 said unless we have good reason to change it).

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Rifaat Shekh-Yusef
Why would we restrict the use of this header in future protocols based on the Digest usage of this header?
What would be the harm in allowing the new protocol that uses the header to restrict it usage?

Regards,
 Rifaat


On Fri, Jan 30, 2015 at 7:55 AM, Julian Reschke <[hidden email]> wrote:
On 2015-01-30 13:34, Hervé Ruellan wrote:
I think it's a good thing to have a common mechanism that could be
reused by several authentication schemes (at least DIGEST and SCRAM for
now).

I find that the definition of the Authentication-Info header field is
fuzzier in this draft than it was in DIGEST. In DIGEST this header field
is intended to be used for "information regarding the successful
authentication of a client response".
I'd tweak the wording in the draft to put back this precision. I think
it would alleviate Martin's concerns. Or did I miss something?

Regards,

Hervé.

No, you didn't miss anything. Sounds like a good point (to stick with what 2617 said unless we have good reason to change it).

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Amos Jeffries-2
On 31/01/2015 3:11 a.m., Rifaat Shekh-Yusef wrote:
> Why would we restrict the use of this header in future protocols based on
> the Digest usage of this header?
> What would be the harm in allowing the new protocol that uses the header to
> restrict it usage?
>

Information leaks. User credentials and secure token are potentially
stored in here, as are details specific to the internal operation of the
security algorithm selected/negotiated.


This header is clearly security related and very likely will be used to
transmit confidential information at some point. At the very least the
security, privacy, cacheability, and hop-by-hop re-usability behaviours
of this header need to be explicitly bounded.

i.e. recipients only implementing this spec need to be made aware of the
*potential* for critical information to be contained in traffic from
future schemes they do not implement already.


I expect this header to be used as a way to indicate implicit
non-cacheable authenticated response from out-of-band authentitication
(HTML login, federated, session resumption, connection auth with no
request credentials)
 - a direct way to kill^H^H contain auth Cookie data

Also as a way to pass Kerberos or NTLM username/group and TTL for the
credentials back to intermediaries without requiring them to participate
in the auth.


Each of these has different needs when it comes to security, but the one
thing they have in common is that they are still sensitive and related
to some previous possibly out-of-band, possibly incomplete
authentication process the recipient has nothing to do with.

I'm also fairly sure there are cases where no sensitive information at
all is transmitted, but security protection is not to protect against
best-case scenarios.

Amos


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Bjoern Hoehrmann
In reply to this post by Mark Nottingham-2
* Mark Nottingham wrote:
>Julian has proposed that
><http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be
>adopted by this WG, with the aim of getting to LC quickly so that it can
>be referenced by other efforts.

There is basically no information in the draft what the header can,
should, or should not be used for, it does not even indicate what the
`Digest` scheme uses it for, and it does not point out caveats like
poor interaction with pipelined requests as they are noted in RFC 2617
and whether such considerations apply to HTTP/2, for instance. I guess
that can be addressed, but it would not have hurt to let the `-00` draft
go through a round of feedback before calling for adoption.
--
Björn Höhrmann · mailto:[hidden email] · 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/ 

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Julian Reschke
On 2015-02-01 10:00, Bjoern Hoehrmann wrote:
> * Mark Nottingham wrote:
>> Julian has proposed that
>> <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be
>> adopted by this WG, with the aim of getting to LC quickly so that it can
>> be referenced by other efforts.
>
> There is basically no information in the draft what the header can,
> should, or should not be used for, it does not even indicate what the
> `Digest` scheme uses it for, and it does not point out caveats like

The latter is supposed to be in the DIGEST spec.

Do you have a proposal for the former?

> poor interaction with pipelined requests as they are noted in RFC 2617
> and whether such considerations apply to HTTP/2, for instance. I guess

Again, that seems to be specific to the nextnonce parameter which is
specific to DIGEST.

> that can be addressed, but it would not have hurt to let the `-00` draft
> go through a round of feedback before calling for adoption.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Bjoern Hoehrmann
* Julian Reschke wrote:

>On 2015-02-01 10:00, Bjoern Hoehrmann wrote:
>> There is basically no information in the draft what the header can,
>> should, or should not be used for, it does not even indicate what the
>> `Digest` scheme uses it for, and it does not point out caveats like
>
>The latter is supposed to be in the DIGEST spec.
>
>Do you have a proposal for the former?
>
>> poor interaction with pipelined requests as they are noted in RFC 2617
>> and whether such considerations apply to HTTP/2, for instance. I guess
>
>Again, that seems to be specific to the nextnonce parameter which is
>specific to DIGEST.

A possible starting point would be to explain whether, how, and why it
is better to use an authentication scheme independent header to specify
authentication scheme specific parameters. If it's pretty much always
better to use `Authentication-Info` then there probably should be some
SHOULD-level requirement to use it somewhere.
--
Björn Höhrmann · mailto:[hidden email] · 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/ 

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Mark Nottingham-2
In reply to this post by Mark Nottingham-2
I haven't seen pushback on adopting this draft (although people have started to raise issues, which is good), so we'll do so.

Julian, you'll continue to edit the document. Please bring the work to <https://github.com/httpwg/http-extensions>; I've already created a label in the issues list for it.

Cheers,


> On 29 Jan 2015, at 9:45 am, Mark Nottingham <[hidden email]> wrote:
>
> Julian has proposed that <http://tools.ietf.org/html/draft-reschke-httpauth-auth-info-00> be adopted by this WG, with the aim of getting to LC quickly so that it can be referenced by other efforts.
>
> I've discussed it with Barry and he agrees that it's a reasonable thing for us to do.
>
> Please discuss; we'll make a decision about adoption on 1 Feb 2015.
>
> Regards,
>
>
> --
> Mark Nottingham   https://www.mnot.net/
>
>

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


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Julian Reschke
In reply to this post by Amos Jeffries-2
On 2015-01-30 22:45, Amos Jeffries wrote:

> On 31/01/2015 3:11 a.m., Rifaat Shekh-Yusef wrote:
>> Why would we restrict the use of this header in future protocols based on
>> the Digest usage of this header?
>> What would be the harm in allowing the new protocol that uses the header to
>> restrict it usage?
>>
>
> Information leaks. User credentials and secure token are potentially
> stored in here, as are details specific to the internal operation of the
> security algorithm selected/negotiated.
> ...

The intent of the draft was to separate out what was defined in RFC
2617; thus I agree that we shouldn't relax the use unless there's broad
consensus that that would be a good idea.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Rifaat Shekh-Yusef
This document does not define any semantics associated with these header, which means that the document that uses these header will be the one that must address the information leak issue.
I do not see why we would restrict a future use of these headers based on the Digest usage; this seems odd to me.

Regards,
 Rifaat



On Mon, Feb 2, 2015 at 8:41 AM, Julian Reschke <[hidden email]> wrote:
On 2015-01-30 22:45, Amos Jeffries wrote:
On 31/01/2015 3:11 a.m., Rifaat Shekh-Yusef wrote:
Why would we restrict the use of this header in future protocols based on
the Digest usage of this header?
What would be the harm in allowing the new protocol that uses the header to
restrict it usage?


Information leaks. User credentials and secure token are potentially
stored in here, as are details specific to the internal operation of the
security algorithm selected/negotiated.
...

The intent of the draft was to separate out what was defined in RFC 2617; thus I agree that we shouldn't relax the use unless there's broad consensus that that would be a good idea.

Best regards, Julian


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Julian Reschke
On 2015-02-02 15:08, Rifaat Shekh-Yusef wrote:
> This document does not define any semantics associated with these
> header, which means that the document that uses these header will be the
> one that must address the information leak issue.
> I do not see why we would restrict a future use of these headers based
> on the Digest usage; this seems odd to me.
>
> Regards,
>   Rifaat

Well, the goal for me was not to define anything new, but just to
extract what we have already into something that can be maintained
separately from DIGEST. As such, Hervé's comment made sense to me, and I
updated the editor's copy accordingly:

 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-auth-info-latest-from-previous.diff.html>

Maybe other potential users of Auth-Info (Yutaka & Alexey) could state
whether having this constraint would affect their ability to use
Authentication-Info?

Assuming that is not the case, I'd like to declare victory, submit a new
draft, and ask Mark to start a WGLC...

Best regards, Julian



Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Julian Reschke
On 2015-02-04 17:46, Julian Reschke wrote:

> On 2015-02-02 15:08, Rifaat Shekh-Yusef wrote:
>> This document does not define any semantics associated with these
>> header, which means that the document that uses these header will be the
>> one that must address the information leak issue.
>> I do not see why we would restrict a future use of these headers based
>> on the Digest usage; this seems odd to me.
>>
>> Regards,
>>   Rifaat
>
> Well, the goal for me was not to define anything new, but just to
> extract what we have already into something that can be maintained
> separately from DIGEST. As such, Hervé's comment made sense to me, and I
> updated the editor's copy accordingly:
>
>
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-auth-info-latest-from-previous.diff.html>
>
>
> Maybe other potential users of Auth-Info (Yutaka & Alexey) could state
> whether having this constraint would affect their ability to use
> Authentication-Info?
>
> Assuming that is not the case, I'd like to declare victory, submit a new
> draft, and ask Mark to start a WGLC...
>
> Best regards, Julian
> ...

Seeing no additional feedback, I went ahead and submitted draft 01.

Best regards, Julian

Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Alexey Melnikov
On 06/02/2015 10:01, Julian Reschke wrote:

> On 2015-02-04 17:46, Julian Reschke wrote:
>> On 2015-02-02 15:08, Rifaat Shekh-Yusef wrote:
>>> This document does not define any semantics associated with these
>>> header, which means that the document that uses these header will be
>>> the
>>> one that must address the information leak issue.
>>> I do not see why we would restrict a future use of these headers based
>>> on the Digest usage; this seems odd to me.
>>>
>>> Regards,
>>>   Rifaat
>>
>> Well, the goal for me was not to define anything new, but just to
>> extract what we have already into something that can be maintained
>> separately from DIGEST. As such, Hervé's comment made sense to me, and I
>> updated the editor's copy accordingly:
>>
>>
>> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-auth-info-latest-from-previous.diff.html>
>>
>>
>>
>> Maybe other potential users of Auth-Info (Yutaka & Alexey) could state
>> whether having this constraint would affect their ability to use
>> Authentication-Info?
>>
>> Assuming that is not the case, I'd like to declare victory, submit a new
>> draft, and ask Mark to start a WGLC...
>>
>> Best regards, Julian
>> ...
>
> Seeing no additional feedback, I went ahead and submitted draft 01.
I think your definition would work for the SCRAM draft.


Reply | Threaded
Open this post in threaded view
|

Re: Call for adoption: draft-reschke-httpauth-auth-info-00

Yutaka OIWA

I'm fine, too.

--
Yutaka OIWA <[hidden email]> on mobile

2015/02/07 0:47 "Alexey Melnikov" <[hidden email]>:
On 06/02/2015 10:01, Julian Reschke wrote:
On 2015-02-04 17:46, Julian Reschke wrote:
On 2015-02-02 15:08, Rifaat Shekh-Yusef wrote:
This document does not define any semantics associated with these
header, which means that the document that uses these header will be the
one that must address the information leak issue.
I do not see why we would restrict a future use of these headers based
on the Digest usage; this seems odd to me.

Regards,
  Rifaat

Well, the goal for me was not to define anything new, but just to
extract what we have already into something that can be maintained
separately from DIGEST. As such, Hervé's comment made sense to me, and I
updated the editor's copy accordingly:


<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-auth-info-latest-from-previous.diff.html>


Maybe other potential users of Auth-Info (Yutaka & Alexey) could state
whether having this constraint would affect their ability to use
Authentication-Info?

Assuming that is not the case, I'd like to declare victory, submit a new
draft, and ask Mark to start a WGLC...

Best regards, Julian
...

Seeing no additional feedback, I went ahead and submitted draft 01.
I think your definition would work for the SCRAM draft.