Subject: [OAUTH-WG] Stephen Farrell's No Objection on draft-ietf-oauth-assertions-18: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 21 Oct 2014 14:33:20 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-oauth-assertions-18: No Objection

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/

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

Thanks for adding the MTI algorithms to the saml and jwt docs
to clear the discuss I put on this one.

I didn't check the comments below.

- 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: John Bradley <[email-masked]>
Date: Tue, 21 Oct 2014 19:00:42 -0300

On the topic of relay protection we added "jti" (JWT ID) Claim to the JWT spec so that we would have a claim to use for replay detection on assertions.

In the Connect profile of the JWT assertions spec for client authentication we did make it required for the sender to include it, but gave some flexibility to the server in interpreting it.

For self signed assertions used as client authentication I think allowing the server to detect replay attacks is probably a good thing.

For authorization assertions the issues get more complicated and, probably shouldn't be locked down at this layer.

There may be reasons for not detecting replay for authentication as well that I am not aware of.

I suspect that as Connect did applications using these specifications will profile them to include replay protection if required.

I am bothered by it not being required in these specs. 

I do remember a discussion on this, but would have a hard time pointing to it now.

John B.

On Oct 21, 2014, at 6:33 PM, Stephen Farrell <[email-masked]> wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth