Subject: [kitten] sasl-oauth "user" as a kvpair or in the gs2 header?

From: Bill Mills <[email-masked]>
Date: Mon, 3 Mar 2014 09:55:21 -0800

Ryan,

Does your implementation get user from the kvpair "user" per -03 of the spec or did you folks do the -04 and later GS2 header "a=$username" construct?

There is "soon" to be motion on the GS2 side which might make the stub GS2 header format actually useful again, but I am sorely inclined to just go with your running code and existing integrations as de-facto standard if you use the kvpairs.

-bill

--------------------------------
William J. Mills
"Paranoid" MUX Yahoo!

---

From: Sam Hartman <[email-masked]>
Date: Mon, 03 Mar 2014 13:44:45 -0500

When we talked about removing the GS2 support, I assumed we were
maintaining the GS2 header, just dropping the descriptions of the
GSS-API mechanism and   reference to GS2.

Speaking as an individual, I'd prefer to maximize alignment with GS2
even if we do not specify as a GSS-API mechanism at this time.

---

From: Bill Mills <[email-masked]>
Date: Mon, 3 Mar 2014 11:42:59 -0800

Well that certainly wasn't clear.  

The *only* thing we avoid if we keep the GS2 header is duplicating the username in the GS2 header and about 6 extra bytes if there ever is a GS2 binding for OAuth.  Yes it's cleaner if we leave the GS2 header stub in there if GS2 ever gets implemented for it.

Is it a compelling enough reason to break existing implementations?

-bill

On Monday, March 3, 2014 10:45 AM, Sam Hartman <[email-masked]> wrote:

---

From: Sam Hartman <[email-masked]>
Date: Tue, 04 Mar 2014 03:06:13 -0500

t's discuss Thursday.
I'd like to understand what the user= value signifies and whether it's
actually a SASL authorization identifier.

I'd like to understand whether there's value in an unprotected SASL
authorization identifier.

---

From: Bill Mills <[email-masked]>
Date: Tue, 4 Mar 2014 07:55:58 -0800

It is not used as a SASL identity.  Quoting from -03 and -14 in progress:

"user (REQUIRED):

Contains the user name being 
authenticated.  The server MAY use this as a routing or database lookup 
hint.  The server MUST NOT use this as authoritative, the user name MUST be asserted by the OAuth credential."
 
Also, looking at the Google API docs for XOAUTH2, they implemented based on the -03 spec and have the "user=$username" syntax.  See https://developers.google.com/gmail/xoauth2_protocol 

Based on Google's server API and the extant clients they have I'd like to ask for a consensus call on the following:

1) Add the -03 "user" kvpair back into the spec.

a) YES or b) NO.  

2) Should we include a GS2 header"

a) No, let's wait for the GS2 update that deals with things that lack mutual auth and then write a spec that defines a GS2 header for SASL+OAUTH.

b) Change the definition of "key" in kvpair to 1*(ALPHA / ",").  This makes a GS2 header followed by a ^A (i.e. "n,a=[email-masked]^A") a valid kvpair which would be ignored by servers that don't understand it. 

c) Define a stub OPTIONAL GS2 header explicitly.

d) Include a fully
 defined GS2 header (language from draft -10).

My own feedback is 1: YES, 2: a or b.

-bill

On Tuesday, March 4, 2014 12:06 AM, Sam Hartman <[email-masked]> wrote:
 
t's discuss Thursday.

---

From: Bill Mills <[email-masked]>
Date: Tue, 4 Mar 2014 01:49:22 -0800

"user (REQUIRED):

a) YES or b) NO.  

d) Include a fully defined GS2 header (language from draft -10).

-bill

 
t's discuss Thursday.

---

From: Ryan Troll <[email-masked]>
Date: Thu, 6 Mar 2014 15:38:14 -0800

Apologies for the delay in responding.

I understand this was discussed in today's meeting; and we're going to have
a follow-up to discuss further - very reasonable.

To answer Bill's original question: user= or a= --> Either works for us.
 If one has better implications than the other, we'll use it.

-R

On Tue, Mar 4, 2014 at 7:55 AM, Bill Mills <[email-masked]> wrote:

> Contains the user name being authenticated. The server MAY use this as a
> routing or database lookup hint. The server MUST NOT use this as
> authoritative, the user name MUST be asserted by the OAuth credential."
>
> Also, looking at the Google API docs for XOAUTH2, they implemented based
> on the -03 spec and have the "user=$username" syntax.  See
> https://developers.google.com/gmail/xoauth2_protocol
>
> Based on Google's server API and the extant clients they have I'd like to
> ask for a consensus call on the following:
>
> a) No, let's wait for the GS2 update that deals with things that lack
> mutual auth and then write a spec that defines a GS2 header for SASL+OAUTH.
>
> b) Change the definition of "key" in kvpair to 1*(ALPHA / ",").  This
> makes a GS2 header followed by a ^A (i.e. "n,a=[email-masked]^A") a
> valid kvpair which would be ignored by servers that don't understand it.
>
> _______________________________________________
> Kitten mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/kitten
>
>

---

From: Bill Mills <[email-masked]>
Date: Wed, 12 Mar 2014 11:56:01 -0700 (PDT)

Please take a look at the attached, specifically 3.1, and see if it captures what's been discussed.

Thanks,

-bill

On Thursday, March 6, 2014 3:38 PM, Ryan Troll <[email-masked]> wrote:

I understand this was discussed in today's meeting; and we're going to have a follow-up to discuss further - very reasonable.

To answer Bill's original question: user= or a= --> Either works for us.  If one has better implications than the other, we'll use it.

-R

>b) Change the definition of "key" in kvpair to 1*(ALPHA / ",").  This makes a GS2 header followed by a ^A (i.e.
 "n,a=[email-masked]^A") a valid kvpair which would be ignored by servers that don't understand it.

---

From: Bill Mills <[email-masked]>
Date: Fri, 14 Mar 2014 14:52:27 -0700 (PDT)

Quoting here, in the hope that it piques someone's interest.  New proposed language is:

" Client responses are a GS2 [RFC5801] header followed by a key/value pair sequence, or may be empty. The gs2-header is defined here for compatibility with GS2 if a GS2 mechanism is formally defined, but this document does not define one. These key/value pairs carry the equivalent values from an HTTP context in order to be able to complete an OAuth style HTTP authorization. Unknown key/value pairs MUST be ignored by the server. The ABNF [RFC5234] syntax is:kvsep          = %x01 key            = 1*(ALPHA / ",") value          = *(VCHAR / SP / HTAB / CR / LF ) kvpair         = key "=" value kvsep
;;gs2-header     = See RFC 5801 client_resp    = (gs2-header kvsep 0*kvpair kvsep) / kvsep 
The GS2 header MUST inclde the user name asociated with the resource being accessed, the "authzid"."

Hoping to wrap this up soon.

Thanks,

-bill

On Wednesday, March 12, 2014 11:56 AM, Bill Mills <[email-masked]> wrote:

Thanks,

-bill

-R

---

From: Ryan Troll <[email-masked]>
Date: Mon, 17 Mar 2014 10:14:41 -0700

Seems reasonable.

The last sentence contains two typos.

-R

On Fri, Mar 14, 2014 at 2:52 PM, Bill Mills <[email-masked]> wrote:

> " Client responses are a GS2 [RFC5801]<https://us-mg904.mail.yahoo.com/neo/launch?.rand=3v2pmo26m8nhi#RFC5801>
>  header followed by a key/value pair sequence, or may be empty. The
> gs2-header is defined here for compatibility with GS2 if a GS2 mechanism is
> formally defined, but this document does not define one. These key/value
> pairs carry the equivalent values from an HTTP context in order to be able
> to complete an OAuth style HTTP authorization. Unknown key/value pairs MUST
> be ignored by the server. The ABNF [RFC5234]<https://us-mg904.mail.yahoo.com/neo/launch?.rand=3v2pmo26m8nhi#RFC5234>
>  syntax is:
>
>
>   kvsep          = %x01
>   key            = 1*(ALPHA / ",")
>   value          = *(VCHAR / SP / HTAB / CR / LF )
>   kvpair         = key "=" value kvsep
> ;;gs2-header     = See RFC 5801
>   client_resp    = (gs2-header kvsep 0*kvpair kvsep) / kvsep
>
> I understand this was discussed in today's meeting; and we're going to
> have a follow-up to discuss further - very reasonable.
>

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Mar 2014 10:19:09 -0700 (PDT)

Fixed. Thanks.

On Monday, March 17, 2014 10:14 AM, Ryan Troll <[email-masked]> wrote:
 
Seems reasonable.

-R

Quoting here, in the hope that it piques someone's interest.  New proposed language is:
>
>
>" Client responses are a GS2 [RFC5801] header followed by a key/value pair sequence, or may be empty. The gs2-header is defined here for compatibility with GS2 if a GS2 mechanism is formally defined, but this document does not define one. These key/value pairs carry the equivalent values from an HTTP context in order to be able to complete an OAuth style HTTP authorization. Unknown key/value pairs MUST be ignored by the server. The ABNF [RFC5234] syntax is:
>kvsep          = %x01 key            = 1*(ALPHA / ",") value          = *(VCHAR / SP / HTAB / CR / LF ) kvpair         = key "=" value kvsep

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Mar 2014 15:13:50 -0500

On Fri, Mar 14, 2014 at 4:52 PM, Bill Mills <[email-masked]> wrote:
> " Client responses are a GS2 [RFC5801] header followed by a key/value pair
> sequence, or may be empty. The gs2-header is defined here for compatibility
> with GS2 if a GS2 mechanism is formally defined, but this document does not

s/formally/eventually/ ?

> define one. These key/value pairs carry the equivalent values from an HTTP
> context in order to be able to complete an OAuth style HTTP authorization.
> Unknown key/value pairs MUST be ignored by the server. The ABNF [RFC5234]
> syntax is:
>
>
>   kvsep          = %x01
>   key            = 1*(ALPHA / ",")

Hmm, MUST?  SASL allows the app to not use an authzid if it doesn't
want to.  I understand that Google's OAuth use case requires an
authzid, but it's not obvious to me that all OAuth use cases will.

+ the two typos Ryan noticed.

Nico
--

---

From: Matt Miller <[email-masked]>
Date: Mon, 17 Mar 2014 14:32:01 -0600

On 3/17/14, 2:13 PM, Nico Williams wrote:
>> " Client responses are a GS2 [RFC5801] header followed by a
>> key/value pair sequence, or may be empty. The gs2-header is
>> defined here for compatibility with GS2 if a GS2 mechanism is
>> formally defined, but this document does not
> 
> s/formally/eventually/ ?
> 
>> define one. These key/value pairs carry the equivalent values
>> from an HTTP context in order to be able to complete an OAuth
>> style HTTP authorization. Unknown key/value pairs MUST be ignored
>> by the server. The ABNF [RFC5234] syntax is:
>> 
>> 
>> kvsep          = %x01 key            = 1*(ALPHA / ",") value
>> = *(VCHAR / SP / HTAB / CR / LF ) kvpair         = key "=" value
>> kvsep ;;gs2-header     = See RFC 5801 client_resp    =
>> (gs2-header kvsep 0*kvpair kvsep) / kvsep
>> 
> Hmm, MUST?  SASL allows the app to not use an authzid if it
> doesn't want to.  I understand that Google's OAuth use case
> requires an authzid, but it's not obvious to me that all OAuth use
> cases will.
> 

I had the same pause as Nico.  The implementation I was looking into
did not require such information.

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Mar 2014 14:13:02 -0700

OK, so given Google's extant implementation, if we change it to SHOULD the MUST is implicit and the de facto standard anyway if you want it to work with Google.

I'd rather have the standard explicitly document what is working now, but I can make the change easily.

-bill

On Monday, March 17, 2014 1:32 PM, Matt Miller <[email-masked]> wrote:

- -- 
- - m&m

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Mar 2014 14:15:19 -0700 (PDT)

OK, so given Google's extant implementation, if we change it to SHOULD 
the MUST is implicit and the de facto standard anyway if you want it to 
work with Google.

-bill

- -- 
- - m&m

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Mar 2014 16:27:12 -0500

On Mon, Mar 17, 2014 at 4:15 PM, Bill Mills <[email-masked]> wrote:
> OK, so given Google's extant implementation, if we change it to SHOULD the
> MUST is implicit and the de facto standard anyway if you want it to work
> with Google.

No need to say either MUST nor SHOULD.  Instead you might want to note
that in common usage of this mechanism the server tends to require
that the client send an authz-id.

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Mar 2014 14:56:18 -0700 (PDT)

This feels like soft-selling what the implementer actually has to do.  It's like how HTTP evolved to be bug-compliant with major browser or server bugs.  Never actually documented but are the de facto standard anyway.  Why leave a landmine like that unspecified?

On Monday, March 17, 2014 2:27 PM, Nico Williams <[email-masked]> wrote:

Nico
--

---

From: Sam Hartman <[email-masked]>
Date: Mon, 17 Mar 2014 18:20:32 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    Nico> On Mon, Mar 17, 2014 at 4:15 PM, Bill Mills <[email-masked]> wrote:
    >> OK, so given Google's extant implementation, if we change it to
    >> SHOULD the MUST is implicit and the de facto standard anyway if
    >> you want it to work with Google.

    Nico> No need to say either MUST nor SHOULD.  Instead you might want
    Nico> to note that in common usage of this mechanism the server
    Nico> tends to require that the client send an authz-id.

what bill described to me was not authz ID.
It was a routing hint that was a lot closer to an in-mechanism
authentication ID.

---

From: Nico Williams <[email-masked]>
Date: Mon, 17 Mar 2014 17:28:51 -0500

On Mon, Mar 17, 2014 at 4:56 PM, Bill Mills <[email-masked]> wrote:
> This feels like soft-selling what the implementer actually has to do.  It's
> like how HTTP evolved to be bug-compliant with major browser or server bugs.
> Never actually documented but are the de facto standard anyway.  Why leave a
> landmine like that unspecified?

Because the way it works in practice is that the app has something
like a dialog or panel where the user is invited to "set/create an
account" or something like that.  The user will be invited to specify
a server name, pick a mechanism, and for the mechnism selection
perhaps addition inputs, and finally they'll be invited to specify an
authzid.  Some of these account parameters are generic:

 - a local name for whatever this "account" is
 - the server name (and port)
 - the authzid
 - the name of the mechanism

everything else is mechanism-specific (e.g., "password", "keystore",
"principal name", ...).

The generic bits are generic.  And authzid has always been
application-specific.  Application protocols are allowed to require an
authzid.  Servers are allowed to require an authzid.  Mechanisms are
NOT allowed to require an authzid.

Nico
--

---

From: Bill Mills <[email-masked]>
Date: Mon, 17 Mar 2014 15:45:45 -0700 (PDT)

Changed MUST to MAY.  Added "It is worth noting that application
protocols are allowed to require an authzid, as are specific server implementations."

On Monday, March 17, 2014 3:28 PM, Nico Williams <[email-masked]> wrote:

Nico
--

---

From: Matt Miller <[email-masked]>
Date: Tue, 18 Mar 2014 14:03:17 -0600

That change works for me.

- -- 
- - m&m

On 3/17/14, 4:45 PM, Bill Mills wrote:
> On Monday, March 17, 2014 3:28 PM, Nico Williams
> <[email-masked]> wrote: On Mon, Mar 17, 2014 at 4:56 PM,
> Bill Mills <[email-masked] <mailto:[email-masked]>>
> wrote:
>> This feels like soft-selling what the implementer actually has to
>> do.
> It's
>> like how HTTP evolved to be bug-compliant with major browser or
>> server
> bugs.
>> Never actually documented but are the de facto standard anyway.
>> Why
> leave a
> account" or something like that.  The user will be invited to
> specify a server name, pick a mechanism, and for the mechnism
> selection perhaps addition inputs, and finally they'll be invited
> to specify an authzid.  Some of these account parameters are
> generic:
> 
> - a local name for whatever this "account" is - the server name
> (and port) - the authzid - the name of the mechanism
> 
> everything else is mechanism-specific (e.g., "password",
> "keystore", "principal name", ...).
> 
> application-specific.  Application protocols are allowed to require
> an authzid.  Servers are allowed to require an authzid.  Mechanisms
> are NOT allowed to require an authzid.
> 
> 
> Nico --
> 
>