Subject: [http-auth] Authentication-Info

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2014 13:51:29 +0100

Hi there,

this is a minor outstanding issue with the Digest and SCRAM drafts. It 
was discussed in both the WG sessions and in hallway conversations.

This header field originally was defined in the "Digest" part of RFC 
2617, and consequently, it was copied over into 
<http://tools.ietf.org/html/draft-ietf-httpauth-digest-08#section-3.5>.

<http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-04> currently 
uses it as well, but with with a slightly differing syntax.

Given the fact that we have two authentication scheme definitions that 
have a use case for this header field -- shouldn't we define it in a way 
so that it becomes a generic (optional) feature for authentications schemes?

Choices:

1) The cleanest approach seems to move the definition into a separate 
spec which later can be absorbed by a future RFC7235bis. I volunteer to 
write that spec (it'll be very short), but this would require changes to 
the Digest spec post-WGLC.

2) Alternatively, we could tune the Digest draft to introduce the header 
field in a more generic way, allowing other schemes to use it as well. 
That would avoid a dependency to a yet unwritten spec, but the 
complexity wouldn't really change.

3) We can tell Alexey to pick a different field name, which would shift 
all required changes to the SCRAM spec.

Feedback appreciated,

Julian

---

From: Michael Sweet <[email-masked]>
Date: Tue, 02 Dec 2014 09:06:11 -0500

Julian,

> On Dec 2, 2014, at 7:51 AM, Julian Reschke <[email-masked]> wrote:
> 
> Hi there,
> 
> this is a minor outstanding issue with the Digest and SCRAM drafts. It was discussed in both the WG sessions and in hallway conversations.
> 
> This header field originally was defined in the "Digest" part of RFC 2617, and consequently, it was copied over into <http://tools.ietf.org/html/draft-ietf-httpauth-digest-08#section-3.5>.
> 
> <http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-04> currently uses it as well, but with with a slightly differing syntax.
> 
> Given the fact that we have two authentication scheme definitions that have a use case for this header field -- shouldn't we define it in a way so that it becomes a generic (optional) feature for authentications schemes?
> 
> Choices:
> 
> 1) The cleanest approach seems to move the definition into a separate spec which later can be absorbed by a future RFC7235bis. I volunteer to write that spec (it'll be very short), but this would require changes to the Digest spec post-WGLC.
> 
> 2) Alternatively, we could tune the Digest draft to introduce the header field in a more generic way, allowing other schemes to use it as well. That would avoid a dependency to a yet unwritten spec, but the complexity wouldn't really change.
> 
> 3) We can tell Alexey to pick a different field name, which would shift all required changes to the SCRAM spec.

In the interests of schedule, I would favor options 2 and 3.

In the interests of reuse/generic use, option 2 would seem to be the way to go.

If we want to minimize changes to both specs, then extending the ABNF in the digest spec to include an optional initial auth-scheme would take of things.  Alternately we can just define a standard "scheme" parameter that contains the auth-scheme value, which has the added benefit of allowing new Digest implementations to include it without breaking existing ones.

(and of course nothing prevents a 7235bis from adopting the definition in the new Digest spec, you just avoid the delay of developing a dependent spec now...)

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2014 15:11:21 +0100

> In the interests of schedule, I would favor options 2 and 3.

I believe we can get done 1) quickly enough.

> If we want to minimize changes to both specs, then extending the ABNF in the digest spec to include an optional initial auth-scheme would take of things.  Alternately we can just define a standard…

Changing the syntax sounds like a breaking change to Digest to me.

Adding a scheme *parameter* would work, but I wonder why that is needed 
anyway. Alexey?

> (and of course nothing prevents a 7235bis from adopting the definition in the new Digest spec, you just avoid the delay of developing a dependent spec now...)

Best regards, Julian

---

From: Ken Murchison <[email-masked]>
Date: Tue, 02 Dec 2014 09:25:04 -0500

On 12/02/2014 07:51 AM, Julian Reschke wrote:
> <http://tools.ietf.org/html/draft-ietf-httpauth-scram-auth-04> 
> currently uses it as well, but with with a slightly differing syntax.
>
> have a use case for this header field -- shouldn't we define it in a 
> way so that it becomes a generic (optional) feature for 
> authentications schemes?
>
> Choices:
>
> spec which later can be absorbed by a future RFC7235bis. I volunteer 
> to write that spec (it'll be very short), but this would require 
> changes to the Digest spec post-WGLC.

I'm in favor of this approach.

>
> 2) Alternatively, we could tune the Digest draft to introduce the 
> header field in a more generic way, allowing other schemes to use it 
> as well. That would avoid a dependency to a yet unwritten spec, but 
> the complexity wouldn't really change.

This would be my second choice.

>
> 3) We can tell Alexey to pick a different field name, which would 
> shift all required changes to the SCRAM spec.

This is a non-starter as far as I'm concerned.  Two separate response 
header fields to return auth success data seems clumsy.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

---

From: Michael Sweet <[email-masked]>
Date: Tue, 02 Dec 2014 09:25:17 -0500

> ...

If optional, it wouldn't break Digest but would not provide a way for new implementations to adopt it.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 02 Dec 2014 15:34:23 +0100

> If optional, it wouldn't break Digest but would not provide a way for new implementations to adopt it.

Let's find out what the syntax variation is about before we start 
planning how to support it :-)

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 5 Dec 2014 19:53:02 -0500

Hi Julian,

The Digest draft based the definition of the Authentication-Info header on
the auth-param defined in RFC7235, and it registers the header with the
Message Header Field Registry.

What else do you think we need to do to make it generic?

Regards,
 Rifaat

On Tue, Dec 2, 2014 at 7:51 AM, Julian Reschke <[email-masked]>
wrote:

> Hi there,
>
> this is a minor outstanding issue with the Digest and SCRAM drafts. It was
> discussed in both the WG sessions and in hallway conversations.
>
> This header field originally was defined in the "Digest" part of RFC 2617,
> and consequently, it was copied over into <http://tools.ietf.org/html/
> draft-ietf-httpauth-digest-08#section-3.5>.
>
> have a use case for this header field -- shouldn't we define it in a way so
> that it becomes a generic (optional) feature for authentications schemes?
>
> Choices:
>
> 1) The cleanest approach seems to move the definition into a separate spec
> which later can be absorbed by a future RFC7235bis. I volunteer to write
> that spec (it'll be very short), but this would require changes to the
> Digest spec post-WGLC.
>
> field in a more generic way, allowing other schemes to use it as well. That
> would avoid a dependency to a yet unwritten spec, but the complexity
> wouldn't really change.
>
> _______________________________________________
> http-auth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-auth
>

---

From: Yutaka OIWA <[email-masked]>
Date: Sat, 6 Dec 2014 13:36:06 +0900

Dear Julian,

I prefer 1) (and 2 as an alternative if 1 is not feasible).
We should not have a separate header for common functionalities
(server-to-client authentication data vehicle)
between auth. schemes as far as possible.

The header is also a definitive part of Mutual spec
(because it mandates mutual authentication on that header),
and I'd like to harmonize use of the header with other schemes.
When syntax differences between other drafts are resolved,
I'll harmonize the syntax in my drafts as well.

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

2014-12-02 21:51 GMT+09:00 Julian Reschke <[email-masked]>:
> and consequently, it was copied over into
> Given the fact that we have two authentication scheme definitions that have
> a use case for this header field -- shouldn't we define it in a way so that
> it becomes a generic (optional) feature for authentications schemes?
>
> Choices:
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 06 Dec 2014 09:07:45 +0100

On 2014-12-06 01:53, Rifaat Shekh-Yusef wrote:
> Hi Julian,
>
> The Digest draft based the definition of the Authentication-Info header
> on the auth-param defined in RFC7235, and it registers the header with
> the Message Header Field Registry.
>

The only remaining thing to do would be to clarify that this header 
field can be used in other auth schemes as well, and to de-couple the 
generic description completely from the Digest-specific aspects...

Best regards, Julian

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Sat, 6 Dec 2014 08:46:58 -0500

This is a simple change, and much easier than option 1.
I will make the change in the next version of the document along with the
WGLC changes.

Regards,
 Rifaat

On Sat, Dec 6, 2014 at 3:07 AM, Julian Reschke <[email-masked]>
wrote:

> The only remaining thing to do would be to clarify that this header field
> can be used in other auth schemes as well, and to de-couple the generic
> description completely from the Digest-specific aspects...
>
> Best regards, Julian
>
>