REVISED Last Call: (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

[Francisco Corella]

The bearer token protocol described in the document referenced in the
subject line is vulnerable to the following attack by a malicious
resource server.

There are two resource servers S1 and S2, S1 hosting a resource R1,
and S2 hosting a resource R2.  Servers are not entitled to access
resources that they do not host.  S1 is malicious.  The client obtains
a broadly scoped access token that allows access to both resources.
The client uses the access token to obtain resource R1 from server S1.
Malicious server S1 then presents the access token received from the
client to server S2 and gains access to resource R2, which it is not
entitled to access.

Including the identity of the intended recipients in the token, as
recommended in Section 4.2, does not help, since the intended
recipients of the broadly scoped token include both R1 and R2.

Francisco___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (The RPKI/Router Protocol) to Proposed Standard

[Terry Manderson]

On 28/01/12 3:02 PM, "Rob Austein"  wrote:

> At Wed, 21 Dec 2011 17:43:23 -0800, Terry Manderson wrote:
>>
>> Apologies for my lack of attention to date on this topic, so speaking only
>> for myself here.
>
> Similar apologies for not having answered this more promptly.  Somehow
> we missed seeing this until our AD asked us about it.
>
> Please see draft-ietf-sidr-rpki-rtr-25, just posted, which we hope
> addresses most of your concerns (there are a few points on which I
> think we're just going to have to agree to disagree).

I will read -25 soon and raise any concerns should they remain.

>
[..]

> RADIUS doesn't have a bulk transfer operation, and bulk transfer of
> data is the main task of this protocol, particularly at start-up.

Is that function of the protocol now highlighted in -25?

>
> You are certainly entitled to your opinion, but it comes a bit late.
> This work was done in the public view, with regular progress reports
> to the SIDR WG, and we have multiple interoperable implementations
> including several of the major router vendors.  So, with all due
> respect, I don't think the folks who have put work into this will be
> all that interested in abandoning running code at this point.

My example was to highlight that without the rationale for why *this*
protocol was desiired any number of options would/could seem perfectly
reasonable and attractive.

>
>> Glossary:
>>
>> Global RPKI:
>> I disagree with this definition for two reasons. 1) I'm not aware of a
>> unified definition for 'distributed system' so this is all rather vague.
>
> The term has been used to describe DNS for decades.  Also see:
>
>   http://en.wikipedia.org/wiki/Distributed_computing

Citing wikipedia - the end is nigh!

>
>> Perhaps you could say 'published at a disparate set of systems'.
>
> I don't find that any clearer.  Readers who can't understand the words
> "distributed set" aren't likely to understand "disparate set" either.
>

I guess we remain in disagreement :).

>> 2) Limiting
>> the servers to be "at" the "IANA, RIRs, NIRs, and ISPs" is also premature.
>> It's not clear to me that these entities will run their own repositories,
>> nor are they going to be the only repository operators in the lifecycle of
>> the RPKI.
>
> This is essentially the same list as appears in section 1.1 of
> draft-ietf-sidr-arch, with the term "LIR" replaced by "ISP".
>
> I suppose we could add "or other service providers".

I think that would satisfy me.

>
>> Cache:
>> The words surrounding the fetch/refresh mechanisms of the RPKI is limiting.
>> Both draft-ietf-sidr-repos-struct and draft-ietf-sidr-res-certs allow for
>> other (future) retrieval mechanisms as defined by the repository operator
>> beyond RSYNC (loosely documented in RFC5781).
>
> Terry, you've made it quite clear that you disagree with the SIDR WG's
> decision to make rsync the mandatory-to-implement RPKI retrieval
> protocol, but you lost that argument a long time ago, and I fail to
> see the point of bringing it up here yet again.

That wasn't the intent Rob, please re-read the paragraph for the reality
that I think this document still needs to be flexible SHOULD a future
retrieval mechanism develop. If you still think that it shouldn't be
flexible - then we remain in disagreement.

>
>> Last sentence. "Trusting this cache further is a matter between the provider
>> of the cache and a relying party". In my mind the Relying Party was the one
>> that did the RPKI validation - would this not be better stated as "Trusting
>> this cache further is a matter between the provider of the cache and the
>> router operator".
>
> If a router is making decisions based on data given to it by a server,
> the router is the relying party in that relationship.  That the server
> in question was itself the relying party in another relationship does
> not change this.
>
> The picture here is not all that different from the way that some
> vendors have chosen to implement DNSSEC.  It's a two-tier security
> relationship: an end-to-end relationship between the publisher of
> signed objects and the validator of those signed objects, then a
> separate security relationship between the entity that validated the
> signed objects and the end entity that actually uses the data.

I think then we remain in disagreement on the phrasing, spelling out
precisely that the relying party identified here has a trust relationship
only with the cache, and not the larger RPKI is important.

>
>> Deployment Structure:
>>
>> Why repeat the definition of "Global RPKI"? It's superfluous.
>
> Because it's not a definition?
>
> I agree that the text here is similar to the definition, but this
> section is trying to describe the roles in the system.

Then I think the text needs work.

>
>> Local Cache: Again. 'Relying party' seems to be borrowed from the
>> CA/identity world. Unless you redefine that term here it seems as if the
>> "router" is making RPKI validation decisions. Which it is not. The router is
>

Re: T-Shirt Design Contest for IETF 83 Paris

[Francis Dupont]

 In your previous mail you wrote:

>  I hope a T-Shirt will feature my favorite French hero Super Dupont
>  
>  http://en.wikipedia.org/wiki/Superdupont

+1 (I should not have to explain why :-)

Thanks

francis.dup...@fdupont.fr
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Brian E Carpenter]

Hi Pete,

On 2012-02-01 08:14, Pete Resnick wrote:
> On 1/31/12 11:59 AM, George, Wes wrote:
>>> From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
>>>
>>> Is that wise? I thought (IIRC, and maybe I'm spacing) the whole
>>> reason for
>>> allocating this space was that 1918 space _couldn't_ easily be used
>>> for CGN
>>> because there were too many conflicting usages.
>>>  
>> [WEG] yes, but the general sense I got from the ensuing discussion was
>> that no one expects anyone to actually adhere to that advice (ie MUST
>> NOT be used as substitute for 1918 space), and as soon as the space is
>> released, it'll be "cats and dogs living together, mass hysteria..."
>> because everyone and their cousin will start using it as 1918-bis
>> anyway, no matter whether the IETF wags their fingers at them or not.

I have no doubt that this space will be (mis)used as additional
private ambiguous address space. But IMHO the text should make it
clear that this is the wrong way to use it and give the reasons
why - basically the same information as in the new text, but stated
exactly the other way round. For example

 Shared Address Space is IPv4 address space designated for Service
 Provider use with the purpose of facilitating CGN deployment.
 Shared Address Space is not intended to be used as additional [RFC1918]
 space, because either or both of the following issues might arise:

 o  Shared Address Space could also be used on the Service Provider side
of the CPE, with overlapping subnet or host addresses.

 o  Some CPE routers behave incorrectly when using the same address block on
both the internal and external interfaces.

> Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested
> text) ended the document up here, let me suggest the slightly less
> pessimistic view from Wes's, and the reason that I think this
> *shouldn't* specifically update 1918:
> 
> This *is* a special use address block that is akin to 1918. It is
> non-routable address space, just like 1918. But unlike 1918, this block
> is defined as "might be used by your ISP on your outside interface". So,
> people using it inside their networks (which, I agree with Wes, will
> happen, and like everything else on the net, will be done stupidly by
> some) have been told that this is *not* private use space and that they
> use it at their own risk and their CGN service might stop working if
> they use it in a way not described in this document. But I'd hate for us
> to allocate space to "CGNs only" when it's obvious that this can be used
> for a whole class of these sorts of things, and can be used by other
> people who build sane equipment that understands "shared" addresses can
> appear on two different interfaces. These aren't "private" addresses a
> la 1918, they're "shared", so it's not an addition to that space. Let's
> properly document what it is we're doing, giving people fair warnings.

Exactly, hence my suggested text above.

   Brian
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Noel Chiappa]

> From: Pete Resnick 

> I'd hate for us to allocate space to "CGNs only" when it's obvious
> that this can be used for a whole class of these sorts of things,
> and can be used by other people who build sane equipment that
> understands "shared" addresses can appear on two different
> interfaces. These aren't "private" addresses a la 1918, they're
> "shared", so it's not an addition to that space.

Ah. That makes sense.

Now, as long as the document clearly says all that... :-)

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Pete Resnick]

On 1/31/12 11:59 AM, George, Wes wrote:

From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]

Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for
allocating this space was that 1918 space _couldn't_ easily be used for CGN
because there were too many conflicting usages.
 

[WEG] yes, but the general sense I got from the ensuing discussion was that no one 
expects anyone to actually adhere to that advice (ie MUST NOT be used as substitute for 
1918 space), and as soon as the space is released, it'll be "cats and dogs living 
together, mass hysteria..." because everyone and their cousin will start using it as 
1918-bis anyway, no matter whether the IETF wags their fingers at them or not.
   


Speaking as one of the bozos^h^h^h^h^h ADs whose comments (and suggested 
text) ended the document up here, let me suggest the slightly less 
pessimistic view from Wes's, and the reason that I think this 
*shouldn't* specifically update 1918:


This *is* a special use address block that is akin to 1918. It is 
non-routable address space, just like 1918. But unlike 1918, this block 
is defined as "might be used by your ISP on your outside interface". So, 
people using it inside their networks (which, I agree with Wes, will 
happen, and like everything else on the net, will be done stupidly by 
some) have been told that this is *not* private use space and that they 
use it at their own risk and their CGN service might stop working if 
they use it in a way not described in this document. But I'd hate for us 
to allocate space to "CGNs only" when it's obvious that this can be used 
for a whole class of these sorts of things, and can be used by other 
people who build sane equipment that understands "shared" addresses can 
appear on two different interfaces. These aren't "private" addresses a 
la 1918, they're "shared", so it's not an addition to that space. Let's 
properly document what it is we're doing, giving people fair warnings.


pr

--
Pete Resnick
Qualcomm Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Jean-Francois . TremblayING]

> I thought (IIRC, and maybe I'm spacing) the whole reason for
> allocating this space was that 1918 space _couldn't_ easily be used for 
CGN
> because there were too many conflicting usages. So, now we're making 
more 1918
> space? This is a good idea... how? If we need more 1918 space, let's do 
so
> deliberately, and not kill the usefulness of this space for CGN. 
(Unless, of
> course...)
>Noel

+1 on this and Brian's comment. 

While I still support this draft, the wording in section 4 is probably too 
soft and reduces a lot the usefulness of this adressing space. 

/JFT
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[George, Wes]

> From: Noel Chiappa [mailto:j...@mercury.lcs.mit.edu]
>
> Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for
> allocating this space was that 1918 space _couldn't_ easily be used for CGN
> because there were too many conflicting usages.
[WEG] yes, but the general sense I got from the ensuing discussion was that no 
one expects anyone to actually adhere to that advice (ie MUST NOT be used as 
substitute for 1918 space), and as soon as the space is released, it'll be 
"cats and dogs living together, mass hysteria..." because everyone and their 
cousin will start using it as 1918-bis anyway, no matter whether the IETF wags 
their fingers at them or not.

> So, now we're making more 1918 space? This is a good idea... how? If we need 
> more 1918 space, let's do so
> deliberately, and not kill the usefulness of this space for CGN. (Unless, of
> course...)
>
[WEG] I think it provides a window of opportunity - get in before the place 
gets busy. Hopefully by the time people have really adopted the space for 
1918-type uses, working IPv4 CGN will be of less relevance... or at least 
that's what I'm telling myself. This just acknowledges what people believe to 
be the case instead of trying to deny that it'll happen.

Wes George

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[Noel Chiappa]

> From: "George, Wes" 

> I've been recommending this direction (that this is basically just more
> private space, no magic)

Is that wise? I thought (IIRC, and maybe I'm spacing) the whole reason for
allocating this space was that 1918 space _couldn't_ easily be used for CGN
because there were too many conflicting usages. So, now we're making more 1918
space? This is a good idea... how? If we need more 1918 space, let's do so
deliberately, and not kill the usefulness of this space for CGN. (Unless, of
course...)

Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: T-Shirt Design Contest for IETF 83 Paris

[Marshall Eubanks]

On Tue, Jan 31, 2012 at 10:59 AM, Olaf Kolkman  wrote:
>
>
> I hope a T-Shirt will feature my favorite French hero Super Dupont
>

And, for myself, I think that Hubert Bonisseur de La Bath (AKA OSS
117) would be perfect proxy IETFer. I can imagine
the line at the mike now.

Regards
Marshall


> http://en.wikipedia.org/wiki/Superdupont
>
> --Olaf
>
> 
>
> Olaf M. Kolkman                        NLnet Labs
> http://www.nlnetlabs.nl/
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

RE: Last Call: (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

[George, Wes]

I've been recommending this direction (that this is basically just more private 
space, no magic) for some time, so I support the change.

However, I strongly believe that the document should formally update RFC1918, 
not just 5735, especially now that it specifically says that in certain 
circumstances the space can be used as 1918 space. Having the linkage between 
the documents (from 1918 to this one, instead of just in the other direction) 
is quite important, IMO.

Wes George


> -Original Message-
> From: ietf-announce-boun...@ietf.org [mailto:ietf-announce-boun...@ietf.org]
> On Behalf Of The IESG
> Sent: Monday, January 30, 2012 6:04 PM
> To: IETF-Announce
> Subject: Last Call:  (IANA
> Reserved IPv4 Prefix for Shared Address Space) to BCP
>
>
> The IESG has received a request from an individual submitter to consider the
> following document:
> - 'IANA Reserved IPv4 Prefix for Shared CGN Space'
>   as a BCP
>
> On its December 15, 2011 telechat, the IESG reviewed version 10 of this
> document and requested various changes. These changes are reflected in
> the draft version 14 and the IESG now solicits community input on the
> changed text only. Please send substantive comments to the ietf@ietf.org
> mailing lists by 2012-02-16. Exceptionally, comments may be sent to
> i...@ietf.org instead. In either case, please retain the beginning of
> the Subject line to allow automated sorting.
>
> Abstract
>
>   This document requests the allocation of an IPv4 /10 address block to
>   be used as Shared Address Space to accommodate the needs of Carrier
>   Grade Network Address Translation (CGN) devices.  It is anticipated
>   that Service Providers will use this Shared Address Space to number
>   the interfaces that connect CGN devices to Customer Premise Equipment
>   (CPE).
>
>   Shared Address Space is distinct from RFC1918 private address space
>   because it is intended for use on Service Provider networks.
>   However, it may be used as RFC 1918 private address space in certain
>   circumstances.  Details are provided in the text of this document.
>
>   As this document proposes the allocation of an additional special-use
>   IPv4 address block, it updates RFC 5735.
>
> The following text captures the most salient change between version 10 and 14
> of this document:
>
>   Shared Address Space is IPv4 address space designated for Service
>  Provider use with the purpose of facilitating CGN deployment.  Also,
>  Shared Address Space can be used as additional [RFC1918] space when
>  at least one of the following conditions is true:
>
>  o  Shared Address Space is not also used on the Service Provider side
> of the CPE.
>
>  o  CPE routers behave correctly when using the same address block on
> both the internal and external interfaces.
>
>
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-weil-shared-transition-space-request/
>
>
> No IPR declarations have been submitted directly on this I-D.
> ___
> IETF-Announce mailing list
> ietf-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce

This E-mail and any of its attachments may contain Time Warner Cable 
proprietary information, which is privileged, confidential, or subject to 
copyright belonging to Time Warner Cable. This E-mail is intended solely for 
the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any 
dissemination, distribution, copying, or action taken in relation to the 
contents of and attachments to this E-mail is strictly prohibited and may be 
unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and 
any printout.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: T-Shirt Design Contest for IETF 83 Paris

[Olaf Kolkman]

I hope a T-Shirt will feature my favorite French hero Super Dupont

http://en.wikipedia.org/wiki/Superdupont

--Olaf

 

Olaf M. KolkmanNLnet Labs
http://www.nlnetlabs.nl/











 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf

Re: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt

[Alexey Melnikov]

On 30/01/2012 05:20, Mike Jones wrote:

Thanks for your useful feedback, Alexey.

Hi Mike,

   Below, I'll respond to each of your comments.  I've also added the OAuth 
working group to the thread, so they are aware of them as well and can 
participate in the discussion.

About your first issue with the WWW-Authenticate ABNF, I am already working 
with Julian, Mark Nottingham, and the chairs to resolve this issue.  Expect to 
see a proposal for review by the working group shortly.

Ok, I will have a look.

About your comments on scope:  OAuth 2.0 (both the Core and Bearer specs) is designed to 
be deployed in diverse and non-interoperable application contexts, meeting a variety of 
application needs.  In those various settings, which are often distinct and potentially 
non-interoperable, parameters such as scope, realm, etc. may have very different 
meanings.  This is not a bug; it is a feature, because it allows the OAuth pattern to 
meet the needs of numerous, often distinct, application environments.  For that reason, a 
registry of scope (or realm) parameters would be ill-advised and counterproductive.  It's 
perfectly OK and expected for a scope value such as "email" to have one meaning 
in one application context and a different meaning in a different, but distinct 
application context.  Trying to impose a single meaning on particular scope values across 
distinct application contexts is both unnecessary and could break many existing 
deployments.  That being said, we fully expect
interoperability profiles to emerge that define interoperable sets of scope 
values within particular application contexts.  (The OpenID Connect 
specifications are one such set of profiles.)  But these meanings will always 
be context-specific - not global in scope.
The way "scope" is currently defined in the document is completely 
useless. You don't have a single example in the document. You don't say 
how the semantics of the value differs from realm. You don't say that 
its values are deployment specific and can be profiled in future 
documents. Please say something about these issues in the document (your 
explanation above would work.)

About your first minor issue, I'll reorder the bullets so the statement about 
the entity-body being single part is followed by the statement about it using 
application/x-www-form-urlencoded, so they will be read together.

Ok.

About your second minor issue on error codes, the error codes registry already 
exists, but is in the OAuth Core spec.  
Seehttp://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-11.4.

Can you please make this clear in the document (by adding a reference)?

About your third minor issue on RFC 6125 versus RFC 2818, you'll find that, per 
the history entries, a previous reference to RFC 2818 was changed to RFC 6125 
in draft 14 at the request of Security Area Director Stephen Farrell.  If you'd 
like to see this reference reintroduced, I'd request that you work with Stephen 
on specific alternative proposed wording that is acceptable to both of you.

Ok, I can work with Stephen and Peter Saint-Andre (RFC 6125 co-author) on some 
text.


Finally, I'll address both of your nits in the manner you suggested.

These are fixed in -16, thanks.


Thanks again,
-- Mike

-Original Message-
From:ietf-boun...@ietf.org  [mailto:ietf-boun...@ietf.org] On Behalf Of Alexey 
Melnikov
Sent: Sunday, January 29, 2012 8:38 AM
To: General Area Review Team; IETF-Discussion 
Discussion;draft-ietf-oauth-v2-bearer@tools.ietf.org
Subject: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please 
see the FAQ at.

Please resolve these comments along with any other Last Call comments you may 
receive.

Document: draft-ietf-oauth-v2-bearer-15.txt
Reviewer: Alexey Melnikov
Review Date: 29 Jan 2012
IETF LC End Date: 7 Feb 2012
IESG Telechat date: (if known) -

Summary: Mostly ready, with a couple of things that should be addressed.

Major Issues:

I have 2 issues in section 3:

3.  The WWW-Authenticate Response Header Field

 If the protected resource request does not include authentication
 credentials or does not contain an access token that enables access
 to the protected resource, the resource server MUST include the HTTP
 "WWW-Authenticate" response header field; it MAY include it in
 response to other conditions as well.  The "WWW-Authenticate" header
 field uses the framework defined by HTTP/1.1, Part 7
 [I-D.ietf-httpbis-p7-auth] as follows:

 challenge   = "Bearer" [ 1*SP 1#param ]

 param   = realm / scope /
   error / error-desc / error-uri /
   auth-param

 scope   = "scope" "=" quoted-string
 error   = "error" "=" quoted-string
 error-desc  = "err