Re: Gen-ART review of draft-ietf-oauth-v2-bearer-15.txt
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 athttp://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq. 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 = error_description =
Re: T-Shirt Design Contest for IETF 83 Paris
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: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
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: draft-weil-shared-transition-space-request-14.txt (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' draft-weil-shared-transition-space-request-14.txt 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
On Tue, Jan 31, 2012 at 10:59 AM, Olaf Kolkman o...@nlnetlabs.nl 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: George, Wes wesley.geo...@twcable.com 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: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
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 Resnickhttp://www.qualcomm.com/~presnick/ 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Pete Resnick presn...@qualcomm.com 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: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
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: T-Shirt Design Contest for IETF 83 Paris
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: draft-ietf-sidr-rpki-rtr-19.txt (The RPKI/Router Protocol) to Proposed Standard
On 28/01/12 3:02 PM, Rob Austein s...@hactrn.net 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 acting more like a NAS (See Radius, 2865) when talking to a local cache. The definition of routers seems to get this right -
REVISED Last Call: draft-ietf-oauth-v2-bearer-15.txt (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
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
Protocol Action: 'Real-time Inter-network Defense (RID)' to Proposed Standard (draft-ietf-mile-rfc6045-bis-11.txt)
The IESG has approved the following document: - 'Real-time Inter-network Defense (RID)' (draft-ietf-mile-rfc6045-bis-11.txt) as a Proposed Standard This document is the product of the Managed Incident Lightweight Exchange Working Group. The IESG contact persons are Sean Turner and Stephen Farrell. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mile-rfc6045-bis/ Technical Summary Real-time Inter-network Defense (RID) outlines a proactive inter-network communication method to facilitate sharing incident handling data while integrating existing detection, tracing, source identification, and mitigation mechanisms for a complete incident handling solution. Combining these capabilities in a communication system provides a way to achieve higher security levels on networks. The data in RID messages is represented in an XML document using IODEF [RFC5070] and the RID XML schema defined in this document. Working Group Summary There was extensive commentary on the pre-WG and WG mailing list on the document indicative of review, correction, and consensus. The working group process has been somewhat abbreviated, as the document is an update of an already-published RFC to change its intended status (Informational to Standards Track) and to apply minor updates. Consensus was reached without problems. Document Quality The document itself derived from the previously published (informational) RFC 6045. The XML schema was reviewed by two experts, one within the WG and one from outside. In addition to the review received within the MILE WG, much of the content within the document (both technical and editorial) has received extensive review prior to its initial publication as RFC6045 in November 2010. Personnel Brian Trammell (tramm...@tik.ee.ethz.ch) is the document shepherd. Sean Turner is the responsible Area Director. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Rescheduled BEHAVE WG Virtual Interim Meeting: Thursday, February 16, 7am PST
Due to a scheduling conflict, the BEHAVE audio conference interim meeting is being rescheduled. The previously-scheduled February 3 interim meeting is cancelled. NEW DATE AND TIME: Thursday, February 16, 7am-8:30am Pacific Standard Time (San Francisco, GMT-08:00). Agenda and audio conference details published at http://trac.tools.ietf.org/wg/behave/trac/wiki/WikiStart ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
