Subject: [Ietf-http-auth] Google HTTP auth
From: Cyrus Daboo <[email-masked]>
To: HTTP authentication list <[email-masked]>
Date: Fri, 21 Apr 2006 12:58:19 -0400
List-Id: ietf-http-auth.osafoundation.org

Hi,
Just in case anyone has missed this: Google have their own authentication 
scheme they are using for their products, including the newly released 
calendar. Details here:

<http://code.google.com/apis/gdata/calendar.html>

and here:

<http://code.google.com/apis/accounts/AuthForInstalledApps.html>

-- 
Cyrus Daboo

Date: Thu, 13 Apr 2006 09:19:55 -0400
From: "Robert Sayre" <[email-masked]>
To: "Robert Sayre" <[email-masked]>, "HTTP authentication list" <[email-masked]>
Subject: Re: [Ietf-http-auth] Fwd: I-D ACTION:draft-sayre-http-hmac-digest-01.txt

On 4/13/06, Joe Orton <[email-masked]> wrote:
>
> If the point of this is to allow use of Digest with a different hashing
> algorithm then why create a whole new auth scheme?  Why not just define
> a new set of algorithm definitions which use the 2617 Digest scheme?

Thanks for the feedback. One of the goals of the draft is to remove
quality-of-protection options, since many parts of Digest are too
unevenly-implemented to rely on. For example, the scheme in this draft
requires a client nonce, something the Digest scheme requires only for
qop=3D"auth" (which some implementations get right) and qop=3D"auth-int"
(which very few implementations even make an effort to support).

> That would be much simpler.

Disagree. The Digest scheme doesn't seem very simple to implement at
all, and one of the use cases I want to address with this draft is
unencrypted, non-browser HTTP traffic. This scheme is simple enough to
implement from the application level. Judging from the Digest
implementations I have studied, I think there's enough baggage after
ten years or so to make integration with existing Digest code somewhat
difficult.

>
> The hashing of header values is I think fundamentally flawed.  Proxies
> may fold, unfold and combine header values as they see fit.  It might be
> feasible to define some canonical form for header values which both
> client and server would map to.

OK. Another strategy might be to recommend a list of headers that are
unlikely to encounter such treatment. Could you point to an example of
such a proxy? I don't doubt you, but it would be useful to observe
this behavior.

--

Robert Sayre

Date: Thu, 13 Apr 2006 11:12:36 +0100
From: Joe Orton <[email-masked]>
To: Robert Sayre <[email-masked]>
Subject: Re: [Ietf-http-auth] Fwd: I-D ACTION:draft-sayre-http-hmac-digest-01.txt
Mail-Followup-To: Robert Sayre <[email-masked]>, HTTP authentication list <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

On Tue, Apr 11, 2006 at 12:08:42PM -0400, Robert Sayre wrote:
> Hi folks,
> 
> I've already started working on addressing some of Yngve's concerns. I
> got some off-list mail that concurred with his suggestions about
> Proxy-Authentication and formulas. I think it would be nice to hear
> some more perspectives on Authentication-Info, hashing algorithms,
> internationalization, and the extent of message integrity the scheme
> should provide.

If the point of this is to allow use of Digest with a different hashing 
algorithm then why create a whole new auth scheme?  Why not just define 
a new set of algorithm definitions which use the 2617 Digest scheme?  
That would be much simpler.

The hashing of header values is I think fundamentally flawed.  Proxies 
may fold, unfold and combine header values as they see fit.  It might be 
feasible to define some canonical form for header values which both 
client and server would map to.

joe

Date: Tue, 11 Apr 2006 12:08:42 -0400
From: "Robert Sayre" <[email-masked]>
To: "HTTP authentication list" <[email-masked]>
Subject: [Ietf-http-auth] Fwd: I-D ACTION:draft-sayre-http-hmac-digest-01.txt

Hi folks,

I've already started working on addressing some of Yngve's concerns. I
got some off-list mail that concurred with his suggestions about
Proxy-Authentication and formulas. I think it would be nice to hear
some more perspectives on Authentication-Info, hashing algorithms,
internationalization, and the extent of message integrity the scheme
should provide.

As a data point, Amazon happened to deploy a similar authentication
scheme for their S3 service:

<http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html>

Change Log:

01:
    Add server nonce, remove client timestamp.
    Specify header handling more extensively.
    Add RFC2119 terms for header handling.
    Demo client excludes hop-by-hop headers.

---------- Forwarded message ----------
From: [email-masked] <[email-masked]>
Date: Apr 10, 2006 6:50 PM
Subject: I-D ACTION:draft-sayre-http-hmac-digest-01.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.

        Title           : HMAC Digest Access Authentication for HTTP
        Author(s)       : A. Melnikov, R. Sayre
        Filename        : draft-sayre-http-hmac-digest-01.txt
        Pages           : 15
        Date            : 2006-4-10

This document specifies an HTTP authentication scheme based on
   cryptographic hashes.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-sayre-http-hmac-digest-01.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the usernam=
e
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
        "get draft-sayre-http-hmac-digest-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
        [email-masked].
In the body type:
        "FILE /internet-drafts/draft-sayre-http-hmac-digest-01.txt".

NOTE:   The mail server at ietf.org can return the document in
        MIME-encoded form by using the "mpack" utility.  To use this
        feature, insert the command "ENCODING mime" before the "FILE"
        command.  To decode the response(s), you will need "munpack" or
        a MIME-compliant mail reader.  Different MIME-compliant mail reader=
s
        exhibit different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have been split
        up into multiple messages), so check your local documentation on
        how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

--

Robert Sayre

"I would have written a shorter letter, but I did not have the time."

Date: Fri, 07 Apr 2006 21:02:08 +0200
From: "Yngve Nysaeter Pettersen" <[email-masked]>
To: "Robert Sayre" <[email-masked]>
Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news
Organization: Opera Software
Cc: HTTP authentication list <[email-masked]>
Reply-To: [email-masked]

On Fri, 07 Apr 2006 19:28:45 +0200, Robert Sayre <[email-masked]> wrote:

> On 4/7/06, Yngve N. Pettersen <[email-masked]> wrote:
>>
>> I'd like to comment on a few things about this draft. Some of the  
>> concerns
>> I have are unfortunately a bit serious, others are less serious.
>
> Hi Yngvie,
>
> Thanks for the detailed comments. I believe some of your concerns have
> been addressed in the -01 revision of the document. Alexey Melnikov
> has agreed to write the SASL aspects of the document, and he also
> brought up many of the same issues you have. The document should appear
> in the I-D directory soon. For now, I have HTML and diffs:
>
> <http://franklinmint.fm/2006/04/07/draft-sayre-http-hmac-digest-01.html>
> <http://franklinmint.fm/2006/03/26/draft-sayre-http-hmac-digest-01-from-00.html>

Thanks for the URLs

>> First off, while I find the "reason" attribute concept interesting, in
>> particular in light of what was presented in an unrelated WG meeting in
>> Dallas, I am not so sure it will be useful in this case. Unless I am
>> mistaken, there is no way to differentiate between unauthorized (wrong
>> username/password) and (header)integrity as the reason for failure based
>> on the hashvalue, and deciding unauthorized based just on the username
>> would open up for an attacker to generate a list of accepted login-IDs  
>> at
>> a server.
>>
>> Suggestion: Remove this item.
>
> The intent here was to allow server to indicate that they recieved a  
> message
> with headers that weren't included in the digest, but need to be in  
> order to
> successfully process the request. I will try to make this clearer.

Do you mean that the integrity reason should be sent if the server expects  
headers A, B, C, and D to be included in the hash, but the client only  
sends an authentication including A, B, and D, although it sends header C  
as well? Or if the client specifies headers A, B, and C, but only header A  
and C arrives?

The second case is OK, although one might suggest that the HTML page in  
the response gives a description of what the problem was. The problem  
might be caused by a gateway or filter.

The first case (which is how I understand the -01 draft) raises the  
question: How is the client supposed to correct its mistake? The only way  
that would be possible would be if the servers sends a minimum required  
list of headers in the challenge, because otherwise clients would have to  
make a hardcoded list of headers they think are useful to include, and the  
problem would have to be fixed by releasing an updated version of the  
application.

>>   - Does this specification really need to have one HMAC algorithm
>> specification and one password algorithm specification? Why not just
>> specify the algorithm that is being used as part of the HMAC and also  
>> use
>> that for the password hash?
>
> Yes, pw-algorithm is necessary for the scheme to work with existing
> authentication databases. Things like the popular Wordpress PHP
> blogging software store passwords as unsalted MD5 hashes. One of the
> goals of this document is to be easy to deploy in those types of
> environments.

Using two different algorithms adds (IMO unnecessary) complexity to the  
system.

I think that the security aspects of using two different algorithms should  
be carefully considered.

>>   - RFC 2617 (Digest) also specified the Authentication-Info response
>> header that lets the server provide additional state information to the
>> client, as well as reverse authentication and protection of the response
>> entity content. AFAICT this new method does not have anything similar.  
>> Why
>> not?
>
> I did not find it widely implemented. I also expect that protecting  
> response
> content will have much more complicated interactions with HTTP  
> intermediaries.

Opera supports this header, as well as protection of response content.

>>   - Several other features of Digest Authentication, such as  
>> server-nonces,
>> stale nonces and the qop method, has been removed as well, but there is  
>> no
>> discussion about why these are excluded. AFAIK the server-nonces in RFC
>> 2617 is used to prevent certain types of attacks. Is the salt value able
>> to provide the same kind of protection?
>
> Server nonces are back in draft-01.

Good to see

>> The less serious concerns:
>>
>>   - How are new digest algorithms going to be added?
>>
>> Suggestion: Add IANA considerations entry for how new algorithms should  
>> be
>> added.
>
> I would rather let the first person who needs to add a scheme set up
> the IANA details.
>
>>
>>   - How are older clients going to be able to authenticate to a server  
>> that
>> supports the newer method?
>
> I don't see an economical way to help them with that. If there are new
> algorithm tokens, they'll have to be updated.
>
>> Suggestion: This probably requires multiple WWW-Authorization headers  
>> with
>> separate algorithms, unless the syntax is changed to permit multiple
>> algorithms.
>
> I'd rather leave this unsaid. It opens up downgrade attacks, which
> makes me uncomfortable. I don't feel strongly about this issue,
> though.

Backward compatibility (for future versions) and forward compatibility  
(for older clients) must be considered now. If it is not considered now,  
we could see serious trouble when we do need to upgrade the system.

Case in point: Even though SSL/TLS have (IMO) described forward  
compatibility well, and backward compatibility has been described (that  
point may IMO have a couple of problems), I have observed *serious*  
trouble with non-compliant implementations all the way back to the SSL v3  
to TLS 1.0 transition, right up to the current transition to TLS 1.1. In  
fact, we've had to disable at least the version rollback security feature  
in the protocol in order to be able to use the newer versions of the  
protocol!

If methods for secure backward and forward compatibility are not defined  
now, I expect that we will see similar problems down the road when new  
methods are added.

Therefore, this specification need to both consider how to add new  
methods, and how newer servers can interact with older clients.

Yes, downgrade attacks could be a problem. Can anything be done to secure  
a sequence of challenges, or a multialgorithm challenge?

>>   - I think that it would be best to specify a canonalization of the
>> headers used in the digest to avoid problems if a gateway edits, breaks
>> up, or concatenates headers. Are CRLFs included? Background: At least  
>> one
>> of the HTTP stacks Opera works with on mobile devices is concatenating
>> multiple headers into one (as is allowed by RFC 2616), and that created
>> some problems for the cookie handling.
>
> Agree. There is new text in draft-01 on this subject. Does it address
> your concerns?

Not quite. You need to specify how headers of the same name is  
concatenated.

What if the client sends

    A: X
    B: Y
    A: Z

and it arrives as

    A: X, Z
    B: Y

or

    A: X, <more whitespace> Z
    B: Y

?

This conversion (at least the first, I am not sure about the second) is  
permitted by RFC 2616.

At the very least you need to define how headers are separated during the  
hash, and how to handle internal, non-quoted, whitespace (including the  
linewrapping method that is also permitted)

>>
>> - What about Proxy Authentication?
>
> I could add text on this. Does anyone see this document being used by
> proxies?

Opera's code only differentiate between proxy and origin-server when it  
comes to methods in very rare cases. You should expect it to be used for  
proxies.

>> - What about integrity of entity bodies? RFC 2617 have functionality for
>> this.
>
> Yes, and I found almost no implementations that used it. For example,
> Mozilla and the Python standard library both contain "TODO" comments
> in their source code. Digest has been around quite a while, and if people
> haven't implemented a feature, that says something. Also, HMAC Digest  
> allows
> implementations to sign headers, so Content-* can be included.

Opera supports RFC 2617 content-protection, but it is quite correct that I  
have not seen any deployment of response content protection, although I do  
know that Apache has a partial implemention which, the last time I checked  
(a couple of years ago) only worked if the server sent an empty response.

>> May I also suggest that the description of the calulations uses the same
>> form as in RFC 2617? Presenting the calculations in formulas will make  
>> it
>> easier to search for errors in the implementation.
>
> Hmm. I found those really confusing, but I guess I could add something
> similar.

I really prefer having formulas as a reference. Several times I've seen  
textual presentation of calculations, in particular cryptographic  
operations, become difficult to understand.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer		             Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Content-class: urn:content-classes:message
Subject: RE: [Ietf-http-auth] HMAC Digest draft and implementation news
Date: Fri, 7 Apr 2006 10:36:54 -0700
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Scott Lawrence" <[email-masked]>, "Leif Johansson" <[email-masked]>
Cc: HTTP authentication list <[email-masked]>

This is a multi-part message in MIME format.

------=_NextPart_000_0032_01C65A48.55B1F930
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

At the W3C workshop on mutual authentication the Google people showed some
statistics on password use that show that 80% of people choose passwords
within a list of 1 million.

Since walking the namespace is a much more practical attack than attacking
the MD5 MAC construction I don't see much value in that approach.

If people want to continue using lightweight passwords securely without also
using SSL I think we need to introduce a public key exchange in addition.

For example:

Challenge = nonce + public_key

Response = E (HMAC (nonce + cnonce [+ content], password), public_key),
cnonce, nonce

I do not see much value in simply replacing PHBMAC-MD5 with HMAC-SHA1. If
you look at the data sizes you will find that there is no real significant
difference between the PHBMAC and HMAC construction here. 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf 
> Of Scott Lawrence
> Sent: Friday, April 07, 2006 10:25 AM
> To: Leif Johansson
> Cc: HTTP authentication list
> Subject: Re: [Ietf-http-auth] HMAC Digest draft and 
> implementation news
> 
> On Fri, 2006-04-07 at 16:01 +0200, Leif Johansson wrote:
> 
> > > Suggestion: Drop MD5 support, and preferably also SHA-1, and go 
> > > direct for SHA-256.
> 
> For practical purposes, we'll be supporting MD5 for a long 
> time.  Even if there are attacks on it found that do 
> compromise it, it is widely deployed in embedded systems that 
> can't easily be updated, so browsers will likely continue to 
> support it for a long time (just as they still support SSLv2 
> despite its problems).
> 
> > The issue is one of algorithm agility which must be 
> supported. It must 
> > be easy to introduce new hashes wo publishing and implementing new 
> > versions of the standard. This probably means negotiation 
> in some form.
> 
> The current spec is pretty agile in this respect.  There is 
> an explicit token for the supported hash method in the 
> WWW-Authenticate challenge.
> Multiple algorithms can already be supported by including 
> multiple challenges in the 40[17] response.  All that would 
> be needed is the definition of new tokens specifying a new 
> hash algorithm.
> 
> --
> Scott Lawrence  tel:+1-781-938-5306;ext=162 or 
> sip:[email-masked]
>   sipXpbx project coordinator - SIPfoundry    
> http://www.sipfoundry.org/sipX
>   Chief Architect             - Pingtel Corp. http://www.pingtel.com/
> 
> 
> _______________________________________________
> Ietf-http-auth mailing list
> [email-masked]
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/ietf-http-auth
> 
> 

------=_NextPart_000_0032_01C65A48.55B1F930
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

------=_NextPart_000_0032_01C65A48.55B1F930--

Date: Fri, 7 Apr 2006 13:28:45 -0400
From: "Robert Sayre" <[email-masked]>
To: "Yngve N. Pettersen" <[email-masked]>
Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news
Cc: HTTP authentication list <[email-masked]>

On 4/7/06, Yngve N. Pettersen <[email-masked]> wrote:
>
> I'd like to comment on a few things about this draft. Some of the concern=
s
> I have are unfortunately a bit serious, others are less serious.

Hi Yngvie,

Thanks for the detailed comments. I believe some of your concerns have
been addressed in the -01 revision of the document. Alexey Melnikov
has agreed to write the SASL aspects of the document, and he also
brought up many of the same issues you have. The document should appear
in the I-D directory soon. For now, I have HTML and diffs:

<http://franklinmint.fm/2006/04/07/draft-sayre-http-hmac-digest-01.html>
<http://franklinmint.fm/2006/03/26/draft-sayre-http-hmac-digest-01-from-00.=
html>

Please keep in mind that the document is not intended to replace HTTP
Digest, but design a new scheme with a subset of features that will
hopefully be easier to deploy. Many features and options have been
omitted because implementors generally don't bother to write the code
for them. It's possible that I have cut too much. IMHO, Digest
provides *way* too many options. I've tried to keep the code paths to
a minimum in HMAC Digest.

>
> First off, while I find the "reason" attribute concept interesting, in
> particular in light of what was presented in an unrelated WG meeting in
> Dallas, I am not so sure it will be useful in this case. Unless I am
> mistaken, there is no way to differentiate between unauthorized (wrong
> username/password) and (header)integrity as the reason for failure based
> on the hashvalue, and deciding unauthorized based just on the username
> would open up for an attacker to generate a list of accepted login-IDs at
> a server.
>
> Suggestion: Remove this item.

The intent here was to allow server to indicate that they recieved a messag=
e
with headers that weren't included in the digest, but need to be in order t=
o
successfully process the request. I will try to make this clearer.

>
> The serious concerns:
>
>   - I am not a crypto expert, but are MD5 and SHA-1 really the proper
> choices for digest algorithm now that both are known to be weaker than on=
e
> would like?

I am also not a crypto expert. My understanding is that the attacks on
MD5 and SHA do not apply to the HMAC versions. That said, it might
make sense to include a stronger, mandatory-to-implement HMAC
construction. I don't expect interop to be as good with the stronger, newer
hash function, though.

>
>   - Does this specification really need to have one HMAC algorithm
> specification and one password algorithm specification? Why not just
> specify the algorithm that is being used as part of the HMAC and also use
> that for the password hash?

Yes, pw-algorithm is necessary for the scheme to work with existing
authentication databases. Things like the popular Wordpress PHP
blogging software store passwords as unsalted MD5 hashes. One of the
goals of this document is to be easy to deploy in those types of
environments.

>   - I18N: This draft does not specify how to prepare usernames and
> passwords containing characters that are not part of US-ASCII
...
> It is a current problem with Basic and Digest
> authentication that there is no exisiting standard on how international
> characters are to be encoded.

Agreed. I know it's a problem with the document, and Alexey has some ideas
on how to solve it. The implementation report is very helpful, thanks.

>   - RFC 2617 (Digest) also specified the Authentication-Info response
> header that lets the server provide additional state information to the
> client, as well as reverse authentication and protection of the response
> entity content. AFAICT this new method does not have anything similar. Wh=
y
> not?

I did not find it widely implemented. I also expect that protecting respons=
e
content will have much more complicated interactions with HTTP intermediari=
es.

>   - Several other features of Digest Authentication, such as server-nonce=
s,
> stale nonces and the qop method, has been removed as well, but there is n=
o
> discussion about why these are excluded. AFAIK the server-nonces in RFC
> 2617 is used to prevent certain types of attacks. Is the salt value able
> to provide the same kind of protection?

Server nonces are back in draft-01. Alexey feels they prevent some types
of attacks from malicious clients, and I feel they don't add much
complexity to the scheme.

> The less serious concerns:
>
>   - How are new digest algorithms going to be added?
>
> Suggestion: Add IANA considerations entry for how new algorithms should b=
e
> added.

I would rather let the first person who needs to add a scheme set up
the IANA details.

>
>   - How are older clients going to be able to authenticate to a server th=
at
> supports the newer method?

I don't see an economical way to help them with that. If there are new
algorithm tokens, they'll have to be updated.

> Suggestion: This probably requires multiple WWW-Authorization headers wit=
h
> separate algorithms, unless the syntax is changed to permit multiple
> algorithms.

I'd rather leave this unsaid. It opens up downgrade attacks, which
makes me uncomfortable. I don't feel strongly about this issue,
though.

>
>   - I think that it would be best to specify a canonalization of the
> headers used in the digest to avoid problems if a gateway edits, breaks
> up, or concatenates headers. Are CRLFs included? Background: At least one
> of the HTTP stacks Opera works with on mobile devices is concatenating
> multiple headers into one (as is allowed by RFC 2616), and that created
> some problems for the cookie handling.

Agree. There is new text in draft-01 on this subject. Does it address
your concerns?

>
> - What about Proxy Authentication?

I could add text on this. Does anyone see this document being used by
proxies?

>
> - What about integrity of entity bodies? RFC 2617 have functionality for
> this.

Yes, and I found almost no implementations that used it. For example,
Mozilla and the Python standard library both contain "TODO" comments
in their source code. Digest has been around quite a while, and if people
haven't implemented a feature, that says something. Also, HMAC Digest allow=
s
implementations to sign headers, so Content-* can be included.

>
> May I also suggest that the description of the calulations uses the same
> form as in RFC 2617? Presenting the calculations in formulas will make it
> easier to search for errors in the implementation.

Hmm. I found those really confusing, but I guess I could add something
similar.

--

Robert Sayre

Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news
From: Scott Lawrence <[email-masked]>
To: Leif Johansson <[email-masked]>
Organization: Pingtel Corp.  http://www.pingtel.com/
Date: Fri, 07 Apr 2006 10:25:27 -0400
Cc: HTTP authentication list <[email-masked]>

On Fri, 2006-04-07 at 16:01 +0200, Leif Johansson wrote:

> > Suggestion: Drop MD5 support, and preferably also SHA-1, and go direct
> > for SHA-256.

For practical purposes, we'll be supporting MD5 for a long time.  Even
if there are attacks on it found that do compromise it, it is widely
deployed in embedded systems that can't easily be updated, so browsers
will likely continue to support it for a long time (just as they still
support SSLv2 despite its problems).

> The issue is one of algorithm agility which must be supported. It must
> be easy to introduce new hashes wo publishing and implementing new
> versions of the standard. This probably means negotiation in some form.

The current spec is pretty agile in this respect.  There is an explicit
token for the supported hash method in the WWW-Authenticate challenge.
Multiple algorithms can already be supported by including multiple
challenges in the 40[17] response.  All that would be needed is the
definition of new tokens specifying a new hash algorithm.

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Architect             - Pingtel Corp. http://www.pingtel.com/

Date: Fri, 07 Apr 2006 16:01:09 +0200
From: Leif Johansson <[email-masked]>
To: "Yngve N. Pettersen" <[email-masked]>
Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news
Cc: HTTP authentication list <[email-masked]>

>  - I am not a crypto expert, but are MD5 and SHA-1 really the proper
> choices for digest algorithm now that both are known to be weaker than
> one would like? As far as I know the current attacks are not in the
> areas that directly affects this authentication method, at present, and
> as I understand it, HMAC is supposed to be somewhat resistant to such
> attacks on the input digest method, but is that protection good enough?
> 
> Suggestion: Drop MD5 support, and preferably also SHA-1, and go direct
> for SHA-256.

The issue is one of algorithm agility which must be supported. It must
be easy to introduce new hashes wo publishing and implementing new
versions of the standard. This probably means negotiation in some form.

You are right about HMAC MD5; people are getting nervous about this and
it should not be used. Today HMAC SHA1 is probably ok but it may not be
for very long.

Going to SHA256 is not the right answer though - by the time SHA1 is
"broken" SHA256 may not be that much better.

The security ADs have made it clear that all protocols published by
the IETF on standards-track must support seamless updates of hash-
algorithms within 2 years.

	Cheers Leif

Date: Fri, 07 Apr 2006 15:50:03 +0200
To: "Robert Sayre" <[email-masked]>, "HTTP authentication list" <[email-masked]>
Subject: Re: [Ietf-http-auth] HMAC Digest draft and implementation news
From: "Yngve N. Pettersen" <[email-masked]>
Organization: Opera Software ASA

Hello all,

On Wed, 22 Mar 2006 20:38:37 -0600, Robert Sayre <[email-masked]> wrote:

> In Internet-Drafts news, draft-sayre-http-hmac-digest-00.txt is now
> available in the I-D directory. It's the same document I've posted
> here before. One significant issue has come to light since then:
> clients need to exclude standard and extension hop-by-hop headers from
> the digest calculation. Per RFC 2616, extension hop-by-hop headers are
> listed in the 'Connection' header.

I'd like to comment on a few things about this draft. Some of the concerns  
I have are unfortunately a bit serious, others are less serious.

First off, while I find the "reason" attribute concept interesting, in  
particular in light of what was presented in an unrelated WG meeting in  
Dallas, I am not so sure it will be useful in this case. Unless I am  
mistaken, there is no way to differentiate between unauthorized (wrong  
username/password) and (header)integrity as the reason for failure based  
on the hashvalue, and deciding unauthorized based just on the username  
would open up for an attacker to generate a list of accepted login-IDs at  
a server.

Suggestion: Remove this item.

The serious concerns:

  - I am not a crypto expert, but are MD5 and SHA-1 really the proper  
choices for digest algorithm now that both are known to be weaker than one  
would like? As far as I know the current attacks are not in the areas that  
directly affects this authentication method, at present, and as I  
understand it, HMAC is supposed to be somewhat resistant to such attacks  
on the input digest method, but is that protection good enough?

Suggestion: Drop MD5 support, and preferably also SHA-1, and go direct for  
SHA-256.

  - Does this specification really need to have one HMAC algorithm  
specification and one password algorithm specification? Why not just  
specify the algorithm that is being used as part of the HMAC and also use  
that for the password hash?

Suggestion: Remove pw-algorithm, and use the algorithm parameter to define  
both the password hash and the function HMAC_func(key) = HMAC(H, key),  
where H is defined by the algorithm parameter.

  - I18N: This draft does not specify how to prepare usernames and  
passwords containing characters that are not part of US-ASCII, such as  
scandinavian letters, cyrillic and letters in the asian writing systems,  
before using them in the authentication method. Similar problems exists  
for other fields as well. It is a current problem with Basic and Digest  
authentication that there is no exisiting standard on how international  
characters are to be encoded. Opera uses UTF-8, while other browsers uses  
a different system, apparently depending on mutual agreement between the  
server- and client-side configurations. This specification should avoid  
making the same mistake as RFC 2617 made on this point.

Suggestion: Get I18N experts involved in this aspect. I believe there are  
several WG chairs that should be able to help locate such experts. With  
respect to specifics I would recommend that the Normalization part (if  
used) should use the same method as the IDNA Nameprep (NFKC), because  
implementations will probably already have that method, and using the same  
method would be beneficial for memory constrained implementations (such as  
phones and PDAs).

  - RFC 2617 (Digest) also specified the Authentication-Info response  
header that lets the server provide additional state information to the  
client, as well as reverse authentication and protection of the response  
entity content. AFAICT this new method does not have anything similar. Why  
not?

Suggestion: Implement the Authentication-Info header, or document in the  
specification why it is left out.

  - Several other features of Digest Authentication, such as server-nonces,  
stale nonces and the qop method, has been removed as well, but there is no  
discussion about why these are excluded. AFAIK the server-nonces in RFC  
2617 is used to prevent certain types of attacks. Is the salt value able  
to provide the same kind of protection?

Suggestion: Implement these attributes in the specification, or document  
the reasons why their removal does not weaken the authentication method.

The less serious concerns:

  - How are new digest algorithms going to be added?

Suggestion: Add IANA considerations entry for how new algorithms should be  
added.

  - How are older clients going to be able to authenticate to a server that  
supports the newer method?

Suggestion: This probably requires multiple WWW-Authorization headers with  
separate algorithms, unless the syntax is changed to permit multiple  
algorithms.

  - I think that it would be best to specify a canonalization of the  
headers used in the digest to avoid problems if a gateway edits, breaks  
up, or concatenates headers. Are CRLFs included? Background: At least one  
of the HTTP stacks Opera works with on mobile devices is concatenating  
multiple headers into one (as is allowed by RFC 2616), and that created  
some problems for the cookie handling.

- What about Proxy Authentication?

- What about integrity of entity bodies? RFC 2617 have functionality for  
this.

May I also suggest that the description of the calulations uses the same  
form as in RFC 2617? Presenting the calculations in formulas will make it  
easier to search for errors in the implementation.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************