Subject: [OAUTH-WG] Mandatory to Implement & Interoperability

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 8 Dec 2011 16:18:47 +0200

Hi all, 

I read through this rather long mail thread again and see whether we are reaching any conclusion on this discussion. 
In turns out that there are actually two types of discussions that relate to each other, namely the TLS version support and the token type. 

Let me go back in time a little bit when I was still chairing another working group (years ago), namely the KEYPROV working group. There we ran into a similar issue, which looked fairly simple at the beginning. We worked on Portable Symmetric Key Container (PSKC),  later published as RFC 6030. We were at the stage where we thought we had to decide on a mandatory-to-implement cryptographic algorithm and, similar to the OAuth case, PSKC is one building block in a larger protocol suite. As you can imagine, everyone had their own deployment environment in mind and did not like the suggestion others made about what as mandatory to implement.

Russ (now IETF chair and at that time security area director) told the group not to worry - we don't need to pick an algorithm. He suggested to just provide a recommendation of what is best in a specific deployment environment (at the time of writing). In fact, he proposed to publish a separate document instead to discussing it in that document. 

I was surprised because I was couldn't see how one would accomplish interoperability. Russ told me that this is in practice not a problem because implementations often implement a range of cryptographic algorithms anyway. Then, as part of the algorithm negotiation procedure (or some discovery) they will figure out what both end points support. He further argued that algorithm preferences will change (as algorithms get old) and we don't want to update our specifications all the time. (This was a bit motivated by the MD5 clean-up that happened at that time.) [Please forgive me if I do not recall the exact words he said many years ago.]

I believe we are having a similar discussion here as well, both with the token type but also with the TLS version. We look at individual specifications because we are used to add security consideration sections to each and every document. Unfortunately, the most useful statements about security (for these multi-party protocols where the functionality is spread over multiple documents) can really only be made at a higher level. Our approach for describing security threats and for recommending countermeasures isn't suitable to all the documents we produce.

Let me list a few desirable results of our standardization work: 

1) Everyone wants interoperability. We can do interop testing of building blocks to see whether a client and a server are able to interact. For example, we could write a few test cases to see how two independent bearer token specifications work with each other. That approach works for some of our building blocks. I do, however, believe that we are more interested of an interoperable system consisting of several components rather than having interop between random components. Even if we do not like it, OAuth is an application level protocol that requires a number of things to be in place to make sense. 

2) We want libraries to be available that allow implementers to quickly "OAuth-enable" their Web applications, i.e., by quickly I mean that an application develop shouldn't have to write everything from scratch. Most of the development time will be spent on aspects that are not subject to standardization in the working group (such as the user interface and the actual application semantic -- the data sharing that happens once the authorization step is completed). These libraries are likely to support various extensions and getting two different implementations to interwork will IMHO in practice not be a problem. However, for a real deployment it seems that the current direction where people are going is more in the line of trust frameworks where much more than just technical interoperability is needed for a working system. See the discussions around NSTIC for that matter. 

3) We want the ability for algorithm negotiation/discovery, at least up to a certain degree. For example, it would would nice if a client talks to a server and they both implement TLS 1.2 then they actually use it. The requirement for crypto-agility fits in here as well. 

4) We want to separate the protocol specification from the cryptographic algorithms and other faster changing components. We don't want to update our protocol specification just because an algorithm becomes obsolete or the protocol suddenly gets used in a different environment where other constraints may be prevalent.  

5) The security analysis and the solution approaches will vary based on the deployment environment. During the Taipei OAuth WG meeting I tried to explain what I mean with this statement with my reference to NIST SP 800-63. For some reason I failed to get the story across and so I try it again here. 

The authors of NIST SP 800-63 (of which one is Tim Polk, former IETF security AD) noticed that identity management protocols will be used for a variety of different usages, each with different security properties, and varying privacy requirements. For this purpose, the NIST guys had introduced the famous "Level of Assurance (LoA)" concept. Different levels put different requirements on different parts of the protocol suite. There is no expectation that bearer assertions will be issued by an authorization server for usage with a client at LoA level 4. A client implementation for the health care environment may also not expect to accept LoA 1 only suitable mechanisms. 

While it may be fine for certain environments not to care about the installed code size there are certainly cases where size of code matters. I am not only thinking about the Internet of Things space but also about the vulnerabilities that are introduced by unnecessary code.  

While I understand that it would be great if anything interworks with anything else out of the box I don't see how to get there.  

Hence, I suggest that we  

a) skip specifying a mandatory-to-implement token-type, TLS version, etc. in the individual specifications, 
b) complete re-chartering and to get some of the other needed building blocks done that get us closer to an more complete "system, 
c) develop OAuth profiles and security recommendations for different security levels (in the style of what SP 800-63 outlines),
d) capture this discussion on mandatory-to-implement security mechanisms in a draft and socialize it with the rest of the IETF security community,
e) have a broader discussion about what we envision the Web identity eco-system to look like. http://tools.ietf.org/html/draft-tschofenig-secure-the-web-00 tries to make a first step but it is still at an early stage. 

Ciao
Hannes

---

From: Justin Richer <[email-masked]>
Date: Thu, 8 Dec 2011 09:30:25 -0500

+1

Very well said, Hannes.

  -- Justin

On 12/08/2011 09:18 AM, Hannes Tschofenig wrote:
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: John Bradley <[email-masked]>
Date: Thu, 8 Dec 2011 11:37:25 -0300

Agreed,   The best place for Token type and some of the other issues is in higher level profiles.

John B.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Dec 2011 07:08:02 -0800

> 3) We want the ability for algorithm negotiation/discovery, at least up to a certain degree. For example, it would would nice if a client talks to a server and they both implement TLS 1.2 then they…

I don't think that certain degree even needs to be all that
complicated. Suppose that in the future there exists a kitchen
sink liboauth which is widely available. As a service provider,
all I really care is that the client can interoperate with
me. So suppose I just generate a sdk that looks like this:

client--->MyServiceShim->liboauth ---------- 
liboauth->MyserviceShim--->server

No need for discovery or anything like that: it's baked into the
shim which I make available for all the usual suspect language
bindings. And it's still a better situation for the service provider
because they don't have to maintain liboauth... the shim becomes
nothing more than a the set of policy decisions that turn the
right knobs in the underlying library.

So did the MTI buy us anything in this -- rather likely -- scenario?
No. Whoever builds liboauth is almost by definition going to be
silent about winners and losers -- it's job is to implement everything,
not take sides.

Mike

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 8 Dec 2011 17:17:05 +0200

Hi Mike, 

I guess we are on the same page with regard to discovery/negotiation. I do not care so much how it is implemented as long it is there. 

While certain libraries may implement everything I don't think it is reasonable to assume that every deployment will have every functionality implemented. I would be super surprised. Even on a server with enough storage this is not a viable option. On constrained devices this is certainly not possible and our story cannot be built on such an assumption. 

Ciao
hannes

On Dec 8, 2011, at 5:08 PM, Michael Thomas wrote:

> client--->MyServiceShim->liboauth ---------- liboauth->MyserviceShim--->server
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 8 Dec 2011 07:42:02 -0800

+1 to both John and Hannes comments.

Phil

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

---

From: William Mills <[email-masked]>
Date: Thu, 8 Dec 2011 08:03:58 -0800 (PST)

+1

________________________________
 From: Justin Richer <[email-masked]>
To: [email-masked] 
Sent: Thursday, December 8, 2011 6:30 AM
Subject: Re: [OAUTH-WG] Mandatory to Implement & Interoperability
 
+1

Very well said, Hannes.

  -- Justin

---

From: Michael Thomas <[email-masked]>
Date: Thu, 08 Dec 2011 08:14:01 -0800

> While certain libraries may implement everything I don't think it is reasonable to assume that every deployment will have every functionality implemented. I would be super surprised. Even on a serv…

Considering that things using oauth are likely to have some sort of
browser rendering engine around, g*d help us all if an oauth library
becomes a flash space consideration :)

Mike

---

From: Torsten Lodderstedt <[email-masked]>
Date: Thu, 08 Dec 2011 19:30:20 +0100

+1

William Mills <[email-masked]> schrieb:

+1

_____________________________________________
From: Justin Richer <[email-masked]>
To: [email-masked] 
Sent: Thursday, December 8, 2011 6:30 AM
Subject: Re: [OAUTH-WG] Mandatory to Implement & Interoperability

+1

Very well said, Hannes.

  -- Justin

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 08 Dec 2011 21:15:13 +0000

> Hi all,
Hi Hannes,
> 3) We want the ability for algorithm negotiation/discovery, at least up to a certain degree. For example, it would would nice if a client talks to a server and they both implement TLS 1.2 then they…
Algorithm negotiation/discovery is always a good thing.

TLS already have this capability builtin, so doing TLS version 
negotiation at the application layer would be wrong.
> 4) We want to separate the protocol specification from the cryptographic algorithms and other faster changing components. We don't want to update our protocol specification just because an algorith…
Separating requirement on crypto from the rest of the protocol is 
generally a good thing.
> While it may be fine for certain environments not to care about the installed code size there are certainly cases where size of code matters. I am not only thinking about the Internet of Things spa…
If the WG is making a claim that OAuth is always going to be a part of 
bigger environments (e.g. healthcare, military, etc), each with its own 
requirements on security mechanisms, then I think this needs to be 
captured in one of the OAuth documents. This is your escape clause from 
the de-facto requirement to specify mandatory-to-implement mechanisms.
> d) capture this discussion on mandatory-to-implement security mechanisms in a draft and socialize it with the rest of the IETF security community,
If I were your AD, I would have asked for some demonstrated effort on d) 
and possibly c) [e.g. some drafts written] before allowing a) and b) to 
go forward.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 09 Dec 2011 12:35:59 +0000

Hannes,

I don't see any proposed text here, I see re-chartering
suggestions. The latter is not going to happen if the
current main documents are wedged. Please focus on the
former now.

You know that I disagree with you and a number of WG
participants about this, so no need for me to repeat
myself, other than to say that I've always said "pick
an MTI, *or* say (convincingly) what that's not needed"
and you've not addressed the latter. Barry's text did
do that.

The fact that a) the room in Taipei seemed to agree with
MTI, b) the list seemed to agree with Barry's suggested
text, and c) this new suggested programme also gets a
bunch of +1's all seems to me to imply that people are
not sufficiently focused on getting this finished but
would still prefer to get what they think of as
perfection.

S.

PS: I would also quibble that the lessons from keyprov
are highly relevant here, but let's not:-)

On 12/08/2011 09:15 PM, Alexey Melnikov wrote:
>> I read through this rather long mail thread again and see whether we
>> are reaching any conclusion on this discussion.
>> In turns out that there are actually two types of discussions that
>> relate to each other, namely the TLS version support and the token type.
>>
>> Let me go back in time a little bit when I was still chairing another
>> working group (years ago), namely the KEYPROV working group. There we
>> ran into a similar issue, which looked fairly simple at the beginning.
>> We worked on Portable Symmetric Key Container (PSKC), later published
>> as RFC 6030. We were at the stage where we thought we had to decide on
>> a mandatory-to-implement cryptographic algorithm and, similar to the
>> OAuth case, PSKC is one building block in a larger protocol suite. As
>> you can imagine, everyone had their own deployment environment in mind
>> and did not like the suggestion others made about what as mandatory to
>> implement.
>>
>> Russ (now IETF chair and at that time security area director) told the
>> group not to worry - we don't need to pick an algorithm. He suggested
>> to just provide a recommendation of what is best in a specific
>> deployment environment (at the time of writing). In fact, he proposed
>> to publish a separate document instead to discussing it in that document.
>>
>> I was surprised because I was couldn't see how one would accomplish
>> interoperability. Russ told me that this is in practice not a problem
>> because implementations often implement a range of cryptographic
>> algorithms anyway. Then, as part of the algorithm negotiation
>> procedure (or some discovery) they will figure out what both end
>> points support. He further argued that algorithm preferences will
>> change (as algorithms get old) and we don't want to update our
>> specifications all the time. (This was a bit motivated by the MD5
>> clean-up that happened at that time.) [Please forgive me if I do not
>> recall the exact words he said many years ago.]
>>
>> I believe we are having a similar discussion here as well, both with
>> the token type but also with the TLS version. We look at individual
>> specifications because we are used to add security consideration
>> sections to each and every document. Unfortunately, the most useful
>> statements about security (for these multi-party protocols where the
>> functionality is spread over multiple documents) can really only be
>> made at a higher level. Our approach for describing security threats
>> and for recommending countermeasures isn't suitable to all the
>> documents we produce.
>>
>> 1) Everyone wants interoperability. We can do interop testing of
>> building blocks to see whether a client and a server are able to
>> interact. For example, we could write a few test cases to see how two
>> independent bearer token specifications work with each other. That
>> approach works for some of our building blocks. I do, however, believe
>> that we are more interested of an interoperable system consisting of
>> several components rather than having interop between random
>> components. Even if we do not like it, OAuth is an application level
>> protocol that requires a number of things to be in place to make sense.
>>
>> 2) We want libraries to be available that allow implementers to
>> quickly "OAuth-enable" their Web applications, i.e., by quickly I mean
>> that an application develop shouldn't have to write everything from
>> scratch. Most of the development time will be spent on aspects that
>> are not subject to standardization in the working group (such as the
>> user interface and the actual application semantic -- the data sharing
>> that happens once the authorization step is completed). These
>> libraries are likely to support various extensions and getting two
>> different implementations to interwork will IMHO in practice not be a
>> problem. However, for a real deployment it seems that the current
>> direction where people are going is more in the line of trust
>> frameworks where much more than just technical interoperability is
>> needed for a working system. See the discussions around NSTIC for that
>> matter.
>>
>> 3) We want the ability for algorithm negotiation/discovery, at least
>> up to a certain degree. For example, it would would nice if a client
>> talks to a server and they both implement TLS 1.2 then they actually
>> use it. The requirement for crypto-agility fits in here as well.
>> 4) We want to separate the protocol specification from the
>> cryptographic algorithms and other faster changing components. We
>> don't want to update our protocol specification just because an
>> algorithm becomes obsolete or the protocol suddenly gets used in a
>> different environment where other constraints may be prevalent.
>> 5) The security analysis and the solution approaches will vary based
>> on the deployment environment. During the Taipei OAuth WG meeting I
>> tried to explain what I mean with this statement with my reference to
>> NIST SP 800-63. For some reason I failed to get the story across and
>> so I try it again here.
>>
>> The authors of NIST SP 800-63 (of which one is Tim Polk, former IETF
>> security AD) noticed that identity management protocols will be used
>> for a variety of different usages, each with different security
>> properties, and varying privacy requirements. For this purpose, the
>> NIST guys had introduced the famous "Level of Assurance (LoA)"
>> concept. Different levels put different requirements on different
>> parts of the protocol suite. There is no expectation that bearer
>> assertions will be issued by an authorization server for usage with a
>> client at LoA level 4. A client implementation for the health care
>> environment may also not expect to accept LoA 1 only suitable mechanisms.
>>
>> While it may be fine for certain environments not to care about the
>> installed code size there are certainly cases where size of code
>> matters. I am not only thinking about the Internet of Things space but
>> also about the vulnerabilities that are introduced by unnecessary code.
>> While I understand that it would be great if anything interworks with
>> anything else out of the box I don't see how to get there.
>>
>> Hence, I suggest that we
>>
>> b) complete re-chartering and to get some of the other needed building
>> blocks done that get us closer to an more complete "system,
>> c) develop OAuth profiles and security recommendations for different
>> security levels (in the style of what SP 800-63 outlines),
>> d) capture this discussion on mandatory-to-implement security
>> mechanisms in a draft and socialize it with the rest of the IETF
>> security community,
>> e) have a broader discussion about what we envision the Web identity
>> eco-system to look like.
>> http://tools.ietf.org/html/draft-tschofenig-secure-the-web-00 tries to
>> make a first step but it is still at an early stage.
>>
>> Ciao
>> Hannes
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 9 Dec 2011 08:30:18 -0700

I can work with Berry's text.

Another alternative is to:

* Require the server to implement at least one of Bearer and MAC, or provide the client with a method for discovering or requesting a specific token type (which is beyond the scope).

This way, until there is a discovery method, each server must support at least one of these two (which is not an unreasonable requirement given that these two cover all the use cases the community has come up with in 5 years). Clients that want to ensure interoperability then, must understand both, but the requirement isn't on the client. In practice, this will keep every existing implementation already in compliance, and will offer clients a guaranteed path to interop is the client so chooses.

The advantage of this approach is that it can be expressed with one sentence and it should not offend those objecting to MTI MAC tokens.

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stephen Farrell
> Sent: Friday, December 09, 2011 4:36 AM
> To: Hannes Tschofenig
> Cc: [email-masked] WG
> I don't see any proposed text here, I see re-chartering suggestions. The
> latter is not going to happen if the current main documents are wedged.
> Please focus on the former now.
> 
> You know that I disagree with you and a number of WG participants about
> this, so no need for me to repeat myself, other than to say that I've always
> said "pick an MTI, *or* say (convincingly) what that's not needed"
> and you've not addressed the latter. Barry's text did do that.
> 
> The fact that a) the room in Taipei seemed to agree with MTI, b) the list
> seemed to agree with Barry's suggested text, and c) this new suggested
> programme also gets a bunch of +1's all seems to me to imply that people are
> not sufficiently focused on getting this finished but would still prefer to get
> what they think of as perfection.
> 
> S.
> 
> PS: I would also quibble that the lessons from keyprov are highly relevant
> here, but let's not:-)
> 
> >> as RFC 6030. We were at the stage where we thought we had to decide
> >> on a mandatory-to-implement cryptographic algorithm and, similar to
> >> the OAuth case, PSKC is one building block in a larger protocol
> >> suite. As you can imagine, everyone had their own deployment
> >> environment in mind and did not like the suggestion others made about
> >> what as mandatory to implement.
> >>
> >> Russ (now IETF chair and at that time security area director) told
> >> the group not to worry - we don't need to pick an algorithm. He
> >> suggested to just provide a recommendation of what is best in a
> >> specific deployment environment (at the time of writing). In fact, he
> >> proposed to publish a separate document instead to discussing it in that
> document.
> >>
> >> approach works for some of our building blocks. I do, however,
> >> believe that we are more interested of an interoperable system
> >> consisting of several components rather than having interop between
> >> random components. Even if we do not like it, OAuth is an application
> >> level protocol that requires a number of things to be in place to make
> sense.
> >>
> >> quickly "OAuth-enable" their Web applications, i.e., by quickly I
> >> mean that an application develop shouldn't have to write everything
> >> from scratch. Most of the development time will be spent on aspects
> >> that are not subject to standardization in the working group (such as
> >> the user interface and the actual application semantic -- the data
> >> sharing that happens once the authorization step is completed). These
> >> needed for a working system. See the discussions around NSTIC for
> >> that matter.
> >>
> >> matters. I am not only thinking about the Internet of Things space
> >> but also about the vulnerabilities that are introduced by unnecessary
> code.
> > bigger environments (e.g. healthcare, military, etc), each with its
> > own requirements on security mechanisms, then I think this needs to be
> > captured in one of the OAuth documents. This is your escape clause
> > from the de-facto requirement to specify mandatory-to-implement
> mechanisms.
> >> b) complete re-chartering and to get some of the other needed
> >> building blocks done that get us closer to an more complete "system,
> > If I were your AD, I would have asked for some demonstrated effort on
> > d) and possibly c) [e.g. some drafts written] before allowing a) and
> > b) to go forward.
> >> http://tools.ietf.org/html/draft-tschofenig-secure-the-web-00 tries
> >> to make a first step but it is still at an early stage.
> >>
> >> Ciao
> >> Hannes
> >