Hi Brian, thanks for your response. I have tried to put additional text into version -04 of the draft to address my earlier comments.
The most recent version of the updated document is there: https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.txt Here is the XML: https://github.com/hannestschofenig/tschofenig-ids/blob/master/oauth-assertions/draft-ietf-oauth-assertions-04.xml It took me a little while to make these changes, as you can imagine. I hope I was able to improve the quality and clarity of the document. I still have to respond to your second mail about the relaxed usage of the RFC 2119 language. Will do that asap. Ciao Hannes On May 30, 2012, at 11:46 PM, Brian Campbell wrote: > Thanks for the comments Hannes. I've attempted to answer some of your > questions/comments inline below (or at least provide some additional info, > context or explanation). > > On Thu, May 24, 2012 at 12:39 PM, Hannes Tschofenig > <hannes.tschofe...@gmx.net> wrote: > Hi Chuck, Mike, Brian, and Yaron, > > I reviewed the document as part of my shepherding role and I believe there is > still room for improvement with the document. I think the document suffers > from the problem that you essentially want to cover every possible use case > in a single document. So, let me start with a high-level mail. > > You are covering two quite different usage scenarios that are only related to > each other by the usage of assertions, namely > > 1. Using Assertions for Client Authentication > > 2. Using Assertions as Authorization Grants > > (Of course these two usages can happen in the same protocol exchange; this > means that you have two assertions in the same message obtained from > different entities with potentially very different properties.) > > It is OK to have these two cases in a single document but the introduction > and section 3 need to untangle them and to describe the use cases to the > reader. In fact, the second part of the document (from section 4 onwards) > does a better job in separating the two cases. > > Yeah, putting them together has its advantages and disadvantages and causing > confusing between the two cases is one of the biggest downsides. Proposed > text that helps untangle the two usages for the reader/implementer would most > definitely be welcomed. > > > I was also wondering what use cases you guys find most interested among all > the options I list below? What have you implemented and deployed (I need that > info for the shepherd writeup)? Maybe we should highlight them in the intro. > > > The primary case I've seen deployed is in an "enterprise to SaaS" model using > SAML assertions as authorization grants. The enterprise has some kind of STS > that can issue assertions and trust has been established between the STS and > the enterprise's accounts at the SaaS. The client presents some kind local > authentication/authorization to the STS and receives a suitable assertion in > exchange. That exchange is via WS-Trust in the deployments I've seen but > that's far from the only way it can be done. Once the client has the > assertion, the OAuth assertion profile/grant type can be employed to get an > OAuth access token from the AS at the SaaS. Then that token be used to access > the SaaS's protected resources/APIs. The trust established between the > enterprise STS and the SaaS is usually already in place and being used to > facilitate Web SSO traffic. > > For the sake of disclosure, my company offers a product that acts in the STS > role described above and one of my co-author's companies is very often the > SaaS. Our product also supports the AS role in that exchange to help enable > organizations to do what the aforementioned SaaS is doing. > > In my experience there has been more initial interest in assertions as grants > than for client authentication. But I'll note that OpenID Connect > specifically calls out the JWT assertion profile as one option for client > authentication. > > > > Regarding the security aspects: I assume that the assertions is always > signed. (I guess you make this assumption as well.) > > Yes and the draft should say as much. The end of §5.2 explicit says "The > Authorization Server MUST validate the assertion's signature..." and there > are a number of other places where the text would seem to imply that the > token/assertion is always singed. Do you think it needs to be made more > explicit? > > > There are a few considerations: > > a) Who creates and signs the assertion? > > It really depends on the situation. The draft in §5.1 defines it as the > Issuer and attempts to give some ideas about how that might work without > being overly prescriptive or restrictive. > > > You sometimes use the term "Security Token Service (STS)" but it is not > introduced in the terminology. Let us assume that this is a third party > entity (and not a role the client can take). > > So, we have two cases: > > -- Assertions obtained from the STS > > -- Assertions self-generated by the client > > Needless to say that the security properties are different between the two. > In the second case the party receiving the assertion cannot trust the content > in the assertion since it had been minted by the client, an untrusted party. > > The client is not necessarily untrusted. In the case where the client is the > issuer, it really needs to be trusted for it to work. That probably makes the > most sense when using assertions as client authentication where the client > sends an assertion that demonstrates possession of a (symmetric or > asymmetric) secret. But it really depends on the situation so that's just one > possibility. > > > Also note that the protocol for obtaining the assertion from the STS may not > have been standardized, which consequently does not necessarily increase > interoperability when deploying such a solution. Any story for this? How did > you handle this in your implementations & deployments? > > Interoperability between the client and the AS is the primary goal of this > spec (and the SAML/JWT incarnations of it). That may impose some requirements > on the STS with respect to the actual content and format of the assertion. > However, the rest of the client <-> STS exchange should have no bearing on > interop (other than between those two parties but that is out of scope here). > > > For what it's worth, as I mentioned earlier, my product offers WS-Trust as a > means for obtaining the assertion. It's not the only way and it's arguably > not ideal. But it is a standard for token exchange and it was something we > already had a lot of infrastructure in place to support in our product. > > > Let us focus on the cases where the assertion is obtained from an STS. Then, > the assertion is signed by the STS (hopefully) and if the client presents it > then it can do that in two ways: > > -- Conveying the assertion as a Bearer Assertion (i.e., possession is the > security) and hopefully the exchange runs over TLS. Replay protection can be > provided via the parameters in the assertion assuming the client has a > capability to obtain assertions on the fly using some protocol to essentially > present a refresh assertion with (almost) every exchange since otherwise the > provided security really suffers. > > FWIW, this whole document more or less assumes that the assertion will be a > bearer assertion. I don't think there's anything necessarily preventing a > holder of key profile from being written on top of it but the SAML/JWT > realizations of this draft are explicitly and intentionally limited in scope > to the bearer case. > > And yes, this exchange must run over TLS (OAuth core at > http://tools.ietf.org/html/draft-ietf-oauth-v2-26#section-3.2 mandates it for > the token endpoint which then is inherited by this spec). > > > -- Using the assertion together with a holder-of-the-key concept. In this > case the assertion would be signed by the STS and then the client in addition > needs to show possession of a secret (which is bound to the token). This > secret (either a shared key or a public/private key pair had been obtained > somehow). > > Again, I think a HoK assertion/confirmation could be profiled from this draft > but it hasn't been done yet and I really haven't heard anyone asking for it. > > > Furthermore, the document at various places talks about the great security > properties and I believe that this is a bit misleading. The great security > properties are only there when you either use > > * a STS obtained assertion with a holder-of-a-key assertion, or > > * let the client sign the assertion (in which case the assertion is quite > degenerated*). > > I believe those security benefits are really only particularly relevant for > [H]MAC'd assertion being used for client authentication as an alternative to > sending the client secret directly via HTTP Basic or as a parameter. This > should probably be made more clear so as not to be misleading. > > > It may also be worth noting that not all assertions can be signed with > symmetric as well as asymmetric credentials. A SAML assertion, for example, > can only be signed with an asymmetric credential (at last to my knowledge). > > > > That is standard practice with SAML and the only thing I've ever seen > implemented/deployed but there is nothing that actually mandates asymmetric > signatures in SAML. > > > 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
