Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03
Hi Hannes, Near the end of §1 of your draft -04 you discuss client authentication with the Resource Server by saying that the client authentication concerns steps (E) and (F) in figure 1. However, my reading of §2.3 of the core OAuth Framework[1] was that only client authentication to the AS was in scope for the spec. Following from that, my assumption and intent with the assertion spec was that client assertion authentication is only defined for a client authenticating to the token endpoint of an AS. §3 of the -03 of the assertions doc[2] even says, "This specification provides a model for using assertions for authentication of an OAuth client during interactions with an Authorization Server". Was there something in the -03 draft (or the core spec for that matter) that suggested it was intended for client to RS authentication? I don't think specifying that (other than in defining how an access token is presented like draft-ietf-oauth-v2-bearer does) that would be appropriate. Maybe some clarification is needed? Thanks, Brian [1] http://tools.ietf.org/html/draft-ietf-oauth-v2-28#section-2.3 [2] http://tools.ietf.org/html/draft-ietf-oauth-assertions-03#section-3 On Sun, Jun 24, 2012 at 7:42 AM, Hannes Tschofenig < hannes.tschofe...@gmx.net> wrote: > 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 > > ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03
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 > 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)
Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03
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 neces
Re: [OAUTH-WG] Review of draft-ietf-oauth-assertions-03
Just catching up here - thanks for the comments Hannes. Did you merge these in by yourself? -cmort On May 24, 2012, at 11:39 AM, Hannes Tschofenig 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. 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. > > Regarding the security aspects: I assume that the assertions is always > signed. (I guess you make this assumption as well.) > > There are a few considerations: > > a) Who creates and signs the assertion? > > 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. > > 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? > > 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. > > -- 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). > > 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*). > > 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). > > 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-WG] Review of draft-ietf-oauth-assertions-03
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. 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. Regarding the security aspects: I assume that the assertions is always signed. (I guess you make this assumption as well.) There are a few considerations: a) Who creates and signs the assertion? 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. 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? 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. -- 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). 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*). 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). Ciao Hannes ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
