Subject: Re: [http-auth] HTTP Digest Access Authentication Algorithm Update

From: David Maciejak <[email-masked]>
Date: Sat, 1 Sep 2012 09:43:37 -0700

----------------original message-----------------
From: "Shekh-Yusef, Rifaat (Rifaat)" [email-masked]
To: "David Maciejak" [email-masked]
CC: "Ahrens, David (David)" [email-masked]
Date: Fri, 31 Aug 2012 14:31:36 -0400
----------------------------------------------------------

Hi David,

Can please raise this on the http-auth mailing list, as this discussion
might be of interest to others?

Sure.

How would you envision it to work if you want to use qop, keeping in mind
the backward compatibility issue?

I mean using "algorithm" as "qop" is used when passing multiple values eg
algorithm="MD5, SHA1" if MD5 is the preferred algo.

But this will break backward compatibility...

Btw, were you able to do some tests about the multiple WWW-Authenticate
headers ?

In page 4 you wrote "The server MAY include multiple WWW-Authenticate
headers", i believe you should define the separator used in this case,

from your example seems to be a double CRLF ? I wonder if there is no border
line effect.

best regards,

david

From: David Maciejak [mailto:[email-masked]] 
Sent: Friday, August 31, 2012 10:59 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Cc: Ahrens, David (David)
Subject: Re: [http-auth] HTTP Digest Access Authentication Algorithm Update

On 08/31/2012 04:39 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hi David,

Thanks for your feedback.

> You mean 2 WWW-Authenticate: Digest are sent to let the client choose the
algo ?

Yes, the idea is to allow servers to still be able to interact with clients
that only support the MD5 algorithm.

yes i realized afterward you did this for older compatibility.
I thought it should have been cleaner to do it like the qop value (eg
qop="auth, auth-int") ordered by preferred algo values.

regards,
david

It is up to the server to decide on the level to security that it wish to
put on any document, and it might decide to only send one header with the
most secured algorithm.

From: David Maciejak [[mailto:[email-masked]] 
Sent: Friday, August 31, 2012 10:17 AM
To: Shekh-Yusef, Rifaat (Rifaat)
Subject: Re: [http-auth] HTTP Digest Access Authentication Algorithm Update

On 08/31/2012 03:46 PM, Shekh-Yusef, Rifaat (Rifaat) wrote:

Hello,

The Digest mechanism, widely used in SIP networks, is based on the HTTP
Digest mechanism defined in RFC 2617.

The HTTP Digest mechanism states that MD5 is the algorithm to be used, and
while it allows other algorithms to be added (per the 'token' defined in
Section 3.2.1, algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token )),
no other algorithm is specified.

In 2008 the US-CERT issued a note that MD5 "should be considered
cryptographically broken and unsuitable for further use". The following
draft is an attempt to specify extensions to the HTTP Digest Access
Authentication scheme by adding support for the SHA1 and SHA2 suite of hash
algorithms.

https://datatracker.ietf.org/doc/draft-ahrens-httpbis-digest-auth-update/?include_text=1

Our initial goal was to address the issue for SIP, but when we discussed
this topic offline with Mark Nottingham (HTTPbis chair) and Tobias Gondrom
(WebSec co-chair), they suggested to us to submit it in the context of
HTTPbis to allow the group to consider HTTP Digest as one of the mechanisms
for HTTP 2.0.

We would really appreciate it if people can review the draft and provide us
with their feedback on the following:

1. The basic idea of extending RFC2617 to support other algorithms.

2. Including the extended HTTP Digest mechanism in HTTP 2.0.

Regards,

Rifaat

_______________________________________________

http-auth mailing list

<a href="mailto:[email-masked]">[email-masked]

https://www.ietf.org/mailman/listinfo/http-auth ->
mailto:[email-masked]]

Hi Rifaat,

yes i believe it's a good idea to update this old rfc with some other hash
algos. 
Moreover, on page 6-7 i am not sure about the example you put.
You mean 2 WWW-Authenticate: Digest are sent to let the client choose the
algo ?

thanks,
david

-- 

David Maciejak 
Sr. Security Researcher 
Fortinet - The New Generation of Secure Gateways
120 rue Albert Caquot | 06560, Sophia Antipolis | France 
PGP Key ID: A30A77ED 

This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient
of this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited.

*** Please note that this message and any attachments may contain
confidential and proprietary material and information and are intended only
for the use of the intended recipient(s). If you are not the intended
recipient, you are hereby notified that any review, use, disclosure,
dissemination, distribution or copying of this message and any attachments
is strictly prohibited. If you have received this email in error, please
immediately notify the sender and destroy this e-mail and any attachments
and all copies, whether electronic or printed. Please also note that any
views, opinions, conclusions or commitments expressed in this message are
those of the individual sender and do not necessarily reflect the views of
Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and
only a writing manually signed by Fortinet's General Counsel can be a
binding commitment of Fortinet to Fortinet's customers or partners. Thank
you. *** 

-- 

David Maciejak 
Sr. Security Researcher 
Fortinet - The New Generation of Secure Gateways
120 rue Albert Caquot | 06560, Sophia Antipolis | France 
PGP Key ID: A30A77ED 

This message is intended only for the personal and confidential use of the
designated recipient(s) named above. If you are not the intended recipient
of this message you are hereby notified that any review, dissemination,
distribution or copying of this message is strictly prohibited.

*** Please note that this message and any attachments may contain
confidential and proprietary material and information and are intended only
for the use of the intended recipient(s). If you are not the intended
recipient, you are hereby notified that any review, use, disclosure,
dissemination, distribution or copying of this message and any attachments
is strictly prohibited. If you have received this email in error, please
immediately notify the sender and destroy this e-mail and any attachments
and all copies, whether electronic or printed. Please also note that any
views, opinions, conclusions or commitments expressed in this message are
those of the individual sender and do not necessarily reflect the views of
Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and
only a writing manually signed by Fortinet's General Counsel can be a
binding commitment of Fortinet to Fortinet's customers or partners. Thank
you. *** 

***  Please note that this message and any attachments may contain confidential 
and proprietary material and information and are intended only for the use of 
the intended recipient(s). If you are not the intended recipient, you are hereby 
notified that any review, use, disclosure, dissemination, distribution or copying 
of this message and any attachments is strictly prohibited. If you have received 
this email in error, please immediately notify the sender and destroy this e-mail 
and any attachments and all copies, whether electronic or printed.
Please also note that any views, opinions, conclusions or commitments expressed 
in this message are those of the individual sender and do not necessarily reflect 
the views of Fortinet, Inc., its affiliates, and emails are not binding on 
Fortinet and only a writing manually signed by Fortinet's General Counsel can be 
a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 2 Sep 2012 21:48:53 -0400

Hi David,

> I mean using "algorithm" as "qop" is used when passing multiple values eg algorithm="MD5, SHA1" if MD5 is the preferred algo.

> But this will break backward compatibility...

Yeah, this will break the backward compatibility, as the RFC2617 defines the algorithm parameter to be a “… a pair of algorithms…”.

> Btw, were you able to do some tests about the multiple WWW-Authenticate headers ?

Not yet.

> In page 4 you wrote "The server MAY include multiple WWW-Authenticate headers", i believe you should define the separator used in this case,

These are two headers in a 401 response, and the extra CRLF should not be there. We will fix it in the next version of the draft.

Regards,

Rifaat

From: David Maciejak [mailto:[email-masked]]
Sent: Saturday, September 01, 2012 12:44 PM
To: [email-masked]
Cc: Shekh-Yusef, Rifaat (Rifaat); Ahrens, David (David)
Subject: RE: [http-auth] HTTP Digest Access Authentication Algorithm Update

----------------original message-----------------
From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
To: "David Maciejak" <[email-masked]>
CC: "Ahrens, David (David)" <[email-masked]>
Date: Fri, 31 Aug 2012 14:31:36 -0400

Hi David,

Can please raise this on the http-auth mailing list, as this discussion might be of interest to others?

Sure.

How would you envision it to work if you want to use qop, keeping in mind the backward compatibility issue?

I mean using "algorithm" as "qop" is used when passing multiple values eg algorithm="MD5, SHA1" if MD5 is the preferred algo.

Btw, were you able to do some tests about the multiple WWW-Authenticate headers ?

In page 4 you wrote "The server MAY include multiple WWW-Authenticate headers", i believe you should define the separator used in this case,

from your example seems to be a double CRLF ? I wonder if there is no border line effect.

best regards,

david

Hi David,

> You mean 2  WWW-Authenticate: Digest are sent to let the client choose the algo ?

Yes, the idea is to allow servers to still be able to interact with clients that only support the MD5 algorithm.

yes i realized afterward you did this for older compatibility.
I thought it should have been cleaner to do it like the qop value (eg  qop="auth, auth-int") ordered by preferred algo values.

regards,
david

It is up to the server to decide on the level to security that it wish to put on any document, and it might decide to only send one header with the most secured algorithm.

Hello,

The Digest mechanism, widely used in SIP networks, is based on the HTTP Digest mechanism defined in RFC 2617.

The HTTP Digest mechanism states that MD5 is the algorithm to be used, and while it allows other algorithms to be added (per the 'token' defined in Section 3.2.1, algorithm = "algorithm" "=" ( "MD5" | "MD5-sess" | token )), no other algorithm is specified.

In 2008 the US-CERT issued a note that MD5 "should be considered cryptographically broken and unsuitable for further use". The following draft is an attempt to specify extensions to the HTTP Digest Access Authentication scheme by adding support for the SHA1 and SHA2 suite of hash algorithms.

Our initial goal was to address the issue for SIP, but when we discussed this topic offline with Mark Nottingham (HTTPbis chair) and Tobias Gondrom (WebSec co-chair), they suggested to us to submit it in the context of HTTPbis to allow the group to consider HTTP Digest as one of the mechanisms for HTTP 2.0.

We would really appreciate it if people can review the draft and provide us with their feedback on the following:

Regards,

Rifaat

http-auth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/http-auth

Hi Rifaat,

yes i believe it's a good idea to update this old rfc with some other hash algos.
Moreover, on page 6-7 i am not sure about the example you put.
You mean 2  WWW-Authenticate: Digest are sent to let the client choose the algo ?

thanks,
david

--

David Maciejak
Sr. Security Researcher

This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.

*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

--

David Maciejak
Sr. Security Researcher

This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited.

*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***

________________________________
*** Please note that this message and any attachments may contain confidential and proprietary material and information and are intended only for the use of the intended recipient(s). If you are not the intended recipient, you are hereby notified that any review, use, disclosure, dissemination, distribution or copying of this message and any attachments is strictly prohibited. If you have received this email in error, please immediately notify the sender and destroy this e-mail and any attachments and all copies, whether electronic or printed. Please also note that any views, opinions, conclusions or commitments expressed in this message are those of the individual sender and do not necessarily reflect the views of Fortinet, Inc., its affiliates, and emails are not binding on Fortinet and only a writing manually signed by Fortinet's General Counsel can be a binding commitment of Fortinet to Fortinet's customers or partners. Thank you. ***
________________________________