+1
________________________________
From: Justin Richer <jric...@mitre.org>
To: oauth@ietf.org
Sent: Thursday, December 8, 2011 6:30 AM
Subject: Re: [OAUTH-WG] Mandatory to Implement & Interoperability
+1
Very well said, Hannes.
-- Justin
On 12/08/2011 09:18 AM, Hannes Tschofenig wrote:
> 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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
