[OAUTH-WG] I-D Action: draft-ietf-oauth-urn-sub-ns-02.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : An IETF URN Sub-Namespace for OAuth Author(s) : Hannes Tschofenig Filename: draft-ietf-oauth-urn-sub-ns-02.txt Pages : 5 Date: 2012-01-03 This document establishes an IETF URN Sub-namespace for use with OAuth related specifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-urn-sub-ns-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-urn-sub-ns-02.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
[OAUTH-WG] I-D Action: draft-ietf-oauth-saml2-bearer-10.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Web Authorization Protocol Working Group of the IETF. Title : SAML 2.0 Bearer Assertion Profiles for OAuth 2.0 Author(s) : Chuck Mortimore Filename: draft-ietf-oauth-saml2-bearer-10.txt Pages : 16 Date: 2012-01-03 This specification defines the use of a SAML 2.0 Bearer Assertion as means for requesting an OAuth 2.0 access token as well as for use as a means of client authentication. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-oauth-saml2-bearer-10.txt ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
Is all this only around the scope parameter? My mail cited below is with regards to the character set for a valid scope parameter, which we should be able to define and then lean on the HTTPbis spec for the actual parameter syntax. From: Mike Jones michael.jo...@microsoft.com To: Julian Reschke julian.resc...@gmx.de Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org; OAuth WG oauth@ietf.org Sent: Friday, December 30, 2011 3:19 PM Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15? I did already back the statement that this is the working group consensus with the e-mails attached in this note sent to you on December 12, 2011: - http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html But since that apparently wasn't convincing to you that this working group decision represents more than just me disagreeing with you, here are references to individual messages referenced in the above e-mail: - Eran Hammer-Lahav: http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html - John Bradley: http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html - William Mills: http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html - Mike Jones: http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html - Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html - Justin Richer: http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html As for your assertion that the specs are in conflict, yes, the Bearer spec includes a different decision than a RECOMMENDED clause in the HTTPbis spec (which was added after the Bearer text was already in place). However, it is not violating any MUST clauses in the HTTPbis spec. Given that no MUSTS are violated, I don't see it mandatory for this tension to be resolved in favor of one spec or the other in order for both to be approved as RFCs. I look forward to seeing that happen soon in both cases (and for the OAuth core spec as well). Best wishes, -- Mike -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Friday, December 30, 2011 2:26 AM To: Mike Jones Cc: Barry Leiba; Mark Nottingham; OAuth WG Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft 15? On 2011-12-29 22:18, Mike Jones wrote: You proposed, Julian 3. Do not specify the ABNF. The ABNF of the WWW-Authenticate is defined in HTTPbis. Just state the names of the parameters, their syntax *after* parsing and their semantics. About some of Mark Nottingham's comments, Barry wrote Let me point out that this represents working-group consensus is not always a valid response. If the working group has actually considered the *issue*, that might be OK. But if there's consensus for the chosen solution and someone brings up a *new* issue with it, that issue needs to be addressed anew. Relative to these two statements, I believe that I should remark at this point that your proposed semantics of only considering the syntax after potential quoting was explicitly considered earlier by the working group and rejected. The consensus, instead, was for the present no quoting will occur for legal inputs semantics. It would be helpful if you could back this statement with pointers to mails. As far as I can tell it's just you disagreeing with me. Back to the facts: a) the bearer spec defines an HTTP authentication scheme, and normatively refers to HTTPbis Part7 for that b) HTTPbis recommends new scheme definitions not to have their own ABNF, as the header field syntax is defined by HTTPbis, not the individual scheme c) the bearer spec defines it's own ABNF nevertheless So the two specs are in conflict, and we should resolve the conflict one way or the other. If you disagree with the recommendation in HTTPbis, then you really really should come over to HTTPbis WG and argue your point of view. If you agree with it, but think that the bearer spec can't follow the recommendation, then it would be good to explain the reasoning (optimally in the spec). If you agree with it, and think the bearer spec *could* follow it, then... change it, by all means. Anyway, if this issue isn't resolved before IETF LC then it will be raised again at that time. I believe that in the New Year the chairs and area directors will need to decide how to proceed on this issue. (The working group consensus, as I see it, is already both well-informed and clear on this point, but I understand that that's not the only consideration.) It would be good to see the spec finished shortly. ... Best regards, Julian ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth___ OAuth mailing list OAuth@ietf.org
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
This is about the syntax for the scope, error, and error_description
parameters. The pertinent text from Section 3
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15#section-3 is:
Producers of scope strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of error and error_description
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of error-uri
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, error-uri
strings MUST conform to the URI-Reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
Cheers,
-- Mike
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Is all this only around the scope parameter? My mail cited below is with
regards to the character set for a valid scope parameter, which we should be
able to define and then lean on the HTTPbis spec for the actual parameter
syntax.
From: Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
To: Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba
barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
I did already back the statement that this is the working group consensus with
the e-mails attached in this note sent to you on December 12, 2011:
- http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
But since that apparently wasn't convincing to you that this working group
decision represents more than just me disagreeing with you, here are
references to individual messages referenced in the above e-mail:
- Eran Hammer-Lahav:
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
- John Bradley:
http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
- William Mills:
http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
- Mike Jones:
http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
- Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
- Justin Richer:
http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html
As for your assertion that the specs are in conflict, yes, the Bearer spec
includes a different decision than a RECOMMENDED clause in the HTTPbis spec
(which was added after the Bearer text was already in place). However, it is
not violating any MUST clauses in the HTTPbis spec. Given that no MUSTS are
violated, I don't see it mandatory for this tension to be resolved in favor of
one spec or the other in order for both to be approved as RFCs. I look forward
to seeing that happen soon in both cases (and for the OAuth core spec as well).
Best wishes,
-- Mike
-Original Message-
From: Julian Reschke
[mailto:julian.resc...@gmx.demailto:julian.resc...@gmx.de]
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft
15?
On 2011-12-29 22:18, Mike Jones wrote:
You proposed, Julian 3. Do not specify the ABNF. The ABNF of the
WWW-Authenticate is defined in HTTPbis. Just state the names of the
parameters, their syntax *after* parsing and their semantics.
About some of Mark Nottingham's comments, Barry wrote Let me point out that
this represents working-group consensus is not always a valid response. If
the working group has actually considered the *issue*, that might be OK. But
if there's consensus for the chosen solution and someone brings up a *new*
issue with it, that issue needs to be addressed anew.
Relative to these two statements, I believe that I should remark at this
point that your proposed semantics of only considering the syntax after
potential quoting was explicitly considered earlier by the working group and
rejected. The consensus, instead, was for the present no quoting will occur
for legal inputs semantics.
It would be helpful if you could back this statement with pointers to mails. As
far as I can tell it's just you disagreeing with me.
Back to the facts:
a) the bearer spec defines an HTTP authentication scheme, and normatively
refers to HTTPbis Part7 for that
b) HTTPbis
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
Why is Bearer dealing with this at all? the BNF for that stuff should be part
of the core spec, and additional values perhaps defined in Bearer.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
This is about the syntax for the scope, error, and error_description
parameters. The pertinent text from Section 3 is:
Producers of scope strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of error and error_description
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of error-uri
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, error-uri
strings MUST conform to the URI-Reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
Cheers,
-- Mike
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Is all this only around the scope parameter? My mail cited below is with
regards to the character set for a valid scope parameter, which we should be
able to define and then lean on the HTTPbis spec for the actual parameter
syntax.
From:Mike Jones michael.jo...@microsoft.com
To: Julian Reschke julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
I did already back the statement that this is the working group consensus with
the e-mails attached in this note sent to you on December 12, 2011:
- http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
But since that apparently wasn't convincing to you that this working group
decision represents more than just me disagreeing with you, here are
references to individual messages referenced in the above e-mail:
- Eran Hammer-Lahav:
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
- John Bradley:
http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
- William Mills:
http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
- Mike Jones:
http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
- Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
- Justin Richer:
http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html
As for your assertion that the specs are in conflict, yes, the Bearer spec
includes a different decision than a RECOMMENDED clause in the HTTPbis spec
(which was added after the Bearer text was already in place). However, it is
not violating any MUST clauses
in the HTTPbis spec. Given that no MUSTS are violated, I don't see it
mandatory for this tension to be resolved in favor of one spec or the other in
order for both to be approved as RFCs. I look forward to seeing that happen
soon in both cases (and for the
OAuth core spec as well).
Best wishes,
-- Mike
-Original Message-
From: Julian Reschke [mailto:julian.resc...@gmx.de]
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft
15?
On 2011-12-29 22:18, Mike Jones wrote:
You proposed, Julian 3. Do not specify the ABNF. The ABNF of the
WWW-Authenticate is defined in HTTPbis. Just state the names of the
parameters, their syntax *after* parsing and their semantics.
About some of Mark Nottingham's comments, Barry wrote Let me point out that
this represents working-group consensus is not always a valid response. If
the working group has actually considered the *issue*, that might be OK. But
if there's consensus for
the chosen solution and someone brings up a *new* issue with it, that issue
needs to be addressed anew.
Relative to these two statements, I believe that I should remark at this
point that your proposed semantics of only considering the syntax after
potential quoting was explicitly considered earlier by the working group and
rejected. The consensus, instead,
was for the present no quoting
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
The core spec doesn't include these parameters.
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Why is Bearer dealing with this at all? the BNF for that stuff should be part
of the core spec, and additional values perhaps defined in Bearer.
From: Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; Julian
Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba
barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
This is about the syntax for the scope, error, and error_description
parameters. The pertinent text from Section 3
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15#section-3 is:
Producers of scope strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of error and error_description
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of error-uri
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, error-uri
strings MUST conform to the URI-Reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
Cheers,
-- Mike
From: William Mills
[mailto:wmi...@yahoo-inc.com]mailto:[mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Is all this only around the scope parameter? My mail cited below is with
regards to the character set for a valid scope parameter, which we should be
able to define and then lean on the HTTPbis spec for the actual parameter
syntax.
From: Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
To: Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba
barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
I did already back the statement that this is the working group consensus with
the e-mails attached in this note sent to you on December 12, 2011:
- http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
But since that apparently wasn't convincing to you that this working group
decision represents more than just me disagreeing with you, here are
references to individual messages referenced in the above e-mail:
- Eran Hammer-Lahav:
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
- John Bradley:
http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
- William Mills:
http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
- Mike Jones:
http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
- Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
- Justin Richer:
http://www.ietf.org/mail-archive/web/oauth/current/msg07692.html
As for your assertion that the specs are in conflict, yes, the Bearer spec
includes a different decision than a RECOMMENDED clause in the HTTPbis spec
(which was added after the Bearer text was already in place). However, it is
not violating any MUST clauses in the HTTPbis spec. Given that no MUSTS are
violated, I don't see it mandatory for this tension to be resolved in favor of
one spec or the other in order for both to be approved as RFCs. I look forward
to seeing that happen soon in both cases (and for the OAuth core spec as well).
Best wishes,
-- Mike
-Original Message-
From: Julian Reschke
[mailto:julian.resc...@gmx.demailto:julian.resc...@gmx.de]
Sent: Friday, December 30, 2011 2:26 AM
To: Mike Jones
Cc: Barry Leiba; Mark Nottingham; OAuth WG
Subject: Re: auth-param syntax, was: [OAUTH-WG] OK to post OAuth Bearer draft
15?
On 2011-12-29 22:18, Mike Jones wrote:
You proposed, Julian 3. Do not specify the ABNF. The ABNF of the
WWW-Authenticate is defined in HTTPbis. Just state the names of the
parameters, their
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
Sorry, I should have been more precise. The Core spec doesn’t define how to
transmit these fields in the WWW-Authenticate response header field. The
Bearer spec does.
-- Mike
From: William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:14 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly has
these as predefined registered parameters. If the definition there isn't
strong enough, or in that spec, we should fix that. That is where these should
be defined.
From: Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; Julian
Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba
barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Tuesday, January 3, 2012 12:00 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
The core spec doesn’t include these parameters.
From: William Mills
[mailto:wmi...@yahoo-inc.com]mailto:[mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Why is Bearer dealing with this at all? the BNF for that stuff should be part
of the core spec, and additional values perhaps defined in Bearer.
From: Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.commailto:wmi...@yahoo-inc.com; Julian
Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba
barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
This is about the syntax for the scope, error, and error_description
parameters. The pertinent text from Section 3
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-15#section-3 is:
Producers of scope strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of error and error_description
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of error-uri
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, error-uri
strings MUST conform to the URI-Reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
Cheers,
-- Mike
From: William Mills
[mailto:wmi...@yahoo-inc.com]mailto:[mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Is all this only around the scope parameter? My mail cited below is with
regards to the character set for a valid scope parameter, which we should be
able to define and then lean on the HTTPbis spec for the actual parameter
syntax.
From: Mike Jones
michael.jo...@microsoft.commailto:michael.jo...@microsoft.com
To: Julian Reschke julian.resc...@gmx.demailto:julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.netmailto:m...@mnot.net; Barry Leiba
barryle...@computer.orgmailto:barryle...@computer.org; OAuth WG
oauth@ietf.orgmailto:oauth@ietf.org
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
I did already back the statement that this is the working group consensus with
the e-mails attached in this note sent to you on December 12, 2011:
- http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
But since that apparently wasn't convincing to you that this working group
decision represents more than just me disagreeing with you, here are
references to individual messages referenced in the above e-mail:
- Eran Hammer-Lahav:
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
- John Bradley:
http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
- William Mills:
http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
- Mike Jones:
Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft 15?
OK, then the core spec should.
From: Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 12:20 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Sorry, I should have been more precise. The Core spec doesn’t define how to
transmit these fields in the WWW-Authenticate response header field. The
Bearer spec does.
-- Mike
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:14 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
http://tools.ietf.org/html/draft-ietf-oauth-v2-22#section-11.2.2 certainly has
these as predefined registered parameters. If the definition there isn't
strong enough, or in that spec, we should fix that. That is where these should
be defined.
From:Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 12:00 PM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
The core spec doesn’t include these parameters.
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 12:00 PM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Why is Bearer dealing with this at all? the BNF for that stuff should be part
of the core spec, and additional values perhaps defined in Bearer.
From:Mike Jones michael.jo...@microsoft.com
To: William Mills wmi...@yahoo-inc.com; Julian Reschke
julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Tuesday, January 3, 2012 11:46 AM
Subject: RE: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
This is about the syntax for the scope, error, and error_description
parameters. The pertinent text from Section 3 is:
Producers of scope strings MUST NOT use characters outside the set
%x21 / %x23-5B / %x5D-7E for representing the scope values and %x20
for the delimiter. Producers of error and error_description
strings MUST NOT use characters outside the set %x20-21 / %x23-5B /
%x5D-7E for representing these values. Producers of error-uri
strings MUST NOT use characters outside the set %x21 / %x23-5B /
%x5D-7E for representing these values. Furthermore, error-uri
strings MUST conform to the URI-Reference syntax. In all these
cases, no character quoting will occur, as senders are prohibited
from using the %5C ('\') character.
Cheers,
-- Mike
From:William Mills [mailto:wmi...@yahoo-inc.com]
Sent: Tuesday, January 03, 2012 11:36 AM
To: Mike Jones; Julian Reschke
Cc: Mark Nottingham; Barry Leiba; OAuth WG
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
Is all this only around the scope parameter? My mail cited below is with
regards to the character set for a valid scope parameter, which we should be
able to define and then lean on the HTTPbis spec for the actual parameter
syntax.
From:Mike Jones michael.jo...@microsoft.com
To: Julian Reschke julian.resc...@gmx.de
Cc: Mark Nottingham m...@mnot.net; Barry Leiba barryle...@computer.org;
OAuth WG oauth@ietf.org
Sent: Friday, December 30, 2011 3:19 PM
Subject: Re: [OAUTH-WG] auth-param syntax, was: OK to post OAuth Bearer draft
15?
I did already back the statement that this is the working group consensus with
the e-mails attached in this note sent to you on December 12, 2011:
- http://www.ietf.org/mail-archive/web/oauth/current/msg08042.html
But since that apparently wasn't convincing to you that this working group
decision represents more than just me disagreeing with you, here are
references to individual messages referenced in the above e-mail:
- Eran Hammer-Lahav:
http://www.ietf.org/mail-archive/web/oauth/current/msg07698.html
- John Bradley:
http://www.ietf.org/mail-archive/web/oauth/current/msg07699.html
- William Mills:
http://www.ietf.org/mail-archive/web/oauth/current/msg07700.html
- Mike Jones:
http://www.ietf.org/mail-archive/web/oauth/current/msg07701.html
- Phil Hunt: http://www.ietf.org/mail-archive/web/oauth/current/msg07702.html
- Justin Richer:
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
Well, this exchange made me read all I could find on reverse proxies. Now I understand--and agree with--the last statement of AYJ: 'the server is a proxy. ' But my understanding is that the proxy (which DNS pointed me to when I tried to get to my bank) belongs in the domain mybank, and this proxy had been issued a valid certificate--which I had ascertained in the process of authentication. So, the end result is that the proxy is part of the bank. If we expect it to be harmful to the bank--so we could the server itself as well as any bank's employee. It would be the bank replaying things to itself, right? Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? the server is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011
Barry -- It's now been two weeks and I haven't heard anything to the objections I raised. It is not my responsibility to come up with mitigation that works, it's the working group's. If there is no reasonable mitigation it should just say that. Mike On 12/16/2011 06:55 AM, Michael Thomas wrote: On 12/16/2011 03:02 AM, Mark Mcgloin wrote: Michael, I will review the comments from Phil where he suggests some changes in section 4.1.4 of the threat model I am unclear exactly what you are proposing. If you want to propose a clearly worded revamp of that section in the next couple of days, I am willing to review and accept legitimate changes. Clearly worded means concise, technically accurate and devoid of alarmist phrases and words used out of context, such as existential. Can I suggest you review with a colleague before posting here. Barry -- I have gone through this section and made comments and was blown off seemingly without reading them at all, and now I'm being told to come up with text for which I can be blown off again: Can I suggest you review... The fact of the matter is that my comments say that the threats are understated and mitigations that are proposed do not work. It's not my job alone to fix this. It's the working group's. In fact if I were to propose text, it would be along the lines of can't be mitigated because I do not know how to fix them. If nobody else can come up with a better mitigation, then that *is* what should be there, not some hand waving nonsense that doesn't work. Mike, instruct users... feh Regards Mark oauth-boun...@ietf.org wrote on 15/12/2011 18:15:45: From: Michael Thomasm...@mtcc.com To: Phil Huntphil.h...@oracle.com Cc: Barry Leibabarryle...@computer.org, oauth WGoauth@ietf.org Date: 15/12/2011 18:16 Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-v2-threatmodel-01, ends 9 Dec 2011 Sent by: oauth-boun...@ietf.org On 12/15/2011 09:54 AM, Phil Hunt wrote: Note: one change recommended below... With regards to 4.1.4… 4.1.4. Threat: End-user credentials phished using compromised or embedded browser A malicious application could attempt to phish end-user passwords by misusing an embedded browser in the end-user authorization process, or by presenting its own user-interface instead of allowing trusted system browser to render the authorization user interface. By doing so, the usual visual trust mechanisms may be bypassed (e.g. TLS confirmation, web site mechanisms). By using an embedded or internal client application user interface, the client application has access to additional information it should not have access to (e.g. uid/ password). [mat] I think it's also worth mentioning either here, or in another threat that there is a further social engineering misuse/attack where an app offers/demands to keep your credentials so that you don't have to go through the authorization rigmarole. Users are already conditioned to give their credentials up to do things -- just this morning I noticed facebook asking for my email password which they promise with sugar on top to not store. It might be worth mentioning that things like CAPTCHA could be deployed to defend against that sort of attack/misuse. [Phil] I don't think we need to really add much here. We could write whole essays on this topic and likely will. I think the point is simply to educate the client developer that there is no need for a client application to ever have access to a raw uid/password (or any other user credential). [/Phi] Remember: I came here not understanding whether this threat was real or not. A threat document that can't be bothered to elaborate on one of the biggest existential threats to the protocol is worthless. The way it is worded now does not make it crystal clear that, yes, this means UIWebView's in iPhone apps, etc too. It should because it needs to scream: THIS THREAT APPLIES TO YOU, AUTH SERVER. [snip] Countermeasures: o Client developers and end-user can be educated to trust an external System-Browser only. [mat] I assume that this is in here just for the amusement factor because it is not a credible countermeasure. [Phil] I agree, Firefox recently demonstrated how poorly users recognize the security signals in the browser by dropping the lock icon without announcement. When I found out, I had already been using it for some time and hadn't noticed. This counter measure should be changed to: o The OAuth flow is designed so that client applications never need to know user passwords. Where possible Client applications SHOULD avoid directly asking for user credentials during an authorization flow. [/Phil] The basic problem here is that the client app is not trusted. So if it's a bad actor this admonition will be ignored. If it's a good actor, there wasn't a threat in first place. So the mitigation completely misses the mark. o Client
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On Tue, 03 Jan 2012 18:34:01 -0500, Igor Faynberg wrote: Well, this exchange made me read all I could find on reverse proxies. Now I understand--and agree with--the last statement of AYJ: 'the server is a proxy. ' But my understanding is that the proxy (which DNS pointed me to when I tried to get to my bank) belongs in the domain mybank, and this proxy had been issued a valid certificate--which I had ascertained in the process of authentication. So, the end result is that the proxy is part of the bank. If we expect it to be harmful to the bank--so we could the server itself as well as any bank's employee. It would be the bank replaying things to itself, right? I'm not sure we quite match ideas on this. The problem is between the client and proxy. Not between the proxy and the server. Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com (server verifies the token FOO is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token FOO expires, gets replaced by token FOO-2. client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com (server verifies the token FOO-2 is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... attacker to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK stuff ... Oops. attacker to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK other-stuff ... Oops. I assume for clarity that the server and client 1 have both correctly implemented Bearer and are performing proper validation and expiry on the query-string tokens. The mitigation is for the server which implements Bearer to be sending Cache-Control with one of the values: no-store, private, proxy-revalidate and/or must-revalidate. AYJ Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? the server is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
Very good to have a clear sequence! Many thanks for all the work explaining this to me. Maybe my misunderstanding can be corrected by considering observations 1) and 2) and answering question 3) in-line: On 1/3/2012 8:30 PM, Amos Jeffries wrote: ... Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 1): If this transaction is done over TLS, then this specific proxy is the ONLY entity in the chain that knows the token at the moment, and since it is in the same domain as the server, we must assume its fidelity.. proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 2) Now the server knows it, too. (server verifies the token FOO is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token FOO expires, gets replaced by token FOO-2. client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Same as in 1) proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Sane as in 2) (server verifies the token FOO-2 is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... 3) How can attacker swipe it, if the token was passed *as part of an encrypted payload?* attacker to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK stuff ... Oops. attacker to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com proxy to attacker: HTTP/1.1 200 OK other-stuff ... Oops. I assume for clarity that the server and client 1 have both correctly implemented Bearer and are performing proper validation and expiry on the query-string tokens. The mitigation is for the server which implements Bearer to be sending Cache-Control with one of the values: no-store, private, proxy-revalidate and/or must-revalidate. AYJ Then it is the bank's problem, not OAuth's as far as I am concerned... Igor On 1/2/2012 7:36 PM, Amos Jeffries wrote: On 1/2/2012 7:07 AM, Amos Jeffries wrote: On 2/01/2012 11:00 p.m., Torsten Lodderstedt wrote: ... general note: I do not understand why caching proxies should impose a problem in case TLS is used (end2end). Could you please explain? Because TLS is hop-by-hop (in HTTP hops, end-to-end only in TCP hops). Proxies which decrypt TLS and provide responses out of cache are already deployed in many places. Mostly in the form of reverse-proxies, but corporate decryption proxies are also on the increase. AYJ On 3/01/2012 11:17 a.m., Igor Faynberg wrote: I am at a loss here; granted, it is a gray area... Does it mean that RFC 2817 has not been implemented properly? From RFC 2817: 5. Upgrade across Proxies As a hop-by-hop header, Upgrade is negotiated between each pair of HTTP counterparties. If a User Agent sends a request with an Upgrade header to a proxy, it is requesting a change to the protocol between itself and the proxy, not an end-to-end change. The more common case is CONNECT method from RFC 2068, from a user agent to a reverse-proxy. Same behaviour. To make it simple: At the client, I establish a session key with the server, and then use it for confidentiality. How is this key known to any proxy? the server is a proxy. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
Re: [OAUTH-WG] OAuth Bearer authentication - for proxies?
On 4/01/2012 3:58 p.m., Igor Faynberg wrote: Very good to have a clear sequence! Many thanks for all the work explaining this to me. Maybe my misunderstanding can be corrected by considering observations 1) and 2) and answering question 3) in-line: On 1/3/2012 8:30 PM, Amos Jeffries wrote: ... Here is a transaction sequence for that bank: client 1 to proxy: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 1): If this transaction is done over TLS, then this specific proxy is the ONLY entity in the chain that knows the token at the moment, and since it is in the same domain as the server, we must assume its fidelity.. The client does too, surely. Fidelity, well; * it is going to cache the reply for re-use, === this is what I worry about. * it is going to log the URL+token for a longish term, * it may pass the URL+token in unencrypted packets (via ICP, HTCP, UDP syslog) to any peers it may have, Given these risks are all internal to the security domain and so very slight, they are still weak points in the transactions long-term integrity. Adding the cache-controls erases the risks related to caching. With correct CC headers URL replay would fail even if TLS were not present. proxy to server: GET /?oauth_token=FOO HTTP/1.1 Host: bank.example.com 2) Now the server knows it, too. (server verifies the token FOO is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK stuff proxy to client 1: HTTP/1.1 200 OK stuff .. some time passes. The token FOO expires, gets replaced by token FOO-2. client 1 to proxy: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Same as in 1) proxy to server: GET /?oauth_token=FOO-2 HTTP/1.1 Host: bank.example.com Sane as in 2) (server verifies the token FOO-2 is valid for client 1 through the proxy) bank server to proxy: HTTP/1.1 200 OK other-stuff proxy to client 1: HTTP/1.1 200 OK other-stuff Attacker processes some URL records they somehow swiped from the client transactions... 3) How can attacker swipe it, if the token was passed *as part of an encrypted payload?* In the last year or so it has become safe to assume SSL/TLS is compromised by MITM. Or alternatively some secondary infection at one of the end points. Paranoia dictates that someone will figure it out somehow if the stakes are high enough. When they do, its a good idea to have the rest of the system firmly sealed. The given sequence was for the reverse-proxy. The alternative scenario is an identical sequence with a SSL interception proxy. For example an installation of: http://wiki.squid-cache.org/Features/SslBump. In that alternative the proxy is outside the servers security domain and inside some third-party ISP domain at the user end. AYJ ___ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
