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