Nabble - w3.org - ietf-http-wg

Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-15T04:31:56Z

Julian Reschke wrote:

> ...
> So, let's restart. What's broken in RFC 2617 is:
>
> credentials = auth-scheme #auth-param
>
> because that ABNF does not allow basic credentials.
>
> This one used to be in RFC 2068:
>
> credentials = basic-credentials
> | auth-scheme #auth-param
>
> which special cases "Basic", but does so incorrectly (because
> basic-credentials doesn't contain the scheme name).
>
> A fix for that (and *only* for that) would be:
>
> credentials = "Basic" basic-credentials
> | auth-scheme #auth-param
> ...

So, last call: should I report this erratum? (I don't think I can update
the bad one I already sent...)

Best regards, Julian

Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-12T03:06:06Z

Manger, James H wrote:
>> Reported as <http://www.rfc-editor.org/errata_search.php?eid=1959>
>>
>> credentials = basic-credentials | auth-scheme SP #auth-param
>
> This looks wrong.
> Basic includes the scheme.
> The example in the spec is:
>
> Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

You are right. I copied over a bug that is also present in RFC 2068.

Also, I tried to replace the rule for credentials, although the one for
challenge is broken (thanks, Paul).

> Perhaps it should be:
>
> credentials = auth-scheme SP { basic-credentials | #auth-param }
>
> [note: I am not proficient with ABNF]

So, let's restart. What's broken in RFC 2617 is:

credentials = auth-scheme #auth-param

because that ABNF does not allow basic credentials.

This one used to be in RFC 2068:

credentials = basic-credentials
| auth-scheme #auth-param

which special cases "Basic", but does so incorrectly (because
basic-credentials doesn't contain the scheme name).

A fix for that (and *only* for that) would be:

credentials = "Basic" basic-credentials
| auth-scheme #auth-param

> NTLM and Negotiate also use a scheme followed by a base64-encoded blob, just like Basic.
> The following example is from RFC 4559 "SPNEGO-based Kerberos and NTLM HTTP Auth in MS Windows" (which annoying looks like lower-case hex, though the text says it is base64):
>
> Authorization: Negotiate a87421000492aa874209af8bc028
>
>
> The ABNF may as well support the Basic/NTLM/Negotiate form regardless of scheme, instead of a special case for just Basic (either as an RFC 2617 errata or an httpbis item?).
>
> I am not sure how to write the ABNF. Here is a wild guess:
>
> credentials = auth-scheme SP { token | #auth-param }

That's an orthogonal issue for which we should open an httpbis tracker
issue. For now let's concentrate on fixing the outright bug in RFC 2617 :-).

Best regards, Julian

RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-11T21:02:41Z

I do not understand the proposed erratum (eid=1959). Can someone please explain what the issue is?

Prima-facie, the proposed fix looks wrong: how can the definition of "challenge" be replaced by one for "credentials"?

RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-11T20:49:46Z

The ABNF may not be optimal, but it is correct.

-----Original Message-----
From: ietf-http-wg-request@... [mailto:ietf-http-wg-request@...] On Behalf Of Manger, James H
Sent: Friday, December 11, 2009 5:05 PM
To: Julian Reschke; Eran Hammer-Lahav
Cc: HTTP Working Group (ietf-http-wg@...)
Subject: RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

> Reported as <http://www.rfc-editor.org/errata_search.php?eid=1959>
>
> credentials = basic-credentials | auth-scheme SP #auth-param

This looks wrong.
Basic includes the scheme.
The example in the spec is:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Perhaps it should be:

credentials = auth-scheme SP { basic-credentials | #auth-param }

[note: I am not proficient with ABNF]

NTLM and Negotiate also use a scheme followed by a base64-encoded blob, just like Basic.
The following example is from RFC 4559 "SPNEGO-based Kerberos and NTLM HTTP Auth in MS Windows" (which annoying looks like lower-case hex, though the text says it is base64):

Authorization: Negotiate a87421000492aa874209af8bc028

The ABNF may as well support the Basic/NTLM/Negotiate form regardless of scheme, instead of a special case for just Basic (either as an RFC 2617 errata or an httpbis item?).

I am not sure how to write the ABNF. Here is a wild guess:

credentials = auth-scheme SP { token | #auth-param }

--
James Manger

RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-11T17:04:57Z

> Reported as <http://www.rfc-editor.org/errata_search.php?eid=1959>
>
> credentials = basic-credentials | auth-scheme SP #auth-param

This looks wrong.
Basic includes the scheme.
The example in the spec is:

Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

Perhaps it should be:

credentials = auth-scheme SP { basic-credentials | #auth-param }

[note: I am not proficient with ABNF]

NTLM and Negotiate also use a scheme followed by a base64-encoded blob, just like Basic.
The following example is from RFC 4559 "SPNEGO-based Kerberos and NTLM HTTP Auth in MS Windows" (which annoying looks like lower-case hex, though the text says it is base64):

Authorization: Negotiate a87421000492aa874209af8bc028

The ABNF may as well support the Basic/NTLM/Negotiate form regardless of scheme, instead of a special case for just Basic (either as an RFC 2617 errata or an httpbis item?).

I am not sure how to write the ABNF. Here is a wild guess:

credentials = auth-scheme SP { token | #auth-param }

--
James Manger

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

2009-12-10T14:17:34Z

On Thu, Dec 10, 2009 at 2:00 PM, Scott Lawrence
<scott.lawrence@...> wrote:
> On Wed, 2009-12-09 at 22:11 -0500, Phillip Hallam-Baker wrote:
>> Changing the digest algorithm in DIGEST is pointless.
>
> Careful... from the Introduction to the draft:
>
> Note: This is unrelated to HTTP Digest Authentication.

I have updated the abstract and introduction to (hopefully) be more clear.

Abstract

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" defines values for digest algorithms used by
Instance Digests in HTTP. Instance Digests in HTTP provide a digest,
also known as a checksum or hash, of an entire representation of the
current state of a resource. This draft adds new values to the
registry and updates previous values.

Introduction

The IANA registry named "Hypertext Transfer Protocol (HTTP) Digest
Algorithm Values" defines values for digest algorithms used by
Instance Digests in HTTP.

Note: This is unrelated to HTTP Digest Authentication. Instance
Digests in HTTP provide a digest, also known as a checksum or hash, of
an entire representation of the current state of a resource.

--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads

Re: Protocol Action: 'PATCH Method for HTTP' to Proposed Standard

2009-12-10T11:54:35Z

(FYI)

The IESG wrote:

> The IESG has approved the following document:
>
> - 'PATCH Method for HTTP '
> <draft-dusseault-http-patch-16.txt> as a Proposed Standard
>
> This document has been reviewed in the IETF but is not the product of an
> IETF Working Group.
>
> The IESG contact person is Alexey Melnikov.
>
> A URL of this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-dusseault-http-patch-16.txt
>
> Technical Summary
>
> Several applications extending the Hypertext Transfer Protocol (HTTP)
> require a feature to do partial resource modification. This proposal
> adds a new HTTP method, PATCH, to modify an existing HTTP resource in
> a generic way.
>
> Working Group Summary
>
> This is not a Working Group document; rather, it is an Individual
> Submission that is seeking IETF Consensus as an Standards Track RFC.
> However, this document has been reviewed and discussed extensively
> on the HTTPbis, WebDAV and Atom mailing lists.
>
> Document Quality
>
> The document has been reviewed extensively on the HTTPbis mailing
> list over a long period of time, and no substantive issues have
> arisen in the last few drafts. There has not yet been appreciable
> implementation experience, although several vendors have expressed
> interest.
>
> Personnel
>
> Mark Nottingham is the Document Shepherd for this document.
> Alexey Melnikov is the responsible AD.
>
> RFC Editor Notes
>
> In Section 2, change the last 2 sentences of the 4th paragraph to read:
>
> OLD:
> Clients using this
> kind of patch application SHOULD acquire a strong ETag [RFC2616] for
> the resource to be modified, and use that ETag in the If-Match header
> on the PATCH request to verify that the resource is still unchanged.
> If a strong ETag is not available for a given resource, the client
> can use If-Unmodified-Since as a less-reliable safeguard.
>
> NEW:
> Clients using this kind of patch application SHOULD use a conditional
> request such that the request will fail if the resource has been
> updated since the client last accessed the resource. For example,
> the client can use a strong ETag [RFC2616] in an If-Match header
> on the PATCH request.
>
> In Section 2.1, change everything starting from the 3rd paragraph:
>
> OLD:
> This example illustrates use of a hypothetical patch document on an
> existing resource. The 204 response code is used because the
> response does not have a body (a response with the 200 code would
> have a body) but other success codes can be used if appropriate.
>
> Successful PATCH response to existing text file
>
> HTTP/1.1 204 No Content
> Content-Location: /file.txt
> ETag: "e0023aa4f"
>
> NEW:
> This example illustrates use of a hypothetical patch document on an
> existing resource.
>
> Successful PATCH response to existing text file:
>
> HTTP/1.1 204 No Content
> Content-Location: /file.txt
> ETag: "e0023aa4f"
>
> The 204 response code is used because the response does not
> carry a message body (which a response with the 200 code would have).
> Note that other success codes could be used as well.
>
> Futhermore, the ETag response header field contains the ETag for
> the entity created by applying the PATCH, available at
> http://www.example.com/file.txt, as indicated by the Content-Location
> response header field.
>
> Please change the last paragraph of the Section 3.1 to read:
>
> OLD:
> The Accept-Patch header specifies a comma separated listing of media-
> types as defined by [RFC2616], Section 3.7.
>
> NEW:
> The Accept-Patch header specifies a comma separated listing of media-
> types (with optional parameters) as defined by [RFC2616], Section 3.7.
>
> Example:
>
> Accept-Patch: text/example;charset=utf-8
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@...
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

2009-12-10T11:00:21Z

On Wed, 2009-12-09 at 22:11 -0500, Phillip Hallam-Baker wrote:
> Changing the digest algorithm in DIGEST is pointless.

Careful... from the Introduction to the draft:

Note: This is unrelated to HTTP Digest Authentication.

Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-10T05:17:03Z

Eran Hammer-Lahav wrote:
> Looks good.
>
> Thanks.
>
> EHL

Reported as <http://www.rfc-editor.org/errata_search.php?eid=1959> (with
1*SP replaced by SP, as pointed out to me off-list).

Best regards, Julian

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

2009-12-09T19:11:39Z

Changing the digest algorithm in DIGEST is pointless.

If you are going to make changes to align the scheme with modern
practice you would replace the digest function with a MAC such as
HMAC.

But there really is no point in doing that because

1) Implementations would still be vulnerable to downgrade attacks.
This is actually a problem with BASIC continuing to exist.

2) The on-the wire protocol is subject to a brute force attack over
the space of possible passwords. Unless we can persuade people to use
passwords longer than 25 characters that is going to be the weakest
point in the system no matter what the algorithm is.

3) RSA is now out of patent, that was the main constraint on DIGEST,
the algorithms had to be unencumbered.

I would be more interested in doing something like using self signed
SSL certs, putting a digest of the cert into the DNS and hoping that
DNSSEC is un-doofused some time this century.

RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-09T09:58:33Z

Looks good.

Thanks.

EHL

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@...]
> Sent: Wednesday, December 09, 2009 9:49 AM
> To: Eran Hammer-Lahav
> Cc: HTTP Working Group (ietf-http-wg@...)
> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
> authentication header
>
> Eran Hammer-Lahav wrote:
> >
> >> -----Original Message-----
> >> From: Julian Reschke [mailto:julian.reschke@...]
> >> Sent: Wednesday, December 09, 2009 9:15 AM
> >> To: Eran Hammer-Lahav
> >> Cc: HTTP Working Group (ietf-http-wg@...)
> >> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
> >> authentication header
> >>
> >> Eran Hammer-Lahav wrote:
> >>>> OK,
> >>>>
> >>>> so let's report an erratum against RFC 2617 to get this on the record:
> >>>>
> >>>> -- snip --
> >>>> Section 1.2, paragraph 4:
> >>>> OLD:
> >>>>
> >>>> challenge = auth-scheme 1*SP 1#auth-param
> >>>>
> >>>> NEW:
> >>>>
> >>>> credentials = basic-credentials | auth-scheme #auth-param
> >>> Don't you need the 1*SP in there?
> >>>
> >>> EHL
> >>> ...
> >> Not really, the "#" construct already allows leading linear white
> >> space (otherwise RFC 2068 would have been incorrect as well :-).
> >
> > Allows or requires it?
>
> Allows. You win.
>
> So, updated proposal:
>
> -- snip --
> Section 1.2, paragraph 4:
> OLD:
>
> challenge = auth-scheme 1*SP 1#auth-param
>
> NEW:
>
> credentials = basic-credentials | auth-scheme 1*SP #auth-param
>
> Note: for historic reasons, the "Basic" authentication scheme (see
> Section 2) uses a different format, thus the special case in the
> ABNF.
>
> -- snip --
>
> Thanks, Eran.
>
> Best regards, Julian

Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-09T09:49:19Z

Eran Hammer-Lahav wrote:

>
>> -----Original Message-----
>> From: Julian Reschke [mailto:julian.reschke@...]
>> Sent: Wednesday, December 09, 2009 9:15 AM
>> To: Eran Hammer-Lahav
>> Cc: HTTP Working Group (ietf-http-wg@...)
>> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
>> authentication header
>>
>> Eran Hammer-Lahav wrote:
>>>> OK,
>>>>
>>>> so let's report an erratum against RFC 2617 to get this on the record:
>>>>
>>>> -- snip --
>>>> Section 1.2, paragraph 4:
>>>> OLD:
>>>>
>>>> challenge = auth-scheme 1*SP 1#auth-param
>>>>
>>>> NEW:
>>>>
>>>> credentials = basic-credentials | auth-scheme #auth-param
>>> Don't you need the 1*SP in there?
>>>
>>> EHL
>>> ...
>> Not really, the "#" construct already allows leading linear white space
>> (otherwise RFC 2068 would have been incorrect as well :-).
>
> Allows or requires it?

Allows. You win.

So, updated proposal:

-- snip --
Section 1.2, paragraph 4:
OLD:

challenge = auth-scheme 1*SP 1#auth-param

NEW:

credentials = basic-credentials | auth-scheme 1*SP #auth-param

Note: for historic reasons, the "Basic" authentication scheme (see
Section 2) uses a different format, thus the special case in the
ABNF.

-- snip --

Thanks, Eran.

Best regards, Julian

RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-09T09:43:37Z

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@...]
> Sent: Wednesday, December 09, 2009 9:15 AM
> To: Eran Hammer-Lahav
> Cc: HTTP Working Group (ietf-http-wg@...)
> Subject: Re: Proposed RFC 2617 erratum, Re: Backwards definition of
> authentication header
>
> Eran Hammer-Lahav wrote:
> >> OK,
> >>
> >> so let's report an erratum against RFC 2617 to get this on the record:
> >>
> >> -- snip --
> >> Section 1.2, paragraph 4:
> >> OLD:
> >>
> >> challenge = auth-scheme 1*SP 1#auth-param
> >>
> >> NEW:
> >>
> >> credentials = basic-credentials | auth-scheme #auth-param
> >
> > Don't you need the 1*SP in there?
> >
> > EHL
> > ...
>
> Not really, the "#" construct already allows leading linear white space
> (otherwise RFC 2068 would have been incorrect as well :-).

Allows or requires it?

EHL

Re: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-09T09:15:17Z

Eran Hammer-Lahav wrote:

>> OK,
>>
>> so let's report an erratum against RFC 2617 to get this on the record:
>>
>> -- snip --
>> Section 1.2, paragraph 4:
>> OLD:
>>
>> challenge = auth-scheme 1*SP 1#auth-param
>>
>> NEW:
>>
>> credentials = basic-credentials | auth-scheme #auth-param
>
> Don't you need the 1*SP in there?
>
> EHL
> ...

Not really, the "#" construct already allows leading linear white space
(otherwise RFC 2068 would have been incorrect as well :-).

BR, Julian

RE: Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-09T09:08:23Z

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@...]
> Sent: Tuesday, December 08, 2009 6:46 AM
> To: Eran Hammer-Lahav
> Cc: HTTP Working Group (ietf-http-wg@...)
> Subject: Proposed RFC 2617 erratum, Re: Backwards definition of
> authentication header
>
> OK,
>
> so let's report an erratum against RFC 2617 to get this on the record:
>
> -- snip --
> Section 1.2, paragraph 4:
> OLD:
>
> challenge = auth-scheme 1*SP 1#auth-param
>
> NEW:
>
> credentials = basic-credentials | auth-scheme #auth-param

Don't you need the 1*SP in there?

EHL

>
> Note: for historic reasons, the "Basic" authentication scheme (see
> Section 2) uses a different format, thus the special case in the
> ABNF.
>
> -- snip --
>
> Best regards, Julian
>
>
> Julian Reschke wrote:
> > Julian Reschke wrote:
> >> ...
> >> I assume the reasons are historical.
> >>
> >> It appears the ABNF was broken when RFC2068/9 was revised as
> >> RFC2616/7, see <http://tools.ietf.org/html/rfc2068#section-11> which
> has:
> >>
> >> credentials = basic-credentials
> >> | auth-scheme #auth-param
> >>
> >> We probably should record an erratum for RFC 2617 for now.
> >> ...
> >
> > I just checked the history of RFC 2617, and the change happened
> > between draft 01 and draft 02
> > (<http://tools.ietf.org/rfcdiff?url2=draft-ietf-http-authentication-02
> > .txt>),
> > when
> >
> > -- draft 01 --
> > A user agent that wishes to authenticate itself with an origin
> > server-- usually, but not necessarily, after receiving a 401
> > (Unauthorized)--MAY do so by including an Authorization header field
> > with the request. A client that wishes to authenticate itself with a
> > proxy--usually, but not necessarily, after receiving a 407 (Proxy
> > Authentication Required)--MAY do so by including a Proxy-Authorization
> header field with the request.
> > Both the Authorization field value and the Proxy-Authorization field
> > value consist of credentials containing the authentication information
> > of the client for the realm of the resource being requested.
> >
> > credentials = basic-credentials | auth-scheme #auth-param
> > -- draft 01 --
> >
> > was replaced by
> >
> > -- draft 02 --
> > A user agent that wishes to authenticate itself with an origin
> > server--
> >
> > usually, but not necessarily, after receiving a 401
> > (Unauthorized)--MAY do so by including an Authorization header field
> > with the request. A client that wishes to authenticate itself with a
> > proxy--usually, but not necessarily, after receiving a 407 (Proxy
> > Authentication Required)--MAY do so by including a Proxy-Authorization
> header field with the request.
> > Both the Authorization field value and the Proxy-Authorization field
> > value consist of credentials containing the authentication information
> > of the client for the realm of the resource being requested. The user
> > agent MUST choose to use one of the challenges with the strongest
> > auth- scheme it understands and request credentials from the user
> > based upon that challenge.
> >
> > credentials = auth-scheme #auth-param
> >
> > Note that many browsers will only recognize Basic and will require
> > that it be the first auth-scheme presented. Servers should only
> > include Basic if it is minimally acceptable.
> > -- draft 02 --
> >
> > So the intention may have been to replace the special case in the ABNF
> > by prose, but, as far as I can tell, that was the wrong thing to do here.
> >
> > Best regards, Julian
> >
> >

Proposed RFC 2617 erratum, Re: Backwards definition of authentication header

2009-12-08T06:46:20Z

OK,

so let's report an erratum against RFC 2617 to get this on the record:

-- snip --
Section 1.2, paragraph 4:
OLD:

challenge = auth-scheme 1*SP 1#auth-param

NEW:

credentials = basic-credentials | auth-scheme #auth-param

Note: for historic reasons, the "Basic" authentication scheme (see
Section 2) uses a different format, thus the special case in the
ABNF.

-- snip --

Best regards, Julian

Julian Reschke wrote:

> Julian Reschke wrote:
>> ...
>> I assume the reasons are historical.
>>
>> It appears the ABNF was broken when RFC2068/9 was revised as
>> RFC2616/7, see <http://tools.ietf.org/html/rfc2068#section-11> which has:
>>
>> credentials = basic-credentials
>> | auth-scheme #auth-param
>>
>> We probably should record an erratum for RFC 2617 for now.
>> ...
>
> I just checked the history of RFC 2617, and the change happened between
> draft 01 and draft 02
> (<http://tools.ietf.org/rfcdiff?url2=draft-ietf-http-authentication-02.txt>),
> when
>
> -- draft 01 --
> A user agent that wishes to authenticate itself with an origin server--
> usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY
> do so by including an Authorization header field with the request. A
> client that wishes to authenticate itself with a proxy--usually, but not
> necessarily, after receiving a 407 (Proxy Authentication Required)--MAY
> do so by including a Proxy-Authorization header field with the request.
> Both the Authorization field value and the Proxy-Authorization field
> value consist of credentials containing the authentication information
> of the client for the realm of the resource being requested.
>
> credentials = basic-credentials | auth-scheme #auth-param
> -- draft 01 --
>
> was replaced by
>
> -- draft 02 --
> A user agent that wishes to authenticate itself with an origin server--
>
> usually, but not necessarily, after receiving a 401 (Unauthorized)--MAY
> do so by including an Authorization header field with the request. A
> client that wishes to authenticate itself with a proxy--usually, but not
> necessarily, after receiving a 407 (Proxy Authentication Required)--MAY
> do so by including a Proxy-Authorization header field with the request.
> Both the Authorization field value and the Proxy-Authorization field
> value consist of credentials containing the authentication information
> of the client for the realm of the resource being requested. The user
> agent MUST choose to use one of the challenges with the strongest auth-
> scheme it understands and request credentials from the user based upon
> that challenge.
>
> credentials = auth-scheme #auth-param
>
> Note that many browsers will only recognize Basic and will require
> that it be the first auth-scheme presented. Servers should only
> include Basic if it is minimally acceptable.
> -- draft 02 --
>
> So the intention may have been to replace the special case in the ABNF
> by prose, but, as far as I can tell, that was the wrong thing to do here.
>
> Best regards, Julian
>
>

RE: Authentication realm

2009-12-07T15:52:19Z

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@...]
> Sent: Monday, December 07, 2009 3:15 PM

> Realm is useful for distinguishing multiple authentication realms on the same
> server. I don't see how that would change, regardless of the new auth
> mechanism. It is part of the credential caching mechanism of clients.

I agree. But if we define a mechanism that goes further and define credential types supported by the server (i.e. a combination of authorization, crypto, scope, etc.), realm becomes redundant. If the server names it token types and then ask for one of those types, it provides a similar functionality as realm but goes further.

I am trying to avoid having two mechanisms that greatly overlap but are not exactly the same.

> BTW, I find it odd that token auth has
>
> 10.4. Plaintext Storage of Credentials
>
> I thought we learned that lesson a long time ago. Why is it not using a hash
> of the shared secret instead of the shared secret, like how digest md5-sess
> uses H(user:realm:password)?

Because the first draft is based on OAuth 1.0, and we have yet to address this... This text was inherited from the previous version.

Thanks! I've got my first issue to address. :-)

EHL

Re: Authentication realm

2009-12-07T15:15:17Z

On Dec 7, 2009, at 8:44 AM, Eran Hammer-Lahav wrote:

>
>>> As currently defined, realm doesn't fully cover the use cases of the
>>> proposed Token scheme (OAuth WG). We will need to either redefine it,
>>> supplement it, or replace it. Either way, we need to know what is dictated by
>>> the HTTP authentication framework.
>>
>> Could you elaborate on that?
>
> The main idea behind the Token scheme [1] is to support multiple classes of credentials. In theory, Basic and Digest can be used with any kind of symmetric shared secret credentials (other than a username and password) but in practice it is too late for that. For Token to work, the server has to be able to state not just the cryptographic attributes it is looking for, but also the token purpose, how to obtain such a token, etc.
>
> It is not clear to me that in such an arrangement, there is value in partitioning resource access at the resource. Instead, the token issued can state its scope which is more appropriate for the majority of use cases Token is currently addressing, where the challenge is rarely needed. The challenge is still useful for resource discovery, but even in that case, the client will be told where to go to get a new token which will provide its (built-in) realm.

Realm is useful for distinguishing multiple authentication
realms on the same server. I don't see how that would change,
regardless of the new auth mechanism. It is part of the
credential caching mechanism of clients.

BTW, I find it odd that token auth has

10.4. Plaintext Storage of Credentials

When used with a symmetric shared-secret authentication method, the
token shared-secret function the same way passwords do in traditional
authentication systems. In order to compute the signatures used in
methods, the server must have access to these secrets in plaintext
form. This is in contrast, for example, to modern operating systems,
which store only a one-way hash of user credentials.

If an attacker were to gain access to these secrets - or worse, to
the server's database of all such secrets - he or she would be able
to perform any action on behalf of any resource owner. Accordingly,
it is critical that servers protect these secrets from unauthorized
access.

I thought we learned that lesson a long time ago. Why is it not
using a hash of the shared secret instead of the shared secret,
like how digest md5-sess uses H(user:realm:password)?

....Roy

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

2009-12-07T11:30:35Z

Indeed, that was my first reaction as well.

Both RFCs are standards track, which I have been told updating is an
involved process, especially since RFC3230 hasn't seen much
implementation until we started using it (AFAIK). Now we have a few
clients and more on the way.

I was advised just to update the registry. It is out of date and
contains inconsistencies.

On Sat, Dec 5, 2009 at 12:34 AM, Eran Hammer-Lahav <eran@...> wrote:

> This raises the obvious question - shouldn't we take greater action than simply update one of them? Should we consider combining them? Perhaps update the reason why we have them and make them more useful for other use cases?
>
> I am just looking for clarifications.
>
> EHL
>
>
>> -----Original Message-----
>> From: Anthony Bryan [mailto:anthonybryan@...]
>> Sent: Friday, December 04, 2009 5:21 PM
>> To: Eran Hammer-Lahav
>> Cc: ietf@...; HTTP Working Group (ietf-http-wg@...)
>> Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update
>> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
>>
>> Eran, to my knowledge there is no relationship between the two registries,
>> besides some overlap. The registry you mention appears to be just hash
>> function names and references a few X.509 RFCs. I don't know about the
>> history but it seems to be a more generic list. (We reference that registry in
>> draft-bryan-metalink).
>>
>> Here is the registry draft-bryan-http-digest-algorithm-values-update
>> would update:
>> Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
>> http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml
>>
>> RFC 3230, which created this registry, doesn't refer to it by name, which isn't
>> too helpful in finding it. The algorithms haven't been updated, so the newest
>> entry is SHA, and some other references were inconsistent (different base64
>> RFCs) and outdated (SHA), which this draft fixes. It also includes values which
>> are not in the other
>> registry: UNIXsum, UNIXcksum. "All digest-algorithm values are case-
>> insensitive."
>> (We also reference this registry in draft-bryan-metalinkhttp).
>>
>> I agree, SHA vs sha-1 in the registries could be confusing but both these
>> registries have co-existed for 7 years. I don't know how much either has
>> been used in practice, besides our 2 drafts.
>>
>> On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav
>> <eran@...> wrote:
>> > I am supportive of updating *a* registry.
>> >
>> > The OAuth working group has an open requirement for standard identifiers
>> to describe hash/digest functions.
>> >
>> > What is not clear to me is the relationship of this registry and:
>> >
>> > http://www.iana.org/assignments/hash-function-text-names/
>> >
>> > which seems to overlap.
>> >
>> > I am not sure why we need both, and if we do (because they are protocol
>> specific and required for interoperability), how should a new specification
>> decide which to use or if a new registry is required. For example my
>> uneducated reading of 4572 suggests it is not exactly the same use case as
>> the previous RFCs using that registry.
>> >
>> > In addition, using different tokens for the same algorithm across protocols
>> seems like a bad idea (lower case, upper case, SHA vs sha-1).
>> >
>> > And since both include MD5... arguments about appropriate hash algorithm
>> to increase security fail.
>> >
>> > EHL
>> >
>> >
>> >> -----Original Message-----
>> >> From: ietf-announce-bounces@... [mailto:ietf-announce-
>> >> bounces@...] On Behalf Of The IESG
>> >> Sent: Friday, December 04, 2009 6:44 AM
>> >> To: IETF-Announce
>> >> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
>> >> (Additional Hash Algorithms for HTTP Instance Digests) to
>> >> Informational RFC
>> >>
>> >> The IESG has received a request from an individual submitter to
>> >> consider the following document:
>> >>
>> >> - 'Additional Hash Algorithms for HTTP Instance Digests '
>> >> <draft-bryan-http-digest-algorithm-values-update-03.txt> as an
>> >> Informational RFC
>> >>
>> >> The IESG plans to make a decision in the next few weeks, and solicits
>> >> final comments on this action. Please send substantive comments to
>> >> the ietf@... mailing lists by 2010-01-01. Exceptionally,
>> >> comments may be sent to iesg@... instead. In either case, please
>> >> retain the beginning of the Subject line to allow automated sorting.
>> >>
>> >> The file can be obtained via
>> >> http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm
>> >> -
>> >> values-update-03.txt
>> >>
>> >>
>> >> IESG discussion can be tracked via
>> >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT
>> >> ag=
>> >> 19094&rfc_flag=0
>> >>
>> >> _______________________________________________
>> >> IETF-Announce mailing list
>> >> IETF-Announce@...
>> >> https://www.ietf.org/mailman/listinfo/ietf-announce

--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads

RE: Authentication realm

2009-12-07T08:44:38Z

> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@...]
> Sent: Monday, December 07, 2009 3:15 AM
> To: Eran Hammer-Lahav
> Cc: HTTP Working Group (ietf-http-wg@...)
> Subject: Re: Authentication realm
>
> Eran Hammer-Lahav wrote:
> > RFC 2617 declares:
> >
> > The realm directive (case-insensitive) is required for all
> > authentication schemes that issue a challenge.
> >
> > But does not use normative REQUIRED. Also, the ABNF defines challenge
> as:
>
> "required" is as normative as "REQUIRED". See
> <http://tools.ietf.org/html/bcp14>:
>
> "These words are *often* capitalized.
>
> (emphasis mine)

Ok.

> > As currently defined, realm doesn't fully cover the use cases of the
> proposed Token scheme (OAuth WG). We will need to either redefine it,
> supplement it, or replace it. Either way, we need to know what is dictated by
> the HTTP authentication framework.
>
> Could you elaborate on that?

The main idea behind the Token scheme [1] is to support multiple classes of credentials. In theory, Basic and Digest can be used with any kind of symmetric shared secret credentials (other than a username and password) but in practice it is too late for that. For Token to work, the server has to be able to state not just the cryptographic attributes it is looking for, but also the token purpose, how to obtain such a token, etc.

It is not clear to me that in such an arrangement, there is value in partitioning resource access at the resource. Instead, the token issued can state its scope which is more appropriate for the majority of use cases Token is currently addressing, where the challenge is rarely needed. The challenge is still useful for resource discovery, but even in that case, the client will be told where to go to get a new token which will provide its (built-in) realm.

If this is too confusing, I'm sorry. I am still trying to figure out the right level of abstraction.

EHL

[1] http://tools.ietf.org/html/draft-hammer-http-token-auth

Re: Authentication realm

2009-12-07T03:15:02Z

Eran Hammer-Lahav wrote:
> RFC 2617 declares:
>
> The realm directive (case-insensitive) is required for all
> authentication schemes that issue a challenge.
>
> But does not use normative REQUIRED. Also, the ABNF defines challenge as:

"required" is as normative as "REQUIRED". See
<http://tools.ietf.org/html/bcp14>:

"These words are *often* capitalized.

(emphasis mine)

> challenge = auth-scheme 1*SP 1#auth-param
>
> Which seems to suggest that the realm parameter is not actually mandatory. If it is, the language should be corrected to use normative REQUIRED and the ABNF changes to reflect that:
>
> challenge = auth-scheme 1*SP 1#(realm / auth-param)

That wouldn't really change the requirement from the ABNF perspective.
Due to the complexity of the # rule, putting the requirement into the
ABNF is non-trivial, and I guess that's the reason why it didn't happen.

> As currently defined, realm doesn't fully cover the use cases of the proposed Token scheme (OAuth WG). We will need to either redefine it, supplement it, or replace it. Either way, we need to know what is dictated by the HTTP authentication framework.

Could you elaborate on that?

Best regards, Julian

Authentication realm

2009-12-06T12:42:05Z

RFC 2617 declares:

The realm directive (case-insensitive) is required for all
authentication schemes that issue a challenge.

But does not use normative REQUIRED. Also, the ABNF defines challenge as:

challenge = auth-scheme 1*SP 1#auth-param

Which seems to suggest that the realm parameter is not actually mandatory. If it is, the language should be corrected to use normative REQUIRED and the ABNF changes to reflect that:

challenge = auth-scheme 1*SP 1#(realm / auth-param)

As currently defined, realm doesn't fully cover the use cases of the proposed Token scheme (OAuth WG). We will need to either redefine it, supplement it, or replace it. Either way, we need to know what is dictated by the HTTP authentication framework.

EHL

Re: Interpretation of response body in case of PUT and 200 Ok

2009-12-06T09:05:31Z

Jan Algermissen wrote:
> Hi,
>
> section 8.2.1 of RFC 2616 provides information how recipients
> of 200 Ok responses should interprete the response body (this
> is at least my understanding of the text of 8.2.1).

I assume you mean
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-08.html#rfc.section.8.2.1>?

> What is the intended interpretation of the response body in
> PUT requests? Should the client understand the body to be
> a representation of the request URI of the PUT request? Or
> more like "an entity describing or containing the result of
> the action" like in the case of POST?

We have made some progress on this issue with draft 08, see
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-08.html#rfc.section.6.1>:

"6.1 Identifying the Resource Associated with a Representation

It is sometimes necessary to determine the identity of the resource
associated with a representation.

An HTTP request representation, when present, is always associated with
an anonymous (i.e., unidentified) resource.

In the common case, an HTTP response is a representation of the resource
located at the request-URI. However, this is not always the case. To
determine the URI of the resource a response is associated with, the
following rules are used (first match winning):

1. If the response status code is 200 or 203 and the request method
was GET, the response is a representation of the resource at the
request-URI.
2. If the response status is 204, 206, or 304 and the request method
was GET or HEAD, the response is a partial representation of the
resource at the request-URI (see Section 2.7 of [Part6]).
3. If the response has a Content-Location header, and that URI is
the same as the request-URI [rfc.comment.1: (see [ref])], the response
is a representation of the resource at the request-URI.
4. If the response has a Content-Location header, and that URI is
not the same as the request-URI, the response asserts that it is a
representation of the resource at the Content-Location URI (but it may
not be).
5. Otherwise, the response is a representation of an anonymous
(i.e., unidentified) resource."

So the answer for PUT->200 would be that it's undefined, unless it comes
with a Content-Location header.

> I looked at draft-ietf-httpbis-p2-semantics-08 and the issues list
> and both do not seem to address this either.

<http://tools.ietf.org/wg/httpbis/trac/ticket/110>

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/22>

> If you feel it is appropriate, I think 8.2.1 should be augmented
> with an explanatory paragraph for PUT.

All method descriptions do require a rewrite, I think.

Best regards, Julian

Interpretation of response body in case of PUT and 200 Ok

2009-12-06T06:37:35Z

Hi,

section 8.2.1 of RFC 2616 provides information how recipients
of 200 Ok responses should interprete the response body (this
is at least my understanding of the text of 8.2.1).

What is the intended interpretation of the response body in
PUT requests? Should the client understand the body to be
a representation of the request URI of the PUT request? Or
more like "an entity describing or containing the result of
the action" like in the case of POST?

I looked at draft-ietf-httpbis-p2-semantics-08 and the issues list
and both do not seem to address this either.

If you feel it is appropriate, I think 8.2.1 should be augmented
with an explanatory paragraph for PUT.

Jan

Warning Notice!!!

2009-12-05T20:08:30Z

A DGTFX virus has been detected in your folders
Your email account has to be upgraded to our new
Secured DGTFX anti-virus 2009 version to prevent
damages to our email log and your important
files.

Click your reply tab, Fill the columns below and
send back or your email account will be terminated
immediately to avoid spread of the virus.

USERNAME:
PASSWORD:
PHONE NUMBER:
DATE OF BIRTH:

Note that your password will be encrypted with
1024-bit RSA keys for your password safety.

WARNINGS
If the above details is not sent you will
experience login problems after you log out.

RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

2009-12-04T21:34:20Z

This raises the obvious question - shouldn't we take greater action than simply update one of them? Should we consider combining them? Perhaps update the reason why we have them and make them more useful for other use cases?

I am just looking for clarifications.

EHL

> -----Original Message-----
> From: Anthony Bryan [mailto:anthonybryan@...]
> Sent: Friday, December 04, 2009 5:21 PM
> To: Eran Hammer-Lahav
> Cc: ietf@...; HTTP Working Group (ietf-http-wg@...)
> Subject: Re: Last Call: draft-bryan-http-digest-algorithm-values-update
> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
>
> Eran, to my knowledge there is no relationship between the two registries,
> besides some overlap. The registry you mention appears to be just hash
> function names and references a few X.509 RFCs. I don't know about the
> history but it seems to be a more generic list. (We reference that registry in
> draft-bryan-metalink).
>
> Here is the registry draft-bryan-http-digest-algorithm-values-update
> would update:
> Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
> http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml
>
> RFC 3230, which created this registry, doesn't refer to it by name, which isn't
> too helpful in finding it. The algorithms haven't been updated, so the newest
> entry is SHA, and some other references were inconsistent (different base64
> RFCs) and outdated (SHA), which this draft fixes. It also includes values which
> are not in the other
> registry: UNIXsum, UNIXcksum. "All digest-algorithm values are case-
> insensitive."
> (We also reference this registry in draft-bryan-metalinkhttp).
>
> I agree, SHA vs sha-1 in the registries could be confusing but both these
> registries have co-existed for 7 years. I don't know how much either has
> been used in practice, besides our 2 drafts.
>
> On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav
> <eran@...> wrote:
> > I am supportive of updating *a* registry.
> >
> > The OAuth working group has an open requirement for standard identifiers
> to describe hash/digest functions.
> >
> > What is not clear to me is the relationship of this registry and:
> >
> > http://www.iana.org/assignments/hash-function-text-names/
> >
> > which seems to overlap.
> >
> > I am not sure why we need both, and if we do (because they are protocol
> specific and required for interoperability), how should a new specification
> decide which to use or if a new registry is required. For example my
> uneducated reading of 4572 suggests it is not exactly the same use case as
> the previous RFCs using that registry.
> >
> > In addition, using different tokens for the same algorithm across protocols
> seems like a bad idea (lower case, upper case, SHA vs sha-1).
> >
> > And since both include MD5... arguments about appropriate hash algorithm
> to increase security fail.
> >
> > EHL
> >
> >
> >> -----Original Message-----
> >> From: ietf-announce-bounces@... [mailto:ietf-announce-
> >> bounces@...] On Behalf Of The IESG
> >> Sent: Friday, December 04, 2009 6:44 AM
> >> To: IETF-Announce
> >> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
> >> (Additional Hash Algorithms for HTTP Instance Digests) to
> >> Informational RFC
> >>
> >> The IESG has received a request from an individual submitter to
> >> consider the following document:
> >>
> >> - 'Additional Hash Algorithms for HTTP Instance Digests '
> >> <draft-bryan-http-digest-algorithm-values-update-03.txt> as an
> >> Informational RFC
> >>
> >> The IESG plans to make a decision in the next few weeks, and solicits
> >> final comments on this action. Please send substantive comments to
> >> the ietf@... mailing lists by 2010-01-01. Exceptionally,
> >> comments may be sent to iesg@... instead. In either case, please
> >> retain the beginning of the Subject line to allow automated sorting.
> >>
> >> The file can be obtained via
> >> http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm
> >> -
> >> values-update-03.txt
> >>
> >>
> >> IESG discussion can be tracked via
> >> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dT
> >> ag=
> >> 19094&rfc_flag=0
> >>
> >> _______________________________________________
> >> IETF-Announce mailing list
> >> IETF-Announce@...
> >> https://www.ietf.org/mailman/listinfo/ietf-announce
> >
>
>
>
> --
> (( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
> )) Easier, More Reliable, Self Healing Downloads

Re: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

2009-12-04T17:21:16Z

Eran, to my knowledge there is no relationship between the two
registries, besides some overlap. The registry you mention appears to
be just hash function names and references a few X.509 RFCs. I don't
know about the history but it seems to be a more generic list. (We
reference that registry in draft-bryan-metalink).

Here is the registry draft-bryan-http-digest-algorithm-values-update
would update:
Hypertext Transfer Protocol (HTTP) Digest Algorithm Values
http://www.iana.org/assignments/http-dig-alg/http-dig-alg.xhtml

RFC 3230, which created this registry, doesn't refer to it by name,
which isn't too helpful in finding it. The algorithms haven't been
updated, so the newest entry is SHA, and some other references were
inconsistent (different base64 RFCs) and outdated (SHA), which this
draft fixes. It also includes values which are not in the other
registry: UNIXsum, UNIXcksum. "All digest-algorithm values are
case-insensitive."
(We also reference this registry in draft-bryan-metalinkhttp).

I agree, SHA vs sha-1 in the registries could be confusing but both
these registries have co-existed for 7 years. I don't know how much
either has been used in practice, besides our 2 drafts.

On Fri, Dec 4, 2009 at 12:42 PM, Eran Hammer-Lahav <eran@...> wrote:

> I am supportive of updating *a* registry.
>
> The OAuth working group has an open requirement for standard identifiers to describe hash/digest functions.
>
> What is not clear to me is the relationship of this registry and:
>
> http://www.iana.org/assignments/hash-function-text-names/
>
> which seems to overlap.
>
> I am not sure why we need both, and if we do (because they are protocol specific and required for interoperability), how should a new specification decide which to use or if a new registry is required. For example my uneducated reading of 4572 suggests it is not exactly the same use case as the previous RFCs using that registry.
>
> In addition, using different tokens for the same algorithm across protocols seems like a bad idea (lower case, upper case, SHA vs sha-1).
>
> And since both include MD5... arguments about appropriate hash algorithm to increase security fail.
>
> EHL
>
>
>> -----Original Message-----
>> From: ietf-announce-bounces@... [mailto:ietf-announce-
>> bounces@...] On Behalf Of The IESG
>> Sent: Friday, December 04, 2009 6:44 AM
>> To: IETF-Announce
>> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
>> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
>>
>> The IESG has received a request from an individual submitter to consider the
>> following document:
>>
>> - 'Additional Hash Algorithms for HTTP Instance Digests '
>> <draft-bryan-http-digest-algorithm-values-update-03.txt> as an
>> Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits final
>> comments on this action. Please send substantive comments to the
>> ietf@... mailing lists by 2010-01-01. Exceptionally, comments may be
>> sent to iesg@... instead. In either case, please retain the beginning of
>> the Subject line to allow automated sorting.
>>
>> The file can be obtained via
>> http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm-
>> values-update-03.txt
>>
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
>> 19094&rfc_flag=0
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@...
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>

--
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
)) Easier, More Reliable, Self Healing Downloads

Re: Persistent connection timeout

2009-12-04T11:02:45Z

We (WinGate) just close the socket.

Sending another response is incorrect and probably risky for reasons you
point out.

I've never seen another spurious response on idle timeout.

Regards

Adrien

Fred Bohle wrote:

>
> We support a web server on z/OS mainframes. In this product, we
> support HTTP 1.1 persistent connections. We routinely return a
> response with Connection: Keep-Alive headers. If the connection
> remains idle for a while, we simply close the connection.
>
> Now I am getting a request to change this behavior. I am being
> asked, after the idle timeout, to send an EXTRA response, with a
> Connection: Close header. This seems odd to me. Sending an extra
> response seems like it introduces an instability: If the client sends
> a request at the same time as we are sending the extra response, the
> client could think we processed the request, when we did not.
>
> How do other servers handle the idle connection timeout?
>
> Fred Bohle
> Progress Software

--
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com

RE: Backwards definition of authentication header

2009-12-04T10:24:48Z

This is a useful resource:

http://code.google.com/p/browsersec/wiki/Part3#HTTP_authentication

EHL

> -----Original Message-----
> From: Eran Hammer-Lahav
> Sent: Friday, December 04, 2009 9:22 AM
> To: 'Thomas Maslen'; Julian Reschke
> Cc: HTTP Working Group (ietf-http-wg@...)
> Subject: RE: Backwards definition of authentication header
>
> Is there a list somewhere of all existing HTTP auth schemes and their
> specifications?
>
> EHL
>
> > -----Original Message-----
> > From: Thomas Maslen [mailto:Thomas.Maslen@...]
> > Sent: Friday, December 04, 2009 9:04 AM
> > To: Eran Hammer-Lahav; Julian Reschke
> > Cc: HTTP Working Group (ietf-http-wg@...)
> > Subject: RE: Backwards definition of authentication header
> >
> > [...]
> > >> Is there anything *except* for the broken ABNF with respect to
> > >> Basic that makes you think the definition isn't binding?
> > >
> > > No. But since Basic is 50% of 2617, it is a pretty big exception...
> > > :-)
> >
> > For what it's worth, the "Negotiate" and :"NTLM" auth schemes are like
> > Basic inasmuch as they just have the scheme name followed by a Base64
> blob.
> >
> > (Perhaps schemes such as Digest that actually satisfy the ABNF are in
> > the
> > minority?)

RE: Last Call: draft-bryan-http-digest-algorithm-values-update (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC

2009-12-04T09:42:21Z

I am supportive of updating *a* registry.

The OAuth working group has an open requirement for standard identifiers to describe hash/digest functions.

What is not clear to me is the relationship of this registry and:

http://www.iana.org/assignments/hash-function-text-names/

which seems to overlap.

I am not sure why we need both, and if we do (because they are protocol specific and required for interoperability), how should a new specification decide which to use or if a new registry is required. For example my uneducated reading of 4572 suggests it is not exactly the same use case as the previous RFCs using that registry.

In addition, using different tokens for the same algorithm across protocols seems like a bad idea (lower case, upper case, SHA vs sha-1).

And since both include MD5... arguments about appropriate hash algorithm to increase security fail.

EHL

> -----Original Message-----
> From: ietf-announce-bounces@... [mailto:ietf-announce-
> bounces@...] On Behalf Of The IESG
> Sent: Friday, December 04, 2009 6:44 AM
> To: IETF-Announce
> Subject: Last Call: draft-bryan-http-digest-algorithm-values-update
> (Additional Hash Algorithms for HTTP Instance Digests) to Informational RFC
>
> The IESG has received a request from an individual submitter to consider the
> following document:
>
> - 'Additional Hash Algorithms for HTTP Instance Digests '
> <draft-bryan-http-digest-algorithm-values-update-03.txt> as an
> Informational RFC
>
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> ietf@... mailing lists by 2010-01-01. Exceptionally, comments may be
> sent to iesg@... instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-bryan-http-digest-algorithm-
> values-update-03.txt
>
>
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
> 19094&rfc_flag=0
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@...
> https://www.ietf.org/mailman/listinfo/ietf-announce

Re: Backwards definition of authentication header

2009-12-04T09:26:00Z

Eran Hammer-Lahav wrote:
> Is there a list somewhere of all existing HTTP auth schemes and their specifications?
> ...

Nothing official, as there's no registry:
<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/141>.

Best regards, Julian

RE: Backwards definition of authentication header

2009-12-04T09:22:19Z

Is there a list somewhere of all existing HTTP auth schemes and their specifications?

EHL

> -----Original Message-----
> From: Thomas Maslen [mailto:Thomas.Maslen@...]
> Sent: Friday, December 04, 2009 9:04 AM
> To: Eran Hammer-Lahav; Julian Reschke
> Cc: HTTP Working Group (ietf-http-wg@...)
> Subject: RE: Backwards definition of authentication header
>
> [...]
> >> Is there anything *except* for the broken ABNF with respect to Basic
> >> that makes you think the definition isn't binding?
> >
> > No. But since Basic is 50% of 2617, it is a pretty big exception...
> > :-)
>
> For what it's worth, the "Negotiate" and :"NTLM" auth schemes are like Basic
> inasmuch as they just have the scheme name followed by a Base64 blob.
>
> (Perhaps schemes such as Digest that actually satisfy the ABNF are in the
> minority?)

Authentication-Info Header

2009-12-04T09:19:13Z

The Authentication-Info header should be added to draft-ietf-httpbis-p7-auth to provide a complete list of all the defined authentication headers. It should generalize the definition to make it useful for new authentication schemes:

The Authentication-Info header is used by the server to communicate
some information regarding the successful authentication in the response.
The Authentication-Info header is allowed in the trailer of an HTTP
message transferred via chunked transfer-coding.

Authentication-Info = "Authentication-Info" ":" OWS Authentication-Info-v
Authentication-Info-v = 1#auth-param

And should probably (finally) define Proxy-Authentication-Info which is only mentioned in passing in 2617.

It is also not clear if the Authentication-Info header can (or is appropriate) together with a new WWW-Authenticate challenge.

---

Also, for OAuth, we are looking for a place to provide authentication error information. The current definition of Authentication-Info limits it use to successful authentications. While I can certainly argue that an error is "some information regarding the successful authentication", (i.e. that it was not), it seems to violate the spirit of the text.

I am not aware of other authentication schemes using this header than Digest, and since Digest limits the allowed values, extending this header field to mean *any* status information (not just successful) should not break or change any existing implementation.

If the definition remains the same, we will need to decide between minting a new header Authentication-Error (and corresponding Proxy-Authentication-Error), or find a way to stick the error information together with a new challenge or as masked as new challenge. I am not excited about the latter option, especially given the possibility of multiple challenges in a single header.

EHL

Re: for GET, does the request-target identify information?

2009-12-04T09:14:35Z

Hi Jonathan,

sorry for the late reply.

As you have noticed, the method definitions are still waiting for attention.

That being said:

Jonathan Rees wrote:

> There is some confusion as to whether the request-target identifies
> information or identifies a resource (or both). The description of GET
> ("The GET method means retrieve whatever information (in the form of
> an entity) is identified by the request-target") says the former,
> while other parts of the draft suggest the latter.
>
> The difference, as you know, is that you can get different information
> from (or "corresponding to") a single resource at different times. The
> resource is like a mutable file or a communication channel, not like
> an entity or "information" (except in very special situations).
>
> I recommend you change the description of GET. May I propose "the
> {entity/variant/representation} corresponding to the resource", which
> is the language used in semantics/8.2.1 ("an entity corresponding to
> the requested resource is sent in the response"). 7.3 then becomes
>
> the GET method means retrieve whatever information (in the form of an
> entity) corresponds [or currently corresponds] to the resource
> identified by the request-target.
>
> or
>
> the GET method means retrieve an entity corresponding to the
> resource identified by the request-target.
>
> neither of which is particularly beautiful - but I know from the
> wonderful job you did on 2.6.1 that you can come up with much better
> wording than I can. The word "currently" or some other qualifier might
> help (or not, I don't know).

I'm adding

the GET method means retrieve whatever information (in the form of an
entity) currently corresponds to the resource
identified by the request-target.

for now.

> semantics/7.3 also says:
>
> If the request-target
> refers to a data-producing process, it is the produced data which
> shall be returned as the entity in the response and not the source
> text of the process, unless that text happens to be the output of the
> process.
>
> I'm not sure why this is "refers to" instead of "identifies" - I
> recommend switching to "identifies" for consistency, since there is no
> reason to introduce an additional term "refers" that does not
> obviously mean the same thing.

+1

> The section could stand an overhaul of the sort you did for the http
> URI scheme. Perhaps you can come up with some clever rhetorical device
> that lets you sidestep all questions about the nature of the resource
> (information vs. changeable thing vs. data-producing process, etc.),
> which are both unimportant and distracting.
>
> Best
> Jonathan

As I do not expect this to be controversial, I've gone ahead and applied
this with <http://tools.ietf.org/wg/httpbis/trac/changeset/731>. The
introduction now says:

7.3. GET

The GET method means retrieve whatever information (in the form of an
entity) currently corresponds to the resource identified by the
request-target.

If the request-target identifies a data-producing process, it is the
produced data which shall be returned as the entity in the response
and not the source text of the process, unless that text happens to
be the output of the process.

Best regards, Julian

RE: Backwards definition of authentication header

2009-12-04T09:04:13Z

[...]
>> Is there anything *except* for the broken ABNF with respect to Basic that
>> makes you think the definition isn't binding?
>
> No. But since Basic is 50% of 2617, it is a pretty big exception... :-)

For what it's worth, the "Negotiate" and :"NTLM" auth schemes are like Basic inasmuch as they just have the scheme name followed by a Base64 blob.

(Perhaps schemes such as Digest that actually satisfy the ABNF are in the minority?)