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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
