Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03

[Brian Campbell <[e-mail]>]

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 <
[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>