Subject: Re: [OAUTH-WG] AD review of -22

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Nov 2011 10:47:32 -0700

I have not seen any responses to these items so I assume the group is in agreement with the comments made. I will push out a revised ID addressing these items in a few days.

EHL

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Stephen Farrell [[email-masked]]
Sent: Thursday, October 13, 2011 10:13 AM
To: [email-masked]
Subject: [OAUTH-WG] AD review of -22

Hi all,

Sorry for having been quite slow with this, but I had a bunch
of travel recently.

Anyway, my AD comments on -22 are attached. I think that the
first list has the ones that need some change before we push
this out for IETF LC, there might or might not be something
to change as a result of the 2nd list of questions and the
rest are really nits can be handled either now or later.

Thanks for all your work on this so far - its nearly there
IMO and we should be able to get the IETF LC started once
these few things are dealt with.

Cheers,
S.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 02 Nov 2011 20:45:21 +0100

Hi Stephen,

I'm concerned about your proposal (7) to make support for MAC a MUST for 
clients and BEARER a MAY only. In my opinion, this does not reflect the 
group's consensus. Beside this, the security threat analysis justifies 
usage of BEARER for nearly all use cases as long as HTTPS (incl. server 
authentication) can be utilized.

regards,
Torsten.

Am 13.10.2011 19:13, schrieb Stephen Farrell:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Wed, 2 Nov 2011 17:06:48 -0300

+1
On 2011-11-02, at 4:45 PM, Torsten Lodderstedt wrote:

> Hi Stephen,
> 
> I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases as long as HTTPS (incl. server authentication) can be utilized.
> regards,
> Torsten.
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Nov 2011 13:11:54 -0700

Do you want to see no change or adjust it to client must implement both, server decides which to use.

EHL

________________________________
From: [email-masked] [[email-masked]] On Behalf Of John Bradley [[email-masked]]
Sent: Wednesday, November 02, 2011 1:06 PM
To: Torsten Lodderstedt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of -22

+1

Hi Stephen,

regards,
Torsten.

Hi all,

Cheers,
S.

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Wed, 2 Nov 2011 13:18:34 -0700

+1

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Justin Richer <[email-masked]>
Date: Wed, 2 Nov 2011 16:27:43 -0400

+1

Leave the current text as is, keep this part of OAuth token-type
agnostic. 

 -- Justin

On Wed, 2011-11-02 at 13:18 -0700, Phil Hunt wrote:
> > > I'm concerned about your proposal (7) to make support for MAC a
> > > MUST for clients and BEARER a MAY only. In my opinion, this does
> > > not reflect the group's consensus. Beside this, the security
> > > threat analysis justifies usage of BEARER for nearly all use cases
> > > as long as HTTPS (incl. server authentication) can be utilized.
> > > regards,
> > > Torsten.
> > >

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Nov 2011 20:28:24 +0000

Hi Torsten,

On 11/02/2011 07:45 PM, Torsten Lodderstedt wrote:
> group's consensus.

That wasn't quite my comment, which is below:

    (7) Doesn't 7.1 need to say which token types are MTI so that we
    get interop?  I think I'd like to see mac being a MUST and bearer
    being a MAY but regardless of my preference, I don't think you
    can be silent on this. And as a consequence one or both of
    the mac/bearer drafts need to end up as normative.

 > Beside this, the security threat analysis justifies

As I said, I personally prefer the mac scheme since it demonstrates
use of a key. However, as I also said, the main concern with this
point is interop. (I do note though that bearer has server-auth TLS
as a MUST USE, so the implication of making bearer a MUST is that
TLS is MTI for the base spec too and a MUST USE for anything
involving the MTI token type.)

In any case I can live with it so long as the set of things that
are MTI is clear.

Incidentally, I don't believe any amount of +1 messages to your
mail answer my point above. As Eran's mail asks: what is it
that you're suggesting be MTI for whom?

S.

---

From: Mike Jones <[email-masked]>
Date: Wed, 2 Nov 2011 20:29:03 +0000

+1

The predominant industry practice is the use of Bearer tokens, so if either of Bearer or MAC becomes Mandatory to Implement, it must be the Bearer spec, with MAC being optional.

I'm fine either remaining silent on this point (leaving the spec token type agnostic, as Justin suggests), or making Bearer MTI, with MAC either being optional or not mentioned at all.

				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Richer
Sent: Wednesday, November 02, 2011 1:28 PM
To: Phil Hunt
Cc: [email-masked]
Subject: Re: [OAUTH-WG] AD review of -22

+1

Leave the current text as is, keep this part of OAuth token-type agnostic. 

 -- Justin

On Wed, 2011-11-02 at 13:18 -0700, Phil Hunt wrote:
> > > > Sorry for having been quite slow with this, but I had a bunch of 
> > > > travel recently.
> > > > 
> > > > this out for IETF LC, there might or might not be something to 
> > > > change as a result of the 2nd list of questions and the rest are 
> > > > really nits can be handled either now or later.
> > > > 
> > > > Thanks for all your work on this so far - its nearly there IMO 
> > > > and we should be able to get the IETF LC started once these few 
> > > > things are dealt with.
> > > > 
> > > > Cheers,
> > > > S. 
> > > > 
> > > > 
> > > >

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Nov 2011 20:31:33 +0000

Agnostic sounds like a fine word.

I'd need to have it demonstrated to me that it doesn't
mean non-interoperable in this case.

S.

---

From: John Bradley <[email-masked]>
Date: Wed, 2 Nov 2011 17:37:21 -0300

If the spec requires clients to implement both, the reality is most clients will only impliment one and be non compliant.

Given that openID Connect supports Bearer ONLY.  Requiring clients to support MAC would cause clients to implement code that won't be used.

It is up to the server to decide what formats it will support.  If clients can't talk to the servers they need to then they will support the token format.

I am opposed to making MAC MTI for Server or client.

I don't want to start a token war, there are use cases for both, and perhaps others in the future.

So I think that is a Canadian way of saying no change.

John B.

---

From: Phillip Hunt <[email-masked]>
Date: Wed, 2 Nov 2011 13:41:58 -0700

The issue is that the service provider will likely only accept ONE token format in practice. The security requirements of the scenario dictate choice of Mac or bearer or for that matter any other new scheme. 

An MTI would complicate the spec by implying a choice of tokens by the client because of the implication that the client has the right to select the MTI token format. 

Phil

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 02 Nov 2011 20:45:19 +0000

So perhaps this is the interesting point of difference.

On 11/02/2011 08:37 PM, John Bradley wrote:
> It is up to the server to decide what formats it will support.

With IETF protocols, its IETF consensus that decides this in
almost all cases that affect interop and it is therefore not
up to the specific server deployment admin what the server
code will support.

I think this case affects interop. and should be treated
as for any other IETF protocol. Am I wrong?

S

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 02 Nov 2011 21:49:38 +0100

If we must define a mandatory token type then bearer + TLS would be my 
suggestion.

regards,
Torsten.

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 2 Nov 2011 13:47:01 -0700

The problem is centered on the definition of a client. If it is a service specific implementation which is merely using OAuth for access, there isn't any interop requirements other than making sure the client and server are compatible. But if the client is a general purpose OAuth library or generic client (e.g. CURL), then the MTI becomes critical for any real interop.

I don't have a strong prefernece here, but we should clearly define the client characteristics in this discussion since an OAuth client isn't usually similar to an HTTP client in its interop reality.

I am not sure how to craft this language into spec form, but we might want to list such a MTI requirement in terms of a 'client designed to work across multiuple providers such as a general purpose library'.

EHL

________________________________________
From: Stephen Farrell [[email-masked]]
Sent: Wednesday, November 02, 2011 1:45 PM
To: John Bradley
Cc: Eran Hammer-Lahav; [email-masked]
Subject: Re: [OAUTH-WG] AD review of -22

S

---

From: John Bradley <[email-masked]>
Date: Wed, 2 Nov 2011 18:04:29 -0300

I could probably live with the client needing to support both token types if we quite narrowly define client as a general purpose library designed to support multiple protocols using OAuth for authorization.

That however is not the general use of the term in OAuth 2.0.  

Many clients will be optimized to work only with Bearer + TLS knowing in advance that the protocols they are used with only require Bearer.

John B.

---

From: André DeMarre <[email-masked]>
Date: Wed, 2 Nov 2011 15:45:24 -0700

Eran's point about the definition of a client is an important one.
There are two breeds of OAuth clients: (1) general purpose and (2)
purpose-built for a specific OAuth service.

When discussing interop, something to consider about OAuth is that
discovery is not part of the core spec, which IMHO leads to many
special purpose clients for a particular web service. This fits well
with many OAuth use cases and isn't a bad thing, simply something that
distinguishes OAuth apart from protocols like OpenID, where it is a
design goal for all clients to be compatable with all OpenID identity
providers.

With the current OAuth landscape, to me it seems reasonable to say
that clients SHOULD support both mac and bearer access token types,
but MAY choose to support any access token types needed to achieve
compatability with the desired server(s).

Regards,
Andre DeMarre

---

From: William Mills <[email-masked]>
Date: Wed, 2 Nov 2011 15:48:59 -0700 (PDT)

I actually think the protected resource specifies the token type(s) in either it's service docs or discovery information, and it does know knowing it's authentication server will issue compatible tokens.  The client may encounter endpoints requiring token types it doesn't support, and it needs to fail gracefully.  The client may select any supported OAuth 2 scheme it understands which the PR supports.

I am not in favor of specifying MUST for any particular flavor of token.

What is the value of mandating a token type?

-bill

________________________________
From: Eran Hammer-Lahav <[email-masked]>
To: John Bradley <[email-masked]>; Torsten Lodderstedt <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Wednesday, November 2, 2011 1:11 PM
Subject: Re: [OAUTH-WG] AD review of -22

 
EHL

+1

Hi Stephen,
>
>I'm concerned about your proposal (7) to make support for MAC a MUST for clients and BEARER a MAY only. In my opinion, this does not reflect the group's consensus. Beside this, the security threat analysis justifies usage of BEARER for nearly all use cases
Torsten. 
>>these few things are dealt with. 
OAuth mailing list [email-masked] https://www.ietf.org/mailman/listinfo/oauth 
_______________________________________________

---

From: Justin Richer <[email-masked]>
Date: Thu, 3 Nov 2011 08:46:14 -0400

This is exactly what I was thinking of. If a given token type is MTI for
clients, but servers can do whatever they want (this, as I read it, is
what was suggested), how does the MTI bit help interop at all?

 -- Justin

On Wed, 2011-11-02 at 15:48 -0700, William Mills wrote:
> I actually think the protected resource specifies the token type(s) in
> either it's service docs or discovery information, and it does know
> knowing it's authentication server will issue compatible tokens.  The
> client may encounter endpoints requiring token types it doesn't
> support, and it needs to fail gracefully.  The client may select any
> supported OAuth 2 scheme it understands which the PR supports.
> 
> 
> 
> ______________________________________________________________________
> ______________________________________________________________________
> > I'm concerned about your proposal (7) to make support for MAC a MUST
> > for clients and BEARER a MAY only. In my opinion, this does not
> > reflect the group's consensus. Beside this, the security threat
> > analysis justifies usage of BEARER for nearly all use cases as long
> > as HTTPS (incl. server authentication) can be utilized.
> > regards,
> > Torsten.
> >

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 3 Nov 2011 09:25:10 -0700

It can help by telling servers that as long as they support one of the MTI types, they will be able to interop. Of course, they don't have to.

My feeling is that until there is an actual discovery experience out there that works, this kind of interop is not really an issue ATM.

EHL

> From: Justin Richer [mailto:[email-masked]]
> Sent: Thursday, November 03, 2011 5:46 AM
> To: William Mills
> Cc: Eran Hammer-Lahav; John Bradley; Torsten Lodderstedt; [email-masked]
> This is exactly what I was thinking of. If a given token type is MTI for clients,
> but servers can do whatever they want (this, as I read it, is what was
> suggested), how does the MTI bit help interop at all?
> 
>  -- Justin
> 
> > > > Anyway, my AD comments on -22 are attached. I think that the first
> > > > list has the ones that need some change before we push this out
> > > > for IETF LC, there might or might not be something to change as a
> > > > result of the 2nd list of questions and the rest are really nits
> > > > can be handled either now or later.
> > > >
> > > > Thanks for all your work on this so far - its nearly there IMO and
> > > > we should be able to get the IETF LC started once these few things
> > > > are dealt with.
> > > >
> > > > Cheers,
> > > > S.
> > > >
> > > >
> > > >

---

From: Phil Hunt <[email-masked]>
Date: Thu, 3 Nov 2011 09:47:14 -0700

+1

I note that RFCs 2616 & 2617 only reference each other. There is no MTI text. It just references them.

It may be reasonable to observe that there are two classes of tokens Bearer, where the client treats token as opaque to return to server at appropriate times, and client-proof tokens such as MAC where the client must do something to prove possession with the objective that an attacker sniffing a client's authentication header (due to non-ssl communication) could not become or masquerade as the client.

Do we need an analogue to the bearer spec that lays foundations for the class of tokens that MAC fits into?  Or should the bearer spec be modified to explain the two classes of tokens?

If we had both, then we could set this up much like HTTP 1.1 does with RFC 2617.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 03 Nov 2011 09:52:15 -0700

> My feeling is that until there is an actual discovery experience out there that works, this kind of interop is not really an issue ATM.

 From what I can tell as a developer, it seems that every oauth server 
deployment
comes with their very own oauth client library/sdk. So there's a twitter 
one, a g+ one,
a fb one, etc. Ultimately there may be an oauth equivalent to openssl, 
but it's
not there afaik, and probably won't be for a while since the library/sdk 
needs to
support php, perl, python, ruby, blah, blah, blah instead of just a C 
library with
higher level language specific veneers on  top of it as needed.

So the reality is that any unified client is going to have to support 
what servers
demand, not the other way around. Which means it's going to have to be a 
kitchen sink
client library to handle the various choices that servers make. So I'd 
say no to
any form of an sdp-like* offer/answer protocol; it's just easier to keep 
adding to
the client kitchen sink.

Mike

[*] sdp offer/answer was necessary because of _hardware_ limitations... 
usually because
of codec complexity where an endpoint physically might not be able to 
interoperate.
that's good motivation. I doubt there's anything comparable with oauth.

>>> From: Eran Hammer-Lahav<[email-masked]>
>>> To: John Bradley<[email-masked]>; Torsten Lodderstedt
>>> <[email-masked]>
>>> Cc: "[email-masked]"<[email-masked]>

---

From: William Mills <[email-masked]>
Date: Thu, 3 Nov 2011 10:24:16 -0700 (PDT)

At this point in the process I think it would be better to add that to the threat model draft.  It would be appropriate to add it in the core spec, but not a good idea now that it's deep into the last call?

________________________________
From: Phil Hunt <[email-masked]>
To: Eran Hammer-Lahav <[email-masked]>
Cc: Justin Richer <[email-masked]>; William Mills <[email-masked]>; "[email-masked]" <[email-masked]>
Sent: Thursday, November 3, 2011 9:47 AM
Subject: Re: [OAUTH-WG] AD review of -22

+1

Phil

@independentid
www.independentid.com
[email-masked]