Subject: [OAUTH-WG] Stephen Farrell's Discuss on draft-ietf-oauth-assertions-17: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 16 Oct 2014 04:22:13 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-assertions-17: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Putting one discuss here rather than one on each of the other
docs. We can fix that as appropriate after we chat.  Where are
the MTI signature and mac algs for these specified? If those
can be tracked back via the SAML and jose docs that's fine,
but I'm not sure if they are.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- general: What prevents/detects conflicts between the oauth
scope parameter and the saml or jwt equivalent?  Are there
other bits of replicated data that could be the basis for a
vulnerability?

(The comment below applies for both saml and jwt so 
putting it here.)

- The no replay protection issue was debated in the
WG wasn't it? (I think I recall it, not sure.) Seems like a
bad plan to me to not require at least implementation of
replay protection in the AS so that it can be turned on. Can
you point me at where that was discussed on the list?

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Oct 2014 14:06:24 -0600

Thanks for your review and feedback on this one too, Stephen. Replies are
inline below...

> http://datatracker.ietf.org/doc/draft-ietf-oauth-assertions/

I believe they can be.

JOSE Implementation Requirements for JWS are in the table in JWA §3.1
https://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-34#section-3.1

And there's §5 SAML and XML Signature Syntax and Processing
http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Scope is not represented inside the assertion (JWT or SAML) so there's no
potential for conflict.

> you point me at where that was discussed on the list?
I described my recollection and justification of the optionality of one
particular type of replay protection in a message yesterday:
http://www.ietf.org/mail-archive/web/oauth/current/msg13567.html

It's worth mentioning that there are different ideas of what replay is and
what to protect against. The one particular type mentioned above is pretty
narrow - checking to see if the same token is used again at the same
relying party.

There are other kinds of more sinister replay which are prevented by
properly audience restricting the assertions. The audience restriction
let's the issuer say specifically what relying party is allowed to consume
the assertion, which ensures that the client can't use it somewhere where
it wasn't intended and that the relying party that receives the assertion
can't turn around and use it to access some other service.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Oct 2014 22:00:56 +0100

Hiya,

> http://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf

Hmm. So the SAML one only seems to have RSA-SHA1 as the MTI and the
JOSE one has only H256 as required.

Doesn't that seem like one is unacceptably old and the other
is not great for this purpose?

My suggestion would be to add rsa-sha256 as MTI for these, as an
addition to whatever JOSE and SAML make MTI. But I'd be happy to
clear if you made any modern signature alg MTI.

Cheers,
S.

PS: Stuff below is fine.

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Oct 2014 15:39:56 -0600

Hiya in return and inline below...

> is not great for this purpose?

Admittedly, I was a little worried you'd say that :)

> clear if you made any modern signature alg MTI.
Honestly, in my view, an MIT on these doesn't make a whole lot of sense as
I think what's actually implemented/supported will be dictated by the
larger deployments of SAML/SAMLP or JWT/JOSE/OpenID Connect. My feeling is
that an MIT in these specs would likely be ignored and/or not influence
implementers/deployers. So my preference would be to leave MTI out of these.

But if you're not swayed by that line of thinking, and I'm guessing you're
not, rsa-sha256 is probably the most appropriate choice. Could you give
some guidance and/or point to examples of where and how to say that
appropriately in the documents? Thanks!

> PS: Stuff below is fine.
Great, thank you.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Oct 2014 22:56:15 +0100

> Admittedly, I was a little worried you'd say that :)

I'm glad we're not surprising one another:-)

> appropriately in the documents? Thanks!

Sure, I'd say probably best is for the jwt one to say that RS256
MUST be supported and for the saml one say that [1] MUST be
supported. (Check [2] for rsa-sha256 for some text)

A sentence in each is all's needed.

Cheers,
S.

[1] http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
[2] http://www.w3.org/TR/2013/NOTE-xmlsec-algorithms-20130411/

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 16 Oct 2014 17:57:19 -0400

On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell <[email-masked]>
wrote:

> On Thu, Oct 16, 2014 at 3:00 PM, Stephen Farrell <
> [email-masked]> wrote:
>
>>

I'm going to back Stephen up on this one.  It best that we do point out the
right thing to do, even if it's not always followed.  Some will expect
implementations to be complaint to the standard and that will hopefully
drive implementations to better choices for algorithms.  We have too many
issues of deployed code and applications using things they should not
(SSLv3).

>
>
>> Cheers,
>> S.
>>
>> PS: Stuff below is fine.
>>
>>
> Great, thank you.
>
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

-- 

Best regards,
Kathleen

---

From: Brian Campbell <[email-masked]>
Date: Thu, 16 Oct 2014 16:15:08 -0600

Alright, I'll add RS256 and
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 as mandatory to implement
in the next revision of draft-ietf-oauth-jwt-bearer and
draft-ietf-oauth-saml2-bearer respectively.

Thanks for the pointers, Stephen.

On Thu, Oct 16, 2014 at 3:57 PM, Kathleen Moriarty <
[email-masked]> wrote:

>
>
> On Thu, Oct 16, 2014 at 5:39 PM, Brian Campbell <
> [email-masked]> wrote:
>
>> Honestly, in my view, an MIT on these doesn't make a whole lot of sense
>> as I think what's actually implemented/supported will be dictated by the
>> But if you're not swayed by that line of thinking, and I'm guessing
>> you're not, rsa-sha256 is probably the most appropriate choice. Could you
>> give some guidance and/or point to examples of where and how to say that
> I'm going to back Stephen up on this one.  It best that we do point out
> the right thing to do, even if it's not always followed.  Some will expect