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

[Eran Hammer-Lahav <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On Behalf
> Of Stephen Farrell
> Sent: Friday, December 09, 2011 4:36 AM
> To: Hannes Tschofenig
> Cc: [e-mail] WG
> Subject: Re: [OAUTH-WG] Mandatory to Implement & Interoperability
> 
> 
> 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:
> > On 08/12/2011 14:18, Hannes Tschofenig wrote:
> >> Hi all,
> > Hi Hannes,
> > Some random thoughts about your message below:
> >> 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.
> > 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
> >> algorithm becomes obsolete or the protocol suddenly gets used in a
> >> different environment where other constraints may be prevalent.
> > Separating requirement on crypto from the rest of the protocol is
> > generally a good thing.
> >> 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.
> > 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.
> >> 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,
> > 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.
> >> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/oauth
> >
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth