From dnelson@elbrys.com Fri Feb 1 04:40:03 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9BC721F8692 for ; Fri, 1 Feb 2013 04:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewf4IN6Jxk4k for ; Fri, 1 Feb 2013 04:40:02 -0800 (PST) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id A482821F8545 for ; Fri, 1 Feb 2013 04:40:01 -0800 (PST) Received: by mail-wg0-f53.google.com with SMTP id fn15so2897460wgb.20 for ; Fri, 01 Feb 2013 04:40:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=ebdKDnoBh7m9tPq9CsqG2q8OMj4AhrV2T68aEmfz9iM=; b=g7UcNS/cFwv5qZHwAHyO2ykCl1W4q7bYXRg8Vyq4BbfpZPPA86s9ZFqzH/+60gR30j tf2fS1RDFne43935VEt37Xunrt4Ht7pAodggH6gwtFelawbIloJS988dhFBaLDH/V/M+ 0etLEozOjdLs6IrfDDJmM3Qk//2E/Fv8oJ2OUO4OebMjSU+abec9V2Xni1S0EkQN5MKv bDScwRnOOJ49za7sH1wvBLAh9rwbFNRKa75ll3jKD5su2cDkenZ43SyrZO3tnsSCZweB lkWykRD9hHPOjxIVUbTadqmCikXIzQ+GzfWeiAZaUPsrTgoVA+EpbuPAKHOJmw7+zHQA WcKA== MIME-Version: 1.0 X-Received: by 10.180.82.41 with SMTP id f9mr2619176wiy.25.1359722400738; Fri, 01 Feb 2013 04:40:00 -0800 (PST) Received: by 10.194.248.199 with HTTP; Fri, 1 Feb 2013 04:40:00 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Feb 2013 07:40:00 -0500 Message-ID: From: Dave Nelson To: siva kumar Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQk4R0F+V3jzXHxrZUutVF0K4sn4dk5PATsu/qb5z3xf75/t5wstnpUOvuI3XPoLTQa1KoAI Cc: Bernard Aboba , radext@ietf.org, Alan DeKok Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 12:40:03 -0000 > If I receive a radius packet with more than one message authenticator, > should I discard the packet or should I ignore it?. You SHOULD verify the message authenticator, where it exists. If there are two, I think this may be challenging. If they are identical in value, I suppose you could assume that the comparison value is to be calculated over the packet as if there were only one, i.e. over a shorter that actual length packet. If one message authenticator is calculated over the packet with the other message authenticator already in place, that would be very non-standard. In any event, you should , IMHO, file a bug report against any RADIUS product that does this. :-) Regards, Dave David B. Nelson Director of Technology Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 From internet-drafts@ietf.org Fri Feb 1 07:48:30 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86BB71F0D03; Fri, 1 Feb 2013 07:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.529 X-Spam-Level: X-Spam-Status: No, score=-102.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtEyDHnZvfJG; Fri, 1 Feb 2013 07:48:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E58B1F0CAF; Fri, 1 Feb 2013 07:48:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130201154830.7522.28011.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2013 07:48:30 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 15:48:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-10.txt Pages : 67 Date : 2013-02-01 Abstract: The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-extensions-10 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aland@deployingradius.com Fri Feb 1 07:50:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1C11F0D0A for ; Fri, 1 Feb 2013 07:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.353 X-Spam-Level: X-Spam-Status: No, score=-101.353 tagged_above=-999 required=5 tests=[AWL=-1.054, BAYES_00=-2.599, MANGLED_STOP=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C03iKrkkQQY7 for ; Fri, 1 Feb 2013 07:50:09 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 536791F0D09 for ; Fri, 1 Feb 2013 07:50:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 42E632240C9B; Fri, 1 Feb 2013 16:50:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zcc9VdLWv+Gy; Fri, 1 Feb 2013 16:50:05 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 7EE2E2240703; Fri, 1 Feb 2013 16:50:04 +0100 (CET) Message-ID: <510BE42B.1060102@deployingradius.com> Date: Fri, 01 Feb 2013 10:50:03 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Barry Leiba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 15:50:11 -0000 I've taken the liberty of responding to both messages here. I've updated the draft as per the comments, and submitted a new version. Diffs should be available shortly from: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions > === COMMENT === > -- Section 1.1.1 -- ... > It's actually entirely possible to deprecate items in a registry, so > if you still want to handle this. The document could add a column to > the table, perhaps called "Status", which would have the values > "current" (or blank to mean "current") or "deprecated" (or "obsolete", > or whatever). I think the simplest thing to do is just to delete that text. The standard space is almost completely full, so the issue will shortly be meaningless. > -- Section 2.1 -- > > === COMMENT === > In the description of "Type": > > I suggest adding a forward reference to make an important clarification here: > > NEW > This field is identical to the Type field of the Attribute format > defined in [RFC2865] Section 5. It will contain one of the Extended > Type values defined in Section 3, below. > END I'm not sure why that's necessary. The Type field always contains a valid RADIUS attribute type. The Attribute Types are managed by IANA, and new attributes of "Extended Type" can be assigned at any time. The intention here is to define the format, independent of value. IANA can then assign certain values as having a particular format. For example, RFC 2865 Section 5 defines Type as: Type The Type field is one octet. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [6]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used. There's no need to say "it contains one of the RADIUS attribute types defined in Sections 5.1 through 5.X of this document". > === COMMENT === > In the description of "Length": > > The Length field is one octet, and indicates the length of this > Attribute including the Type, Length, Extended-Type, and Value > fields. Permitted values are between 4 and 255. If a client or > server receives an Extended Attribute with a Length of 2 or 3, > then that Attribute MUST be considered to be an "invalid > attribute", and handled as per Section 2.8, below. > > Curious: What does a client or server do when it receives an Extended > Attribute with a length of 0 or 1? (Same comment goes for Section > 2.2.) This is covered in the definition of RADIUS attributes, in RFC 2865, Section 5, top of page 25. The Length field includes the "Type" and "Length" fields, so Lengths of 0 and 1 are invalide. The idea behind this specification is to work *within* existing RADIUS practices. We don't re-defined RADIUS at all. > === DISCUSS === > Also, this doesn't make sense to me. Section 2.8 starts with this: > > The term "invalid attribute" is new to this specification. It is > defined to mean that the Length field of an Attribute is valid (as > per [RFC2865], Section 5, top of page 25). > > These two appear to be contradictory: the first says that if the > length is invalid, it's an "invalid attribute", and the second says > that "invalid attribute" means that the length field is valid (but > there are other problems). This comment also applies to "TLV-Length" > in Section 2.3. The intent here is that the *contents* of the attribute are invalid. The next sentence (elided above) says: However, the Value field of the attribute does not follow the format required by the data type defined for that Attribute. e.g. an Attribute of type "address" which encapsulates more than four, or less than four, octets of data. So an attribute which carries a 2-byte "IPv4" address is invalid. The RADIUS packet itself can be properly parsed (validated, signed, etc.). But the data carried by a particular attribute is meaningless. RADIUS already has the concept of "malformed" packets. These are packets which do not pass validation as having the correct format. This is again independent of interpretation of the contents of the packet. e.g. an Accounting-Request sent to an authentication port is correctly formed, but is not valid for that port. Re-using the word "malformed" to describe the attribute would cause the confusion you highlight above. > === DISCUSS === > In the description of "Value": > > This field is similar to the Value field of the Attribute format > defined in [RFC2865] Section 5. The format of the data SHOULD be > a valid RADIUS data type. > > The addition of the Extended-Type field decreases the maximum > length for attributes of type "text" or "string" from 253 to 252 > octets. Where an Attribute needs to carry more than 252 octets of > data, the "Long Extended Type" format SHOULD be used. > > The first SHOULD makes a subtle, but very significant change to the > RADIUS protocol, and I want to make sure what you're doing is what you > mean to do. 2865 says, "The format of the value field is one of five > data types." It has to be one of those types, and can't be anything > else -- nothing else is defined. The text in RFC 2865 isn't a MUST. Many other RADIUS RFCs have been published which add new data types, *without* defining them as was done in 2865. e.g. 3162 defines "Address" to be IPv6 addresses, even though 2865 says "address" is IPv4. 6158 notes this issue, and defines more data types, but doesn't name them, I just published an individual draft yesterday to address this issue: https://datatracker.ietf.org/doc/draft-dekok-radext-datatypes/ > But you are now allowing an > implementor who understands the implications of doing so to use a > different data type. That has *always* been the RADIUS practice. This document changes nothing. > 1. Do you really mean to allow that? Yes. > 2. If "yes" to (1), what other data types exist that might be used? Lots. > Where are their formats defined? 6158, and my individual draft. > 3. If "yes" to (1), what *are* the implications of using other data types? Pretty much nothing. Implementations define many non-standard data types, such as 8-bit integer, 32-bit integer, "polymorphic" attributes, etc. > That comment also applies to "Value" in Section 2.2 and to "TLV-Value" > in Section 2.3. The same responses as above apply. > For the second SHOULD, there's a similar issue: What are the > alternatives to using the "Long Extended Type" format? What are the > implications of using those alternatives? The alternatives are to use "ad hoc" methods. An attribute is defined to have the magical property that multiple attributes mean fragmented data. This has to be specified for each attribute needing this property, and has to be implemented in an ad-hoc way in any client or server. i.e. there is *no* standard way to transport more than 253 octets of data. That's why we're writing this draft. > -- Section 2.2 -- > > === COMMENT === > In the description of "Type": > > As in 2.1, I suggest adding a forward reference to make an important > clarification here: > > NEW > This field is identical to the Type field of the Attribute format > defined in [RFC2865] Section 5. It will contain one of the Long > Extended Type values defined in Section 3, below. > END The same comments as above apply. I'm not sure why a forward reference is necessary. > === DISCUSS === > In the description of the "M" bit: > > 1. The first two paragraphs contradict each other. The first says > that M MUST be 0 if length < 255. The second says, "When the More > field is set (1), the attribute SHOULD have a Length field of value > 255". According to the first paragraph, that needs to be MUST, not > SHOULD. And then with that change, the next clause (about value 4) > can be removed. > The "that is" at the beginning of the third sentence > should be removed, because the ordering has not been mentioned before. I'm not sure why. Where else would this be mentioned? > 2. The last sentence of the second paragraph ends, "and the last > attribute in a packet MUST NOT have the More field set (1)." That's > certainly true, but isn't what you really want to say that all pieces > of the entire fragmented attribute MUST be included in one packet? Sure. But RADIUS doesn't support inter-packet fragmentation. I'll add some clarifying text. > 3. The third paragraph, which contradicts the first, should be removed. OK. > In the description of "Value": > > === DISCUSS === > This field is similar to the Value field of the Attribute format > defined in [RFC2865] Section 5. It may contain a complete set of > data (when the Length field has value less than 255), or it may > contain a fragment of data (when the More field is set). > > Isn't it possible for the Length field to be equal to 255 and to have > M=0 (if the last fragment of the fragmented attribute takes up the > whole 255 bytes, for instance)? And doesn't the last fragment of a > fragmented attribute contain a fragment of data, even though the More > field is 0? Yes. > === DISCUSS === > We note that the maximum size of a fragmented attribute is limited > only by the RADIUS packet length limitation (i.e. 4096 octets, not > counting various headers and overhead). Implementations SHOULD be > able to handle fragmented attributes of 4096 octets. > > This is incorrect: the RADIUS packet length is limited to 4096 octets > *including* the various headers and overhead. That puts a maximum > size of fragmented attributes as something less than 4096. As I > compute it: > > The RADIUS header is 20 octets, so that's 4096-20 = 4076 octets left > for attributes. That will hold 15 fragments of 255 octets each, and a > 16th fragment of 231 octets. And that results in a total attribute > length (after headers are removed and the fragments are assembled) of > 15*251+227 = 3992. I think that's a little detailed for the document, but sure. I'll write some clarifying text. > === DISCUSS === > The last paragraph of Section 2.2 says this: > > Implementations MUST be able to process non- > contiguous fragments. That is, fragments which are mixed together > with other attributes of a different Type. > > That contradicts what you said in the description of the "M" bit: Sort of. The text above suggests that implementations be liberal in what they accept. The other text mandates that implementations be conservative in what they generate. > === DISCUSS === > -- Section 2.3.1 -- > > The depth of TLV nesting is limited only by the restrictions on the > TLV-Length field. The limit of 253 octets of data results in a limit > of 126 levels of nesting. However, nesting depths of more than 4 are > NOT RECOMMENDED. > > Again: Why is it NOT RECOMMENDED? The recommendation above came out of discussion in the RADEXT WG. There are existing non-IETF specifications which uses nested TLVs. They haven't seen a need for a nesting of more than 4 levels deep. The WG consensus was that we had no idea *why* anyone would need more than 4 levels of nesting. And if a specification tried to use that deep of a nesting, it would cause discussion, and likely a re-design. > How would I know how to evaluate the implications of going for more > than 4 levels? The WG has no idea. That's why the text recommends against it, but without detailed reasons. > === COMMENT === > -- Section 2.7.2 -- > > The last paragraph seems out of place, as the following section > describes the TLV naming, basically repeating the last paragraph of > 2.7.2. I suggest correcting that organizational oddness. OK. > === COMMENT === > -- Section 2.7.3 -- > > At the end of the first paragraph, I think "replied" should be "repeated". OK. > === COMMENT === > -- Section 2.7.4 -- > > In the first sentence of the fourth paragraph, it seems as though "few > restrictions" is meant to be "a few restrictions", yes? The intention is to state that a naive approach would require 8-bit numbers at each level of the "dotted number" notation. However, various portions of the notation can be 32 bits or 16 bits. The only way to know is to examine the numbers themselves. e.g. as discussed in the document, 26.429.32768 is allowed, but 26.428.32768 is not. We don't want to get into the gritty details of defining the entire set of allowed values. Instead, we note that many values exist, with few restrictions. > What does the example in paragraph 5 tell me that the example in > paragraph 3 doesn't? That is, why is the second example needed? It's a duplicate. It can be removed. > === COMMENT === > -- Section 2.8 -- > > For Attributes of type "Long Extended Type", an Attribute is > considered to be an "invalid attribute" when does not match the > criteria set out in Section 2.2, above. > > 1. Typo: "when *it* does not match". OK. > 2. I think it would be useful to remind implementors that one bad > apple spoils the whole bunch: that if one fragment of a fragmented > attribute is invalid, the entire attribute (all fragments) needs to be > considered invalid. That's phrased a little awkwardly. See Section 2.2: Any interpretation of the resulting data MUST occur after the fragments have been reassembled. i.e. you can't have one fragment that's invalid. Either the entire attribute is invalid, or none of it is. I think a better phrasing would be to update that text in Section 2.2 with the following: If the reassembled data does not match the expected format, all fragments MUST be treated as "invalid attributes", and the reassembled data MUST be discarded. > === COMMENT === > -- Sections 3 and 4 subsections -- > > It somewhat bothers me to have the diagrams and some information > repeated here (repeated repeatedly, in fact). Is it not possible to > refer back to Sections 2.1 and 2.2 even more than you already do? It's the practice with RADIUS specifications. RFC 2865 defines an attribute format, data types, but then repeats the ASCII art for each attribute. It could instead have said "1 is User-Name, data type text". > You might then also add the information in these two paragraphs to the > descriptions of "Value" in Sections 2.1 and 2.2: > > The Value field is one or more octets. Implementations not > supporting this specification SHOULD support the field as > undistinguished octets. > > Implementations supporting this specification MUST use the > Identifier of "Type.Extended-Type" to determine the interpretation > of the Value field. OK. > === DISCUSS === > -- Section 2.1 -- > > In the description of Extended Type: > > Values 241-255 are reserved and SHOULD NOT be used. > > Why is this SHOULD NOT, rather than MUST NOT? Isn't this another > aspect of potential "antisocial behaviour"? I'll change it to MUST NOT. > === DISCUSS === > -- Section 2.8 -- > > When an implementation receives an "invalid attribute", it SHOULD be > silently discarded. If it is not discarded, it MUST NOT be handled > in the same manner as a well-formed attribute. > > This is contradicted by the discussion of proxies in Section 5.2: OK. > This practice is NOT RECOMMENDED. Proxy servers SHOULD forward > attributes, even ones which they do not understand, or which are not > in a local dictionary. When forwarded, these attributes SHOULD be > sent verbatim, with no modifications or changes. This requirement > includes "invalid attributes", as there may be some other system in > the network which understands them. > > I know that the point in Section 2.8 is not intended to apply to > proxies. I think you need to make that clear, to avoid implementation > errors. This should work, I think: > > NEW > When an implementation receives an "invalid attribute", it SHOULD be > silently discarded, except when the implementation is acting as a > proxy (see Section 5.2 for discussion of proxy servers). If it is > not discarded, it MUST NOT be handled in the same manner as a > well-formed attribute. > END OK. I'll use that text. > === DISCUSS === > -- Section 6.2 -- > > Complex data types MAY be used where they reduce complexity in > non-RADIUS systems, though this practice is NOT RECOMMENDED. The > complex data type exceptions of [RFC6158] Section 3.2.4 still > apply. In all other situations, complex data types MUST NOT be > used. Instead, complex data types MUST be decomposed into TLVs. ... > NEW > [RFC6158], Section 3.2.4, describes situations in which complex > data types might be appropriate. They SHOULD NOT be used even > in those situations, without careful consideration of the > described limitations. In all other cases, not covered by the > complex data type exceptions, complex data types MUST NOT be > used. Instead, complex data types MUST be decomposed into TLVs. > END That looks good. I'll use it. > === DISCUSS === > -- Section 6.4 -- > > * The data type "tlv" SHOULD NOT be used for standard RADIUS > attributes. This format was NOT RECOMMENDED by [RFC6158], > but their utility is now evident. > > I don't understand what this means to say. "SHOULD NOT" and "NOT > RECOMMENDED" are synonyms. Are you just repeating what 6158 says, or > are you intending to change it? (In contrast, what you say a couple > of bullets down about integer64 *is* correct, changing a SHOULD NOT > from 6158 to a MAY here.) I'll just delete the second sentence from the bullet point. > === DISCUSS === > -- Section 6.5 and 6.6 -- > > From 6.5: > * Where a group of TLVs is loosely defined, or is expected to change, > they SHOULD request allocation from the "long extended space". > > From 6.6: > * Specifications of an attribute which always encode less than 253 > octets of data MUST NOT request allocation from the long extended > space. The standard space, or the short extended space MUST be > used instead. > > Isn't this a contradiction? If I have a loosely defined group of TLVs > that I expect to have change, but which will always be less than 253 > octets, which space do I get it from? The text says "short extended space". > === COMMENT === > -- Section 6.6 -- > * When the extended space is nearing exhaustion, a new specification > SHOULD be written which requests allocation of one or more RADIUS > Attributes from the "Reserved" portion of the standard space > > Very small point, but: it's quite odd in a protocol standard to use > 2119 language to try to give the IETF an action item for later. Do > you mind losing the "SHOULD", and maybe making it "will have to be"? OK. I'll make the change. > === DISCUSS === > -- Section 9 -- > > Your grammar doesn't allow for the whitespace that's in your examples. > Being strict about it, your first two examples should be like this, > according to the grammar: > > 241.1"bob" > 241.2{12345} > > That's clearly not what you want. You'll need to change the last > three items in your grammar like this: > > NEW > TLV = "{" SP 1*DIGIT SP DATA SP "}" > > DATA = (HEXCHAR *(SP HEXCHAR)) / (TLV *(SP TLV)) / STRING > > LINE = Identifier SP DATA > OLD OK. > And in Section 9.2, your long data portions lack the required quotation marks. OK. > === COMMENT === > I gather that you've been exchanging messages with IANA about the IANA > Considerations. There's nothing that looks amiss here, but I strongly > encourage you to be very sure that IANA correctly understands what you > want them to do AND that you update the document to reflect anything > that comes up in the discussion. It can be a total pain later if this > gets done wrong. Done. < From shiv.annauniv@gmail.com Fri Feb 1 03:06:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C9E21F8D13 for ; Fri, 1 Feb 2013 03:05:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5E2cELtlLb5 for ; Fri, 1 Feb 2013 03:05:59 -0800 (PST) Received: from mail-ob0-f179.google.com (mail-ob0-f179.google.com [209.85.214.179]) by ietfa.amsl.com (Postfix) with ESMTP id B26FA21F8C50 for ; Fri, 1 Feb 2013 03:05:58 -0800 (PST) Received: by mail-ob0-f179.google.com with SMTP id un3so3918903obb.38 for ; Fri, 01 Feb 2013 03:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=9aIOkfznpMXGJuh4dZcge8kFeDKqn+bAdS/TEqomhv4=; b=RVSyFK+6mY2Y32Q16MJPQ4jEk1RFriPuhtonddvfqlLHm9S+ywEuAOZ4Z59NtV2JY1 q9i4yxl/VENQjiGZ4IMChAhW4OFNcokP6LV9mtHKqkrx6qzLZRNXzwa+GcDXoTN38z6e fuwz2vY3K3jQW16woqTrIRjBNEkEcG4lUgKnrsYsBlslr6Sh9RIAj/UKG780WPt7KbvY M2tp1iQVdb+Tf/HR/iUtrHQQfwMnh9TNfP4ADSc0Ziu6et+BX6lU8OIUxUWk+0z90lRn QJyksd3dEoe4LE+LkmPOViNfZ/2JC8E94Gi3abOiZUWJUeVFWoKlVM3OF06IlIE5aqR7 7WbQ== MIME-Version: 1.0 X-Received: by 10.182.12.39 with SMTP id v7mr8996624obb.47.1359716758063; Fri, 01 Feb 2013 03:05:58 -0800 (PST) Received: by 10.182.232.42 with HTTP; Fri, 1 Feb 2013 03:05:57 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Feb 2013 16:35:57 +0530 Message-ID: From: siva kumar To: Dave Nelson Content-Type: multipart/alternative; boundary=f46d04446c015c0a6804d4a7ba72 X-Mailman-Approved-At: Fri, 01 Feb 2013 11:14:35 -0800 Cc: Bernard Aboba , radext@ietf.org, Alan DeKok Subject: Re: [radext] rfc3579- Doubt regarding Access challenge packet X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 11:06:00 -0000 --f46d04446c015c0a6804d4a7ba72 Content-Type: text/plain; charset=ISO-8859-1 I am sorry if I am disturbing this forum, with lame questions. But I am new to this and eager to know more by developing it. As per the advice from members, I am ignoring the attributes which are mentioned as 0 as per the table of attributes in rfc 3579 instead of discarding the packet. But, for example, message authenticator is mentioned as 1. which means there should be only one message authenticator in a radius packet. If I receive a radius packet with more than one message authenticator, should I discard the packet or should I ignore it?. Thanks & Regards, Sivakumar.S On Thu, Jan 31, 2013 at 6:24 PM, Dave Nelson wrote: > On Thu, Jan 31, 2013 at 2:23 AM, siva kumar > wrote: > > > If service type is not supported and if NAS consider access-accept as > > access-reject, is it ok to not authenticate/authorize the port > > without sending eap failure. Will this create an unending authentication > > retries. > > I think what you're asking is what's the best way for the NAS to > signal to the end user, via the 802.1X supplicant, that the RADIUS > Server is misconfigured. After all, if EAP authentication succeeds, > but the RADUS Server provisions a service the NAS cannot deliver, the > server is very likely misconfigured. My answer is anything that gets > the end user to call the Help Desk and open a trouble ticket. :-) > > Regards, > > Dave > > David B. Nelson > Director of Technology > Elbrys Networks, Inc. > www.elbrys.com > +1.603.570.2636 > --f46d04446c015c0a6804d4a7ba72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am sorry if I am disturbing this forum, with lame questions. But I am new= to this and eager to know more by developing it.

As per the advice = from members, I am ignoring the attributes which are mentioned as 0 as per = the
table of attributes in rfc 3579 instead of discarding the packet. But, for = example, message authenticator is
mentioned as 1. which means there shou= ld be only one message authenticator in a radius packet.
If I receive a= radius packet with more than one message authenticator, should I discard t= he packet or
should I ignore it?.

Thanks & Regards,
Sivakumar.S

On Thu, Jan 31, 2013 at 6:24 PM, Dave Nelson <dne= lson@elbrys.com> wrote:
On Thu,= Jan 31, 2013 at 2:23 AM, siva kumar <shiv.annauniv@gmail.com> wrote:

> If service type is not supported and if NAS consider access-accept as<= br> > access-reject, is it ok to not authenticate/authorize the port
> without sending eap failure. Will this create an unending authenticati= on
> retries.

I think what you're asking is what's the best way for the NAS= to
signal to the end user, via the 802.1X supplicant, that the RADIUS
Server is misconfigured. =A0After all, if EAP authentication succeeds,
but the RADUS Server provisions a service the NAS cannot deliver, the
server is very likely misconfigured. =A0My answer is anything that gets
the end user to call the Help Desk and open a trouble ticket. =A0:-)

Regards,

Dave

David B. Nelson
Director of Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

--f46d04446c015c0a6804d4a7ba72-- From aland@deployingradius.com Fri Feb 1 13:36:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58CEE21E8082 for ; Fri, 1 Feb 2013 13:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.422 X-Spam-Level: X-Spam-Status: No, score=-102.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcXP3ZYdG7ZJ for ; Fri, 1 Feb 2013 13:36:07 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 68B8321E8049 for ; Fri, 1 Feb 2013 13:36:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 89DF52240C9B for ; Fri, 1 Feb 2013 22:36:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bn5uYEu+zofQ for ; Fri, 1 Feb 2013 22:36:06 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 223282240C36 for ; Fri, 1 Feb 2013 22:36:06 +0100 (CET) Message-ID: <510C3545.3060607@deployingradius.com> Date: Fri, 01 Feb 2013 16:36:05 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [radext] Update data types draft X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 21:36:08 -0000 Given Barry's comments, the data type draft becomes more relevant. It clarifies issues which he raised, and which have been ambiguous in previous specifications. http://www.ietf.org/id/draft-dekok-radext-datatypes-01.txt Alan DeKok. From hartmans@painless-security.com Fri Feb 1 13:57:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC4F321E8056 for ; Fri, 1 Feb 2013 13:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q+oboRaeMsbB for ; Fri, 1 Feb 2013 13:57:57 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2C56E21E8050 for ; Fri, 1 Feb 2013 13:57:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0024620183; Fri, 1 Feb 2013 16:53:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D432F43FD; Fri, 1 Feb 2013 16:57:55 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <510C3545.3060607@deployingradius.com> Date: Fri, 01 Feb 2013 16:57:55 -0500 In-Reply-To: <510C3545.3060607@deployingradius.com> (Alan DeKok's message of "Fri, 01 Feb 2013 16:36:05 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" Subject: Re: [radext] Update data types draft X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 21:57:57 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Given Barry's comments, the data type draft becomes more Alan> relevant. It clarifies issues which he raised, and which have Alan> been ambiguous in previous specifications. Alan> http://www.ietf.org/id/draft-dekok-radext-datatypes-01.txt Agreed. I think it's good to work on the data types. That said, I'd push back if Barry wants to add a normative reference to the data types draft. --Sam From barryleiba@gmail.com Fri Feb 1 16:40:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE23121E804A for ; Fri, 1 Feb 2013 16:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.061 X-Spam-Level: X-Spam-Status: No, score=-101.061 tagged_above=-999 required=5 tests=[AWL=-1.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_STOP=2.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEMwxP9lkDrf for ; Fri, 1 Feb 2013 16:40:19 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F31F0CFB for ; Fri, 1 Feb 2013 16:40:18 -0800 (PST) Received: by mail-la0-f41.google.com with SMTP id fo12so3297920lab.0 for ; Fri, 01 Feb 2013 16:40:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=RjkA0HnC+bj4d1Bo3xzlOKjNPRo0DdFZd30uftch++I=; b=f5mCD6pX3ldQs53XBsT6q0cXRkqAxoqCFhdqDLQN0g6JcJj37fepMaMxAww964ywPl idCtma5k9hS8nE3/7zt4kNVyYZ9Nx2P8jYVLdX6evivqJCelgzhS5zot4N/osKIY6/QI TdWQXuC/wfKn5ow0mgWaF3uk+WK+Ms8smpJ3/bYwlOFVs6yKQSabcbPR0rHuVYwF52zd LvA6FnCT4itTf9tvZ8XYM/Ylfix+b7pE7wpSFbzKzGj45r54YkSd7hXJ4trXu8KDy5c+ HRkZoP88a5Gfqdfvp9qLwuR8zk/mUrKKE9nR67VSW3tVaABV5N1Q382fLkU0WOOKXFB8 5T0A== MIME-Version: 1.0 X-Received: by 10.112.47.168 with SMTP id e8mr5462888lbn.46.1359765617867; Fri, 01 Feb 2013 16:40:17 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Fri, 1 Feb 2013 16:40:17 -0800 (PST) In-Reply-To: <510BE42B.1060102@deployingradius.com> References: <510BE42B.1060102@deployingradius.com> Date: Fri, 1 Feb 2013 19:40:17 -0500 X-Google-Sender-Auth: tniaCFmRhL-UUWedx4cfA-fZ9So Message-ID: From: Barry Leiba To: Alan DeKok Content-Type: text/plain; charset=ISO-8859-1 Cc: "radext@ietf.org" , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 00:40:20 -0000 Hi, Alan. > I've taken the liberty of responding to both messages here. Great; thanks for merging them. And thanks for the quick reply. I'm travelling (Japan & China), but I'll try to be as responsive. Just the things that need further comment... >> -- Section 2.1 -- >> >> === COMMENT === >> In the description of "Type": >> >> I suggest adding a forward reference to make an important > clarification here: >> >> NEW >> This field is identical to the Type field of the Attribute format >> defined in [RFC2865] Section 5. It will contain one of the Extended >> Type values defined in Section 3, below. >> END > > I'm not sure why that's necessary. The Type field always contains a > valid RADIUS attribute type. The Attribute Types are managed by IANA, > and new attributes of "Extended Type" can be assigned at any time. > > The intention here is to define the format, independent of value. > IANA can then assign certain values as having a particular format. Understood... and this is a non-blocking comment, so I won't pursue it beyond this response. I just thought it would be useful to clarify that *this* format is *only* used with the extended type values, and not with any others. If you think it's not necessary to say that, then we're done here. But perhaps it's a harmless and useful thing to add. >> === COMMENT === >> In the description of "Length": >> >> The Length field is one octet, and indicates the length of this >> Attribute including the Type, Length, Extended-Type, and Value >> fields. Permitted values are between 4 and 255. If a client or >> server receives an Extended Attribute with a Length of 2 or 3, >> then that Attribute MUST be considered to be an "invalid >> attribute", and handled as per Section 2.8, below. >> >> Curious: What does a client or server do when it receives an Extended >> Attribute with a length of 0 or 1? (Same comment goes for Section >> 2.2.) > > This is covered in the definition of RADIUS attributes, in RFC 2865, > Section 5, top of page 25. The Length field includes the "Type" and > "Length" fields, so Lengths of 0 and 1 are invalide. Right, I understand that. And so... what should an implementation that receives an EA with a length of 1 do? If the answer is, "Well, treat it as an invalid attribute, of course," then why shouldn't the text above just say, "If a client or server receives an Extended attribute with a length less than 4, then..."? I don't see the point in calling out 2 and 3 specifically. But, again, this one is non-blocking, so this is all I'll say about that. Do what you think is best. >> === DISCUSS === >> Also, this doesn't make sense to me. Section 2.8 starts with this: >> >> The term "invalid attribute" is new to this specification. It is >> defined to mean that the Length field of an Attribute is valid (as >> per [RFC2865], Section 5, top of page 25). >> >> These two appear to be contradictory: the first says that if the >> length is invalid, it's an "invalid attribute", and the second says >> that "invalid attribute" means that the length field is valid (but >> there are other problems). This comment also applies to "TLV-Length" >> in Section 2.3. > > The intent here is that the *contents* of the attribute are invalid. Yes, I get that. You are saying (in 2.8) that "invalid attribute" is a situation when the length is valid and the content is not. But you are also saying (in 2.1) that an EA is considered "invalid attribute" when its length is invalid. Do you not see those two as contradictory? >> === DISCUSS === >> In the description of "Value": >> >> This field is similar to the Value field of the Attribute format >> defined in [RFC2865] Section 5. The format of the data SHOULD be >> a valid RADIUS data type. >> >> The addition of the Extended-Type field decreases the maximum >> length for attributes of type "text" or "string" from 253 to 252 >> octets. Where an Attribute needs to carry more than 252 octets of >> data, the "Long Extended Type" format SHOULD be used. >> >> The first SHOULD makes a subtle, but very significant change to the >> RADIUS protocol, and I want to make sure what you're doing is what you >> mean to do. 2865 says, "The format of the value field is one of five >> data types." It has to be one of those types, and can't be anything >> else -- nothing else is defined. > > The text in RFC 2865 isn't a MUST. I think we understand normative language differently (perhaps we should loop Pete Resnick in on this point). When a spec says "X is Y" or "X contains integer values from 1 to 9", or similar things, it's making a normative statement that that's the way it is, and there are no other choices. It really is equivalent to MUST, in a situation where using the word MUST is not necessary. > Many other RADIUS RFCs have been > published which add new data types And that's fine: they have expanded the definition of the field. In an example where the base spec says "X is an integer that has values from 1 to 9", we can put out another spec that updates the base and says, "valid values for X are expanded to include 10 through 66." The result is that X can now be 1 to 66. But 88 is still invalid (MUST NOT be used, if you put it in 2119 language). If you then say, in another update document, "X SHOULD have values from 1 to 75", you have made a significant change: you're not only expanding the valid range to 75, but you're *also* saying that 88 is OK now, if the implementor fully understands the implications. Before, 88 was simply invalid. Now, 88 is valid, but NOT RECOMMENDED. There's a difference, and I want to be sure that difference is intended, not accidental. >> But you are now allowing an >> implementor who understands the implications of doing so to use a >> different data type. > > That has *always* been the RADIUS practice. This document changes > nothing. That's simply not correct. It may well be that this document does not change actual practice. But it's *certainly* true that this document changes what is *valid* according to the specification. >From this discussion, though, it seems that the change *is* what you mean to do. But it disturbs me that you don't see that you're changing anything (and, by extension, that the WG perhaps does not understand that either). >> 1. Do you really mean to allow that? > > Yes. OK > >> 2. If "yes" to (1), what other data types exist that might be used? > > Lots. > >> Where are their formats defined? > > 6158, and my individual draft. OK, and I understand that the RADIUS community is well aware of this. I have no concern about that now; thanks. >> 3. If "yes" to (1), what *are* the implications of using other data types? > > Pretty much nothing. Implementations define many non-standard data > types, such as 8-bit integer, 32-bit integer, "polymorphic" > attributes, etc. Then what's the point of the SHOULD? If it doesn't matter -- if there are no interoperability implications, or whatnot -- then you shouldn't be saying SHOULD. >> For the second SHOULD, there's a similar issue: What are the >> alternatives to using the "Long Extended Type" format? What are the >> implications of using those alternatives? > > The alternatives are to use "ad hoc" methods. An attribute is > defined to have the magical property that multiple attributes mean > fragmented data. This has to be specified for each attribute needing > this property, and has to be implemented in an ad-hoc way in any > client or server. > > i.e. there is *no* standard way to transport more than 253 octets of > data. That's why we're writing this draft. Understood. Then why is this not MUST? >> === DISCUSS === >> In the description of the "M" bit: >> >> 1. The first two paragraphs contradict each other. The first says >> that M MUST be 0 if length < 255. The second says, "When the More >> field is set (1), the attribute SHOULD have a Length field of value >> 255". According to the first paragraph, that needs to be MUST, not >> SHOULD. And then with that change, the next clause (about value 4) >> can be removed. >> The "that is" at the beginning of the third sentence >> should be removed, because the ordering has not been mentioned before. > > I'm not sure why. Where else would this be mentioned? I think you misunderstand what I'm asking -- it's a minor point of English usage. We usually use "that is" to talk about something that's already been said, but we need to highlight it or say it another way. In this case, you haven't said anything at all about ordering yet, so I think you should just take the words "that is" out. That's all. No big deal, and this part is certainly non-blocking! >> The RADIUS header is 20 octets, so that's 4096-20 = 4076 octets left >> for attributes. That will hold 15 fragments of 255 octets each, and a >> 16th fragment of 231 octets. And that results in a total attribute >> length (after headers are removed and the fragments are assembled) of >> 15*251+227 = 3992. > > I think that's a little detailed for the document, but sure. I'll > write some clarifying text. Yes, sure... I didn't mean that I expected you to put the computation in the document! Thanks. >> === DISCUSS === >> The last paragraph of Section 2.2 says this: >> >> Implementations MUST be able to process non- >> contiguous fragments. That is, fragments which are mixed together >> with other attributes of a different Type. >> >> That contradicts what you said in the description of the "M" bit: > > Sort of. The text above suggests that implementations be liberal in > what they accept. The other text mandates that implementations be > conservative in what they generate. OK, but then I think this text should make that clear. Something like this: Implementations MUST be able to process non- contiguous fragments -- that is, fragments which are mixed together with other attributes of a different Type. This will allow them to accept errors in the sending of the atrtibutes. Or some such. Otherwise, it leaves the contradiction in question. >> === DISCUSS === >> -- Section 2.3.1 -- >> >> The depth of TLV nesting is limited only by the restrictions on the >> TLV-Length field. The limit of 253 octets of data results in a limit >> of 126 levels of nesting. However, nesting depths of more than 4 are >> NOT RECOMMENDED. >> >> Again: Why is it NOT RECOMMENDED? > > The recommendation above came out of discussion in the RADEXT WG. > There are existing non-IETF specifications which uses nested TLVs. > They haven't seen a need for a nesting of more than 4 levels deep. > > The WG consensus was that we had no idea *why* anyone would need > more than 4 levels of nesting. And if a specification tried to use > that deep of a nesting, it would cause discussion, and likely a > re-design. Understood. But from the point of view of RFC 2119 (Section 6): Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. If there is no reason to limit the nesting depth other than that you think it's unnecessary to allow more than 4 levels, then you shouldn't be using 2119 key words for it. Maybe, "However, nesting depths of more than 4 have not been shown to be necessary, may be indicative of implementation errors, and ought not be used." Or something like that. Doesn't have to go into any detail, but just not say that something is an interoperability issue if it's not. >> === COMMENT === >> -- Section 2.7.4 -- >> >> In the first sentence of the fourth paragraph, it seems as though "few >> restrictions" is meant to be "a few restrictions", yes? ... > Instead, we note that many values exist, with few restrictions. Ack. Then it's correct as it stands. >> === COMMENT === >> -- Section 2.8 -- >> >> For Attributes of type "Long Extended Type", an Attribute is >> considered to be an "invalid attribute" when does not match the >> criteria set out in Section 2.2, above. ... >> 2. I think it would be useful to remind implementors that one bad >> apple spoils the whole bunch: that if one fragment of a fragmented >> attribute is invalid, the entire attribute (all fragments) needs to be >> considered invalid. ... > I think a better phrasing would be to update that text in Section > 2.2 with the following: > > If the reassembled data does not match the expected format, all > fragments MUST be treated as "invalid attributes", and the reassembled > data MUST be discarded. Perfect. >> === COMMENT === >> -- Sections 3 and 4 subsections -- >> >> It somewhat bothers me to have the diagrams and some information >> repeated here (repeated repeatedly, in fact). Is it not possible to >> refer back to Sections 2.1 and 2.2 even more than you already do? > > It's the practice with RADIUS specifications. RFC 2865 defines an > attribute format, data types, but then repeats the ASCII art for each > attribute. OK. No problem. >> === DISCUSS === >> -- Section 6.5 and 6.6 -- >> >> From 6.5: >> * Where a group of TLVs is loosely defined, or is expected to change, >> they SHOULD request allocation from the "long extended space". >> >> From 6.6: >> * Specifications of an attribute which always encode less than 253 >> octets of data MUST NOT request allocation from the long extended >> space. The standard space, or the short extended space MUST be >> used instead. >> >> Isn't this a contradiction? If I have a loosely defined group of TLVs >> that I expect to have change, but which will always be less than 253 >> octets, which space do I get it from? > > The text says "short extended space". The text in 6.6 says that, yes. But the text in 6.5 says that it SHOULD come from "long extended space". I think they contradict each other. Don't they? --- Ha... a much smaller list remains! Barry From hartmans@painless-security.com Fri Feb 1 17:32:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED5F21F8C0B for ; Fri, 1 Feb 2013 17:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_STOP=2.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnsJUiJH8Wg4 for ; Fri, 1 Feb 2013 17:32:36 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2955721F8995 for ; Fri, 1 Feb 2013 17:32:25 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 79B6F20183; Fri, 1 Feb 2013 20:28:25 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E7E6443FD; Fri, 1 Feb 2013 20:32:23 -0500 (EST) From: Sam Hartman To: Barry Leiba References: <510BE42B.1060102@deployingradius.com> Date: Fri, 01 Feb 2013 20:32:23 -0500 In-Reply-To: (Barry Leiba's message of "Fri, 1 Feb 2013 19:40:17 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , radext-ads@tools.ietf.org, Alan DeKok Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 01:32:37 -0000 >>>>> "Barry" == Barry Leiba writes: esn't make sense to me. Section >>> 2.8 starts with this: >>> >>> The term "invalid attribute" is new to this specification. It >>> is defined to mean that the Length field of an Attribute is >>> valid (as per [RFC2865], Section 5, top of page 25). >>> >>> These two appear to be contradictory: the first says that if the >>> length is invalid, it's an "invalid attribute", and the second >>> says that "invalid attribute" means that the length field is >>> valid (but there are other problems). This comment also applies >>> to "TLV-Length" in Section 2.3. >> >> The intent here is that the *contents* of the attribute are >> invalid. Barry> Yes, I get that. Barry> You are saying (in 2.8) that "invalid attribute" is a Barry> situation when the length is valid and the content is not. Barry> But you are also saying (in 2.1) that an EA is considered Barry> "invalid attribute" when its length is invalid. If I may, I think this is a layering issue. You have the base radius layer, which requires length be at least 2. If your length isn't 2, you fall off the parse path in RFC 2865; it's a low level problem. If your length is at least 2 you get into an attribute-type-specific abstraction. One outcome of this abstraction is "invalid attribute," a new concept introduced in this spec. It means well-formed at the 2865-level but semantically garbage at an attribute-type-specific level introduced in this spec. And the attribute-type-specific layer for extended types introduces the length must be 4 rule. So, it's kind of like saying that a different chunk of code in the abstraction will return an error depending on which length range things fall in. 0-1: something like BaseRadius.WayTooShort; 2: if it's an extended attribute extendedattribute.InvalidAttribute The above is just an analogy to explain why I don't think it's contradictory. I'm not entirely convinced that distinction in abstraction is useful. I.E. the spec might be improved by addressing your concern, and the wording might not be good enough for you to see a reading that isn't contradictory, but I don't see any internal consistency problem. --Sam From aland@deployingradius.com Fri Feb 1 17:34:09 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2672B21F8E05 for ; Fri, 1 Feb 2013 17:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckU1M7DK4sBy for ; Fri, 1 Feb 2013 17:34:07 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 947B821F8E02 for ; Fri, 1 Feb 2013 17:34:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id F22CE2240C9B; Sat, 2 Feb 2013 02:34:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lujjIkjz5Vzb; Sat, 2 Feb 2013 02:34:04 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id E964D2240A2D; Sat, 2 Feb 2013 02:34:03 +0100 (CET) Message-ID: <510C6D0A.6020503@deployingradius.com> Date: Fri, 01 Feb 2013 20:34:02 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Barry Leiba References: <510BE42B.1060102@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 01:34:09 -0000 Barry Leiba wrote: > Understood... and this is a non-blocking comment, so I won't pursue > it beyond this response. I just thought it would be useful to clarify > that *this* format is *only* used with the extended type values, and > not with any others. If you think it's not necessary to say that, > then we're done here. But perhaps it's a harmless and useful thing to > add. I'll take a look at coming up with some phrasing. > Right, I understand that. And so... what should an implementation > that receives an EA with a length of 1 do? It won't. The *packet* is malformed, and will be discarded. So any *attribute* parsing will always see a Length of 2 or more. > If the answer is, "Well, treat it as an invalid attribute, of course," > then why shouldn't the text above just say, "If a client or server > receives an Extended attribute with a length less than 4, then..."? I > don't see the point in calling out 2 and 3 specifically. Because 2 and 3 are values which allow the packet to be "well formed", but result in the attribute being invalid. Therefore, they need to be called out as invalid for the attribute. > You are saying (in 2.8) that "invalid attribute" is a situation when > the length is valid and the content is not. > > But you are also saying (in 2.1) that an EA is considered "invalid > attribute" when its length is invalid. > > Do you not see those two as contradictory? Superficially, yes. It's the distinction between packets and attributes that makes them consistent. Perhaps the text could better say: --- The term "invalid attribute" is new to this specification. It is defined to mean that the Length field of an Attribute permits the packet to be accepted as not being "malformed". However, the Value field of the attribute does not follow the format required by the data type defined for that Attribute, and therefore the attribute is "malformed". In order to distinguish the two cases, we refer to "malformed" packets, and "invalid attributes". For example, an implementation receives a packet which is well-formed. That packet contains an Attribute allegedly of data type "address", but which has Length not equal to four. In that situation, the packet is well formed, but the attribute is not. Therefore, it is an "invalid attribute". A similar analysis can be performed when an attribute carries TLVs. The encapsulating attribute may be well formed, but the TLV may be an "invalid attribute". The existence of an "invalid attribute" in a packet or attribute MUST NOT result in the implementation discarding the entire packet, or treating the packet as a negative acknowledgment. Instead, only the "invalid attribute" is treated specially. --- > I think we understand normative language differently (perhaps we > should loop Pete Resnick in on this point). When a spec says "X is Y" > or "X contains integer values from 1 to 9", or similar things, it's > making a normative statement that that's the way it is, and there are > no other choices. It really is equivalent to MUST, in a situation > where using the word MUST is not necessary. Yes. However, this document isn't setting out to correct two decades of RADIUS mis-steps. I don't want to see this document held up to correct ambiguities raised in other specifications. >> Many other RADIUS RFCs have been >> published which add new data types > > And that's fine: they have expanded the definition of the field. That's the point. They haven't. The "data types" defined in RFC 2865 were *never* expanded. Later RFCs used many new data types, without naming or defining them. They therefore fail to meet the requirement of 2865 that only 5 data types are valid. >>> But you are now allowing an >>> implementor who understands the implications of doing so to use a >>> different data type. >> That has *always* been the RADIUS practice. This document changes >> nothing. > > That's simply not correct. It may well be that this document does not > change actual practice. But it's *certainly* true that this document > changes what is *valid* according to the specification. > > From this discussion, though, it seems that the change *is* what you > mean to do. But it disturbs me that you don't see that you're > changing anything (and, by extension, that the WG perhaps does not > understand that either). Of course we're changing RADIUS by adding the new formats. That much is obvious. What I object to is the idea that we can't add *new* data types to the ones listed in 2865. Why? This document updates 2865, which is part of the IETF process. Much effort went into ensuring that *existing* implementations wouldn't break when they saw packets using the new data types. For those implementations, nothing changes. They see attributes which were unallocated when the implementation was written. Therefore, they ignore them. >>> 3. If "yes" to (1), what *are* the implications of using other data types? >> Pretty much nothing. Implementations define many non-standard data >> types, such as 8-bit integer, 32-bit integer, "polymorphic" >> attributes, etc. > > Then what's the point of the SHOULD? If it doesn't matter -- if there > are no interoperability implications, or whatnot -- then you shouldn't > be saying SHOULD. Yes. It will be a MUST. >> i.e. there is *no* standard way to transport more than 253 octets of >> data. That's why we're writing this draft. > > Understood. Then why is this not MUST? OK. >>> That contradicts what you said in the description of the "M" bit: >> Sort of. The text above suggests that implementations be liberal in >> what they accept. The other text mandates that implementations be >> conservative in what they generate. > > OK, but then I think this text should make that clear. Something like this: > > Implementations MUST be able to process non- > contiguous fragments -- that is, fragments which are mixed together > with other attributes of a different Type. This will allow them to > accept errors in the sending of the atrtibutes. > > Or some such. Otherwise, it leaves the contradiction in question. OK. I'll add some text. > Understood. But from the point of view of RFC 2119 (Section 6): > > Imperatives of the type defined in this memo must be used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a particular method > on implementors where the method is not required for > interoperability. > > If there is no reason to limit the nesting depth other than that you > think it's unnecessary to allow more than 4 levels, then you shouldn't > be using 2119 key words for it. The consensus was also that allowing nesting of more than 4 levels deep would make implementations much more complex. > Maybe, "However, nesting depths of > more than 4 have not been shown to be necessary, may be indicative of > implementation errors, and ought not be used." Or something like that. > Doesn't have to go into any detail, but just not say that something > is an interoperability issue if it's not. How about this: The depth of TLV nesting is limited only by the restrictions on the TLV-Length field. The limit of 253 octets of data results in a limit of 126 levels of nesting. However, nesting depths of more than 4 are NOT RECOMMENDED. They have not been demonstrated to be necessary in practice, and they appear to make implementations more complex. Reception of packets with such deeply nest TLVs may indicate implementation errors or denial of service attacks. Where implementations do not support deep nesting of TLVs, it is RECOMMENDED that the unsupported layers are treated as "invalid attributes". >>> Isn't this a contradiction? If I have a loosely defined group of TLVs >>> that I expect to have change, but which will always be less than 253 >>> octets, which space do I get it from? >> The text says "short extended space". > > The text in 6.6 says that, yes. But the text in 6.5 says that it > SHOULD come from "long extended space". I think they contradict each > other. Don't they? The text in 6.5 says: * Where a group of TLVs is strictly defined, and not expected to change, and totals less than 247 octets of data, they SHOULD request allocation from the "short extended space". * Where a group of TLVs is loosely defined, or is expected to change, they SHOULD request allocation from the "long extended space". So I think it's OK. > Ha... a much smaller list remains! Quick turn-around helps. I'll issue another draft now. Alan DeKok. From internet-drafts@ietf.org Fri Feb 1 17:37:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EEF121F8AA8; Fri, 1 Feb 2013 17:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LijBZ6Lwe1b; Fri, 1 Feb 2013 17:37:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D3FF21F8AB0; Fri, 1 Feb 2013 17:37:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130202013710.27195.27056.idtracker@ietfa.amsl.com> Date: Fri, 01 Feb 2013 17:37:10 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-11.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 01:37:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-11.txt Pages : 67 Date : 2013-02-01 Abstract: The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-extensions-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From barryleiba@gmail.com Fri Feb 1 22:44:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884D021F8F69 for ; Fri, 1 Feb 2013 22:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.014 X-Spam-Level: X-Spam-Status: No, score=-103.014 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGp8mj-wh0Ts for ; Fri, 1 Feb 2013 22:44:23 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC80B21F8F64 for ; Fri, 1 Feb 2013 22:44:22 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id n8so5281039lbj.17 for ; Fri, 01 Feb 2013 22:44:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=fy+Y4RNMLSMmYz1+V5hmHg058gCwn4zBvHsAi5qqQEk=; b=J/227dALuVn6GV6eJeF7XrGKZrfGOtxyjcu2HXgAMdi7gQNuKpp3T/11rOgqzVCHQE lbBt1HZlXGByE4Cad1wyixf+sum8jqB6OeJI7LT4q+LGwD7N6EW+KNXkwY5OUlHZI+gK zwc+ADA6MCncYzcHE3PwvYqgCfq0JO6Ewje/oFBLWvn9BEDFpPvrxvPE4uXvNLoTuiKH XSeORCm7/bC6q0Y/+G3B1bApUolxIQ38JIKWvjpTWH8Ke77qzE44jXKJlEuxjtPwzH1H uAbF4gMMaye3sFFe30W4BlT82DakYvZOhxH/0CiBAdMlZsPUi+pkG4qQ54aFCJD33jJM z+0Q== MIME-Version: 1.0 X-Received: by 10.152.147.36 with SMTP id th4mr13433543lab.19.1359787454538; Fri, 01 Feb 2013 22:44:14 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Fri, 1 Feb 2013 22:44:14 -0800 (PST) In-Reply-To: <510C6D0A.6020503@deployingradius.com> References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> Date: Sat, 2 Feb 2013 01:44:14 -0500 X-Google-Sender-Auth: 5q10H5ococ4E7DkyapUJPqYHB2Q Message-ID: From: Barry Leiba To: Alan DeKok Content-Type: text/plain; charset=ISO-8859-1 Cc: "radext@ietf.org" , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 06:44:24 -0000 >> Right, I understand that. And so... what should an implementation >> that receives an EA with a length of 1 do? > > It won't. The *packet* is malformed, and will be discarded. So any > *attribute* parsing will always see a Length of 2 or more. Ack. Between Sam's answer and yours, I now understand this. I still think it would be better to just say "less than 4", which would cover all cases without confusing anyone (uh, like me)... but this issue is answered, and if you really want to say "2 or 3" rather than "less than 4", I understand. > Superficially, yes. It's the distinction between packets and > attributes that makes them consistent. > > Perhaps the text could better say: > > --- > The term "invalid attribute" is new to this specification. It is > defined to mean that the Length field of an Attribute permits the > packet to be accepted as not being "malformed". However, the Value > field of the attribute does not follow the format required by the data > type defined for that Attribute, and therefore the attribute is > "malformed". In order to distinguish the two cases, we refer to > "malformed" packets, and "invalid attributes". ...etc... That'd be lovely, and thanks. I accept that this might already be clear to RADIUS folks ("RADII"?). On the other hand, there are often people implementing our specs who don't start off knowing what they're doing, and clarity for outsiders can really help them. >> I think we understand normative language differently (perhaps we >> should loop Pete Resnick in on this point). When a spec says "X is Y" >> or "X contains integer values from 1 to 9", or similar things, it's >> making a normative statement that that's the way it is, and there are >> no other choices. It really is equivalent to MUST, in a situation >> where using the word MUST is not necessary. > > Yes. However, this document isn't setting out to correct two decades > of RADIUS mis-steps. I don't want to see this document held up to > correct ambiguities raised in other specifications. No, I agree with you. I'm certainly not aiming to do that, and I'll consider my comments in that light. >> From this discussion, though, it seems that the change *is* what you >> mean to do. But it disturbs me that you don't see that you're >> changing anything (and, by extension, that the WG perhaps does not >> understand that either). > > Of course we're changing RADIUS by adding the new formats. That much > is obvious. What I object to is the idea that we can't add *new* data > types to the ones listed in 2865. Why? This document updates 2865, > which is part of the IETF process. Ah, no, you still misunderstand. You *absolutely* can do that, and should. That's not my question at all. My question was just about the SHOULD. The original spec said that there were certain valid data types, and everything else was invalid. Other specs added new data types, but everything else that wasn't specified somewhere was still invalid. By putting that SHOULD in, you're saying that other data types, ones that aren't specified in any specs, ARE valid, but just SHOULD NOT be used. That's different to what the spec said before. You have told me that this change is reflecting actual deployment, and is intentional. I accept that, so we're actually OK on this point now. I wish this had been specified differently, but we are where we are. So I think we can let this point rest, and thanks for working with me on it. > How about this: > > The depth of TLV nesting is limited only by the restrictions on the > TLV-Length field. The limit of 253 octets of data results in a limit > of 126 levels of nesting. However, nesting depths of more than 4 are > NOT RECOMMENDED. They have not been demonstrated to be necessary in > practice, and they appear to make implementations more complex. > Reception of packets with such deeply nest TLVs may indicate > implementation errors or denial of service attacks. Where > implementations do not support deep nesting of TLVs, it is RECOMMENDED > that the unsupported layers are treated as "invalid attributes". Groovy. >>>> Isn't this a contradiction? If I have a loosely defined group of TLVs >>>> that I expect to have change, but which will always be less than 253 >>>> octets, which space do I get it from? >>> >>> The text says "short extended space". >> >> The text in 6.6 says that, yes. But the text in 6.5 says that it >> SHOULD come from "long extended space". I think they contradict each >> other. Don't they? > > The text in 6.5 says: > > * Where a group of TLVs is strictly defined, and not expected to > change, and totals less than 247 octets of data, they SHOULD > request allocation from the "short extended space". > > * Where a group of TLVs is loosely defined, or is expected to change, > they SHOULD request allocation from the "long extended space". > > So I think it's OK. This is the only one that remains, and I'm happy to downgrade it to COMMENT level, given the discussion. It is now officially non-blocking. It's that second bullet you quote that I wonder about. Is it possible for a group of TLVs to be loosely defined or expected to change (and thus fit under the second bullet there), and yet always encode less than 253 octets (and this fit into the "short extended space MUST be used" bullet in 6.6? Perhaps that's not possible, so there's no issue at all. But if it is possible, I think there's a conflict between the last bullet in 6.5 and the 6th bullet in 6.6, *in that specific situation*. I'll go through the diffs between -09 and -11 now, while I wait for my flight to HKG, and double-check that we're all set on the other points. b From barryleiba@gmail.com Fri Feb 1 22:53:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA1521F90C1 for ; Fri, 1 Feb 2013 22:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.013 X-Spam-Level: X-Spam-Status: No, score=-103.013 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nNZrogt0aMd for ; Fri, 1 Feb 2013 22:53:50 -0800 (PST) Received: from mail-lb0-f180.google.com (mail-lb0-f180.google.com [209.85.217.180]) by ietfa.amsl.com (Postfix) with ESMTP id 2E63E21F90BD for ; Fri, 1 Feb 2013 22:53:49 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id q12so5147225lbc.25 for ; Fri, 01 Feb 2013 22:53:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cE2E/Mco9fw1H2y40qva4lXPBoQcnHYi9QovdSo2KV8=; b=BwK5RUwb3M3NyOReVkw7Au8M9E5f4DKxpXeGCWl6dZ/OPHhilea+sdBty7IBIwr9kH VODwsNYyK85OotAjYGiHcttQGKvVebG8785ycQ3E8Hz0Nq+KfYm0UKXuohVrhqKel4vm B5RVZSNrAzES5QqqEwMJuJQhl4FXgOK1MmaavOsuwMWgqkTfxt9qhVIRb5e2wy6I0QN3 ycxUR7fvbrkJHZvFtoredf3pRK4Utd/mQm8rSIrBSUT6GeImW9LzJjs7KEd5xcLjwsIQ yEtB3EUCnU59jE1gxG6CqsnJZXrZ8or4/Cr0+C1apFhwXCfmoIMicRDKExHbf4mbPKKC /kyw== MIME-Version: 1.0 X-Received: by 10.112.82.166 with SMTP id j6mr5680838lby.25.1359788029082; Fri, 01 Feb 2013 22:53:49 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Fri, 1 Feb 2013 22:53:48 -0800 (PST) In-Reply-To: References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> Date: Sat, 2 Feb 2013 01:53:48 -0500 X-Google-Sender-Auth: -_LS0-4tUgzdrdl8rm6BmEVOHBg Message-ID: From: Barry Leiba To: Alan DeKok Content-Type: text/plain; charset=ISO-8859-1 Cc: "radext@ietf.org" , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Feb 2013 06:53:52 -0000 > I'll go through the diffs between -09 and -11 now, while I wait for my > flight to HKG, and double-check that we're all set on the other > points. Verified. Please make any further changes that my last message moves you to, and then make sure the working group is OK with the changes. And, again, thanks very much for working through this with me! Barry From barryleiba@gmail.com Sat Feb 2 18:49:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A96D21F8423 for ; Sat, 2 Feb 2013 18:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.012 X-Spam-Level: X-Spam-Status: No, score=-103.012 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUwG4sWGEHKB for ; Sat, 2 Feb 2013 18:49:23 -0800 (PST) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id DC69521F884A for ; Sat, 2 Feb 2013 18:49:18 -0800 (PST) Received: by mail-lb0-f171.google.com with SMTP id gg13so5744819lbb.30 for ; Sat, 02 Feb 2013 18:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dz9XrmEnLnu6BmDTey7f5fU54MAmDzjfjaGTDl1zV6E=; b=N4nzqQhoWJjPm1cao1VScTE1lu0jGP6M/zhJan6fagZWe9PUrUoWpSPJTrREOGubBt xfgyH0Xge6c61yX5fott5wwtWpYm4jjFVqrVKQtFbDFPJ2Kr2fqAAzF7eZI/8GnVZNMT +WjdidGpLON26zGonp0An4qXS3JstJ0MQXfVq1F9q0WsHcDbDcX5iaNeeM/hZqVckeaH AUdCffDnxJ10KCxlnCPH6Rq1iZVZr3R1NQNB342yi5dR5jxfkFavuaLCHCAkHIJ9+u5J QRDs19O4t7tkCEP5eZGBuYeuLZdxyLq55Y71qXOv0VOmcNFZ3idyJMAZkf75asFdHyaK PwNw== MIME-Version: 1.0 X-Received: by 10.152.121.212 with SMTP id lm20mr15196460lab.42.1359859758119; Sat, 02 Feb 2013 18:49:18 -0800 (PST) Sender: barryleiba@gmail.com Received: by 10.112.47.168 with HTTP; Sat, 2 Feb 2013 18:49:17 -0800 (PST) In-Reply-To: References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> Date: Sun, 3 Feb 2013 11:49:17 +0900 X-Google-Sender-Auth: z8e5SVS7Vty--Z5lU2MFFn4DlGk Message-ID: From: Barry Leiba To: Alan DeKok Content-Type: text/plain; charset=ISO-8859-1 Cc: "radext@ietf.org" , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 02:49:24 -0000 >> I'll go through the diffs between -09 and -11 now, while I wait for my >> flight to HKG, and double-check that we're all set on the other >> points. > > Verified. Please make any further changes that my last message moves > you to, and then make sure the working group is OK with the changes. FWIW, my suggestion: 1. Alan posts a -12 version if he has further changes. 2. Alan posts a message to the radext list, saying that he's made quite a bunch of changes in response to IESG Evaluation, and the WG should review them. Include a URL for the diff between -09 and -12 (or -11). 3. The chairs post a message to the radext list asking for any objections to the changes to be posted by, say, 15 Feb. The chairs might specifically note that this is a call for review of the changes only. 4. Benoit sticks the document on the 21 Feb telechat agenda (and remember to go back afterward and remove the "returning item" flag). I suggest doing this now; no need to wait. 5. When 15 Feb rolls around, Benoit changes the status back to "IESG Evaluation". Of course, this all assumes no significant objections from the WG, but you all know how to deal with that if it happens. :-) Barry From peterd@iea-software.com Sat Feb 2 21:38:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D66521F8479 for ; Sat, 2 Feb 2013 21:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0x2iWMc9y8-a for ; Sat, 2 Feb 2013 21:38:41 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id B3A4C21F8456 for ; Sat, 2 Feb 2013 21:38:40 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Sat, 2 Feb 2013 21:38:34 -0800 Date: Sat, 2 Feb 2013 21:37:00 -0800 (Pacific Standard Time) From: Peter Deacon To: "radext@ietf.org" Message-ID: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 05:38:42 -0000 Put together a small presentation for an approach to support large RADIUS packets beyond 4096 bytes. The approach leverages a simple 802.1Q style scheme for large packet support across all command codes. Would be interested to gage any interest from WG in general concept. Narration not included.. please feel free to contact me if you have any questions. http://www.iea-software.com/ietf/radfragment.pdf regards, Peter From aland@deployingradius.com Sun Feb 3 07:12:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BCE821F843B for ; Sun, 3 Feb 2013 07:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.446 X-Spam-Level: X-Spam-Status: No, score=-102.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dyd4o8X69mAb for ; Sun, 3 Feb 2013 07:12:10 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 549C621F845A for ; Sun, 3 Feb 2013 07:12:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D46812240FA1; Sun, 3 Feb 2013 16:11:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rp7wJvQR6dUV; Sun, 3 Feb 2013 16:11:17 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 4DE59224078F; Sun, 3 Feb 2013 16:11:17 +0100 (CET) Message-ID: <510E7E16.6070105@deployingradius.com> Date: Sun, 03 Feb 2013 10:11:18 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Barry Leiba References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 15:12:11 -0000 Barry Leiba wrote: > 1. Alan posts a -12 version if he has further changes. I don't at this time. > 2. Alan posts a message to the radext list, saying that he's made > quite a bunch of changes in response to IESG Evaluation, and the WG > should review them. Include a URL for the diff between -09 and -12 > (or -11). http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-extensions-10.txt http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-extensions-11.txt I hope there will be little issue with the diffs. They are clarifications, with no change of function or meaning. Alan DeKok. From hartmans@painless-security.com Sun Feb 3 07:29:04 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B63F21F853C for ; Sun, 3 Feb 2013 07:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCLzQp6PQ3Ee for ; Sun, 3 Feb 2013 07:29:03 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 81C4321F8539 for ; Sun, 3 Feb 2013 07:29:03 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 6BB4920118; Sun, 3 Feb 2013 10:25:00 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D257243FD; Sun, 3 Feb 2013 10:28:58 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> <510E7E16.6070105@deployingradius.com> Date: Sun, 03 Feb 2013 10:28:58 -0500 In-Reply-To: <510E7E16.6070105@deployingradius.com> (Alan DeKok's message of "Sun, 03 Feb 2013 10:11:18 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , Barry Leiba , radext-ads@tools.ietf.org Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 15:29:04 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Barry Leiba wrote: >> 1. Alan posts a -12 version if he has further changes. Alan> I don't at this time. >> 2. Alan posts a message to the radext list, saying that he's made >> quite a bunch of changes in response to IESG Evaluation, and the >> WG should review them. Include a URL for the diff between -09 >> and -12 (or -11). Alan> http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-extensions-10.txt Alan> http://tools.ietf.org/rfcdiff?url2=draft-ietf-radext-radius-extensions-11.txt Alan> I hope there will be little issue with the diffs. They are Alan> clarifications, with no change of function or meaning. I have not reviewed the diffs, but from what I've read of barry's comments and Alan's responses, this all sounds quite minor. --Sam From hartmans@painless-security.com Sun Feb 3 08:03:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7C021F8473 for ; Sun, 3 Feb 2013 08:03:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.369 X-Spam-Level: X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKVIRra4qoEZ for ; Sun, 3 Feb 2013 08:03:54 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C6E6F21F8449 for ; Sun, 3 Feb 2013 08:03:52 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id D81D420118; Sun, 3 Feb 2013 10:59:49 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5262243FD; Sun, 3 Feb 2013 11:03:48 -0500 (EST) From: Sam Hartman To: Peter Deacon References: Date: Sun, 03 Feb 2013 11:03:48 -0500 In-Reply-To: (Peter Deacon's message of "Sat, 2 Feb 2013 21:37:00 -0800 (Pacific Standard Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 16:03:55 -0000 >>>>> "Peter" == Peter Deacon writes: Peter> Put together a small presentation for an approach to support Peter> large RADIUS packets beyond 4096 bytes. The approach Peter> leverages a simple 802.1Q style scheme for large packet Peter> support across all command codes. Hi. When I read your presentation, I was quite frustrated, because there's been a concept of RADIUS fragmentation going on for several months and your presentation is not responsive to that existing discussion. I hope that when people introduce alternatives into an ongoing discussion it is because they believe their alternative provides significant additional value. I hope that the introduction of the alternative would be focused around that additional value rather than presenting an alternative without relating it to the context of the ongoing discussion. I believe that by relating it to the ongoing discussion and comparing approaches, the conversation is more respectful of the different alternatives and their value. Would you explain why you find this approach better than the approach already under discussion? I think the existing approach has two significant advantages over the new approach: 1) It never requires there to be RADIUS packets running around longer than 4096 bytes. In a lot of RADIUS implementations I've looked at, there are a number of places where 4096-byte static buffers are used. I'd have fairly low confidence that you could find and fix all those buffers, especially in calling code for libraries. Interestingly, these same implementations can deal much more gracefully with decoded/expanded packets that couldn't possibly fit into 4096 bytes. That is, the structures used to deal with attributes are far more able to deal with larger attributes than the structures used to deal with packets. Note that even for RADIUS over TCP we did not relax the 4096 limit. I think this is a good call both because of the implementation concern and because of the proxy concern. 2) The existing solution works better in a case where an intermediate proxy does not support fragmentation. I *think* support with proxies that don't understand fragmentation is probably important. However I need to ponder that more. --Sam From a.cudbardb@networkradius.com Sun Feb 3 09:53:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4284321F8550 for ; Sun, 3 Feb 2013 09:53:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdZD2hezTOQv for ; Sun, 3 Feb 2013 09:53:39 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE9121F8444 for ; Sun, 3 Feb 2013 09:53:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 51D442240FA1; Sun, 3 Feb 2013 18:53:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVmuyc6a+AVE; Sun, 3 Feb 2013 18:53:34 +0100 (CET) Received: from [192.168.2.22] (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id EB5A6224078F; Sun, 3 Feb 2013 18:53:33 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_F80C752D-F07C-46D6-983D-0B69EC41E66F"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Arran Cudbard-Bell In-Reply-To: Date: Sun, 3 Feb 2013 12:53:02 -0500 Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1499) Cc: "radext@ietf.org" , Peter Deacon Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 17:53:40 -0000 --Apple-Mail=_F80C752D-F07C-46D6-983D-0B69EC41E66F Content-Type: multipart/alternative; boundary="Apple-Mail=_14893E8B-596D-40B6-8C01-BB86062ED4C6" --Apple-Mail=_14893E8B-596D-40B6-8C01-BB86062ED4C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > 1) It never requires there to be RADIUS packets running around longer > than 4096 bytes. In a lot of RADIUS implementations I've looked at, > there are a number of places where 4096-byte static buffers are > used. I'd have fairly low confidence that you could find and fix all > those buffers, especially in calling code for libraries. = Interestingly, > these same implementations can deal much more gracefully with > decoded/expanded packets that couldn't possibly fit into 4096 > bytes. That is, the structures used to deal with attributes are far = more > able to deal with larger attributes than the structures used to deal > with packets. Note that even for RADIUS over TCP we did not relax the > 4096 limit. I think this is a good call both because of the > implementation concern and because of the proxy concern. With Peter's approach reassembling the complete packet in an = intermmediary buffer may introduce issues with exhaustion, and makes it = more likely that a client that has misimplemented the fragmentation = extention could acidentally cause a DoS on the upstream proxy. Though I believe in theory it may have a slight advantage in the case = where there are multiple unreliable hops. Say we have a single proxy server, with unrealiable upstream and = downstream connections, and that there's a 50% chance the packet will be = dropped as it traverses those connections. NAS <-- 50% --> Proxy <-- 50% --> Server There's a 6.25% chance that the fragmentation round will complete, so = lets say it'd take 16 retransmissions to complete the round = successfully. Now for the poposed scheme, lets say it takes 2 attempts to complete = each link traversal successfully, meaning it should only take 8 = retransmissions to complete the round successfully. > 2) The existing solution works better in a case where an intermediate > proxy does not support fragmentation. >=20 > I *think* support with proxies that don't understand fragmentation is > probably important. > However I need to ponder that more. I think it probably is too. If nothing else it'd require additional = effort on the part of the administrator to upgrade all intermmediary = proxy servers. I've also seen a few instances recently where vendors have implemented = proxy servers on auxillary devices like firewalls and NAT boxes to = mirror sessions created on the NAS. Upgrading these embedded devices to = support fragmentation would not be feasible. On a non-technical note. I don't know about everyone else I prefer to = read proposals without the chromic assault, maybe it'd be best to stick = to something resembling the standard RFC format in future? -Arran --Apple-Mail=_14893E8B-596D-40B6-8C01-BB86062ED4C6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
1) It never requires there to be RADIUS = packets running around longer
than 4096 bytes. In a lot of RADIUS = implementations I've looked at,
there are a number of places where 4096-byte = static buffers are
used. I'd = have fairly low confidence that you could find and fix = all
those buffers, especially = in calling code for libraries. Interestingly,
these same implementations can deal much more = gracefully with
decoded/expanded= packets that couldn't possibly fit into 4096
bytes. That is, the structures used to deal = with attributes are far more
able to deal with larger attributes than the = structures used to deal
with = packets.  Note that even for RADIUS over TCP we did not relax = the
4096 limit. I think this = is a good call both because of the
implementation concern and because = of the proxy concern.

With Peter's approach reassembling = the complete packet in an intermmediary buffer may introduce issues with = exhaustion, and makes it more likely that a client that has = misimplemented the fragmentation extention could acidentally cause a DoS = on the upstream proxy.

Though= I believe in theory it may have a slight advantage in the case where = there are multiple unreliable hops.

Say we have a single proxy server, with = unrealiable upstream and downstream connections, and that there's a 50% = chance the packet will be dropped as it traverses those = connections.

NAS = <-- 50% --> Proxy <-- 50% --> Server

There's a 6.25% chance that the fragmentation = round will complete, so lets say it'd take 16 retransmissions to = complete the round successfully.

Now for the poposed scheme, lets say it takes = 2 attempts to complete each link traversal successfully, meaning it = should only take 8 retransmissions to complete the round = successfully.

2) The existing solution works better in a = case where an intermediate
proxy= does not support fragmentation.

I *think* support with proxies that don't = understand fragmentation is
probably important.
However I need to = ponder that more.

I think it probably is too. If nothing = else it'd require additional effort on the part of the administrator to = upgrade all intermmediary proxy servers.

I've also seen a few instances recently where = vendors have implemented proxy servers on auxillary devices like = firewalls and NAT boxes to mirror sessions created on the NAS. Upgrading = these embedded devices to support fragmentation would not be = feasible.

On a = non-technical note. I don't know about everyone else I prefer to read = proposals without the chromic assault, maybe it'd be best to stick to = something resembling the standard RFC format in future?

-Arran
= --Apple-Mail=_14893E8B-596D-40B6-8C01-BB86062ED4C6-- --Apple-Mail=_F80C752D-F07C-46D6-983D-0B69EC41E66F Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMLTCCBbww ggOkoAMCAQICCQDgDuc54nniwjANBgkqhkiG9w0BAQUFADCBrzELMAkGA1UEBhMCRlIxEzARBgNV BAgMClJob25lIEFscHMxETAPBgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElV UzEPMA0GA1UECwwGRnJhbmNlMSQwIgYDVQQDDBtlbXBsb3llZXMubmV0d29ya3JhZGl1cy5jb20x KDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wHhcNMTIxMTA0MTYyNTAy WhcNMjIxMTAyMTYyNTAyWjCBqTELMAkGA1UEBhMCRlIxEzARBgNVBAgMClJob25lIEFscHMxETAP BgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElVUzEPMA0GA1UECwwGRnJhbmNl MRswGQYDVQQDDBJBcnJhbiBDdWRiYXJkLUJlbGwxKzApBgkqhkiG9w0BCQEWHGEuY3VkYmFyZGJA bmV0d29ya3JhZGl1cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+oyztJu99 hxoGKXeIgLu9s2yZWTefCI6SRePRn8JogcMP+URSSxrmaiTOMFVq6YebDgNwhqcxcX88LaA9gq+y eXTN/xke8XUogibLccuT1gzrHsVTxdfkNSBDZ3Ar0ePzZlfl+1v/TMis/AirhfmZRJ6YiXfwtfHN 3+fR4w/uQZ1a7sM0XeLHZloJ2ltw3LlER+fXlpE3d424jM2ulhQcdgpvARHZnysyj6rkFQaDxOyT Z4Sr4pBQ5QT5NZFlFubXFPDvUVjGvTjyaLn+27PEEjylPX0LAKwNW5/El1DYvNmauBhqm6ZqXB0f 8TL9WvJvwxuZVKxh43FAk/wlh16PAgMBAAGjgd4wgdswCQYDVR0TBAIwADARBglghkgBhvhCAQEE BAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud DgQWBBTJo8sR/WO+nHHOaOZdURNAcGbcAzAfBgNVHSMEGDAWgBRie89pUWaGz/uhMgr2Pf/UxBAv sDAnBgNVHREEIDAegRxhLmN1ZGJhcmRiQG5ldHdvcmtyYWRpdXMuY29tMCQGA1UdEgQdMBuBGXN1 cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wDQYJKoZIhvcNAQEFBQADggIBAA8XtsB8MMMYN5p2htV7 dRbIxOuPL4gtemmrsRmYtRUP7pdLP4NahBrnVWEve60q+zdgZO6IcqoYvoeG1/Yr82DABoHFai7H V3UU3nG4SPJk8+VXeeOGbpnCcylhm45MYZvdikbogsbItMtnDRZbV/7mJeNgADGJYaQGC7IzGoQ2 aawHiXVNRFI5JUcN/2Pj8xPApGNDbssA3kncW5+fqlmZXZE8lIE0GXH/qNAvS1rxT1WEAZ6dzI0y UIWIVQugeAQvEGTey4VW0XFPtX/Si6OQNFyXVLgQa17bneH+M/XVNYVK887bDMKjLLmHfSZnH/ra RCl2OCjtHkj850T1dJ8DUE83jyz4qlU1ARZjivJcXv/btIN4DCDyE/2vyar6OCd/ynwvIQyJAprY WJ+7dnOf/owQ9m9OUZnN+iSE/dsEdD3N+VfckD6FPefibUxZrwGdKSmpAkHZplYWCpOHhiXMI+8c dYhJsX43dBlHievq4eAU5qa6LiyazMdg3G4tlJYRcLc91CeQ9dB2M4IHJsnhOoaxVtkRGyVeXugd 7f6N5OXpbUIM7yUzmFd9owZZ6LrRkwKLBQOWoI1B1FlDKc5aaKDHER6wiDPRDUlsQu+5LEUaOdIK gTJncoXWCyVgIKHGmNjodOQp64lsbBxZH/pshb9CGlOGyfkbr2NUfNReMIIGaTCCBFGgAwIBAgIJ ANAO5znieeK+MA0GCSqGSIb3DQEBBQUAMIGSMQswCQYDVQQGEwJGUjETMBEGA1UECAwKUmhvbmUg QWxwczEXMBUGA1UECgwOTmV0d29yayBSQURJVVMxDzANBgNVBAsMBkZyYW5jZTEaMBgGA1UEAwwR bmV0d29ya3JhZGl1cy5jb20xKDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5j b20wHhcNMTIxMTA0MTUzMDM1WhcNMjIxMTAyMTUzMDM1WjCBrzELMAkGA1UEBhMCRlIxEzARBgNV BAgMClJob25lIEFscHMxETAPBgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElV UzEPMA0GA1UECwwGRnJhbmNlMSQwIgYDVQQDDBtlbXBsb3llZXMubmV0d29ya3JhZGl1cy5jb20x KDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQC3aWd6I+mwM+eD8op/lrrZTbOegzFmdk0SsEN2lrok2s7Wzud+bRx7 SlzMx//OoAxj9w0SgwNaWCaixIjnhmyvJ9Fxu6fk3Ql/U6ThhGO7ca+UXDOtFsjg4AMsdN8FdNZz 183rDmMm5oAERyKEevc0iuutiyqfrmeS8IQXOiuqztZoypIoYtlICxtdcF2hVT0z+urpwDiKJ8qH NBLEjxD3VpFVA3DOyZGOtxpwsP9W6GUIhGamAgC+jqgFOqBitzsaKT521R6sdlPYuy6/q/L1M0jX g4xgBrBZCWYOTsFf1F8kXT2dqm1SGA3CARm4Mjn3CtV26QNhU2hbjw/hL8tPIrpOehyxEMJ8Bzbp HzMTjmW5N2OOBRK61DEbH1Y4gKgPtaAjMqKechFdiL/JCG/tbxFjCYZYLRPsz/MiT/rOSoWEOLkM ice+76KpVHqDUzjJxvDO4GnmnRIarqistG7ai51/adyJ1BRcmkAEKrmk5ToFzWTEkJtg+BZblToX q2upHg6AEeHbIXpv7s+u5V9rIlihXMbq4hhrW4DDrAEX/ZIFczaFPA4gIFj5u7QXD6DD0iSiPsdu FcTOsOFf55j93yg7PAQ9GbXSEdIN9lKwuggW+PSxNhcgr7ieYH6C5E8kLse5jgTt9u4NDg/eiLQK agkf+lVdHlzi5tAW9tW1fwIDAQABo4GiMIGfMB0GA1UdDgQWBBRie89pUWaGz/uhMgr2Pf/UxBAv sDAfBgNVHSMEGDAWgBSX4gMQTLLNEQEqik7f9MpkimjmDDAMBgNVHRMEBTADAQH/MAsGA1UdDwQE AwIBBjARBglghkgBhvhCAQEEBAMCAQYwJAYDVR0RBB0wG4EZc3VwcG9ydEBuZXR3b3JrcmFkaXVz LmNvbTAJBgNVHRIEAjAAMA0GCSqGSIb3DQEBBQUAA4ICAQCVSM0a5CgoDsnX2zEMy5Lb9FW9//tr wqCBP1PfgDyJgDoIHzpRGgpNQvir2tjLP26KanNMYAibFl/mKrv3KAfaTaQsu8aOj4aWJOM8FwsK wruN90uLDFYV5hZMHy7QDc5pueIsZdE5/To+ekK7nHJr0WrM3o1fkV3p3EqA17aG7VIpeMgfJvwA +foO+IqGBQIsw4/HYfL5elva+n8Pp2rvHYddIqgKnmEeIsDRmdp0RMYBuPrixvJ7503kyxcIxZ9R 5umJyrLIMUBbGiPyi5IuL3nIjkAnxFyCzLO2HSeDqRhIieVY8a7yiPOhb0XV+KEBfyvJz0fj3qgn BguBEhSQA/F4X7EaBsqrWdxqk1hl5+k1Nu+bO35yWPeATXfW+dRJVh8xrb/lDnlhw6lyjccih3Oo 2Ut6+R/nP/7GZP+WO1Dtq/XsyWfhXnvZVdh6+3QWolXYmY2rBJDd2jAJo8brgwF1IIQohMCoqOj8 8uVQbrLmG/lozjlnO+JuofmDMKjhha2kDUT946qzfajDTR9o1lASP4h9eyKk/7q10V+lz+QbsH4s 6KpgBnrNxRRrgd0/fE3LekBDTouKSvsJT+X2/p9oX5OyoQKNtXSm85T83Ko9PCiDRTIU1V2Bc6er RpOrU4n6Z8y87GJ+giQcmpN5CR2F2YNf3ZW9Wff+UnvXAzGCA+owggPmAgEBMIG9MIGvMQswCQYD VQQGEwJGUjETMBEGA1UECAwKUmhvbmUgQWxwczERMA8GA1UEBwwIR3Jlbm9ibGUxFzAVBgNVBAoM Dk5ldHdvcmsgUkFESVVTMQ8wDQYDVQQLDAZGcmFuY2UxJDAiBgNVBAMMG2VtcGxveWVlcy5uZXR3 b3JrcmFkaXVzLmNvbTEoMCYGCSqGSIb3DQEJARYZc3VwcG9ydEBuZXR3b3JrcmFkaXVzLmNvbQIJ AOAO5znieeLCMAkGBSsOAwIaBQCgggIBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMDIwMzE3NTMwMlowIwYJKoZIhvcNAQkEMRYEFJKeMbw1eiUOJQs35q4ws5bQ FVyXMIHOBgkrBgEEAYI3EAQxgcAwgb0wga8xCzAJBgNVBAYTAkZSMRMwEQYDVQQIDApSaG9uZSBB bHBzMREwDwYDVQQHDAhHcmVub2JsZTEXMBUGA1UECgwOTmV0d29yayBSQURJVVMxDzANBgNVBAsM BkZyYW5jZTEkMCIGA1UEAwwbZW1wbG95ZWVzLm5ldHdvcmtyYWRpdXMuY29tMSgwJgYJKoZIhvcN AQkBFhlzdXBwb3J0QG5ldHdvcmtyYWRpdXMuY29tAgkA4A7nOeJ54sIwgdAGCyqGSIb3DQEJEAIL MYHAoIG9MIGvMQswCQYDVQQGEwJGUjETMBEGA1UECAwKUmhvbmUgQWxwczERMA8GA1UEBwwIR3Jl bm9ibGUxFzAVBgNVBAoMDk5ldHdvcmsgUkFESVVTMQ8wDQYDVQQLDAZGcmFuY2UxJDAiBgNVBAMM G2VtcGxveWVlcy5uZXR3b3JrcmFkaXVzLmNvbTEoMCYGCSqGSIb3DQEJARYZc3VwcG9ydEBuZXR3 b3JrcmFkaXVzLmNvbQIJAOAO5znieeLCMA0GCSqGSIb3DQEBAQUABIIBAJi98TJEzAVZ7Zlun/ba et3u/wzmaxI5wtDUQUbA913GKqLBBqGLEfH7ztED7ZZKfFZJW3RtA7hEmMSa44Y20awTnk11oANP Jux2RwelBeI/SDXUGU9seCj2M3kvqnMViMjg6aG9Yq84cowOoqNTj94vI0nW70I/EjmUKAS3Cv0I ARGWKsiErRDLw6dVFtKFJPDVcRM8nA9W2J9JpdTgXeP0nrCUSF0P/8NLMY50mu9isol8t63Km8Ij fDB/zN6D/PFWn+lN5bEuQA/fdGRXImeGDf16btnmIvOguGf6k+XZRNPeZRnjHU1NBWYOj4qvP8sE 32ADZYLUy+nzTC7DZYMAAAAAAAA= --Apple-Mail=_F80C752D-F07C-46D6-983D-0B69EC41E66F-- From a.cudbardb@freeradius.org Sun Feb 3 09:49:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C6621F854F for ; Sun, 3 Feb 2013 09:49:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0NS8JmYmy97 for ; Sun, 3 Feb 2013 09:49:16 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A1C2B21F853C for ; Sun, 3 Feb 2013 09:49:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id ABC462240FA1; Sun, 3 Feb 2013 18:49:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRzKjOO8ScCb; Sun, 3 Feb 2013 18:49:12 +0100 (CET) Received: from [192.168.2.22] (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 4943022404AC; Sun, 3 Feb 2013 18:49:12 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Arran Cudbard-Bell In-Reply-To: Date: Sun, 3 Feb 2013 12:48:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sam Hartman X-Mailer: Apple Mail (2.1499) X-Mailman-Approved-At: Sun, 03 Feb 2013 09:54:32 -0800 Cc: "radext@ietf.org" , Peter Deacon Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 17:49:17 -0000 > 1) It never requires there to be RADIUS packets running around longer > than 4096 bytes. In a lot of RADIUS implementations I've looked at, > there are a number of places where 4096-byte static buffers are > used. I'd have fairly low confidence that you could find and fix all > those buffers, especially in calling code for libraries. = Interestingly, > these same implementations can deal much more gracefully with > decoded/expanded packets that couldn't possibly fit into 4096 > bytes. That is, the structures used to deal with attributes are far = more > able to deal with larger attributes than the structures used to deal > with packets. Note that even for RADIUS over TCP we did not relax the > 4096 limit. I think this is a good call both because of the > implementation concern and because of the proxy concern. With Peter's approach reassembling the complete packet in an = intermmediary buffer may introduce issues with exhaustion, and makes it = more likely that a client that has misimplemented the fragmentation = extention could acidentally cause a DoS on the upstream proxy. Though I believe in theory it may have a slight advantage in the case = where there are multiple unreliable hops. Say we have a single proxy server, with unrealiable upstream and = downstream connections, and that there's a 50% chance the packet will be = dropped as it traverses those connections. NAS <-- 50% --> Proxy <-- 50% --> Server There's a 6.25% chance that the fragmentation round will complete, so = lets say it'd take 16 retransmissions to complete the round = successfully. Now for the poposed scheme, lets say it takes 2 attempts to complete = each link traversal successfully, meaning it should only take 8 = retransmissions to complete the round successfully. > 2) The existing solution works better in a case where an intermediate > proxy does not support fragmentation. >=20 > I *think* support with proxies that don't understand fragmentation is > probably important. > However I need to ponder that more. I think it probably is too. If nothing else it'd require additional = effort on the part of the administrator to upgrade all intermmediary = proxy servers. I've also seen a few instances recently where vendors have implemented = proxy servers on auxillary devices like firewalls and NAT boxes to = mirror sessions created on the NAS. Upgrading these embedded devices to = support fragmentation would not be feasible. On a non-technical note. I don't know about everyone else I prefer to = read proposals without the chromic assault, maybe it'd be best to stick = to something resembling the standard RFC format in future? -Arran= From peterd@iea-software.com Sun Feb 3 09:59:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066BD21F8605 for ; Sun, 3 Feb 2013 09:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZuytaAqUilV for ; Sun, 3 Feb 2013 09:59:10 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 34FD221F857B for ; Sun, 3 Feb 2013 09:59:10 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 3 Feb 2013 09:57:11 -0800 Date: Sun, 3 Feb 2013 09:57:23 -0800 (Pacific Standard Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 17:59:11 -0000 On Sun, 3 Feb 2013, Sam Hartman wrote: >>>>>> "Peter" == Peter Deacon writes: > When I read your presentation, I was quite frustrated, because there's > been a concept of RADIUS fragmentation going on for several months and > your presentation is not responsive to that existing discussion. I hope > that when people introduce alternatives into an ongoing discussion it is > because they believe their alternative provides significant additional > value. I hope that the introduction of the alternative would be focused > around that additional value rather than presenting an alternative > without relating it to the context of the ongoing discussion. I believe > that by relating it to the ongoing discussion and comparing approaches, > the conversation is more respectful of the different alternatives and > their value. > Would you explain why you find this approach better than the approach > already under discussion? Hi Sam, My understanding fragmentation approach SAML uses is intended for Interop with existing systems (proxies) already in the field while my approach does not. While both accomplish same goals where they overlap the constraints are different. My primary issue with SAML draft which prompted this is lack of command code coverage. It does not work with accounting even while there is talk about pushing large quantities of data thru accounting messages. If I am to push a large authorization attribute there is no way to alter my authorization later via dynamic authorization. I have no interest in seeing these issues constantly readdressed as someone later finds a need to support huge messages in Accounting or CoA. > I think the existing approach has two significant advantages over the > new approach: > 1) It never requires there to be RADIUS packets running around longer > than 4096 bytes. In a lot of RADIUS implementations I've looked at, > there are a number of places where 4096-byte static buffers are used. > I'd have fairly low confidence that you could find and fix all those > buffers, especially in calling code for libraries. Interestingly, these > same implementations can deal much more gracefully with decoded/expanded > packets that couldn't possibly fit into 4096 bytes. That is, the > structures used to deal with attributes are far more able to deal with > larger attributes than the structures used to deal with packets. Note > that even for RADIUS over TCP we did not relax the 4096 limit. I think > this is a good call both because of the implementation concern and > because of the proxy concern. Illustrations were intended to help convey a logical concept. Any approach accomplishing the same result gets the job done. There is no reason individual fragments ever have to be combined into a single block of memory if the implementor finds this to be easier given their constraints. One may elect to calculate lengths, MD5s, HMACs..etc over fragments just as they could a fully assembled product. With regards to the artificial limit in TCP case fragments could act as a bridge to enable large packet flows between TCP and UDP systems supporting fragments. > 2) The existing solution works better in a case where an intermediate > proxy does not support fragmentation. > I *think* support with proxies that don't understand fragmentation is > probably important. However I need to ponder that more. I agree this is a key difference. regards, Peter From hartmans@painless-security.com Sun Feb 3 10:15:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67FE121F843E for ; Sun, 3 Feb 2013 10:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytHH7aseDnqh for ; Sun, 3 Feb 2013 10:15:00 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CD04F21F842E for ; Sun, 3 Feb 2013 10:15:00 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id CE49120393; Sun, 3 Feb 2013 13:10:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3335743FD; Sun, 3 Feb 2013 13:14:56 -0500 (EST) From: Sam Hartman To: Peter Deacon References: Date: Sun, 03 Feb 2013 13:14:56 -0500 In-Reply-To: (Peter Deacon's message of "Sun, 3 Feb 2013 09:57:23 -0800 (Pacific Standard Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 18:15:01 -0000 >>>>> "Peter" == Peter Deacon writes: >> 1) It never requires there to be RADIUS packets running around >> longer than 4096 bytes. In a lot of RADIUS implementations I've >> looked at, there are a number of places where 4096-byte static >> buffers are used. I'd have fairly low confidence that you could >> find and fix all those buffers, especially in calling code for >> libraries. Interestingly, these same implementations can deal >> much more gracefully with decoded/expanded packets that couldn't >> possibly fit into 4096 bytes. That is, the structures used to >> deal with attributes are far more able to deal with larger >> attributes than the structures used to deal with packets. Note >> that even for RADIUS over TCP we did not relax the 4096 limit. I >> think this is a good call both because of the implementation >> concern and because of the proxy concern. Peter> Illustrations were intended to help convey a logical concept. Peter> Any approach accomplishing the same result gets the job done. I apparently wasn't clear. The advantage I see in the existing draft is that each packet is composed entirely of well-formed RADIUS attributes and each packet has its own ID and RADIUS header. You can use almost all your existing packet decoding logic and all your existing attribute decoding logic. You could get some of these benefits if you introduce constraints like each fragment must end on an attribute boundary. However I still think you're approach is going to do much more damage to packet processing routines and especially to the APIs to these routines. From peterd@iea-software.com Sun Feb 3 10:30:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7B821F86FA for ; Sun, 3 Feb 2013 10:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Me7Uxop2+N1M for ; Sun, 3 Feb 2013 10:30:42 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5880221F8581 for ; Sun, 3 Feb 2013 10:30:42 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 3 Feb 2013 10:28:40 -0800 Date: Sun, 3 Feb 2013 10:28:56 -0800 (Pacific Standard Time) From: Peter Deacon To: Arran Cudbard-Bell In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Sam Hartman , "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 18:30:43 -0000 On Sun, 3 Feb 2013, Arran Cudbard-Bell wrote: > With Peter's approach reassembling the complete packet in an > intermmediary buffer may introduce issues with exhaustion, and makes it > more likely that a client that has misimplemented the fragmentation > extention could acidentally cause a DoS on the upstream proxy. Hi Arran, You are correct proxies would need to store the entire request before passing it on. Some mitigating thoughts.. Pick a lower bound on fragment size everyone must support making anything above this an administrative option. With Fragment-Reject server can signal request too big to client. While request must be stored it my not necessarily have to be a contiguous block. regards, Peter From peterd@iea-software.com Sun Feb 3 11:15:48 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860DB21F882E for ; Sun, 3 Feb 2013 11:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFDUePNiG3hm for ; Sun, 3 Feb 2013 11:15:48 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id D3AB121F897A for ; Sun, 3 Feb 2013 11:15:47 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 3 Feb 2013 11:13:38 -0800 Date: Sun, 3 Feb 2013 11:14:01 -0800 (Pacific Standard Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 19:15:48 -0000 On Sun, 3 Feb 2013, Sam Hartman wrote: >>>>>> "Peter" == Peter Deacon writes: > >> 1) It never requires there to be RADIUS packets running around > >> longer than 4096 bytes. In a lot of RADIUS implementations I've > >> looked at, there are a number of places where 4096-byte static > >> buffers are used. I'd have fairly low confidence that you could > >> find and fix all those buffers, especially in calling code for > >> libraries. Interestingly, these same implementations can deal > >> much more gracefully with decoded/expanded packets that couldn't > >> possibly fit into 4096 bytes. That is, the structures used to > >> deal with attributes are far more able to deal with larger > >> attributes than the structures used to deal with packets. Note > >> that even for RADIUS over TCP we did not relax the 4096 limit. I > >> think this is a good call both because of the implementation > >> concern and because of the proxy concern. > Peter> Illustrations were intended to help convey a logical concept. > Peter> Any approach accomplishing the same result gets the job done. > I apparently wasn't clear. The advantage I see in the existing draft is > that each packet is composed entirely of well-formed RADIUS attributes > and each packet has its own ID and RADIUS header. Hi Sam, I apologize for any confusion. It is the case here as well. "outer" (Fragment-Req/Resp) messages are essentially the same as Accounting-Request / Accounting-Response. The only difference they have a different command code. ALL constraints which apply to an Accounting style of request (Also Disconnect/CoA) apply to Fragment-Request. Fragment-Requests are well formed containing complete AVPs only. > You can use almost all your existing packet decoding logic and all your > existing attribute decoding logic. > You could get some of these benefits if you introduce constraints like > each fragment must end on an attribute boundary. Each fragment ends on an attribute boundary. On pg16 responsibilities of the "outer" (What is sent on the wire) vs "inner" (constructed packet) briefly touch on this issue. "outer" request has an id, header, must be well formed with its authenticator validated. "inner" request has header, must be well formed with authenticator fully validated same as if it were on wire. Inner request does not have an ID field as outer request is performing this function. It is set 0 in inner header for compatibility. regards, Peter From aland@deployingradius.com Sun Feb 3 12:30:34 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221BE21F87EA for ; Sun, 3 Feb 2013 12:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIZt3-fNO3V0 for ; Sun, 3 Feb 2013 12:30:33 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1E69521F8581 for ; Sun, 3 Feb 2013 12:30:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1A0212240FA1; Sun, 3 Feb 2013 21:29:30 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V7w8Vu72p13i; Sun, 3 Feb 2013 21:29:29 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 2CAFA2240703; Sun, 3 Feb 2013 21:29:29 +0100 (CET) Message-ID: <510EC8A8.7050301@deployingradius.com> Date: Sun, 03 Feb 2013 15:29:28 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 20:30:34 -0000 Peter Deacon wrote: > It does not work with accounting even while there is talk about pushing > large quantities of data thru accounting messages. Such as? > If I am to push a large authorization attribute there is no way to alter > my authorization later via dynamic authorization. The CoA packet can contain Service-Type = Additional-Authorization. The fragmentation method can then be used to send large amounts of authorization data. Alan DeKok. From peterd@iea-software.com Sun Feb 3 13:49:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E5D21F889C for ; Sun, 3 Feb 2013 13:49:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZHHP0vJUI-D for ; Sun, 3 Feb 2013 13:49:14 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1D51021F8896 for ; Sun, 3 Feb 2013 13:49:13 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 3 Feb 2013 13:46:39 -0800 Date: Sun, 3 Feb 2013 13:47:25 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <510EC8A8.7050301@deployingradius.com> Message-ID: References: <510EC8A8.7050301@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 21:49:14 -0000 On Sun, 3 Feb 2013, Alan DeKok wrote: > Peter Deacon wrote: >> It does not work with accounting even while there is talk about pushing >> large quantities of data thru accounting messages. > Such as? Dreams of RADIUS transport of detailed statistical information per session from prior threads involving counters and IPFIX. >> If I am to push a large authorization attribute there is no way to alter >> my authorization later via dynamic authorization. > The CoA packet can contain Service-Type = Additional-Authorization. > The fragmentation method can then be used to send large amounts of > authorization data. Or solve the underlying problem and avoid having to invent more and more workarounds. regards, Peter From aland@deployingradius.com Sun Feb 3 16:04:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61AA021F8871 for ; Sun, 3 Feb 2013 16:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5vGjxVasIqcO for ; Sun, 3 Feb 2013 16:04:49 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B98F121F886A for ; Sun, 3 Feb 2013 16:04:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 81E152240FA1; Mon, 4 Feb 2013 01:04:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iR5OqL4AZca9; Mon, 4 Feb 2013 01:04:41 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 953622240703; Mon, 4 Feb 2013 01:04:41 +0100 (CET) Message-ID: <510EFB18.1040407@deployingradius.com> Date: Sun, 03 Feb 2013 19:04:40 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510EC8A8.7050301@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 00:04:50 -0000 Peter Deacon wrote: > Dreams of RADIUS transport of detailed statistical information per > session from prior threads involving counters and IPFIX. Accounting can use the Acct-Multi-Session-Id to tie accounting for individual streams to one session. >> The CoA packet can contain Service-Type = Additional-Authorization. >> The fragmentation method can then be used to send large amounts of >> authorization data. > > Or solve the underlying problem and avoid having to invent more and more > workarounds. Having one method to get authorization to the NAS is preferable to having two methods. Alan DeKok. From peterd@iea-software.com Sun Feb 3 18:35:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0577621F891C for ; Sun, 3 Feb 2013 18:35:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8SYg34euuIZ for ; Sun, 3 Feb 2013 18:35:21 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 7D69521F890F for ; Sun, 3 Feb 2013 18:35:21 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 3 Feb 2013 18:32:05 -0800 Date: Sun, 3 Feb 2013 18:33:31 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <510EFB18.1040407@deployingradius.com> Message-ID: References: <510EC8A8.7050301@deployingradius.com> <510EFB18.1040407@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 02:35:22 -0000 On Sun, 3 Feb 2013, Alan DeKok wrote: > Peter Deacon wrote: >> Dreams of RADIUS transport of detailed statistical information per >> session from prior threads involving counters and IPFIX. > Accounting can use the Acct-Multi-Session-Id to tie accounting for > individual streams to one session. With a few thousand flows to export for one session what happens? Do I send a few thousand accounting records? Do I invent only as many sessions as necessary to make everything fit into a few accounting records? How many "workarounds" must be tolerated? >>> The CoA packet can contain Service-Type = Additional-Authorization. >>> The fragmentation method can then be used to send large amounts of >>> authorization data. >> Or solve the underlying problem and avoid having to invent more and more >> workarounds. > Having one method to get authorization to the NAS is preferable to > having two methods. If I want to change an authorization parameter I send a message with the parameter I want changed and thats that. If the parameter cannot be changed I get an Error-Cause back explaining why. With this hypothetical reauthorization scheme I send a message saying please reauthorize yourself and hope for the best. Two RADIUS transactions instead of one and no feedback. regards, Peter From a.cudbardb@networkradius.com Sun Feb 3 19:14:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA9AA21F89A4 for ; Sun, 3 Feb 2013 19:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfrAr5Zo2ydL for ; Sun, 3 Feb 2013 19:14:44 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1F8C21F899F for ; Sun, 3 Feb 2013 19:14:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3E2AA2240FA1; Mon, 4 Feb 2013 04:14:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rQqUHr40NHI; Mon, 4 Feb 2013 04:14:40 +0100 (CET) Received: from [192.168.2.22] (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 356E4224078F; Mon, 4 Feb 2013 04:14:40 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_A474D6C9-17B0-4AD8-A913-D05F09488B74"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Arran Cudbard-Bell In-Reply-To: Date: Sun, 3 Feb 2013 22:14:08 -0500 Message-Id: <2769A0F2-700C-479E-ADE4-5B4D53FD30D4@networkradius.com> References: <510EC8A8.7050301@deployingradius.com> <510EFB18.1040407@deployingradius.com> To: Peter Deacon X-Mailer: Apple Mail (2.1499) Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 03:14:45 -0000 --Apple-Mail=_A474D6C9-17B0-4AD8-A913-D05F09488B74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Feb 2013, at 21:33, Peter Deacon wrote: > On Sun, 3 Feb 2013, Alan DeKok wrote: >=20 >> Peter Deacon wrote: >>> Dreams of RADIUS transport of detailed statistical information per >>> session from prior threads involving counters and IPFIX. >=20 >> Accounting can use the Acct-Multi-Session-Id to tie accounting for >> individual streams to one session. >=20 > With a few thousand flows to export for one session what happens? >=20 > Do I send a few thousand accounting records? Do I invent only as many = sessions as necessary to make everything fit into a few accounting = records? Yes, I've seen at least one vendor implement their NAT accounting like = this. Of course there's huge overhead with this approach, but it's = significantly reduced if you pack multiple RADIUS packets into a single = UDP packet. I believe Alan has some ideas on this. It also re-uses the existing accounting model to signal when connections = are established and terminate. >=20 >>>> The CoA packet can contain Service-Type =3D = Additional-Authorization. >>>> The fragmentation method can then be used to send large amounts of >>>> authorization data. >=20 >>> Or solve the underlying problem and avoid having to invent more and = more >>> workarounds. >=20 >> Having one method to get authorization to the NAS is preferable to >> having two methods. >=20 > If I want to change an authorization parameter I send a message with = the parameter I want changed and thats that. If the parameter cannot be = changed I get an Error-Cause back explaining why. Yes. > With this hypothetical reauthorization scheme I send a message saying = please reauthorize yourself and hope for the best. Two RADIUS = transactions instead of one and no feedback. This is no different than what happens when the server returns an = Access-Accept. Yes it may be useful to allow the NAS to signal the = server saying that an error occurred, but that is outside of the scope = of fragmentation. -Arran= --Apple-Mail=_A474D6C9-17B0-4AD8-A913-D05F09488B74 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMLTCCBbww ggOkoAMCAQICCQDgDuc54nniwjANBgkqhkiG9w0BAQUFADCBrzELMAkGA1UEBhMCRlIxEzARBgNV BAgMClJob25lIEFscHMxETAPBgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElV UzEPMA0GA1UECwwGRnJhbmNlMSQwIgYDVQQDDBtlbXBsb3llZXMubmV0d29ya3JhZGl1cy5jb20x KDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wHhcNMTIxMTA0MTYyNTAy WhcNMjIxMTAyMTYyNTAyWjCBqTELMAkGA1UEBhMCRlIxEzARBgNVBAgMClJob25lIEFscHMxETAP BgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElVUzEPMA0GA1UECwwGRnJhbmNl MRswGQYDVQQDDBJBcnJhbiBDdWRiYXJkLUJlbGwxKzApBgkqhkiG9w0BCQEWHGEuY3VkYmFyZGJA bmV0d29ya3JhZGl1cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+oyztJu99 hxoGKXeIgLu9s2yZWTefCI6SRePRn8JogcMP+URSSxrmaiTOMFVq6YebDgNwhqcxcX88LaA9gq+y eXTN/xke8XUogibLccuT1gzrHsVTxdfkNSBDZ3Ar0ePzZlfl+1v/TMis/AirhfmZRJ6YiXfwtfHN 3+fR4w/uQZ1a7sM0XeLHZloJ2ltw3LlER+fXlpE3d424jM2ulhQcdgpvARHZnysyj6rkFQaDxOyT Z4Sr4pBQ5QT5NZFlFubXFPDvUVjGvTjyaLn+27PEEjylPX0LAKwNW5/El1DYvNmauBhqm6ZqXB0f 8TL9WvJvwxuZVKxh43FAk/wlh16PAgMBAAGjgd4wgdswCQYDVR0TBAIwADARBglghkgBhvhCAQEE BAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud DgQWBBTJo8sR/WO+nHHOaOZdURNAcGbcAzAfBgNVHSMEGDAWgBRie89pUWaGz/uhMgr2Pf/UxBAv sDAnBgNVHREEIDAegRxhLmN1ZGJhcmRiQG5ldHdvcmtyYWRpdXMuY29tMCQGA1UdEgQdMBuBGXN1 cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wDQYJKoZIhvcNAQEFBQADggIBAA8XtsB8MMMYN5p2htV7 dRbIxOuPL4gtemmrsRmYtRUP7pdLP4NahBrnVWEve60q+zdgZO6IcqoYvoeG1/Yr82DABoHFai7H V3UU3nG4SPJk8+VXeeOGbpnCcylhm45MYZvdikbogsbItMtnDRZbV/7mJeNgADGJYaQGC7IzGoQ2 aawHiXVNRFI5JUcN/2Pj8xPApGNDbssA3kncW5+fqlmZXZE8lIE0GXH/qNAvS1rxT1WEAZ6dzI0y UIWIVQugeAQvEGTey4VW0XFPtX/Si6OQNFyXVLgQa17bneH+M/XVNYVK887bDMKjLLmHfSZnH/ra RCl2OCjtHkj850T1dJ8DUE83jyz4qlU1ARZjivJcXv/btIN4DCDyE/2vyar6OCd/ynwvIQyJAprY WJ+7dnOf/owQ9m9OUZnN+iSE/dsEdD3N+VfckD6FPefibUxZrwGdKSmpAkHZplYWCpOHhiXMI+8c dYhJsX43dBlHievq4eAU5qa6LiyazMdg3G4tlJYRcLc91CeQ9dB2M4IHJsnhOoaxVtkRGyVeXugd 7f6N5OXpbUIM7yUzmFd9owZZ6LrRkwKLBQOWoI1B1FlDKc5aaKDHER6wiDPRDUlsQu+5LEUaOdIK gTJncoXWCyVgIKHGmNjodOQp64lsbBxZH/pshb9CGlOGyfkbr2NUfNReMIIGaTCCBFGgAwIBAgIJ ANAO5znieeK+MA0GCSqGSIb3DQEBBQUAMIGSMQswCQYDVQQGEwJGUjETMBEGA1UECAwKUmhvbmUg QWxwczEXMBUGA1UECgwOTmV0d29yayBSQURJVVMxDzANBgNVBAsMBkZyYW5jZTEaMBgGA1UEAwwR bmV0d29ya3JhZGl1cy5jb20xKDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5j b20wHhcNMTIxMTA0MTUzMDM1WhcNMjIxMTAyMTUzMDM1WjCBrzELMAkGA1UEBhMCRlIxEzARBgNV BAgMClJob25lIEFscHMxETAPBgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElV UzEPMA0GA1UECwwGRnJhbmNlMSQwIgYDVQQDDBtlbXBsb3llZXMubmV0d29ya3JhZGl1cy5jb20x KDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQC3aWd6I+mwM+eD8op/lrrZTbOegzFmdk0SsEN2lrok2s7Wzud+bRx7 SlzMx//OoAxj9w0SgwNaWCaixIjnhmyvJ9Fxu6fk3Ql/U6ThhGO7ca+UXDOtFsjg4AMsdN8FdNZz 183rDmMm5oAERyKEevc0iuutiyqfrmeS8IQXOiuqztZoypIoYtlICxtdcF2hVT0z+urpwDiKJ8qH NBLEjxD3VpFVA3DOyZGOtxpwsP9W6GUIhGamAgC+jqgFOqBitzsaKT521R6sdlPYuy6/q/L1M0jX g4xgBrBZCWYOTsFf1F8kXT2dqm1SGA3CARm4Mjn3CtV26QNhU2hbjw/hL8tPIrpOehyxEMJ8Bzbp HzMTjmW5N2OOBRK61DEbH1Y4gKgPtaAjMqKechFdiL/JCG/tbxFjCYZYLRPsz/MiT/rOSoWEOLkM ice+76KpVHqDUzjJxvDO4GnmnRIarqistG7ai51/adyJ1BRcmkAEKrmk5ToFzWTEkJtg+BZblToX q2upHg6AEeHbIXpv7s+u5V9rIlihXMbq4hhrW4DDrAEX/ZIFczaFPA4gIFj5u7QXD6DD0iSiPsdu FcTOsOFf55j93yg7PAQ9GbXSEdIN9lKwuggW+PSxNhcgr7ieYH6C5E8kLse5jgTt9u4NDg/eiLQK agkf+lVdHlzi5tAW9tW1fwIDAQABo4GiMIGfMB0GA1UdDgQWBBRie89pUWaGz/uhMgr2Pf/UxBAv sDAfBgNVHSMEGDAWgBSX4gMQTLLNEQEqik7f9MpkimjmDDAMBgNVHRMEBTADAQH/MAsGA1UdDwQE AwIBBjARBglghkgBhvhCAQEEBAMCAQYwJAYDVR0RBB0wG4EZc3VwcG9ydEBuZXR3b3JrcmFkaXVz LmNvbTAJBgNVHRIEAjAAMA0GCSqGSIb3DQEBBQUAA4ICAQCVSM0a5CgoDsnX2zEMy5Lb9FW9//tr wqCBP1PfgDyJgDoIHzpRGgpNQvir2tjLP26KanNMYAibFl/mKrv3KAfaTaQsu8aOj4aWJOM8FwsK wruN90uLDFYV5hZMHy7QDc5pueIsZdE5/To+ekK7nHJr0WrM3o1fkV3p3EqA17aG7VIpeMgfJvwA +foO+IqGBQIsw4/HYfL5elva+n8Pp2rvHYddIqgKnmEeIsDRmdp0RMYBuPrixvJ7503kyxcIxZ9R 5umJyrLIMUBbGiPyi5IuL3nIjkAnxFyCzLO2HSeDqRhIieVY8a7yiPOhb0XV+KEBfyvJz0fj3qgn BguBEhSQA/F4X7EaBsqrWdxqk1hl5+k1Nu+bO35yWPeATXfW+dRJVh8xrb/lDnlhw6lyjccih3Oo 2Ut6+R/nP/7GZP+WO1Dtq/XsyWfhXnvZVdh6+3QWolXYmY2rBJDd2jAJo8brgwF1IIQohMCoqOj8 8uVQbrLmG/lozjlnO+JuofmDMKjhha2kDUT946qzfajDTR9o1lASP4h9eyKk/7q10V+lz+QbsH4s 6KpgBnrNxRRrgd0/fE3LekBDTouKSvsJT+X2/p9oX5OyoQKNtXSm85T83Ko9PCiDRTIU1V2Bc6er RpOrU4n6Z8y87GJ+giQcmpN5CR2F2YNf3ZW9Wff+UnvXAzGCA+owggPmAgEBMIG9MIGvMQswCQYD VQQGEwJGUjETMBEGA1UECAwKUmhvbmUgQWxwczERMA8GA1UEBwwIR3Jlbm9ibGUxFzAVBgNVBAoM Dk5ldHdvcmsgUkFESVVTMQ8wDQYDVQQLDAZGcmFuY2UxJDAiBgNVBAMMG2VtcGxveWVlcy5uZXR3 b3JrcmFkaXVzLmNvbTEoMCYGCSqGSIb3DQEJARYZc3VwcG9ydEBuZXR3b3JrcmFkaXVzLmNvbQIJ AOAO5znieeLCMAkGBSsOAwIaBQCgggIBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMDIwNDAzMTQwOFowIwYJKoZIhvcNAQkEMRYEFHT43ruHS5in6XH+NYDJAFvt qHDqMIHOBgkrBgEEAYI3EAQxgcAwgb0wga8xCzAJBgNVBAYTAkZSMRMwEQYDVQQIDApSaG9uZSBB bHBzMREwDwYDVQQHDAhHcmVub2JsZTEXMBUGA1UECgwOTmV0d29yayBSQURJVVMxDzANBgNVBAsM BkZyYW5jZTEkMCIGA1UEAwwbZW1wbG95ZWVzLm5ldHdvcmtyYWRpdXMuY29tMSgwJgYJKoZIhvcN AQkBFhlzdXBwb3J0QG5ldHdvcmtyYWRpdXMuY29tAgkA4A7nOeJ54sIwgdAGCyqGSIb3DQEJEAIL MYHAoIG9MIGvMQswCQYDVQQGEwJGUjETMBEGA1UECAwKUmhvbmUgQWxwczERMA8GA1UEBwwIR3Jl bm9ibGUxFzAVBgNVBAoMDk5ldHdvcmsgUkFESVVTMQ8wDQYDVQQLDAZGcmFuY2UxJDAiBgNVBAMM G2VtcGxveWVlcy5uZXR3b3JrcmFkaXVzLmNvbTEoMCYGCSqGSIb3DQEJARYZc3VwcG9ydEBuZXR3 b3JrcmFkaXVzLmNvbQIJAOAO5znieeLCMA0GCSqGSIb3DQEBAQUABIIBACMLTwzXb7PkCEV3mhP+ dY9rDGOX8Ri8McrhFpayMxGr1kZkHOqoZiJzubRAHkiwMOL75se/MJ4KfG2sw0HgnMA7+Er4UA4i 0sU2vNPoC98Nwnac2LnxvREY+pctMIuBt8t+pkHbEaYr7KP02vpA4G39HsPPLQevqTsAbCdxPYTj KwQeZZYA9bsE3B7EYfMt7uwGUNHxLvAk3ECoxsc8YfvgOK0xChBMkNkkSW0v5nD9vZqRzUbJpH6m WAI8dpS78nkk43gO9mWj/+vRdDAbfMz7a6HFnRs1ovBXqNQx5gEXvBByk55WvUBmSE+a1G6LEaxU sOqobtqneFadLTzzBBwAAAAAAAA= --Apple-Mail=_A474D6C9-17B0-4AD8-A913-D05F09488B74-- From aland@deployingradius.com Sun Feb 3 19:50:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2D21F8999 for ; Sun, 3 Feb 2013 19:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdSK862tlIIl for ; Sun, 3 Feb 2013 19:50:12 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 86F2121F8995 for ; Sun, 3 Feb 2013 19:50:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 27E992240FA1; Mon, 4 Feb 2013 04:50:09 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4azst6s3Aam8; Mon, 4 Feb 2013 04:50:06 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 720702240F52; Mon, 4 Feb 2013 04:50:06 +0100 (CET) Message-ID: <510F2FED.5000300@deployingradius.com> Date: Sun, 03 Feb 2013 22:50:05 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510EC8A8.7050301@deployingradius.com> <510EFB18.1040407@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 03:50:15 -0000 Peter Deacon wrote: >> Accounting can use the Acct-Multi-Session-Id to tie accounting for >> individual streams to one session. > > With a few thousand flows to export for one session what happens? I have no idea. How does it work today? > Do I send a few thousand accounting records? Do I invent only as many > sessions as necessary to make everything fit into a few accounting records? How does it work with your solution? > If I want to change an authorization parameter I send a message with the > parameter I want changed and thats that. Then you don't need to send bulk data, do you? > With this hypothetical reauthorization scheme I send a message saying > please reauthorize yourself and hope for the best. Two RADIUS > transactions instead of one and no feedback. This is how some vendors have implemented CoA, because the semantics around changing an existing session can be difficult. Instead of CoA, they implement Disconnect-Request, and force the end machine to re-authenticate / re-authorize. So there is precedent for the approach I'm suggesting. It's deployed today, and it works. Alan DeKok. From peterd@iea-software.com Sun Feb 3 20:16:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE97521F8A27 for ; Sun, 3 Feb 2013 20:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7s5XajoigGD for ; Sun, 3 Feb 2013 20:16:57 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 7DA1921F895B for ; Sun, 3 Feb 2013 20:16:57 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 3 Feb 2013 20:13:26 -0800 Date: Sun, 3 Feb 2013 20:15:06 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <510F2FED.5000300@deployingradius.com> Message-ID: References: <510EC8A8.7050301@deployingradius.com> <510EFB18.1040407@deployingradius.com> <510F2FED.5000300@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 04:16:58 -0000 On Sun, 3 Feb 2013, Alan DeKok wrote: > This is how some vendors have implemented CoA, because the semantics > around changing an existing session can be difficult. Instead of CoA, > they implement Disconnect-Request, and force the end machine to > re-authenticate / re-authorize. > So there is precedent for the approach I'm suggesting. It's deployed > today, and it works. Dropping the session and expecting it will quickly re-authenticate is very different from reauthorization approach suggested earlier. I remember myself once making this same assumption - CoA is pointless you could just issue a disconnect and most systems would reauth so quick the user would be none the wiser. Unfortunately I was proven wrong after operators saw things differently. regards, Peter From alex@um.es Mon Feb 4 00:28:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C98821F848B for ; Mon, 4 Feb 2013 00:28:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.549 X-Spam-Level: X-Spam-Status: No, score=-4.549 tagged_above=-999 required=5 tests=[AWL=-0.950, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moj-4u2LyB8y for ; Mon, 4 Feb 2013 00:28:25 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 31E2121F843A for ; Mon, 4 Feb 2013 00:28:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 677DD5D597 for ; Mon, 4 Feb 2013 09:28:24 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4JOB5vAal2j7 for ; Mon, 4 Feb 2013 09:28:23 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id D31B55D599 for ; Mon, 4 Feb 2013 09:28:23 +0100 (CET) Message-ID: <510F7127.7060203@um.es> Date: Mon, 04 Feb 2013 09:28:23 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 08:28:26 -0000 El 03/02/13 18:57, Peter Deacon escribió: > On Sun, 3 Feb 2013, Sam Hartman wrote: > >>>>>>> "Peter" == Peter Deacon writes: > >> When I read your presentation, I was quite frustrated, because there's >> been a concept of RADIUS fragmentation going on for several months and >> your presentation is not responsive to that existing discussion. I hope >> that when people introduce alternatives into an ongoing discussion it is >> because they believe their alternative provides significant additional >> value. I hope that the introduction of the alternative would be focused >> around that additional value rather than presenting an alternative >> without relating it to the context of the ongoing discussion. I believe >> that by relating it to the ongoing discussion and comparing approaches, >> the conversation is more respectful of the different alternatives and >> their value. > >> Would you explain why you find this approach better than the approach >> already under discussion? > > Hi Sam, > > My understanding fragmentation approach SAML uses is intended for > Interop with existing systems (proxies) already in the field while my > approach does not. While both accomplish same goals where they > overlap the constraints are different. > > My primary issue with SAML draft which prompted this is lack of > command code coverage. Current fragmentation draft is not only for SAML, but a generic fragmentation mechanism. Indeed, it does not need to be a consequence of large attributes. It could also be provoked by a large amount of small attributes. > > It does not work with accounting even while there is talk about > pushing large quantities of data thru accounting messages. > > If I am to push a large authorization attribute there is no way to > alter my authorization later via dynamic authorization. > > I have no interest in seeing these issues constantly readdressed as > someone later finds a need to support huge messages in Accounting or CoA. Well, current fragmentation draft could be extended for Accounting support. It should be straightforward as it adds only minor changes to RADIUS processing. > >> I think the existing approach has two significant advantages over the >> new approach: > >> 1) It never requires there to be RADIUS packets running around longer >> than 4096 bytes. In a lot of RADIUS implementations I've looked at, >> there are a number of places where 4096-byte static buffers are used. >> I'd have fairly low confidence that you could find and fix all those >> buffers, especially in calling code for libraries. Interestingly, >> these same implementations can deal much more gracefully with >> decoded/expanded packets that couldn't possibly fit into 4096 bytes. >> That is, the structures used to deal with attributes are far more >> able to deal with larger attributes than the structures used to deal >> with packets. Note that even for RADIUS over TCP we did not relax >> the 4096 limit. I think this is a good call both because of the >> implementation concern and because of the proxy concern. > > Illustrations were intended to help convey a logical concept. Any > approach accomplishing the same result gets the job done. > > There is no reason individual fragments ever have to be combined into > a single block of memory if the implementor finds this to be easier > given their constraints. > > One may elect to calculate lengths, MD5s, HMACs..etc over fragments > just as they could a fully assembled product. > > With regards to the artificial limit in TCP case fragments could act > as a bridge to enable large packet flows between TCP and UDP systems > supporting fragments. > >> 2) The existing solution works better in a case where an intermediate >> proxy does not support fragmentation. > >> I *think* support with proxies that don't understand fragmentation is >> probably important. However I need to ponder that more. > > I agree this is a key difference. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Mon Feb 4 02:40:29 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4B5C21F8619 for ; Mon, 4 Feb 2013 02:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.493 X-Spam-Level: X-Spam-Status: No, score=-3.493 tagged_above=-999 required=5 tests=[AWL=1.106, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tw+2FoSqYjtA for ; Mon, 4 Feb 2013 02:40:29 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id DCE1C21F85D4 for ; Mon, 4 Feb 2013 02:40:28 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Feb 2013 02:36:00 -0800 Date: Mon, 4 Feb 2013 02:38:35 -0800 (Pacific Standard Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <510F7127.7060203@um.es> Message-ID: References: <510F7127.7060203@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 10:40:29 -0000 On Mon, 4 Feb 2013, Alejandro Perez Mendez wrote: >>> When I read your presentation, I was quite frustrated, because there's >>> been a concept of RADIUS fragmentation going on for several months and >>> your presentation is not responsive to that existing discussion. I hope >>> that when people introduce alternatives into an ongoing discussion it >>> because they believe their alternative provides significant additional >>> value. I hope that the introduction of the alternative would be focused >>> around that additional value rather than presenting an alternative >>> without relating it to the context of the ongoing discussion. I believe >>> that by relating it to the ongoing discussion and comparing approaches, >>> the conversation is more respectful of the different alternatives and >>> their value. >>> Would you explain why you find this approach better than the approach >>> already under discussion? >> My understanding fragmentation approach SAML uses is intended for >> Interop with existing systems (proxies) already in the field while my >> approach does not. While both accomplish same goals where they >> overlap the constraints are different. >> My primary issue with SAML draft which prompted this is lack of >> command code coverage. > Current fragmentation draft is not only for SAML, but a generic > fragmentation mechanism. Indeed, it does not need to be a consequence of > large attributes. It could also be provoked by a large amount of small > attributes. Hi Alejandro, I might as well list all of my problems with the draft. Before I do for what it is worth as with IPv6 transition efforts there are multiple solutions given different constraints faced by operators and implementors. One and only one solution is not necessarily going to solve everyones problem. My intent was not necessarily to compete with your approach but to offer up a more general solution separately to solve the larger problem as a separate matter on a separate tract. Like I told Sam the constraints are different. You I assume want this to pass thru existing proxy infrastructure. I am looking for a solution that is more universal and offers less of a chance for breakage and unintended consequences. I do not think it is reasonable to assume these differences can be reconciled given tools we have to work with. There is unpredictable consequences in breaking a contract which until now has always been true with regards to access to entire proxied request attributes and response attributes in order for intermediates to make decisions. First and most importantly it is not simply the case proxy is only performed based on user-name attribute. It can and is done on any arrangement of arbitrary attributes. Second if I am a proxy applying policy I want to make decisions based on a full picture of what is going on not part of it and not a dynamic situation that looks different based on how many bytes were in the original packet. If I see something that needs to be changed how do I change it if part of the thing has already leaked past me? How do I understand a data filters implications if the other half of it is in the next packet and it is too late to do anything about it then? This is not EAP where you are doing challenges just to establish identity. There are some interesting things in this draft like the misuse of Access-Challenge to convey authorization attributes and the covering up of this misuse by following the letter but not the spirit of law by resorting a bunch of sorting and shifting of attributes. Once you add up the hacks, dynamic sizing arithmetic, removal of various attributes and workarounds for specific protocols mentioned by name (EAP) this scheme ceases to be the simple solution advertised. >> It does not work with accounting even while there is talk about >> pushing large quantities of data thru accounting messages. >> If I am to push a large authorization attribute there is no way to >> alter my authorization later via dynamic authorization. >> I have no interest in seeing these issues constantly readdressed as >> someone later finds a need to support huge messages in Accounting or > CoA. > Well, current fragmentation draft could be extended for Accounting > support. It should be straightforward as it adds only minor changes to > RADIUS processing. regards, Peter From alex@um.es Mon Feb 4 02:56:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32BA21F8449 for ; Mon, 4 Feb 2013 02:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.913 X-Spam-Level: X-Spam-Status: No, score=-6.913 tagged_above=-999 required=5 tests=[AWL=1.686, BAYES_00=-2.599, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-9F6fsOeG7W for ; Mon, 4 Feb 2013 02:56:53 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBE821F8444 for ; Mon, 4 Feb 2013 02:56:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 3FD234B922 for ; Mon, 4 Feb 2013 11:56:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GBlEhFjxqLyP for ; Mon, 4 Feb 2013 11:56:50 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id A11754B919 for ; Mon, 4 Feb 2013 11:56:49 +0100 (CET) Message-ID: <510F93F1.5020206@um.es> Date: Mon, 04 Feb 2013 11:56:49 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: radext@ietf.org References: <510F7127.7060203@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 10:56:53 -0000 El 04/02/13 11:38, Peter Deacon escribió: > On Mon, 4 Feb 2013, Alejandro Perez Mendez wrote: > >>>> When I read your presentation, I was quite frustrated, because there's >>>> been a concept of RADIUS fragmentation going on for several months and >>>> your presentation is not responsive to that existing discussion. I >>>> hope >>>> that when people introduce alternatives into an ongoing discussion it > >>>> because they believe their alternative provides significant additional >>>> value. I hope that the introduction of the alternative would be >>>> focused >>>> around that additional value rather than presenting an alternative >>>> without relating it to the context of the ongoing discussion. I >>>> believe >>>> that by relating it to the ongoing discussion and comparing >>>> approaches, >>>> the conversation is more respectful of the different alternatives and >>>> their value. > >>>> Would you explain why you find this approach better than the approach >>>> already under discussion? > >>> My understanding fragmentation approach SAML uses is intended for >>> Interop with existing systems (proxies) already in the field while >>> my approach does not. While both accomplish same goals where they >>> overlap the constraints are different. > >>> My primary issue with SAML draft which prompted this is lack of >>> command code coverage. > >> Current fragmentation draft is not only for SAML, but a generic >> fragmentation mechanism. Indeed, it does not need to be a consequence >> of large attributes. It could also be provoked by a large amount of >> small attributes. > > Hi Alejandro, > > I might as well list all of my problems with the draft. Before I do > for what it is worth as with IPv6 transition efforts there are > multiple solutions given different constraints faced by operators and > implementors. One and only one solution is not necessarily going to > solve everyones problem. > > My intent was not necessarily to compete with your approach but to > offer up a more general solution separately to solve the larger > problem as a separate matter on a separate tract. > > Like I told Sam the constraints are different. You I assume want this > to pass thru existing proxy infrastructure. I am looking for a > solution that is more universal and offers less of a chance for > breakage and unintended consequences. I do not think it is reasonable > to assume these differences can be reconciled given tools we have to > work with. > > > There is unpredictable consequences in breaking a contract which until > now has always been true with regards to access to entire proxied > request attributes and response attributes in order for intermediates > to make decisions. > > First and most importantly it is not simply the case proxy is only > performed based on user-name attribute. It can and is done on any > arrangement of arbitrary attributes. > > Second if I am a proxy applying policy I want to make decisions based > on a full picture of what is going on not part of it and not a dynamic > situation that looks different based on how many bytes were in the > original packet. If I see something that needs to be changed how do I > change it if part of the thing has already leaked past me? We also provide a mechanism where proxies supporting this fragmentation scheme can receive the whole packet, modify it, and then continue with the proxing. Hence, it would then be very similar to what you propose. > > How do I understand a data filters implications if the other half of > it is in the next packet and it is too late to do anything about it then? > > This is not EAP where you are doing challenges just to establish > identity. > > There are some interesting things in this draft like the misuse of > Access-Challenge to convey authorization attributes Authorization attributes are just an example of a possible cause for a large RADIUS packets. But they may not be the only one.The draft intends to provide a generic fragmentation mechanisms, not only for authorization purposes. > and the covering up of this misuse by following the letter but not the > spirit of law by resorting a bunch of sorting and shifting of > attributes. Once you add up the hacks, dynamic sizing arithmetic, > removal of various attributes and workarounds for specific protocols > mentioned by name (EAP) this scheme ceases to be the simple solution > advertised. As you explained before, we started from different requirements. Our aim was to introduce the minimal impact on existing infrastructures, to ease its deployment, in such a way that End to End implementations can work, even though intermediary parties do not implement the specification. Regards, Alejandro > >>> It does not work with accounting even while there is talk about >>> pushing large quantities of data thru accounting messages. > >>> If I am to push a large authorization attribute there is no way to >>> alter my authorization later via dynamic authorization. > >>> I have no interest in seeing these issues constantly readdressed as >>> someone later finds a need to support huge messages in Accounting or >> CoA. > >> Well, current fragmentation draft could be extended for Accounting >> support. It should be straightforward as it adds only minor changes >> to RADIUS processing. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Mon Feb 4 03:57:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D73721F8447 for ; Mon, 4 Feb 2013 03:57:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gs57FZEInevv for ; Mon, 4 Feb 2013 03:57:19 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 86F5A21F8439 for ; Mon, 4 Feb 2013 03:57:19 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 6A49C202CE; Mon, 4 Feb 2013 06:53:07 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 35E6143FD; Mon, 4 Feb 2013 06:57:11 -0500 (EST) From: Sam Hartman To: radext@ietf.org Date: Mon, 04 Feb 2013 06:57:11 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: peterd@iea-software.com Subject: [radext] Process surrounding Peter's fragmentation proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 11:57:20 -0000 So, Peter's f/floated a sketch of a proposal on the list and has gotten some initial feedback. At this stage in the process it's important that people be given an opportunity to present alternatives but not to delay the process indefinitely. In general, I've seen this handled by asking people to present their proposals in the form of an internet draft by some deadline. So, since people were wanting a call for adoption on Alex's proposal, I think it would be reasonable to establish a deadline reasonably soon for any alternatives to Alex's proposal. I propose that any such alternative needs to be submitted as an individual I-D by the 00 cutoff for the Upcoming IETF. I believe that gives a couple of weeks, which is in my experience enough time for a reasonable sketch. I wouldn't expect such a draft to be as detailed as Alex's proposal as he's had a couple of rounds, but I would expect more detail than a slide deck. (I do appreciate the slide deck though. That was a great summary to get discussion started.) Then the WG can discuss the proposals on the table after the 00 cutoff and adopt 0 or more of them. Peter noted that his proposal may not be in competition with Alex's proposal. So, even if he doesn't choose to make it formally as an i-d now, then he could potentially bring it up later. However, the IETF does have a moderate bias in favor of one solution per problem. So, late comers do tend to have to meet a significantly higher bar, just as a WG tends to have to meet a significantly higher bar at IESG review if it proposes multiple solutions to similar problems. I think we should decide when that bar gets raised and I think it should be during this IETF cycle. I think that gives a fair balance between giving people a chance to propose alternatives and keeping things moving so that ABFAB and other parties are not delayed by the process. Chairs, participants, does this sound reasonable? --Sam From aland@deployingradius.com Mon Feb 4 04:29:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A386321F861F for ; Mon, 4 Feb 2013 04:29:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOXpYH5PD1dx for ; Mon, 4 Feb 2013 04:29:45 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9E33521F85FC for ; Mon, 4 Feb 2013 04:29:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BA5E42240F52; Mon, 4 Feb 2013 13:29:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZY-qi-2U00w; Mon, 4 Feb 2013 13:29:43 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id E94582240703; Mon, 4 Feb 2013 13:29:42 +0100 (CET) Message-ID: <510FA9B7.9010307@deployingradius.com> Date: Mon, 04 Feb 2013 07:29:43 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, peterd@iea-software.com Subject: Re: [radext] Process surrounding Peter's fragmentation proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 12:29:46 -0000 Sam Hartman wrote: > Chairs, participants, does this sound reasonable? It works for me. Alan DeKok. From aland@deployingradius.com Mon Feb 4 05:16:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79FF21F8673 for ; Mon, 4 Feb 2013 05:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.507 X-Spam-Level: X-Spam-Status: No, score=-103.507 tagged_above=-999 required=5 tests=[AWL=1.092, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbnogJs8Nqor for ; Mon, 4 Feb 2013 05:16:08 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E68E321F8652 for ; Mon, 4 Feb 2013 05:16:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 739EB2240F52; Mon, 4 Feb 2013 14:15:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feI07mujVRpi; Mon, 4 Feb 2013 14:15:20 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 8CB872240EBC; Mon, 4 Feb 2013 14:15:19 +0100 (CET) Message-ID: <510FB466.5090102@deployingradius.com> Date: Mon, 04 Feb 2013 08:15:18 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 13:16:08 -0000 Peter Deacon wrote: > My intent was not necessarily to compete with your approach but to offer > up a more general solution separately to solve the larger problem as a > separate matter on a separate tract. The current draft tries to meet the following goals: - no changes required to existing proxies (who don't implement it) - minimal changes to RADIUS - fits within the existing RADIUS infrastructure > Like I told Sam the constraints are different. You I assume want this > to pass thru existing proxy infrastructure. I am looking for a solution > that is more universal and offers less of a chance for breakage and > unintended consequences. I do not think it is reasonable to assume > these differences can be reconciled given tools we have to work with. If the proposal is to not use existing RADIUS, you might as well design the *best* solution, and pretend that RADIUS doesn't exist. > There is unpredictable consequences in breaking a contract which until > now has always been true with regards to access to entire proxied > request attributes and response attributes in order for intermediates to > make decisions. The proposal allows for that. Proxies CAN re-assemble the traffic, if they are aware of the new functionality. If they are unaware, they pass it straight through. With your proposal, proxies unaware of fragmentation will simply block all of the traffic. > First and most importantly it is not simply the case proxy is only > performed based on user-name attribute. It can and is done on any > arrangement of arbitrary attributes. "Can". Not "Required". > Second if I am a proxy applying policy I want to make decisions based on > a full picture of what is going on not part of it and not a dynamic > situation that looks different based on how many bytes were in the > original packet. If I see something that needs to be changed how do I > change it if part of the thing has already leaked past me? You're inventing a problem which doesn't need to exist. > How do I understand a data filters implications if the other half of it > is in the next packet and it is too late to do anything about it then? You just re-assemble the traffic. Like with your draft. > There are some interesting things in this draft like the misuse of > Access-Challenge to convey authorization attributes and the covering up > of this misuse by following the letter but not the spirit of law by > resorting a bunch of sorting and shifting of attributes. The point of allowing updates to standards is... to allow updates. We can update 2865 to allow *certain* authorization attributes in Access-Challenge. The RFCs aren't written in stone. They aren't inviolate for all time. Alan DeKok. From jouni.nospam@gmail.com Mon Feb 4 05:36:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0874221F86AB for ; Mon, 4 Feb 2013 05:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[AWL=0.347, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25sapbLbobr1 for ; Mon, 4 Feb 2013 05:36:54 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0250A21F869A for ; Mon, 4 Feb 2013 05:36:53 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id gf7so6697856lbb.32 for ; Mon, 04 Feb 2013 05:36:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=+dog+sdLGfMxnmdP2SmMneaG/24HbFwbzpXebruQYzw=; b=mNYZKapjbC6JYsAmvvi+f/bI9bzhydUaz9WN5VykVQ/Hb1Nz7Pgsbw4TnBGhRWAVXH hB7desZrqoXovIE8RRDlLg7++zt0l2Ogm61p97uHBgtiCQY66uQVFWM0n/NAU/GyJtAd awINnY9wQ+pOYTZRUAzMKz4lgsLZqhfKc6BQ/UWTqqtoy9H1x+FUw7ETO0sWj9+pw0JA tMhpK3SswaCFUb1JV3jzYl1Mryy2WvmY5pePHcuKnXiw2bZGqw87KEJx0HkluYuly9Nk PvrnBP51qjLsZ4k6ncalWvBo5P2eq0ZSm2sOr/yFJJ08pzQqYWC7ACyia/snMefuNVoz 6CQg== X-Received: by 10.152.109.146 with SMTP id hs18mr19418891lab.8.1359985012890; Mon, 04 Feb 2013 05:36:52 -0800 (PST) Received: from [192.168.250.102] ([194.100.71.98]) by mx.google.com with ESMTPS id gu8sm9037745lab.6.2013.02.04.05.36.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Feb 2013 05:36:51 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 4 Feb 2013 15:36:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4128DFC5-B5CA-46F6-AB85-789B4F9F01AC@gmail.com> References: To: "radext@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [radext] Process surrounding Peter's fragmentation proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 13:36:55 -0000 Folks, =46rom a chair point of view, there is still only one proposal on table to consider - I have not seen a competing I-D. There is no need for=20 any further deadlines; the topic is in the charter and there has been 2 months time to come up with a competing I-D for a chartered item. I think the process has been fair so far in that sense. As I already mailed to some (or one?) author a while back, a single email from the _authors_ to chairs asking for WG adoption when they think the I-D "is in a good shape enough" is all that is needed. Been waiting for that.. If I missed such email, sorry about it. - Jouni On Feb 4, 2013, at 1:57 PM, Sam Hartman = wrote: >=20 > So, Peter's f/floated a sketch of a proposal on the list and has = gotten > some initial feedback. > At this stage in the process it's important that people be given an > opportunity to present alternatives but not to delay the process > indefinitely. > In general, I've seen this handled by asking people to present their > proposals in the form of an internet draft by some deadline. >=20 > So, since people were wanting a call for adoption on Alex's proposal, = I > think it would be reasonable to establish a deadline reasonably soon = for > any alternatives to Alex's proposal. I propose that any such > alternative needs to be submitted as an individual I-D by the 00 = cutoff > for the Upcoming IETF. I believe that gives a couple of weeks, which = is > in my experience enough time for a reasonable sketch. I wouldn't = expect > such a draft to be as detailed as Alex's proposal as he's had a couple > of rounds, but I would expect more detail than a slide deck. (I do > appreciate the slide deck though. That was a great summary to get > discussion started.) >=20 > Then the WG can discuss the proposals on the table after the 00 = cutoff > and adopt 0 or more of them. >=20 > Peter noted that his proposal may not be in competition with Alex's > proposal. So, even if he doesn't choose to make it formally as an i-d > now, then he could potentially bring it up later. However, the IETF > does have a moderate bias in favor of one solution per problem. So, = late > comers do tend to have to meet a significantly higher bar, just as a = WG > tends to have to meet a significantly higher bar at IESG review if it > proposes multiple solutions to similar problems. >=20 > I think we should decide when that bar gets raised and I think it = should > be during this IETF cycle. I think that gives a fair balance between > giving people a chance to propose alternatives and keeping things = moving > so that ABFAB and other parties are not delayed by the process. >=20 > Chairs, participants, does this sound reasonable? >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Mon Feb 4 05:46:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1904221F8682 for ; Mon, 4 Feb 2013 05:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyX5CH2P1ftW for ; Mon, 4 Feb 2013 05:46:42 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7D80F21F86B6 for ; Mon, 4 Feb 2013 05:46:42 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id B76472026F; Mon, 4 Feb 2013 08:42:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 80D3343FD; Mon, 4 Feb 2013 08:46:41 -0500 (EST) From: Sam Hartman To: Jouni Korhonen References: <4128DFC5-B5CA-46F6-AB85-789B4F9F01AC@gmail.com> Date: Mon, 04 Feb 2013 08:46:41 -0500 In-Reply-To: <4128DFC5-B5CA-46F6-AB85-789B4F9F01AC@gmail.com> (Jouni Korhonen's message of "Mon, 4 Feb 2013 15:36:53 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" Subject: Re: [radext] Process surrounding Peter's fragmentation proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 13:46:43 -0000 >>>>> "Jouni" == Jouni Korhonen writes: Jouni> Folks, Jouni> From a chair point of view, there is still only one proposal Jouni> on table to consider - I have not seen a competing I-D. There Jouni> is no need for any further deadlines; the topic is in the Jouni> charter and there has been 2 months time to come up with a Jouni> competing I-D for a chartered item. I think the process has Jouni> been fair so far in that sense. To be clear I'm also OK with this. AUthors, let me know if I can help in any way to get to a point where you're ready to mail the chairs asking for adoption. From alex@um.es Mon Feb 4 07:45:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAAC21F87FF for ; Mon, 4 Feb 2013 07:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uV6isar9ufa for ; Mon, 4 Feb 2013 07:45:44 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 329AC21F87B3 for ; Mon, 4 Feb 2013 07:45:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id C18545359D for ; Mon, 4 Feb 2013 16:45:42 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CU-ICcUtQBRt for ; Mon, 4 Feb 2013 16:45:42 +0100 (CET) Received: from [192.168.1.128] (40.13.15.37.dynamic.jazztel.es [37.15.13.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id E9C6E53676 for ; Mon, 4 Feb 2013 16:45:41 +0100 (CET) Message-ID: <510FD7A3.3030104@um.es> Date: Mon, 04 Feb 2013 16:45:39 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: radext@ietf.org References: <4128DFC5-B5CA-46F6-AB85-789B4F9F01AC@gmail.com> In-Reply-To: <4128DFC5-B5CA-46F6-AB85-789B4F9F01AC@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [radext] Process surrounding Peter's fragmentation proposal X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 15:45:45 -0000 Hi Jouni, We are about to reflect some of the comments collected in a new version 05 (it should be prepared by the end of this week the later), and then we will make the call for adoption. Best regards, Alejandro > Folks, > > From a chair point of view, there is still only one proposal on table > to consider - I have not seen a competing I-D. There is no need for > any further deadlines; the topic is in the charter and there has been > 2 months time to come up with a competing I-D for a chartered item. I > think the process has been fair so far in that sense. > > As I already mailed to some (or one?) author a while back, a single > email from the _authors_ to chairs asking for WG adoption when they > think the I-D "is in a good shape enough" is all that is needed. Been > waiting for that.. If I missed such email, sorry about it. > > - Jouni > > > On Feb 4, 2013, at 1:57 PM, Sam Hartman wrote: > >> So, Peter's f/floated a sketch of a proposal on the list and has gotten >> some initial feedback. >> At this stage in the process it's important that people be given an >> opportunity to present alternatives but not to delay the process >> indefinitely. >> In general, I've seen this handled by asking people to present their >> proposals in the form of an internet draft by some deadline. >> >> So, since people were wanting a call for adoption on Alex's proposal, I >> think it would be reasonable to establish a deadline reasonably soon for >> any alternatives to Alex's proposal. I propose that any such >> alternative needs to be submitted as an individual I-D by the 00 cutoff >> for the Upcoming IETF. I believe that gives a couple of weeks, which is >> in my experience enough time for a reasonable sketch. I wouldn't expect >> such a draft to be as detailed as Alex's proposal as he's had a couple >> of rounds, but I would expect more detail than a slide deck. (I do >> appreciate the slide deck though. That was a great summary to get >> discussion started.) >> >> Then the WG can discuss the proposals on the table after the 00 cutoff >> and adopt 0 or more of them. >> >> Peter noted that his proposal may not be in competition with Alex's >> proposal. So, even if he doesn't choose to make it formally as an i-d >> now, then he could potentially bring it up later. However, the IETF >> does have a moderate bias in favor of one solution per problem. So, late >> comers do tend to have to meet a significantly higher bar, just as a WG >> tends to have to meet a significantly higher bar at IESG review if it >> proposes multiple solutions to similar problems. >> >> I think we should decide when that bar gets raised and I think it should >> be during this IETF cycle. I think that gives a fair balance between >> giving people a chance to propose alternatives and keeping things moving >> so that ABFAB and other parties are not delayed by the process. >> >> Chairs, participants, does this sound reasonable? >> >> --Sam >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Mon Feb 4 08:32:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6A21F84BB for ; Mon, 4 Feb 2013 08:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.631 X-Spam-Level: X-Spam-Status: No, score=-3.631 tagged_above=-999 required=5 tests=[AWL=0.968, BAYES_00=-2.599, GB_I_LETTER=-2] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaAb7AMod1Mu for ; Mon, 4 Feb 2013 08:32:26 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 37F8F21F84B9 for ; Mon, 4 Feb 2013 08:32:26 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Feb 2013 08:27:05 -0800 Date: Mon, 4 Feb 2013 08:30:30 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <510FB466.5090102@deployingradius.com> Message-ID: References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 16:32:27 -0000 On Mon, 4 Feb 2013, Alan DeKok wrote: > Peter Deacon wrote: >> My intent was not necessarily to compete with your approach but to offer >> up a more general solution separately to solve the larger problem as a >> separate matter on a separate tract. >> Second if I am a proxy applying policy I want to make decisions based on >> a full picture of what is going on not part of it and not a dynamic >> situation that looks different based on how many bytes were in the >> original packet. If I see something that needs to be changed how do I >> change it if part of the thing has already leaked past me? > You're inventing a problem which doesn't need to exist. >> How do I understand a data filters implications if the other half of it >> is in the next packet and it is too late to do anything about it then? > You just re-assemble the traffic. Like with your draft. Reassembling requires support for the specification. If you don't support the specification then you experience breakage. There is no free lunch. >> There are some interesting things in this draft like the misuse of >> Access-Challenge to convey authorization attributes and the covering up >> of this misuse by following the letter but not the spirit of law by >> resorting a bunch of sorting and shifting of attributes. > The point of allowing updates to standards is... to allow updates. > We can update 2865 to allow *certain* authorization attributes in > Access-Challenge. The RFCs aren't written in stone. They aren't > inviolate for all time. I don't see any standards being updated. All I see are hacks to work around them. regards, Peter From hartmans@painless-security.com Mon Feb 4 08:38:06 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4421F88B0 for ; Mon, 4 Feb 2013 08:38:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3KUAXGEnI8U for ; Mon, 4 Feb 2013 08:38:05 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C0C3321F88AC for ; Mon, 4 Feb 2013 08:38:05 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 74D932026F; Mon, 4 Feb 2013 11:34:00 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D4BE143FD; Mon, 4 Feb 2013 11:38:04 -0500 (EST) From: Sam Hartman To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> Date: Mon, 04 Feb 2013 11:38:04 -0500 In-Reply-To: (Peter Deacon's message of "Mon, 4 Feb 2013 08:30:30 -0800 (Pacific Standard Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Alejandro Perez Mendez , Alan DeKok Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 16:38:06 -0000 Hi, Peter. I'm a bit confused by some of your language; I'd appreciate it if you would help me get past the 0th order to the emotions and thoughts behind it. I've found that terms like hacks tend to have a lot of perception behind them. One person's hack is another person's evolution in action. Are you saying that you're concerned because you don't think that the complexity introduced by Alex's solution justifies the benefits? --Sam From aland@deployingradius.com Mon Feb 4 10:07:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C1221F847B for ; Mon, 4 Feb 2013 10:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxlWFec71X4F for ; Mon, 4 Feb 2013 10:07:11 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF01621F8AD1 for ; Mon, 4 Feb 2013 10:06:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 202F322410B0; Mon, 4 Feb 2013 19:05:46 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F2mLeAJ+3i3t; Mon, 4 Feb 2013 19:05:44 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 982802240F52; Mon, 4 Feb 2013 19:05:43 +0100 (CET) Message-ID: <510FF876.9060303@deployingradius.com> Date: Mon, 04 Feb 2013 13:05:42 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 18:07:12 -0000 Peter Deacon wrote: >> You just re-assemble the traffic. Like with your draft. > > Reassembling requires support for the specification. If you don't > support the specification then you experience breakage. That is not true. If proxies don't support the proposal, then they can't filter the new attributes. This is the *same* problem proxies have today, when new attributes are defined. And your proposal is worse. Implementations which don't support can't proxy anything. It is impossible to get large amounts of authorization data from a compliant server, through non-compliant proxies, and to a compliant NAS. You're complaining about a problem which doesn't exist for the current proposal. And most tellingly, you're *not* applying the same standard to your proposal. > There is no free lunch. For the other readers, the text I wrote which Peter deleted, says: The proposal allows for that. Proxies CAN re-assemble the traffic, if they are aware of the new functionality. If they are unaware, they pass it straight through. > I don't see any standards being updated. All I see are hacks to work > around them. I said: "We CAN update 2865". You are straw-manning me. You are inventing problems which don't exist. You apply rules to me that you don't apply to yourself. You are deleting my comments, and then claiming I don't support my position. You ignore *direct* questions when I ask you to explain your position. You "defend" your position by re-stating it over and over. You insult people by calling their solutions "hacks". It makes you no friends. And it ensures that people will ignore you as contributing nothing positive to the discussion. Alan DeKok. From peterd@iea-software.com Mon Feb 4 10:57:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4682B21F894D for ; Mon, 4 Feb 2013 10:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.739 X-Spam-Level: X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJkA-Js0-ipp for ; Mon, 4 Feb 2013 10:57:44 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id ACA3F21F8936 for ; Mon, 4 Feb 2013 10:57:44 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Feb 2013 10:52:01 -0800 Date: Mon, 4 Feb 2013 10:55:47 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <510FF876.9060303@deployingradius.com> Message-ID: References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <510FF876.9060303@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 18:57:45 -0000 On Mon, 4 Feb 2013, Alan DeKok wrote: > Peter Deacon wrote: >>> You just re-assemble the traffic. Like with your draft. >> Reassembling requires support for the specification. If you don't >> support the specification then you experience breakage. > That is not true. If proxies don't support the proposal, then they > can't filter the new attributes. This is the *same* problem proxies > have today, when new attributes are defined. What new attributes? My understanding this is a general solution there need not be any new attributes involved. This is not about filtering new attributes themselves exceeding 4096 bytes the problem is loss of ability to see and manage existing ones. I think Alex's careful precise language in responding to me on this exact issue is 100% accurate. You have to parse the whole context. > And your proposal is worse. Implementations which don't support can't > proxy anything. It is impossible to get large amounts of authorization > data from a compliant server, through non-compliant proxies, and to a > compliant NAS. As I've been saying all along and Q&A section brings up as the very first issues. What my little slideshow however says or does not say is ultimately irrelevant in context of Alex's draft which must stand on its own. > You're complaining about a problem which doesn't exist for the current > proposal. And most tellingly, you're *not* applying the same standard > to your proposal. I have gone out of my way to make it clear both to Sam and Alex in at least three separate messages the constraints and assumptions behind both are different. I am seeking a long term solution that solves the problem generally for all command codes and place no value in interop with the proxies of today. >> I don't see any standards being updated. All I see are hacks to work >> around them. > I said: "We CAN update 2865". > You are straw-manning me. You are inventing problems which don't > exist. You apply rules to me that you don't apply to yourself. You are > deleting my comments, and then claiming I don't support my position. You > ignore *direct* questions when I ask you to explain your position. You > "defend" your position by re-stating it over and over. You insult > people by calling their solutions "hacks". I will respond separately on the "hack" comment later. Needless to say no insult was intended toward Alex or anyone else. regards, Peter From peterd@iea-software.com Mon Feb 4 11:51:56 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F03DD21F8AA0 for ; Mon, 4 Feb 2013 11:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.725 X-Spam-Level: X-Spam-Status: No, score=-2.725 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CibARj5O3jtJ for ; Mon, 4 Feb 2013 11:51:55 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0270721F8A89 for ; Mon, 4 Feb 2013 11:51:54 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Feb 2013 11:45:59 -0800 Date: Mon, 4 Feb 2013 11:49:52 -0800 (Pacific Standard Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org, Alejandro Perez Mendez , Alan DeKok Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 19:51:56 -0000 On Mon, 4 Feb 2013, Sam Hartman wrote: > I'm a bit confused by some of your language; I'd appreciate it if you > would help me get past the 0th order to the emotions and thoughts behind > it. > I've found that terms like hacks tend to have a lot of perception behind > them. One person's hack is another person's evolution in action. > Are you saying that you're concerned because you don't think that the > complexity introduced by Alex's solution justifies the benefits? Hi Sam, I appreciate Alex's effort and while this sounds contradictory I don't object to Alex's works or the resulting draft and its trade-offs. I believe have been able to see the space clearly enough to at least understand constraints involved and with that understanding don't know I would have done much differently. The underlying theme that lead to "hack" was my focus on the disparity between the nature of the problem and the nature of the solution: The problem is essentially a low level transport issue. The solution involves assorted changes at a much different logical layer. What does the order of attributes of certain types and special accommodations for specific instances of authentication protocols have to do with just making a packet bigger? This was my thinking. And like I said before my main issue is not these issues for as much oxygen as they have consumed but lack of command code coverage. I think in the final analysis when you tally up the workaround/machinary necessary to make this work and opportunity cost of leaving other command codes *CURRENTLY* undressed -- from my understanding of implementation effort for all concerned it does not add up for me. When I looked the totality of the situation I wondered if we can't do better and thats what I still want to explore. Not better in terms of a direct comparison with Alex's work but different..different goals different constraints. regards, Peter From hartmans@painless-security.com Mon Feb 4 12:16:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D8821F8528 for ; Mon, 4 Feb 2013 12:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwdUji3AvwFS for ; Mon, 4 Feb 2013 12:16:14 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C981F21F8523 for ; Mon, 4 Feb 2013 12:16:13 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 58F562026F; Mon, 4 Feb 2013 15:12:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B588C43FD; Mon, 4 Feb 2013 15:16:12 -0500 (EST) From: Sam Hartman To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> Date: Mon, 04 Feb 2013 15:16:12 -0500 In-Reply-To: (Peter Deacon's message of "Mon, 4 Feb 2013 11:49:52 -0800 (Pacific Standard Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Alejandro Perez Mendez , Alan DeKok Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:16:14 -0000 Hi, Peter. If you view this as a transport issue, I think that learning from around 8 or 9 years of Kerberos experience with fragmentation would be valuable. Kerberos supports longer packets over TCP than UDP. If a client finds that it's trying to send a large message over UDP, it opens a TCP connection. If a server finds it's trying to send a large message over UDP, then it generats a TCP required error message. If we're going to view this problem at the transport layer, that's probably a simpler approach that gets the command code coverage you're looking for. --Sam From peterd@iea-software.com Mon Feb 4 12:37:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CA221F8A99 for ; Mon, 4 Feb 2013 12:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.713 X-Spam-Level: X-Spam-Status: No, score=-2.713 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekcjEJevBKM6 for ; Mon, 4 Feb 2013 12:37:44 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id A43B221F8235 for ; Mon, 4 Feb 2013 12:37:11 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Feb 2013 12:37:14 -0800 Date: Mon, 4 Feb 2013 12:35:13 -0800 (Pacific Standard Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org, Alejandro Perez Mendez , Alan DeKok Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:37:45 -0000 On Mon, 4 Feb 2013, Sam Hartman wrote: > If you view this as a transport issue, I think that learning from around > 8 or 9 years of Kerberos experience with fragmentation would be > valuable. > Kerberos supports longer packets over TCP than UDP. If a client finds > that it's trying to send a large message over UDP, it opens a TCP > connection. If a server finds it's trying to send a large message over > UDP, then it generats a TCP required error message. > If we're going to view this problem at the transport layer, that's > probably a simpler approach that gets the command code coverage you're > looking for. Hi Sam, I've never been thrilled with TCP transport for RADIUS but in a situation where it might only get used when shippings lots of data it sounds like a great idea! Excessive round trip delay that follows from moving bulk data in RADIUS/UDP acking every 'fragment' would also go away. regards, Peter From aland@deployingradius.com Mon Feb 4 12:40:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F4D21F8ACE for ; Mon, 4 Feb 2013 12:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pf+ETjMGop2D for ; Mon, 4 Feb 2013 12:40:37 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B273F21F8AB6 for ; Mon, 4 Feb 2013 12:40:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 32B6D22410DF; Mon, 4 Feb 2013 21:39:45 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXzcpZWQTtRt; Mon, 4 Feb 2013 21:39:42 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 3BDEF22404C2; Mon, 4 Feb 2013 21:39:42 +0100 (CET) Message-ID: <51101C8C.9000608@deployingradius.com> Date: Mon, 04 Feb 2013 15:39:40 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <510FF876.9060303@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:40:38 -0000 Peter Deacon wrote: > What new attributes? My understanding this is a general solution there > need not be any new attributes involved. You haven't read the draft, and you're wasting my time. Even without that, this is an ignorant response. The existin > This is not about filtering new attributes themselves exceeding 4096 > bytes the problem is loss of ability to see and manage existing ones. > > I think Alex's careful precise language in responding to me on this > exact issue is 100% accurate. You have to parse the whole context. > >> And your proposal is worse. Implementations which don't support can't >> proxy anything. It is impossible to get large amounts of authorization >> data from a compliant server, through non-compliant proxies, and to a >> compliant NAS. > > As I've been saying all along and Q&A section brings up as the very > first issues. > > What my little slideshow however says or does not say is ultimately > irrelevant in context of Alex's draft which must stand on its own. > >> You're complaining about a problem which doesn't exist for the current >> proposal. And most tellingly, you're *not* applying the same standard >> to your proposal. > > I have gone out of my way to make it clear both to Sam and Alex in at > least three separate messages the constraints and assumptions behind > both are different. > > I am seeking a long term solution that solves the problem generally for > all command codes and place no value in interop with the proxies of today. > >>> I don't see any standards being updated. All I see are hacks to work >>> around them. > >> I said: "We CAN update 2865". > >> You are straw-manning me. You are inventing problems which don't >> exist. You apply rules to me that you don't apply to yourself. You >> are deleting my comments, and then claiming I don't support my >> position. You ignore *direct* questions when I ask you to explain your >> position. You "defend" your position by re-stating it over and over. >> You insult people by calling their solutions "hacks". > > I will respond separately on the "hack" comment later. Needless to say > no insult was intended toward Alex or anyone else. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Feb 4 12:42:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30DF21F8B0B for ; Mon, 4 Feb 2013 12:42:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jm7KFxNWN+Uq for ; Mon, 4 Feb 2013 12:42:50 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0F42C21F8B1A for ; Mon, 4 Feb 2013 12:42:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 07C6922410DF; Mon, 4 Feb 2013 21:42:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sd-aicsb0B7w; Mon, 4 Feb 2013 21:42:45 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 80E5322404C2; Mon, 4 Feb 2013 21:42:44 +0100 (CET) Message-ID: <51101D43.4090103@deployingradius.com> Date: Mon, 04 Feb 2013 15:42:43 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Alejandro Perez Mendez , radext@ietf.org Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:42:51 -0000 Peter Deacon wrote: > Excessive round trip delay that follows from moving bulk data in > RADIUS/UDP acking every 'fragment' would also go away. P = # of hops N = # of fragments You either have (N) acks at each hop, for N*P acks. Or, you have P hops, with N acks traversing all hops... for P*N acks. How is N*P != P*N? Alan DeKok. From aland@deployingradius.com Mon Feb 4 12:46:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA16221F8B34 for ; Mon, 4 Feb 2013 12:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJq4Qp0ER2u9 for ; Mon, 4 Feb 2013 12:46:02 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D22121F8B30 for ; Mon, 4 Feb 2013 12:46:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CC7B722410DF; Mon, 4 Feb 2013 21:46:01 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dDUm4dI31Ec; Mon, 4 Feb 2013 21:46:01 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id D86F32240D50; Mon, 4 Feb 2013 21:46:00 +0100 (CET) Message-ID: <51101E07.3090709@deployingradius.com> Date: Mon, 04 Feb 2013 15:45:59 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <510FF876.9060303@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:46:02 -0000 A more complete response... Peter Deacon wrote: >> That is not true. If proxies don't support the proposal, then they >> can't filter the new attributes. This is the *same* problem proxies >> have today, when new attributes are defined. > > What new attributes? Any new attributes which require multi-packet reassembly. > My understanding this is a general solution there > need not be any new attributes involved. Existing attributes can't be fragmented across multiple packets. This proposal doesn't change that. > What my little slideshow however says or does not say is ultimately > irrelevant in context of Alex's draft which must stand on its own. My comments were directed to your methods of discourse, not the documents. Alan DeKok. From hartmans@painless-security.com Mon Feb 4 12:52:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4DE21F85CC for ; Mon, 4 Feb 2013 12:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZPVMMnvNBz3 for ; Mon, 4 Feb 2013 12:52:11 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CF3F621F8AE7 for ; Mon, 4 Feb 2013 12:52:10 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 27FC82026F; Mon, 4 Feb 2013 15:48:05 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8972943FD; Mon, 4 Feb 2013 15:52:09 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <51101D43.4090103@deployingradius.com> Date: Mon, 04 Feb 2013 15:52:09 -0500 In-Reply-To: <51101D43.4090103@deployingradius.com> (Alan DeKok's message of "Mon, 04 Feb 2013 15:42:43 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Peter Deacon , Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:52:11 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Peter Deacon wrote: >> Excessive round trip delay that follows from moving bulk data in >> RADIUS/UDP acking every 'fragment' would also go away. Alan> P = # of hops N = # of fragments Alan> You either have (N) acks at each hop, for N*P acks. No. TCP can combine acks. Also, TCP can have multiple acks outstanding. See analysis of TFTP performance compared to say FTP performance for a discussion of this and related TCP vs UDP performance issues. --Sam From aland@deployingradius.com Mon Feb 4 12:57:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B69BA21F85DF for ; Mon, 4 Feb 2013 12:57:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+egNooWOVhA for ; Mon, 4 Feb 2013 12:57:09 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 19EFF21F87D5 for ; Mon, 4 Feb 2013 12:57:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 92C9B22410DF; Mon, 4 Feb 2013 21:57:08 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0udwbRzBjZF; Mon, 4 Feb 2013 21:57:08 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id C74F52240F52; Mon, 4 Feb 2013 21:57:07 +0100 (CET) Message-ID: <511020A2.8040709@deployingradius.com> Date: Mon, 04 Feb 2013 15:57:06 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <51101D43.4090103@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Peter Deacon , Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:57:10 -0000 Sam Hartman wrote: > No. TCP can combine acks. Also, TCP can have multiple acks > outstanding. See analysis of TFTP performance compared to say FTP > performance for a discussion of this and related TCP vs UDP performance > issues. Yes. But the RADIUS fragmentation proposals can't. Alan DeKok. From peterd@iea-software.com Mon Feb 4 12:57:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C1DE21F8A77 for ; Mon, 4 Feb 2013 12:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.704 X-Spam-Level: X-Spam-Status: No, score=-2.704 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IzGaiZDFo8Nt for ; Mon, 4 Feb 2013 12:57:56 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id AEFD821F892D for ; Mon, 4 Feb 2013 12:57:56 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Feb 2013 12:57:57 -0800 Date: Mon, 4 Feb 2013 12:55:58 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <51101D43.4090103@deployingradius.com> Message-ID: References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <51101D43.4090103@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Sam Hartman , Alejandro Perez Mendez , radext@ietf.org Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 20:57:57 -0000 On Mon, 4 Feb 2013, Alan DeKok wrote: > Peter Deacon wrote: >> Excessive round trip delay that follows from moving bulk data in >> RADIUS/UDP acking every 'fragment' would also go away. > P = # of hops > N = # of fragments > You either have (N) acks at each hop, for N*P acks. > Or, you have P hops, with N acks traversing all hops... for P*N acks. > How is N*P != P*N? I was thinking mostly of clients and servers talking to each other rather than proxy chains. In proxy case the benefit is local handling of transport problems at each hop combined with windowing benefit vs having to chain up delay times and probability of further dropped packets. regards, Peter From aland@deployingradius.com Mon Feb 4 13:03:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430E421F8A1C for ; Mon, 4 Feb 2013 13:03:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7PUgNdJq4oL for ; Mon, 4 Feb 2013 13:03:09 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B299F21F8964 for ; Mon, 4 Feb 2013 13:03:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6295222410DF; Mon, 4 Feb 2013 22:02:23 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18jkzoXbDsAX; Mon, 4 Feb 2013 22:02:22 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id 5CF462240C5A; Mon, 4 Feb 2013 22:02:22 +0100 (CET) Message-ID: <511021DD.1000002@deployingradius.com> Date: Mon, 04 Feb 2013 16:02:21 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <51101D43.4090103@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Alejandro Perez Mendez , radext@ietf.org Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:03:10 -0000 Peter Deacon wrote: > In proxy case the benefit is local handling of transport problems at > each hop combined with windowing benefit vs having to chain up delay > times and probability of further dropped packets. Then TCP should be used. Alan DeKok. From peterd@iea-software.com Mon Feb 4 13:03:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFFDC21F8996 for ; Mon, 4 Feb 2013 13:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.696 X-Spam-Level: X-Spam-Status: No, score=-2.696 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GS2hIzmOqYcb for ; Mon, 4 Feb 2013 13:03:32 -0800 (PST) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6E6C921F84B9 for ; Mon, 4 Feb 2013 13:03:32 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 4 Feb 2013 13:03:33 -0800 Date: Mon, 4 Feb 2013 13:01:35 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <51101E07.3090709@deployingradius.com> Message-ID: References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <510FF876.9060303@deployingradius.com> <51101E07.3090709@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:03:33 -0000 On Mon, 4 Feb 2013, Alan DeKok wrote: >>> That is not true. If proxies don't support the proposal, then they >>> can't filter the new attributes. This is the *same* problem proxies >>> have today, when new attributes are defined. >> What new attributes? > Any new attributes which require multi-packet reassembly. >> My understanding this is a general solution there >> need not be any new attributes involved. > Existing attributes can't be fragmented across multiple packets. This > proposal doesn't change that. It is not the attributes individually it is access to the full request and or response messages. See my original message to Alex. regards, Peter From aland@deployingradius.com Mon Feb 4 13:14:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0421F8B0A for ; Mon, 4 Feb 2013 13:14:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBqNev-fuNs9 for ; Mon, 4 Feb 2013 13:14:02 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1AB2321F8A5F for ; Mon, 4 Feb 2013 13:14:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CADA322410DF; Mon, 4 Feb 2013 22:13:15 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPCKlYReI20s; Mon, 4 Feb 2013 22:13:15 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id E34F42240F52; Mon, 4 Feb 2013 22:13:14 +0100 (CET) Message-ID: <51102469.7010601@deployingradius.com> Date: Mon, 04 Feb 2013 16:13:13 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> <510FF876.9060303@deployingradius.com> <51101E07.3090709@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 21:14:02 -0000 Peter Deacon wrote: > It is not the attributes individually it is access to the full request > and or response messages. See my original message to Alex. And if the proxy doesn't implement the proposal, it won't know about the fragmentation. Just like what happens with your proposal. Your comments amount to "systems which don't implement a feature won't be able to use the feature." So? I fail to see why this is a surprise. I fail to see why you're wasting everyone's time by claiming it's a problem with the fragmentation draft. Alan DeKok. From alex@um.es Mon Feb 4 23:35:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7F921F89B9 for ; Mon, 4 Feb 2013 23:35:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.069 X-Spam-Level: X-Spam-Status: No, score=-6.069 tagged_above=-999 required=5 tests=[AWL=0.530, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3QhhLwnauNg for ; Mon, 4 Feb 2013 23:35:19 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE1F21F898A for ; Mon, 4 Feb 2013 23:35:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id D2B074BD22; Tue, 5 Feb 2013 08:35:17 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id jFuildNQ9Goz; Tue, 5 Feb 2013 08:35:17 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id C2F8D4BC45; Tue, 5 Feb 2013 08:35:12 +0100 (CET) Message-ID: <5110B630.5040405@um.es> Date: Tue, 05 Feb 2013 08:35:12 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: Peter Deacon References: <510F7127.7060203@um.es> <510FB466.5090102@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Sam Hartman , Alan DeKok , radext@ietf.org Subject: Re: [radext] RADIUS fragmentation concept X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 07:35:20 -0000 El 04/02/13 20:49, Peter Deacon escribió: > On Mon, 4 Feb 2013, Sam Hartman wrote: > >> I'm a bit confused by some of your language; I'd appreciate it if you >> would help me get past the 0th order to the emotions and thoughts behind >> it. > >> I've found that terms like hacks tend to have a lot of perception behind >> them. One person's hack is another person's evolution in action. > >> Are you saying that you're concerned because you don't think that the >> complexity introduced by Alex's solution justifies the benefits? > > Hi Sam, > > I appreciate Alex's effort and while this sounds contradictory I don't > object to Alex's works or the resulting draft and its trade-offs. > > I believe have been able to see the space clearly enough to at least > understand constraints involved and with that understanding don't know > I would have done much differently. > > The underlying theme that lead to "hack" was my focus on the disparity > between the nature of the problem and the nature of the solution: > > The problem is essentially a low level transport issue. The solution > involves assorted changes at a much different logical layer. What > does the order of attributes of certain types and special > accommodations for specific instances of authentication protocols have > to do with just making a packet bigger? This was my thinking. Hello Peter, I understand what you say, but this is the way this kind of problems have been addressed within RADIUS. Take for example attribute fragmentation. You could have defined instead a new attribute format, which supports more than 255 bytes. However, what it is defined is that you can put several "small" attributes into an ordered sequence, and it does the trick. Our solution follows the same reasoning. We can arrange packets in such a way that multiple packets represents logically a single large packet. I understand one can think problem and solution are not at the same level..., but this is far from being a new way to face this kind of problems within RADIUS. Regards, Alejandro > > And like I said before my main issue is not these issues for as much > oxygen as they have consumed but lack of command code coverage. > > I think in the final analysis when you tally up the > workaround/machinary necessary to make this work and opportunity cost > of leaving other command codes *CURRENTLY* undressed -- from my > understanding of implementation effort for all concerned it does not > add up for me. > > When I looked the totality of the situation I wondered if we can't do > better and thats what I still want to explore. Not better in terms of > a direct comparison with Alex's work but different..different goals > different constraints. > > regards, > Peter From bclaise@cisco.com Tue Feb 5 06:49:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D01E21F87CB for ; Tue, 5 Feb 2013 06:49:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.585 X-Spam-Level: X-Spam-Status: No, score=-10.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6rvRlyokI0H for ; Tue, 5 Feb 2013 06:49:49 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0445E21F87C4 for ; Tue, 5 Feb 2013 06:49:48 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15EneM8002483; Tue, 5 Feb 2013 15:49:40 +0100 (CET) Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r15EmwoQ012116; Tue, 5 Feb 2013 15:49:14 +0100 (CET) Message-ID: <51111BDA.7020703@cisco.com> Date: Tue, 05 Feb 2013 15:48:58 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Barry Leiba References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , radext-ads@tools.ietf.org, Alan DeKok Subject: Re: [radext] Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 14:49:50 -0000 Thanks Barry, I can see how the document improved thanks to your review. See in line. >>> I'll go through the diffs between -09 and -11 now, while I wait for my >>> flight to HKG, and double-check that we're all set on the other >>> points. >> Verified. Please make any further changes that my last message moves >> you to, and then make sure the working group is OK with the changes. > FWIW, my suggestion: > > 1. Alan posts a -12 version if he has further changes. > 2. Alan posts a message to the radext list, saying that he's made > quite a bunch of changes in response to IESG Evaluation, and the WG > should review them. Include a URL for the diff between -09 and -12 > (or -11). https://www.ietf.org/rfcdiff?url1=draft-ietf-radext-radius-extensions-09&difftype=--html&submit=Go!&url2=draft-ietf-radext-radius-extensions-11 > 3. The chairs post a message to the radext list asking for any > objections to the changes to be posted by, say, 15 Feb. The chairs > might specifically note that this is a call for review of the changes > only. Chairs, please do so. > 4. Benoit sticks the document on the 21 Feb telechat agenda (and > remember to go back afterward and remove the "returning item" flag). > I suggest doing this now; no need to wait. Done. > 5. When 15 Feb rolls around, Benoit changes the status back to "IESG > Evaluation". Will do. Regards, Benoit > > Of course, this all assumes no significant objections from the WG, but > you all know how to deal with that if it happens. :-) > > Barry > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > From ietf@augustcellars.com Tue Feb 5 11:29:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8591921F879D for ; Tue, 5 Feb 2013 11:29:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUxuvsy4bGUH for ; Tue, 5 Feb 2013 11:29:38 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0817621F8778 for ; Tue, 5 Feb 2013 11:29:37 -0800 (PST) Received: from Philemon (74-95-210-210-Houston.hfc.comcastbusiness.net [74.95.210.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 67C672CA5C; Tue, 5 Feb 2013 11:29:36 -0800 (PST) From: "Jim Schaad" To: Date: Tue, 5 Feb 2013 13:29:01 -0600 Message-ID: <000901ce03d7$13659740$3a30c5c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4DtNaZF+sd8s9tQWWMU3bOQVbaIA== Content-Language: en-us Cc: radext@ietf.org Subject: [radext] Comments on draft-dekok-radext-datatypes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 19:29:38 -0000 Alan, First let me say that I am probably not yet truly competent to review this draft so you can take some of this as probably wrong. 1. In the text in section 2. Where you are talking about the tag "Value", you should make clear that this does not apply when you are using the string "value". 2. While I understand the desire to have upper case strings in the section headers, having different names that vary only by capitalization (for example IPv4addr and ipv4addr) seems to add confusion rather than removing it. 3. For IPv4addr, can the sub-set consist of multiple ranges of addresses or is it supposed to be a single range? Is there any benefit in saying how the ranges should be specified for inclusion in a dictionary file? I guess that the multiple ranges would apply to all of the types specified that can be restricted. 4. For Time, I think you probably need to add the standard verbiage about not encoding leap seconds at this point. 5. For Text, why is an "absent" text string not allowed? This would mean a length of 0 octets. 6. For Text, probably not necessary - but is there an advantage to saying it is not null terminated? 7. Why should the String type not have the standard verbiage copied from Text about ranges of lengths? 8. Ditto comment on zero length octet string 9. For IPv6addr - ditto the question about defining standard way of specifying the range for inclusion in dictionary files. (I would be surprised if the answer was any different.) 10. For TLV, is there a reason that a TLV-Data cannot be zero bytes long? Just putting in the type might be enough to signal what needs to be said. 11. For Long-Extended, It would seem that the use of the More bit is problematic with the use of fragmented packaging as it is currently defined. If a proxy looks at this type (for some reason), I would expect it to start tossing packets in which either 1) the next attribute is not the same type and extended type or 2) it is the last attribute in a packet. This means that the fragment draft may want to change the M flag to a T flag and back again. 12. For Long-Extended, what does it mean if the content is not a valid RADIUS data type? What is the SHOULD doing in this statement. I would think that the content is going to be based on how the attribute is defined. Following the SHOULD says that I need to add a String wrapper on my SAML statement when sending it. Is this what is intended? 13. In section 3.1 - you should re-iterate the fact that the Value field is an artifact of the registry and does not have any one-the wire meaning. Typos s/thes/these/ s/consisten/consistent/ s/longths/lengths/ s/.././ s/completely fill/completely fills/ jim From aland@deployingradius.com Tue Feb 5 12:04:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F75F21F86D6 for ; Tue, 5 Feb 2013 12:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.26 X-Spam-Level: X-Spam-Status: No, score=-102.26 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOJx+4FJTojb for ; Tue, 5 Feb 2013 12:04:53 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A95B21F8688 for ; Tue, 5 Feb 2013 12:04:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 65F962240D35; Tue, 5 Feb 2013 21:03:54 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NsoZEKNGMK2o; Tue, 5 Feb 2013 21:03:52 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.150]) by power.freeradius.org (Postfix) with ESMTPSA id CFD9A22404C2; Tue, 5 Feb 2013 21:03:51 +0100 (CET) Message-ID: <511165A6.4090001@deployingradius.com> Date: Tue, 05 Feb 2013 15:03:50 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <000901ce03d7$13659740$3a30c5c0$@augustcellars.com> In-Reply-To: <000901ce03d7$13659740$3a30c5c0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] Comments on draft-dekok-radext-datatypes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 20:04:54 -0000 Jim Schaad wrote: > First let me say that I am probably not yet truly competent to review this > draft so you can take some of this as probably wrong. Reviews are always welcome. Sometimes getting outside reviews clarifies things which were obvious to people on the inside. > 1. In the text in section 2. Where you are talking about the tag "Value", > you should make clear that this does not apply when you are using the string > "value". OK. I'll try to come up with some clarifying text. > 2. While I understand the desire to have upper case strings in the section > headers, having different names that vary only by capitalization (for > example IPv4addr and ipv4addr) seems to add confusion rather than removing > it. Good point. I'll fix it to use lowercase for the section headers. > 3. For IPv4addr, can the sub-set consist of multiple ranges of addresses or > is it supposed to be a single range? It could be multiple ranges. I'll poke the text. > Is there any benefit in saying how > the ranges should be specified for inclusion in a dictionary file? I'd avoid talking about dictionary files. They've been used for 20 years, but they haven't previously been defined in RFCs. > I guess that the multiple ranges would apply to all of the types specified > that can be restricted. Yes. I'll go fix that. > 4. For Time, I think you probably need to add the standard verbiage about > not encoding leap seconds at this point. Ouch, yes. > 5. For Text, why is an "absent" text string not allowed? This would mean a > length of 0 octets. Zero length attributes are not allowed in RADIUS. > 6. For Text, probably not necessary - but is there an advantage to saying > it is not null terminated? Sure. RFC 2865 says the same thing. > 7. Why should the String type not have the standard verbiage copied from > Text about ranges of lengths? Sure. I'll go fix that. > 8. Ditto comment on zero length octet string Done. > 9. For IPv6addr - ditto the question about defining standard way of > specifying the range for inclusion in dictionary files. (I would be > surprised if the answer was any different.) It's the same answer. > 10. For TLV, is there a reason that a TLV-Data cannot be zero bytes long? > Just putting in the type might be enough to signal what needs to be said. Same answer as above for text and string. > 11. For Long-Extended, It would seem that the use of the More bit is > problematic with the use of fragmented packaging as it is currently defined. > If a proxy looks at this type (for some reason), I would expect it to start > tossing packets in which either 1) the next attribute is not the same type > and extended type or 2) it is the last attribute in a packet. This means > that the fragment draft may want to change the M flag to a T flag and back > again. Yes, there are interaction effects. I'll have to think about that. > 12. For Long-Extended, what does it mean if the content is not a valid > RADIUS data type? It's a "string" > What is the SHOULD doing in this statement. It's changed to a MUST. > I would > think that the content is going to be based on how the attribute is defined. > Following the SHOULD says that I need to add a String wrapper on my SAML > statement when sending it. Is this what is intended? If the SAML stuff is printable text, it's "text" format. If the SAML stuff is a binary blob, it's a "string" format. So yes, data types which are opaque to RADIUS MUST be data type "string". I'll add some text clarifying this. For example CHAP-Password is also of type "string", even though it has a complex structure which is parsed by RADIUS implementations. > 13. In section 3.1 - you should re-iterate the fact that the Value field is > an artifact of the registry and does not have any one-the wire meaning. OK. > Typos > s/thes/these/ > s/consisten/consistent/ > s/longths/lengths/ > s/.././ > s/completely fill/completely fills/ Thanks. Alan DeKok. From jouni.nospam@gmail.com Wed Feb 6 08:42:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E5D21F8507 for ; Wed, 6 Feb 2013 08:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO2Mc+GddcXI for ; Wed, 6 Feb 2013 08:42:24 -0800 (PST) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 5C37421F84E0 for ; Wed, 6 Feb 2013 08:42:22 -0800 (PST) Received: by mail-lb0-f173.google.com with SMTP id gf7so1342673lbb.4 for ; Wed, 06 Feb 2013 08:42:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=4QxDfwmA2Cudhx2lUPaDNJJu8NJhnOf3Rc8zxGRgH2E=; b=zYjM4RTOWs+5xMFy+k6rqfyJWPb/RTofohmYxhqiByz5f8SfyWqqXKsJBNMlN8De+a m2cDDj6jSf5z8Puyk0dF1265DanusQwiRDeaZdP+i+jvAX4hKp1IVuHg4EtpV1Ehybsl SwGIgYiSehARiYZI3rkLuYl+X23EC/CdncFL8iJCTt50OpDce0+eFsjpwmQ4pi3RuKIM QXj8WgqHZJc/sLmpyl3fCTnfpkXcaWDGF/EBG0q3PDmrNCK2T8F4dHl8MR0oKGaYRSmU MinrK0MwCBEG8XHCBTnqmuka/RxExSIcqKFormLlcPuRu4lcsyDcZkpohhz8pzhpughh Vejg== X-Received: by 10.152.144.202 with SMTP id so10mr27480743lab.9.1360168941274; Wed, 06 Feb 2013 08:42:21 -0800 (PST) Received: from [10.37.73.99] ([77.95.242.34]) by mx.google.com with ESMTPS id v7sm3477740lbg.13.2013.02.06.08.42.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Feb 2013 08:42:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Wed, 6 Feb 2013 18:42:08 +0200 Content-Transfer-Encoding: 7bit Message-Id: <473C0020-09E7-40F8-A21E-D735C4CEA068@gmail.com> References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1499) Cc: Barry Leiba , radext-ads@tools.ietf.org Subject: [radext] please check draft-ietf-radext-radius-extensions-11 was Re: Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 16:42:25 -0000 Folks, Everybody has already seen the proposal from Barry - thanks for it ;) So lets make it official. Since we all have seen the changes and the discussion that lead to those, we should be OK with a one week review time. Every WG member is encouraged to verify the latest -11 version of the I-D whether the _changes_ are from -09. This is not a place for new material etc. Express your OK/NOK/opinion by 13th Feb. If everything is fine, our AD can do the required steps regarding IESG telechat agenda and we are one step closer to publication. - Jouni & Mauricio On Feb 3, 2013, at 4:49 AM, Barry Leiba wrote: >>> I'll go through the diffs between -09 and -11 now, while I wait for my >>> flight to HKG, and double-check that we're all set on the other >>> points. >> >> Verified. Please make any further changes that my last message moves >> you to, and then make sure the working group is OK with the changes. > > FWIW, my suggestion: > > 1. Alan posts a -12 version if he has further changes. > 2. Alan posts a message to the radext list, saying that he's made > quite a bunch of changes in response to IESG Evaluation, and the WG > should review them. Include a URL for the diff between -09 and -12 > (or -11). > 3. The chairs post a message to the radext list asking for any > objections to the changes to be posted by, say, 15 Feb. The chairs > might specifically note that this is a call for review of the changes > only. > 4. Benoit sticks the document on the 21 Feb telechat agenda (and > remember to go back afterward and remove the "returning item" flag). > I suggest doing this now; no need to wait. > 5. When 15 Feb rolls around, Benoit changes the status back to "IESG > Evaluation". > > Of course, this all assumes no significant objections from the WG, but > you all know how to deal with that if it happens. :-) > > Barry > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Thu Feb 7 21:12:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 170D021F844E for ; Thu, 7 Feb 2013 21:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMkqaIFlKXnV for ; Thu, 7 Feb 2013 21:12:25 -0800 (PST) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6E55121F8440 for ; Thu, 7 Feb 2013 21:12:19 -0800 (PST) Received: by mail-lb0-f179.google.com with SMTP id j14so2646272lbo.24 for ; Thu, 07 Feb 2013 21:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=nnif94u4u9VVIuTSDglqZrX96UD6v+nHVGX4PZudSWw=; b=o5Pi3FsNr79AyHijkV8N1Sw2YLlxyZ8WyZsnpAtQjmTMny6rvL+YTuYlSB6udupwqG 57yNIZSBfDG56ZmIqh7o3TEpmEYYC9ooIxZaFLK+1hJfb6mUwb2IPXqCHN6IMzI4v0Cn EyzL/L5Ri3mZqOkSrqspWPAn9NmcGU81hklr51RGj+MvN+QHlHIoz8lb1C0SHFa8p0kE ZU5Ep8b3ZLvouCNUka5XPZnJbp/AiLZk729hvkkvvtD47/dUhnZqefYWzgfwa9G5RmB9 NXcFGbHVb8awwz3F5otTYhJnHSaRAbKTHA++fMmMypCGa1kbc5yEbGDUALnQx4ivJPki RRPQ== X-Received: by 10.112.29.72 with SMTP id i8mr1771815lbh.33.1360300338377; Thu, 07 Feb 2013 21:12:18 -0800 (PST) Received: from [10.37.85.189] ([77.95.242.36]) by mx.google.com with ESMTPS id iw6sm16009019lab.2.2013.02.07.21.12.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 07 Feb 2013 21:12:17 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Fri, 8 Feb 2013 07:11:20 +0200 To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [radext] WG session scheduled for IETF#86 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 05:12:26 -0000 Folks, Our WG session is tentatively(!) scheduled on radext Session 1 (1:30:00) Tuesday, Afternoon Session III 1700-1830 Room Name: Boca 1 --------------------------------------------- If someone has overwhelming issues with the time, let us know. - Jouni From alex@um.es Fri Feb 8 01:21:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC6F121F86DC; Fri, 8 Feb 2013 01:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vaEAEDYiNbX7; Fri, 8 Feb 2013 01:21:30 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3C3B521F8596; Fri, 8 Feb 2013 01:21:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id CF91553708; Fri, 8 Feb 2013 10:21:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id rzhzaYT6eCCZ; Fri, 8 Feb 2013 10:21:26 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 7EA2953626; Fri, 8 Feb 2013 10:21:24 +0100 (CET) Message-ID: <5114C394.7060303@um.es> Date: Fri, 08 Feb 2013 10:21:24 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: "radext@ietf.org" References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> In-Reply-To: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------020402050503090004070306" Cc: "abfab@ietf.org" Subject: [radext] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 09:21:33 -0000 This is a multi-part message in MIME format. --------------020402050503090004070306 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, after the valuable comments received from Jim Schaad and Yoshihiro Ohba, and further internal discussion, we have uploaded an updated version of the RADIUS fragmentation draft. The most relevant changes include: * Fragmentation can only occur after authentication. Clients wanting to send large amounts of data can signal this situation on the first Access-Request, but the exchange will happen after authentication is completed for security reasons. * More-Data-Pending is now called Frag-Status, and its functionality has been extended to cover other fragmentation signalling (including the More-Data-Pending one). * Access-Accept fragmentation is based on a series of Access-Accept packets, not mixing different types. * Security considerations and IANA considerations have been significantly improved. * The section regarding interaction with EAP has been removed, as it does not make sense any more. * Included discussion about allowed large packet size and its security implications. * Included discussion about unsupported packet types (i.e. accounting and CoA) and the rationale behind that decision. Regards, Alejandro -------- Mensaje original -------- Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt Fecha: Fri, 08 Feb 2013 01:01:48 -0800 De: internet-drafts@ietf.org Para: alex@um.es CC: aland@networkradius.com, gabilm@um.es, diego@tid.es, pereniguez@um.es, rafa@um.es A new version of I-D, draft-perez-radext-radius-fragmentation-05.txt has been successfully submitted by Alejandro Perez-Mendez and posted to the IETF repository. Filename: draft-perez-radext-radius-fragmentation Revision: 05 Title: Support of fragmentation of RADIUS packets Creation date: 2013-02-08 WG ID: Individual Submission Number of pages: 27 URL: http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-05.txt Status: http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation Htmlized: http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-05 Abstract: This document describes a mechanism providing fragmentation support of RADIUS packets that exceed the 4096 bytes limit. The IETF Secretariat --------------020402050503090004070306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello,

after the valuable comments received from Jim Schaad and Yoshihiro Ohba, and further internal discussion, we have uploaded an updated version of the RADIUS fragmentation draft.

The most relevant changes include:
  • Fragmentation can only occur after authentication. Clients wanting to send large amounts of data can signal this situation on the first Access-Request, but the exchange will happen after authentication is completed for security reasons.
  • More-Data-Pending is now called Frag-Status, and its functionality has been extended to cover other fragmentation signalling (including the More-Data-Pending one).
  • Access-Accept fragmentation is based on a series of Access-Accept packets, not mixing different types.
  • Security considerations and IANA considerations have been significantly improved.
  • The section regarding interaction with EAP has been removed, as it does not make sense any more.
  • Included discussion about allowed large packet size and its security implications.
  • Included discussion about unsupported packet types (i.e. accounting and CoA) and the rationale behind that decision.
Regards,
Alejandro

-------- Mensaje original --------
Asunto: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt
Fecha: Fri, 08 Feb 2013 01:01:48 -0800
De: internet-drafts@ietf.org
Para: alex@um.es
CC: aland@networkradius.com, gabilm@um.es, diego@tid.es, pereniguez@um.es, rafa@um.es 


A new version of I-D, draft-perez-radext-radius-fragmentation-05.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Filename:	 draft-perez-radext-radius-fragmentation
Revision:	 05
Title:		 Support of fragmentation of RADIUS packets
Creation date:	 2013-02-08
WG ID:		 Individual Submission
Number of pages: 27
URL:             http://www.ietf.org/internet-drafts/draft-perez-radext-radius-fragmentation-05.txt
Status:          http://datatracker.ietf.org/doc/draft-perez-radext-radius-fragmentation
Htmlized:        http://tools.ietf.org/html/draft-perez-radext-radius-fragmentation-05
Diff:            http://www.ietf.org/rfcdiff?url2=draft-perez-radext-radius-fragmentation-05

Abstract:
   This document describes a mechanism providing fragmentation support
   of RADIUS packets that exceed the 4096 bytes limit.

                                                                                  


The IETF Secretariat


--------------020402050503090004070306-- From aland@deployingradius.com Fri Feb 8 13:58:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E46821F8B6D for ; Fri, 8 Feb 2013 13:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvqrwiOm+p+F for ; Fri, 8 Feb 2013 13:58:24 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7837321F8B62 for ; Fri, 8 Feb 2013 13:58:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5A7C12240D35 for ; Fri, 8 Feb 2013 22:57:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XTInBQSFsr8X for ; Fri, 8 Feb 2013 22:57:35 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id A6BA02240633 for ; Fri, 8 Feb 2013 22:57:35 +0100 (CET) Message-ID: <511574CF.20709@deployingradius.com> Date: Fri, 08 Feb 2013 16:57:35 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [radext] Presentations for IETF 86 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 21:58:25 -0000 Can we have time for the following presentations: - DTLS (status, todos) - maybe 5 minutes? - NAI - 5-10 min - fragmentation - 15 minutes - data types (low priority) - 5-10 minutes We could also have a short discussion on the various accounting proposals. It would be nice to make progress there. Alan DeKok. From jouni.nospam@gmail.com Fri Feb 8 14:53:13 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1455E21F8B8B for ; Fri, 8 Feb 2013 14:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viLTvY5W7AZc for ; Fri, 8 Feb 2013 14:53:12 -0800 (PST) Received: from mail-ea0-f170.google.com (mail-ea0-f170.google.com [209.85.215.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6CFC721F87CA for ; Fri, 8 Feb 2013 14:53:12 -0800 (PST) Received: by mail-ea0-f170.google.com with SMTP id a11so1837097eaa.1 for ; Fri, 08 Feb 2013 14:53:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=xvH32bcPXmz3S0sMPATIdbgnlItJ5R/JsXRomn6N0M0=; b=N3R1m8pRNdt2krC8LwcfxMiR4UAZmgWzr+mXd3m/E52S/ot6GxVxN7TEl4bwNOoOCG xNvkr7GUI7ykk4tAwY1lsB6ElxDi1pWTIVdJ9CmEwUG+d9lHccqFrw4S3aQX2+jG/asc mKCFbrBIHC6i0uZObP1kpQW5bdkOyAOxs12jMkaBP/ZM82fL8g3jjW4jUmKlAJic2y9f vXngiGhyKuE1Fw0oyQfiflovU00ryXNBE5jcNPwH9FMNSLCq5QmsrSJC4Q7BHAJ6bbEH ELZYd72im/3uTcL9DOfCXPtvv3f1IZ9TcnRFSoej++ZAejgQLKsPIcOnEXPKO76+EGtB 1Y/g== X-Received: by 10.14.202.197 with SMTP id d45mr21082897eeo.1.1360363991560; Fri, 08 Feb 2013 14:53:11 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:61fe:5a14:8166:e44d? ([2001:1bc8:101:f101:61fe:5a14:8166:e44d]) by mx.google.com with ESMTPS id t4sm49647600eel.0.2013.02.08.14.53.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 14:53:10 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 9 Feb 2013 00:53:07 +0200 Message-Id: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: "radext-chairs@tools.ietf.org" Subject: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 22:53:13 -0000 Folks, This email starts a two week consensus call on adopting: Filename: draft-perez-radext-radius-fragmentation Revision: 05 Title: Support of fragmentation of RADIUS packets Creation date: 2013-02-08 Number of pages: 27 Express your concerns or support by 23rd Feb on the mailing list. - Jouni & Mauricio From hartmans@painless-security.com Sun Feb 10 05:54:59 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B2DE21F85AC; Sun, 10 Feb 2013 05:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VgVTGh6LWrTg; Sun, 10 Feb 2013 05:54:59 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D7D7F21F85AB; Sun, 10 Feb 2013 05:54:58 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (unknown [62.50.232.18]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 751A22026C; Sun, 10 Feb 2013 08:50:40 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6BB9643FD; Sun, 10 Feb 2013 08:54:53 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> Date: Sun, 10 Feb 2013 08:54:53 -0500 In-Reply-To: <5114C394.7060303@um.es> (Alejandro Perez Mendez's message of "Fri, 08 Feb 2013 10:21:24 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 13:54:59 -0000 Hi, Alex. With my draft-ietf-abfab-aaa-saml hat on, I have a problem with one of the proposed changes: * Fragmentation can only occur after authentication. Clients wanting to send large amounts of data can signal this situation on the first Access-Request, but the exchange will happen after authentication is completed for security reasons. Unfortunately some of the use cases for SAML involve looking at the SAML request to determine what authentication would be acceptable. As an example, we need to look at the LOA to determine what EAP methods are acceptable. As such, we do actually need to be able to send things like SAML requests prior to authentication. So, I'd like to better understand the reasons for this change. If it's DOS concerns, I would prefer to revert the change and simply note the concern in security considerations. Also, from a DOS standpoint, since the entity being authenticated is the user, not the NAS, I'd like to understand how you're better off from a DOS standpoint after authentication. --Sam From aland@deployingradius.com Sun Feb 10 07:10:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6DD021F8455; Sun, 10 Feb 2013 07:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cw68YwdAvtH4; Sun, 10 Feb 2013 07:10:07 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id EEE8021F8450; Sun, 10 Feb 2013 07:10:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 15F742240F82; Sun, 10 Feb 2013 16:10:05 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUZVPjh9kyyb; Sun, 10 Feb 2013 16:10:03 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 5B4BC2240B5A; Sun, 10 Feb 2013 16:10:02 +0100 (CET) Message-ID: <5117B84C.10405@deployingradius.com> Date: Sun, 10 Feb 2013 10:10:04 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 15:10:08 -0000 Sam Hartman wrote: > So, I'd like to better understand the reasons for this change. > If it's DOS concerns, I would prefer to revert the change and simply > note the concern in security considerations. It's partly DoS. The issue of the NAS sending large amounts of data to the home server is an issue. If it's for a trusted user, OK. If it's for an unknown user, it's not OK. i.e. even if the NAS only sends 10K of data, attackers can open up thousands of unauthenticated connections, and potentially DoS the server. > Also, from a DOS standpoint, since the entity being authenticated is the > user, not the NAS, I'd like to understand how you're better off from a > DOS standpoint after authentication. It reduces the attack profile. The issue of large volumes of authentication data is limited to (a) trusted NASes, and (b) known users. The other issues are packet size, and changes to existing EAP processing. EAP already largely fills RADIUS packets. Adding SAML data means that any UDP packet will be fragmented. It will then fail to cross the wider net. TCP / TLS doesn't have this problem, of course. The EAP processing issue is about synchronization. The EAP-Success needs to be in the Access-Accept. If the NAS is sending large amounts of data, it may overflow the initial sequence of packets. So... does the data get fragmented to the post-authentication stage? Will the NAS continue trying to send more data after EAP-Success? Will the server send EAP-Success in an Access-Challenge, and continue asking for the data? It's not clear what's best here. Alan DeKok. From ietf@augustcellars.com Sun Feb 10 13:10:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1667D21F8BCC for ; Sun, 10 Feb 2013 13:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nmSabmVCVYq for ; Sun, 10 Feb 2013 13:10:21 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8374B21F8B67 for ; Sun, 10 Feb 2013 13:10:21 -0800 (PST) Received: from Philemon (74-95-210-210-Houston.hfc.comcastbusiness.net [74.95.210.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 7038E38F4F; Sun, 10 Feb 2013 13:10:20 -0800 (PST) From: "Jim Schaad" To: Date: Sun, 10 Feb 2013 15:09:51 -0600 Message-ID: <004e01ce07d2$f8764470$e962cd50$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4HrTas78WcXXcFQT6b1Rwm2e/89A== Content-Language: en-us Cc: radext@ietf.org Subject: [radext] Comments on draft-halwasia-radext-capability-negotiation-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 21:10:22 -0000 I find it very difficult to begin to evaluate how this draft really works if it is missing the section on RADIUS Proxy Behavior. Proxies are going to have different answers if they do not support this feature, and if they do. Proxies will also have different answers based on how they support or don't support, but can ask the next proxy in line for an answer. Proxies may end up with different answers based on the routing of a message that it obtains. Thus talking to the same server, but over a different route may come up with a different answer. I think that there may be a security consideration on asking for and recieveing different answers for capabilities. For example, if one asks about a security capability there is the possibility of a down grade attack from any proxy in the system and possibly from people outside of the proxy net based on the routing of messages. Jim From aland@deployingradius.com Sun Feb 10 13:35:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7C9F21F877B for ; Sun, 10 Feb 2013 13:35:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ds5HfIG9vUDi for ; Sun, 10 Feb 2013 13:35:49 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B952421F85C0 for ; Sun, 10 Feb 2013 13:35:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6A8542241138; Sun, 10 Feb 2013 22:35:49 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QugmmSDv9c0j; Sun, 10 Feb 2013 22:35:46 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 3EBCB2240633; Sun, 10 Feb 2013 22:35:46 +0100 (CET) Message-ID: <511812B0.7050403@deployingradius.com> Date: Sun, 10 Feb 2013 16:35:44 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <004e01ce07d2$f8764470$e962cd50$@augustcellars.com> In-Reply-To: <004e01ce07d2$f8764470$e962cd50$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, draft-halwasia-radext-capability-negotiation@tools.ietf.org Subject: Re: [radext] Comments on draft-halwasia-radext-capability-negotiation-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 21:35:50 -0000 Jim Schaad wrote: > I find it very difficult to begin to evaluate how this draft really works if > it is missing the section on RADIUS Proxy Behavior. Proxies are going to > have different answers if they do not support this feature, and if they do. The intention of the draft is that capabilities are point to point. > Proxies will also have different answers based on how they support or don't > support, but can ask the next proxy in line for an answer. I would be wary of multi-hop capabilities. > Proxies may end up with different answers based on the routing of a message > that it obtains. Thus talking to the same server, but over a different > route may come up with a different answer. Exactly. Any multi-hop capability negotiation has to include the capabilities of *all* hops, along with a "name" for the home server. For now, that's an area of discussion. This draft fills a need for NAS to local server negotiation. Anything past that is unknown. > I think that there may be a security consideration on asking for and > recieveing different answers for capabilities. For example, if one asks > about a security capability there is the possibility of a down grade attack > from any proxy in the system and possibly from people outside of the proxy > net based on the routing of messages. If the packets are signed appropriately, impersonation attacks can't occur. The attacks left are then in-network downgrade attacks. I'd largely attribute those to misconfiguration instead of malice. I would view this draft as negotiating RADIUS capabilities, not security ones. e.g. negotiating TLS to a home server may be out of scope. But negotiating packet size, rate, or other features may be relevant. Any issue of security negotiation would best be left for a later draft, which specifies that negotiation. This draft just tries to set the framework for the negotiation process. Alan DeKok. From ietf@augustcellars.com Sun Feb 10 13:42:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EEC21F8808 for ; Sun, 10 Feb 2013 13:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9JSZo5xjiJWY for ; Sun, 10 Feb 2013 13:42:15 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 419C721F87F6 for ; Sun, 10 Feb 2013 13:42:15 -0800 (PST) Received: from Philemon (74-95-210-210-Houston.hfc.comcastbusiness.net [74.95.210.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id ADEBA2C9BC; Sun, 10 Feb 2013 13:42:14 -0800 (PST) From: "Jim Schaad" To: "'Alan DeKok'" References: <004e01ce07d2$f8764470$e962cd50$@augustcellars.com> <511812B0.7050403@deployingradius.com> In-Reply-To: <511812B0.7050403@deployingradius.com> Date: Sun, 10 Feb 2013 15:41:45 -0600 Message-ID: <006601ce07d7$6d855220$488ff660$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKVpVNCVwv44Q1tzwvi0/OVEnma2QHhjb25ltVXVqA= Content-Language: en-us Cc: radext@ietf.org, draft-halwasia-radext-capability-negotiation@tools.ietf.org Subject: Re: [radext] Comments on draft-halwasia-radext-capability-negotiation-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 21:42:16 -0000 It was suggested at one time that the fragmentation could be one of the items negotiated, from what you state below I would assume that you would generally disagree with this as this is an end-to-end capability and not a single hop capability in general. Jim > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Sunday, February 10, 2013 3:36 PM > To: Jim Schaad > Cc: draft-halwasia-radext-capability-negotiation@tools.ietf.org; > radext@ietf.org > Subject: Re: [radext] Comments on draft-halwasia-radext-capability- > negotiation-00 > > Jim Schaad wrote: > > I find it very difficult to begin to evaluate how this draft really > > works if it is missing the section on RADIUS Proxy Behavior. Proxies > > are going to have different answers if they do not support this feature, and > if they do. > > The intention of the draft is that capabilities are point to point. > > > Proxies will also have different answers based on how they support or > > don't support, but can ask the next proxy in line for an answer. > > I would be wary of multi-hop capabilities. > > > Proxies may end up with different answers based on the routing of a > > message that it obtains. Thus talking to the same server, but over a > > different route may come up with a different answer. > > Exactly. Any multi-hop capability negotiation has to include the capabilities > of *all* hops, along with a "name" for the home server. > > For now, that's an area of discussion. This draft fills a need for NAS to local > server negotiation. Anything past that is unknown. > > > I think that there may be a security consideration on asking for and > > recieveing different answers for capabilities. For example, if one > > asks about a security capability there is the possibility of a down > > grade attack from any proxy in the system and possibly from people > > outside of the proxy net based on the routing of messages. > > If the packets are signed appropriately, impersonation attacks can't occur. > The attacks left are then in-network downgrade attacks. I'd largely attribute > those to misconfiguration instead of malice. > > I would view this draft as negotiating RADIUS capabilities, not security ones. > e.g. negotiating TLS to a home server may be out of scope. But negotiating > packet size, rate, or other features may be relevant. > > Any issue of security negotiation would best be left for a later draft, which > specifies that negotiation. This draft just tries to set the framework for the > negotiation process. > > Alan DeKok. From aland@deployingradius.com Sun Feb 10 13:51:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4169E21F881A for ; Sun, 10 Feb 2013 13:51:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iO6EI9HDs1md for ; Sun, 10 Feb 2013 13:51:42 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id A0CF721F87E0 for ; Sun, 10 Feb 2013 13:51:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 473992241138; Sun, 10 Feb 2013 22:50:50 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tu889j+cJJ41; Sun, 10 Feb 2013 22:50:50 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 8C1FE2240741; Sun, 10 Feb 2013 22:50:49 +0100 (CET) Message-ID: <51181638.9020902@deployingradius.com> Date: Sun, 10 Feb 2013 16:50:48 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <004e01ce07d2$f8764470$e962cd50$@augustcellars.com> <511812B0.7050403@deployingradius.com> <006601ce07d7$6d855220$488ff660$@augustcellars.com> In-Reply-To: <006601ce07d7$6d855220$488ff660$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, draft-halwasia-radext-capability-negotiation@tools.ietf.org Subject: Re: [radext] Comments on draft-halwasia-radext-capability-negotiation-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 21:51:44 -0000 Jim Schaad wrote: > It was suggested at one time that the fragmentation could be one of the > items negotiated, from what you state below I would assume that you would > generally disagree with this as this is an end-to-end capability and not a > single hop capability in general. Right now, capabilities are single hop. The draft is relatively simple, and easy to implement. In theory, they could be multi-hop. I'm not sure what that would look like. Specifying that would require much discussion. There are a number of open issues and undefined concepts. Alan DeKok. From alex@um.es Mon Feb 11 02:00:48 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBCFD21F86D9; Mon, 11 Feb 2013 02:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.442, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTQ43ziBAKeY; Mon, 11 Feb 2013 02:00:47 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 164F821F86AF; Mon, 11 Feb 2013 02:00:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 26F7C53691; Mon, 11 Feb 2013 11:00:45 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FiapnXENl6KN; Mon, 11 Feb 2013 11:00:44 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id BF6B15377B; Mon, 11 Feb 2013 11:00:43 +0100 (CET) Message-ID: <5118C14A.80409@um.es> Date: Mon, 11 Feb 2013 11:00:42 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sam Hartman References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 10:00:48 -0000 > Hi, Alex. > > With my draft-ietf-abfab-aaa-saml hat on, I have a problem with one of > the proposed changes: > > * Fragmentation can only occur after authentication. Clients wanting to send > large amounts of data can signal this situation on the first > Access-Request, but the exchange will happen after authentication is > completed for security reasons. > > > Unfortunately some of the use cases for SAML involve looking at the SAML > request to determine what authentication would be acceptable. As an > example, we need to look at the LOA to determine what EAP methods are > acceptable. Hi Sam, do you expect this data to be so large that makes the first Access-Request packet to exceed the limit? It is not avoiding SAML data to be on the packet, just avoiding the use of fragmentation for security reasons. When using EAP, the first Access-Request is usually small, as it only contains EAP-Identity. Hence, almost 4KB would be available for SAML data. Regards, Alejandro > As such, we do actually need to be able to send things like SAML > requests prior to authentication. > > So, I'd like to better understand the reasons for this change. > If it's DOS concerns, I would prefer to revert the change and simply > note the concern in security considerations. > > Also, from a DOS standpoint, since the entity being authenticated is the > user, not the NAS, I'd like to understand how you're better off from a > DOS standpoint after authentication. > > --Sam From ietf@augustcellars.com Mon Feb 11 06:39:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C7121F8826; Mon, 11 Feb 2013 06:39:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LQA+RRNAluZ; Mon, 11 Feb 2013 06:39:48 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 98E1821F8800; Mon, 11 Feb 2013 06:39:48 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 138CD38F25; Mon, 11 Feb 2013 06:39:47 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , "'Sam Hartman'" References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5118C14A.80409@um.es> In-Reply-To: <5118C14A.80409@um.es> Date: Mon, 11 Feb 2013 06:39:19 -0800 Message-ID: <009301ce0865$93c31d80$bb495880$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ0Y0qCk2RfjVP9dQOdyaZ8W81U7wI0Zd0uAVZ7gxkCCHJUZJb7aang Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 14:39:49 -0000 I just created a really simple one, and it was less than 1K in size. However, this assumes that it is not signed. If you sign it then it will quickly jump in size as you are going to be looking at have a certificate and a signature included in the message which will likely be greater than 4K. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf Of > Alejandro Perez Mendez > Sent: Monday, February 11, 2013 2:01 AM > To: Sam Hartman > Cc: radext@ietf.org; abfab@ietf.org > Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext- > radius-fragmentation-05.txt > > > > Hi, Alex. > > > > With my draft-ietf-abfab-aaa-saml hat on, I have a problem with one of > > the proposed changes: > > > > * Fragmentation can only occur after authentication. Clients wanting to > send > > large amounts of data can signal this situation on the first > > Access-Request, but the exchange will happen after authentication is > > completed for security reasons. > > > > > > Unfortunately some of the use cases for SAML involve looking at the > > SAML request to determine what authentication would be acceptable. As > > an example, we need to look at the LOA to determine what EAP methods > > are acceptable. > Hi Sam, > > do you expect this data to be so large that makes the first Access-Request > packet to exceed the limit? It is not avoiding SAML data to be on the packet, > just avoiding the use of fragmentation for security reasons. When using EAP, > the first Access-Request is usually small, as it only contains EAP-Identity. > Hence, almost 4KB would be available for SAML data. > > Regards, > Alejandro > > > As such, we do actually need to be able to send things like SAML > > requests prior to authentication. > > > > So, I'd like to better understand the reasons for this change. > > If it's DOS concerns, I would prefer to revert the change and simply > > note the concern in security considerations. > > > > Also, from a DOS standpoint, since the entity being authenticated is > > the user, not the NAS, I'd like to understand how you're better off > > from a DOS standpoint after authentication. > > > > --Sam > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Mon Feb 11 07:36:19 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718F221F8849; Mon, 11 Feb 2013 07:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laoIhz2oQ4uu; Mon, 11 Feb 2013 07:36:18 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 26BBD21F87D4; Mon, 11 Feb 2013 07:36:09 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id BFCE92CA18; Mon, 11 Feb 2013 07:36:08 -0800 (PST) From: "Jim Schaad" To: "'Cantor, Scott'" , "'Alejandro Perez Mendez'" , "'Sam Hartman'" References: <009301ce0865$93c31d80$bb495880$@augustcellars.com> In-Reply-To: Date: Mon, 11 Feb 2013 07:35:39 -0800 Message-ID: <00a001ce086d$72c47c20$584d7460$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMRF364oFEzl9j1/fNhPIWYyzVN2pXuq2Eg Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:36:19 -0000 It is true that a certificate is not needed, however in the cases that we are looking at - cross-organization requests - it will be more likely to want to include it than not. Otherwise you have a much harder problem of supporting referring to and fetching the certificate in order to validate the signature. That said, I would hope that it would be possible to not do any signatures at all. I just don't know that it is realistic to require that the signature be omitted. jim > -----Original Message----- > From: Cantor, Scott [mailto:cantor.2@osu.edu] > Sent: Monday, February 11, 2013 7:13 AM > To: Jim Schaad; 'Alejandro Perez Mendez'; 'Sam Hartman' > Cc: radext@ietf.org; abfab@ietf.org > Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-radext- > radius-fragmentation-05.txt > > On 2/11/13 9:39 AM, "Jim Schaad" wrote: > > >I just created a really simple one, and it was less than 1K in size. > >However, this assumes that it is not signed. If you sign it then it > >will quickly jump in size as you are going to be looking at have a > >certificate and a signature included in the message which will likely > >be greater than 4K. > > You don't have to include a certificate to sign a message, though. > > Not that it isn't large anyway, but it's not impossible to stay under 4k even > when signing. > > -- Scott From cantor.2@osu.edu Mon Feb 11 07:12:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E15B21F8797; Mon, 11 Feb 2013 07:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekuEVarCN8MC; Mon, 11 Feb 2013 07:12:39 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe001.messaging.microsoft.com [216.32.180.184]) by ietfa.amsl.com (Postfix) with ESMTP id 4591521F879A; Mon, 11 Feb 2013 07:12:39 -0800 (PST) Received: from mail101-co1-R.bigfish.com (10.243.78.200) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 15:12:38 +0000 Received: from mail101-co1 (localhost [127.0.0.1]) by mail101-co1-R.bigfish.com (Postfix) with ESMTP id 109623C0139; Mon, 11 Feb 2013 15:12:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI X-SpamScore: -5 X-BigFish: VPS-5(zf7Izbb2dI98dI9371I146fIzz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail101-co1: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ; Received: from mail101-co1 (localhost.localdomain [127.0.0.1]) by mail101-co1 (MessageSwitch) id 136059555688898_13562; Mon, 11 Feb 2013 15:12:36 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.207]) by mail101-co1.bigfish.com (Postfix) with ESMTP id 13176580068; Mon, 11 Feb 2013 15:12:36 +0000 (UTC) Received: from cio-tnc-pf08 (164.107.81.222) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server id 14.1.225.23; Mon, 11 Feb 2013 15:12:34 +0000 Received: from CIO-TNC-HT06.osuad.osu.edu (localhost [127.0.0.1]) by cio-tnc-pf08 (Postfix) with ESMTP id 19B8B2E0059; Mon, 11 Feb 2013 10:12:34 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT06.osuad.osu.edu ([fe80::3d16:84bd:8d88:7cfd%12]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 10:12:34 -0500 From: "Cantor, Scott" To: Jim Schaad , 'Alejandro Perez Mendez' , 'Sam Hartman' Thread-Topic: [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt Thread-Index: AQHOCGo36D4/g1Tcn0O+OOMs17kL9A== Date: Mon, 11 Feb 2013 15:12:33 +0000 Message-ID: In-Reply-To: <009301ce0865$93c31d80$bb495880$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A72DB382B85A643B085F9DC1A9CA1FD@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-Mailman-Approved-At: Mon, 11 Feb 2013 08:05:21 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:12:40 -0000 On 2/11/13 9:39 AM, "Jim Schaad" wrote: >I just created a really simple one, and it was less than 1K in size. >However, this assumes that it is not signed. If you sign it then it will >quickly jump in size as you are going to be looking at have a certificate >and a signature included in the message which will likely be greater than >4K. You don't have to include a certificate to sign a message, though. Not that it isn't large anyway, but it's not impossible to stay under 4k even when signing. -- Scott From bernard_aboba@hotmail.com Mon Feb 11 08:50:19 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CAF121F8A84 for ; Mon, 11 Feb 2013 08:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.438 X-Spam-Level: X-Spam-Status: No, score=-102.438 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jzEhFHOU46xE for ; Mon, 11 Feb 2013 08:50:18 -0800 (PST) Received: from blu0-omc4-s13.blu0.hotmail.com (blu0-omc4-s13.blu0.hotmail.com [65.55.111.152]) by ietfa.amsl.com (Postfix) with ESMTP id 8294021F8A7E for ; Mon, 11 Feb 2013 08:50:18 -0800 (PST) Received: from BLU002-W94 ([65.55.111.135]) by blu0-omc4-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Feb 2013 08:50:18 -0800 X-EIP: [GXyarAP/5xh4dca26T0UwO2U1qHvaRRE] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_aa360c28-10f8-4f1e-8c41-571ea7bec042_" From: Bernard Aboba To: Jouni Korhonen , "radext@ietf.org" Date: Mon, 11 Feb 2013 08:50:17 -0800 Importance: Normal In-Reply-To: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2013 16:50:18.0366 (UTC) FILETIME=[DF7859E0:01CE0877] Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 16:50:19 -0000 --_aa360c28-10f8-4f1e-8c41-571ea7bec042_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am against adopting this document=2C because the problem is not well stat= ed=2C the requirements for a solution (such as backward compatibility) are = not identified and potential alternative solutions are not identified. In= particular: a. The document states that there are no other proposals for solving the pr= oblem. In fact=2C recommended solutions are described in RFC 6158 Section = 3.1 - and requirements are also outlined there. =20 b. The document gives examples of SAML assertions and JSON tokens as reason= s why the limit needs to be extended. As noted in RFC 6158 Section 3.1=2C = other mechanisms (such as names and URLs) can be used to handle those cases= .=20 c. The document does not adequately describe how backward compatibility is = handled in various cases. For example=2C a RADIUS client may be talking to= a RADIUS proxy that supports the extension=2C but the RADIUS server may no= t=3B or the RADIUS client could be talking to a legacy RADIUS proxy=2C but = the server may support the extension. The document does not describe how = these different cases are detected. Instead=2C it seems to assume that the= extension is supported uniformly. =20 > From: jouni.nospam@gmail.com > Date: Sat=2C 9 Feb 2013 00:53:07 +0200 > To: radext@ietf.org > CC: radext-chairs@tools.ietf.org > Subject: [radext] Adoption call for draft-perez-radext-radius-fragmentati= on-05 >=20 > Folks=2C >=20 > This email starts a two week consensus call on adopting: >=20 > Filename: draft-perez-radext-radius-fragmentation > Revision: 05 > Title: Support of fragmentation of RADIUS packets > Creation date: 2013-02-08 > Number of pages: 27 >=20 > Express your concerns or support by 23rd Feb on the mailing list. >=20 > - Jouni & Mauricio >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_aa360c28-10f8-4f1e-8c41-571ea7bec042_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I am against adopting this docum= ent=2C because the problem is not well stated=2C the requirements for a sol= ution (such as backward compatibility) are not identified and potential alt= ernative solutions are not identified. =3B =3B In particular:
a. The document states that there are no other proposals for solving the = problem. =3B In fact=2C recommended solutions are described in RFC 6158= Section 3.1 - and requirements are also outlined there. =3B

b.= The document gives examples of SAML assertions and JSON tokens as reasons = why the limit needs to be extended. =3B As noted in RFC 6158 Section 3.= 1=2C other mechanisms (such as names and URLs) can be used to handle those = cases.

c. The document does not adequately describe how backward co= mpatibility is handled in various cases. =3B For example=2C a RADIUS cl= ient may be talking to a RADIUS proxy that supports the extension=2C but th= e RADIUS server may not=3B or the RADIUS client could be talking to a legac= y RADIUS proxy=2C but the server may support the extension. =3B The doc= ument does not describe =3B how these different cases are detected.&nbs= p=3B Instead=2C it seems to assume that the extension is supported uniforml= y. =3B

>=3B From: = jouni.nospam@gmail.com
>=3B Date: Sat=2C 9 Feb 2013 00:53:07 +0200
= >=3B To: radext@ietf.org
>=3B CC: radext-chairs@tools.ietf.org
&g= t=3B Subject: [radext] Adoption call for draft-perez-radext-radius-fragment= ation-05
>=3B
>=3B Folks=2C
>=3B
>=3B This email star= ts a two week consensus call on adopting:
>=3B
>=3B Filename: = draft-perez-radext-radius-fragmentation
>=3B Revision: = 05
>=3B Title: Support of fragmentation of RADIUS pack= ets
>=3B Creation date: 2013-02-08
>=3B Number of pages: = 27
>=3B
>=3B Express your concerns or support by 23rd Feb on the= mailing list.
>=3B
>=3B - Jouni &=3B Mauricio
>=3B
= >=3B
>=3B _______________________________________________
>=3B= radext mailing list
>=3B radext@ietf.org
>=3B https://www.ietf.o= rg/mailman/listinfo/radext
= --_aa360c28-10f8-4f1e-8c41-571ea7bec042_-- From aland@deployingradius.com Mon Feb 11 11:30:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088EA21F87D4 for ; Mon, 11 Feb 2013 11:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D7abYxL74Isy for ; Mon, 11 Feb 2013 11:30:45 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C870221F87D2 for ; Mon, 11 Feb 2013 11:30:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1621F2240B5A; Mon, 11 Feb 2013 20:30:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfe7ezHuovwr; Mon, 11 Feb 2013 20:30:38 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 4661222407B9; Mon, 11 Feb 2013 20:30:38 +0100 (CET) Message-ID: <511946DC.2060806@deployingradius.com> Date: Mon, 11 Feb 2013 14:30:36 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , Jouni Korhonen , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 19:30:46 -0000 Bernard Aboba wrote: > I am against adopting this document, because the problem is not well > stated, the requirements for a solution (such as backward compatibility) > are not identified and potential alternative solutions are not > identified. In particular: > > a. The document states that there are no other proposals for solving the > problem. In fact, recommended solutions are described in RFC 6158 > Section 3.1 - and requirements are also outlined there. I'll deal with that section by section. 3.1 1) doesn't talk about pre-authentication data sent from the NAS to a server. This data doesn't fit into 4K packets. Leveraging EAP (request / challenge) to send the data isn't feasible. EAP already fills packets to PMTU, and not all authentications use EAP. As is noted for NAS-Filter-Rule, sending large amounts of data server to NAS is a problem. This draft addresses that problem. The rest of the comments apply (CoA, Accounting, etc.) The fragmentation draft doesn't propose changing that. 2) Using names rather than values works for many use-cases. Where the data is more dynamic (e.g. SAML authorization), that is difficult or impossible to pre-provision "named" policies. They need to be dynamic. Similar comments apply for dynamic NAS-Filter-Rules. 3) PMTU discovery doesn't work that well, as noted in 6158. > b. The document gives examples of SAML assertions and JSON tokens as > reasons why the limit needs to be extended. As noted in RFC 6158 > Section 3.1, other mechanisms (such as names and URLs) can be used to > handle those cases. Names are problematic for reasons noted above. 6158 doesn't appear to reference URLs, so far as I can find. URLs were discussed on the RADEXT list prior to publication. I think URLs would be a good solution, if they can be (a) dynamically created, (b) have contents dynamically updated. (c) securely accessed, and (d) accessed from remote systems. Satisfying all of those constraints is hard. A working solution is to leverage RADIUS. > c. The document does not adequately describe how backward compatibility > is handled in various cases. For example, a RADIUS client may be > talking to a RADIUS proxy that supports the extension, but the RADIUS > server may not; or the RADIUS client could be talking to a legacy RADIUS > proxy, but the server may support the extension. The document does not > describe how these different cases are detected. Instead, it seems to > assume that the extension is supported uniformly. The document could be clearer. One of the major goals for this proposal is to be transparent to existing proxies. The only systems needing to implement the draft at the ones which either generate, or consume the "large" data being fragmented. The intermediate proxies just pass everything through unchanged. If the proxies want to examine the contents of the "large" data, then they need to re-assemble it. But the fragmentation proposal has been tested with unaware proxies, and it works fine. I think the take-aware here is that the document could use updates with respect to problem statement, clarification of terminology, use-cases, and text which addresses the 6158 concerns. A simple version of the problem statement is this. One RADIUS system needs to send large amounts of data to another RADIUS system. The RADIUS system administrators may not have access to the firewall, web server, routers, or any other application server. They do have access to RADIUS. So it makes a certain amount of sense to transfer the data over RADIUS. Alan DeKok. From bernard_aboba@hotmail.com Mon Feb 11 13:20:31 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC14E21F8844 for ; Mon, 11 Feb 2013 13:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.443 X-Spam-Level: X-Spam-Status: No, score=-102.443 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwv6sPvPVnbl for ; Mon, 11 Feb 2013 13:20:30 -0800 (PST) Received: from blu0-omc2-s1.blu0.hotmail.com (blu0-omc2-s1.blu0.hotmail.com [65.55.111.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD4321F883E for ; Mon, 11 Feb 2013 13:20:30 -0800 (PST) Received: from BLU002-W89 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Feb 2013 13:20:30 -0800 X-EIP: [WcF5Qeadt/wb5tLsggEOERGwWUGzZRQg] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2a80c9f7-5ba1-4166-aa48-f27ca7b61ee0_" From: Bernard Aboba To: Alan DeKok Date: Mon, 11 Feb 2013 13:20:29 -0800 Importance: Normal In-Reply-To: <511946DC.2060806@deployingradius.com> References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com>, , <511946DC.2060806@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 11 Feb 2013 21:20:30.0122 (UTC) FILETIME=[9E6E00A0:01CE089D] Cc: "radext@ietf.org" , Jouni Korhonen , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:20:31 -0000 --_2a80c9f7-5ba1-4166-aa48-f27ca7b61ee0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks=2C Alan. Your explanations below make a lot of sense. Unfortunatel= y=2C they are not in the document :( Given that there are potentially multiple competing approaches=2C I think i= t is important for the requirements and problem statement to be clearly lai= d out=2C and for proposed solutions to describe how they address the requir= ements. Before these pre-requisites have been completed=2C it seems premat= ure to me to call for adoption of a particular solution.=20 > Date: Mon=2C 11 Feb 2013 14:30:36 -0500 > From: aland@deployingradius.com > To: bernard_aboba@hotmail.com > CC: radext@ietf.org=3B jouni.nospam@gmail.com=3B radext-chairs@tools.ietf= .org > Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmen= tation-05 >=20 > Bernard Aboba wrote: > > I am against adopting this document=2C because the problem is not well > > stated=2C the requirements for a solution (such as backward compatibili= ty) > > are not identified and potential alternative solutions are not > > identified. In particular: > >=20 > > a. The document states that there are no other proposals for solving th= e > > problem. In fact=2C recommended solutions are described in RFC 6158 > > Section 3.1 - and requirements are also outlined there.=20 >=20 > I'll deal with that section by section. >=20 > 3.1 1) doesn't talk about pre-authentication data sent from the NAS to > a server. This data doesn't fit into 4K packets. Leveraging EAP > (request / challenge) to send the data isn't feasible. EAP already > fills packets to PMTU=2C and not all authentications use EAP. >=20 > As is noted for NAS-Filter-Rule=2C sending large amounts of data server > to NAS is a problem. This draft addresses that problem. >=20 > The rest of the comments apply (CoA=2C Accounting=2C etc.) The > fragmentation draft doesn't propose changing that. >=20 > 2) Using names rather than values works for many use-cases. Where the > data is more dynamic (e.g. SAML authorization)=2C that is difficult or > impossible to pre-provision "named" policies. They need to be dynamic. >=20 > Similar comments apply for dynamic NAS-Filter-Rules. >=20 > 3) PMTU discovery doesn't work that well=2C as noted in 6158. >=20 > > b. The document gives examples of SAML assertions and JSON tokens as > > reasons why the limit needs to be extended. As noted in RFC 6158 > > Section 3.1=2C other mechanisms (such as names and URLs) can be used to > > handle those cases. >=20 > Names are problematic for reasons noted above. 6158 doesn't appear to > reference URLs=2C so far as I can find. URLs were discussed on the RADEX= T > list prior to publication. >=20 > I think URLs would be a good solution=2C if they can be (a) dynamically > created=2C (b) have contents dynamically updated. (c) securely accessed= =2C > and (d) accessed from remote systems. >=20 > Satisfying all of those constraints is hard. A working solution is to > leverage RADIUS. >=20 > > c. The document does not adequately describe how backward compatibility > > is handled in various cases. For example=2C a RADIUS client may be > > talking to a RADIUS proxy that supports the extension=2C but the RADIUS > > server may not=3B or the RADIUS client could be talking to a legacy RAD= IUS > > proxy=2C but the server may support the extension. The document does n= ot > > describe how these different cases are detected. Instead=2C it seems = to > > assume that the extension is supported uniformly.=20 >=20 > The document could be clearer. >=20 > One of the major goals for this proposal is to be transparent to > existing proxies. The only systems needing to implement the draft at > the ones which either generate=2C or consume the "large" data being > fragmented. The intermediate proxies just pass everything through > unchanged. >=20 > If the proxies want to examine the contents of the "large" data=2C then > they need to re-assemble it. But the fragmentation proposal has been > tested with unaware proxies=2C and it works fine. >=20 > I think the take-aware here is that the document could use updates > with respect to problem statement=2C clarification of terminology=2C > use-cases=2C and text which addresses the 6158 concerns. >=20 > A simple version of the problem statement is this. One RADIUS system > needs to send large amounts of data to another RADIUS system. The > RADIUS system administrators may not have access to the firewall=2C web > server=2C routers=2C or any other application server. They do have acces= s > to RADIUS. So it makes a certain amount of sense to transfer the data > over RADIUS. >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_2a80c9f7-5ba1-4166-aa48-f27ca7b61ee0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks=2C Alan. =3B Your exp= lanations below make a lot of sense. =3B Unfortunately=2C they are not = in the document :(

Given that there are potentially multiple competi= ng approaches=2C I think it is important for the requirements and problem s= tatement to be clearly laid out=2C and for proposed solutions to describe h= ow they address the requirements. =3B Before these pre-requisites have = been completed=2C it seems premature to me to call for adoption of a partic= ular solution.

>=3B Da= te: Mon=2C 11 Feb 2013 14:30:36 -0500
>=3B From: aland@deployingradius= .com
>=3B To: bernard_aboba@hotmail.com
>=3B CC: radext@ietf.org= =3B jouni.nospam@gmail.com=3B radext-chairs@tools.ietf.org
>=3B Subjec= t: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-0= 5
>=3B
>=3B Bernard Aboba wrote:
>=3B >=3B I am against a= dopting this document=2C because the problem is not well
>=3B >=3B s= tated=2C the requirements for a solution (such as backward compatibility)>=3B >=3B are not identified and potential alternative solutions are = not
>=3B >=3B identified. In particular:
>=3B >=3B
>= =3B >=3B a. The document states that there are no other proposals for sol= ving the
>=3B >=3B problem. In fact=2C recommended solutions are de= scribed in RFC 6158
>=3B >=3B Section 3.1 - and requirements are als= o outlined there.
>=3B
>=3B I'll deal with that section by se= ction.
>=3B
>=3B 3.1 1) doesn't talk about pre-authentication d= ata sent from the NAS to
>=3B a server. This data doesn't fit into 4K= packets. Leveraging EAP
>=3B (request / challenge) to send the data = isn't feasible. EAP already
>=3B fills packets to PMTU=2C and not all= authentications use EAP.
>=3B
>=3B As is noted for NAS-Filter= -Rule=2C sending large amounts of data server
>=3B to NAS is a problem= . This draft addresses that problem.
>=3B
>=3B The rest of th= e comments apply (CoA=2C Accounting=2C etc.) The
>=3B fragmentation d= raft doesn't propose changing that.
>=3B
>=3B 2) Using names r= ather than values works for many use-cases. Where the
>=3B data is mo= re dynamic (e.g. SAML authorization)=2C that is difficult or
>=3B impo= ssible to pre-provision "named" policies. They need to be dynamic.
>= =3B
>=3B Similar comments apply for dynamic NAS-Filter-Rules.
&g= t=3B
>=3B 3) PMTU discovery doesn't work that well=2C as noted in 6= 158.
>=3B
>=3B >=3B b. The document gives examples of SAML ass= ertions and JSON tokens as
>=3B >=3B reasons why the limit needs to = be extended. As noted in RFC 6158
>=3B >=3B Section 3.1=2C other me= chanisms (such as names and URLs) can be used to
>=3B >=3B handle th= ose cases.
>=3B
>=3B Names are problematic for reasons noted a= bove. 6158 doesn't appear to
>=3B reference URLs=2C so far as I can f= ind. URLs were discussed on the RADEXT
>=3B list prior to publication= .
>=3B
>=3B I think URLs would be a good solution=2C if they c= an be (a) dynamically
>=3B created=2C (b) have contents dynamically up= dated. (c) securely accessed=2C
>=3B and (d) accessed from remote syst= ems.
>=3B
>=3B Satisfying all of those constraints is hard. A= working solution is to
>=3B leverage RADIUS.
>=3B
>=3B >= =3B c. The document does not adequately describe how backward compatibility=
>=3B >=3B is handled in various cases. For example=2C a RADIUS cli= ent may be
>=3B >=3B talking to a RADIUS proxy that supports the ext= ension=2C but the RADIUS
>=3B >=3B server may not=3B or the RADIUS c= lient could be talking to a legacy RADIUS
>=3B >=3B proxy=2C but the= server may support the extension. The document does not
>=3B >=3B = describe how these different cases are detected. Instead=2C it seems to>=3B >=3B assume that the extension is supported uniformly.
>= =3B
>=3B The document could be clearer.
>=3B
>=3B One = of the major goals for this proposal is to be transparent to
>=3B exis= ting proxies. The only systems needing to implement the draft at
>=3B= the ones which either generate=2C or consume the "large" data being
>= =3B fragmented. The intermediate proxies just pass everything through
&= gt=3B unchanged.
>=3B
>=3B If the proxies want to examine the = contents of the "large" data=2C then
>=3B they need to re-assemble it.= But the fragmentation proposal has been
>=3B tested with unaware pro= xies=2C and it works fine.
>=3B
>=3B I think the take-aware he= re is that the document could use updates
>=3B with respect to problem= statement=2C clarification of terminology=2C
>=3B use-cases=2C and te= xt which addresses the 6158 concerns.
>=3B
>=3B A simple versi= on of the problem statement is this. One RADIUS system
>=3B needs to = send large amounts of data to another RADIUS system. The
>=3B RADIUS = system administrators may not have access to the firewall=2C web
>=3B = server=2C routers=2C or any other application server. They do have access<= br>>=3B to RADIUS. So it makes a certain amount of sense to transfer the= data
>=3B over RADIUS.
>=3B
>=3B Alan DeKok.
>=3B _= ______________________________________________
>=3B radext mailing lis= t
>=3B radext@ietf.org
>=3B https://www.ietf.org/mailman/listinfo= /radext
= --_2a80c9f7-5ba1-4166-aa48-f27ca7b61ee0_-- From hartmans@painless-security.com Tue Feb 12 05:09:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54B8E21F8D53 for ; Tue, 12 Feb 2013 05:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.503 X-Spam-Level: X-Spam-Status: No, score=-2.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgkMfteFnPR6 for ; Tue, 12 Feb 2013 05:09:00 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5254021F8D4B for ; Tue, 12 Feb 2013 05:09:00 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id A8C3220115; Tue, 12 Feb 2013 08:04:37 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A6A0743FD; Tue, 12 Feb 2013 08:08:57 -0500 (EST) From: Sam Hartman To: Bernard Aboba References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> <511946DC.2060806@deployingradius.com> Date: Tue, 12 Feb 2013 08:08:57 -0500 In-Reply-To: (Bernard Aboba's message of "Mon, 11 Feb 2013 13:20:29 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , Jouni Korhonen , "radext-chairs@tools.ietf.org" , Alan DeKok Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 13:09:01 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard, I understand that you're concerned because you want us to make sure we adopt a solution that actually meets our needs. I appreciate that concern. I am concerned though because I've found that the requirements process you are outlining tends to add significant value and tends to be a very heavy-weight process. So, I'd like to propose a balance below that I think will allow your concern to be addressed without introducing as much delay as the approach you recommend. Bernard> Given that there are potentially multiple competing Bernard> approaches, I think it is important for the requirements Bernard> and problem statement to be clearly laid out, and for Bernard> proposed solutions to describe how they address the Bernard> requirements. Before these pre-requisites have been Bernard> completed, it seems premature to me to call for adoption of Bernard> a particular solution. I am in favor of discussion on the list of requirements and advantages/disadvantages of various proposals. I am strongly against including requirements text in a draft that the Wg adopts or in attempting to come to consensus within the WG on these requirements. My experience is that trying to do tends to slow down work and is often used as a process approach for delaying/blocking proposals. It's my experience that having the requirements discussion is quite valuable, but that it's easier to gain consensus on wether to do the work than it is to gain consensus on the requirements. The consensus on the requirements is not actually necessary. So, I think that Alan's response--discussing the rationale on the list--is the right one. I would not object if Bernard or someone else wanted to write up an informational document capturing that discussion. I recommend that rather than attempting to gain consensus on such a document we simply document the various positions that emerge. I would not support delaying adopting drafts or publishing solution on completion of such an informational document. From hartmans@painless-security.com Tue Feb 12 05:15:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0524721F8D74; Tue, 12 Feb 2013 05:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuDPTVlxZpur; Tue, 12 Feb 2013 05:15:15 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9881521F8D71; Tue, 12 Feb 2013 05:15:14 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id AD1B720115; Tue, 12 Feb 2013 08:10:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A562E43FD; Tue, 12 Feb 2013 08:15:12 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5117B84C.10405@deployingradius.com> Date: Tue, 12 Feb 2013 08:15:12 -0500 In-Reply-To: <5117B84C.10405@deployingradius.com> (Alan DeKok's message of "Sun, 10 Feb 2013 10:10:04 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 13:15:16 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> It's partly DoS. The issue of the NAS sending large amounts Alan> of data to the home server is an issue. If it's for a trusted Alan> user, OK. If it's for an unknown user, it's not OK. OK. I'm confused, because the NAS is sending data for itself in the cases where we're talking about. If the data is being sent by the user, I'd expect it to be in the EAP stream. The cases I at least am contemplating here are where the NAS wants to send data about what it requires etc. Alan> i.e. even if the NAS only sends 10K of data, attackers can Alan> open up thousands of unauthenticated connections, and Alan> potentially DoS the server. Attackers who have any valid account could probably do the same. >> Also, from a DOS standpoint, since the entity being authenticated >> is the user, not the NAS, I'd like to understand how you're >> better off from a DOS standpoint after authentication. Alan> It reduces the attack profile. The issue of large volumes Alan> of authentication data is limited to (a) trusted NASes, and Alan> (b) known users. Although this is also limited to trusted NASes. The question is whether known user vs unknown user makes a difference for data between NAS and home server. Alan> The other issues are packet size, and changes to existing Alan> EAP processing. EAP already largely fills RADIUS packets. Alan> Adding SAML data means that any UDP packet will be fragmented. Alan> It will then fail to cross the wider net. TCP / TLS doesn't Alan> have this problem, of course. my assumption is that if you were sending access-accept saml auth data you'd do it before you started EAP. --Sam From aland@deployingradius.com Tue Feb 12 06:23:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5FE921F8B1E; Tue, 12 Feb 2013 06:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0MLFjPyJfAJ; Tue, 12 Feb 2013 06:23:11 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 357F721F8B0A; Tue, 12 Feb 2013 06:23:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 30BC82240C42; Tue, 12 Feb 2013 15:22:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HP+oQ+i0mLd; Tue, 12 Feb 2013 15:22:14 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 72D972240B4D; Tue, 12 Feb 2013 15:22:13 +0100 (CET) Message-ID: <511A5014.6050503@deployingradius.com> Date: Tue, 12 Feb 2013 09:22:12 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5117B84C.10405@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] [abfab] Fwd: New Version Notification for draft-perez-radext-radius-fragmentation-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:23:11 -0000 Sam Hartman wrote: > I'm confused, because the NAS is sending data for itself in the cases > where we're talking about. The issue is that the NAS sends data on behalf of the user. Even if the user is unknown. So attackers can leverage the NAS to send large amounts of data. > Attackers who have any valid account could probably do the same. Yes. But that allows a negative feedback effect. You call the known person and tell them to stop attacking you. > Although this is also limited to trusted NASes. > The question is whether known user vs unknown user makes a difference > for data between NAS and home server. I think it does. It lowers the attack profile. > my assumption is that if you were sending access-accept saml auth data > you'd do it before you started EAP. I'm wary of that approach. Alan DeKok. From hartmans@painless-security.com Tue Feb 12 06:28:30 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06CE621F8E3E for ; Tue, 12 Feb 2013 06:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0j5r+cZ-Jso for ; Tue, 12 Feb 2013 06:28:29 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6522521F8E38 for ; Tue, 12 Feb 2013 06:28:29 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 45BA620115; Tue, 12 Feb 2013 09:24:07 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E9A8043FD; Tue, 12 Feb 2013 09:28:25 -0500 (EST) From: Sam Hartman To: Jouni Korhonen References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> Date: Tue, 12 Feb 2013 09:28:25 -0500 In-Reply-To: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> (Jouni Korhonen's message of "Sat, 9 Feb 2013 00:53:07 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:28:30 -0000 I support adopting the previous version of this draft (draft-perez-radext-radius-fragmentation-04) and would support adopting the current version (draft-perez-radext-radius-fragmentation-05) if a mechanism was added for fragmented information in access-request prior to authentication. That is, I disagree with one of the changes the authors made between 04 and 05. --Sam From bernard_aboba@hotmail.com Tue Feb 12 07:42:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21BE21F8D96; Tue, 12 Feb 2013 07:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ce8c5t7K3X7J; Tue, 12 Feb 2013 07:42:51 -0800 (PST) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by ietfa.amsl.com (Postfix) with ESMTP id 383E021F8D8F; Tue, 12 Feb 2013 07:42:51 -0800 (PST) Received: from BLU002-W95 ([65.55.111.73]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 12 Feb 2013 07:42:50 -0800 X-EIP: [Xcwnlm9VnR13DYEWFZJcfhmv8sH0RJQq] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_c7c4316c-a584-48d0-b113-42dd47325c17_" From: Bernard Aboba To: Alan DeKok Date: Tue, 12 Feb 2013 07:42:50 -0800 Importance: Normal In-Reply-To: <511A5014.6050503@deployingradius.com> References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es>, <5117B84C.10405@deployingradius.com>, , <511A5014.6050503@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 12 Feb 2013 15:42:50.0861 (UTC) FILETIME=[9D61D9D0:01CE0937] Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] Why not a URL? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:42:51 -0000 --_c7c4316c-a584-48d0-b113-42dd47325c17_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Let me ask a potentially stupid question: Why can't we send a URL pointing to the {SAML Assertion=2C Certificate} ins= tead of sending the data itself? This is what was done in IKE to avoid fragmentation.=20 > > my assumption is that if you were sending access-accept saml auth data > > you'd do it before you started EAP. >=20 > I'm wary of that approach. >=20 > Alan DeKok. = --_c7c4316c-a584-48d0-b113-42dd47325c17_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Let me ask a potentially stupid = question:

Why can't we send a URL pointing to the {SAML Assertion=2C= Certificate} instead of sending the data itself?

This is what was d= one in IKE to avoid fragmentation.

>=3B >=3B my assumption= is that if you were sending access-accept saml auth data
>=3B >=3B = you'd do it before you started EAP.
>=3B
>=3B I'm wary of that= approach.
>=3B
>=3B Alan DeKok.

= --_c7c4316c-a584-48d0-b113-42dd47325c17_-- From bclaise@cisco.com Tue Feb 12 07:56:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F2C21F8F1A for ; Tue, 12 Feb 2013 07:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.41 X-Spam-Level: X-Spam-Status: No, score=-9.41 tagged_above=-999 required=5 tests=[AWL=-1.112, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upAENWedG8p5 for ; Tue, 12 Feb 2013 07:56:39 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 9944C21F8EEF for ; Tue, 12 Feb 2013 07:56:39 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1CFucqe016939; Tue, 12 Feb 2013 16:56:38 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1CFu3oN008850; Tue, 12 Feb 2013 16:56:13 +0100 (CET) Message-ID: <511A6613.9090206@cisco.com> Date: Tue, 12 Feb 2013 16:56:03 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: draft-ietf-radext-ieee802ext@tools.ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050400050803060809060303" Cc: radext@ietf.org Subject: Re: [radext] Additional comments on draft-ietf-radext-ieee802ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:56:40 -0000 This is a multi-part message in MIME format. --------------050400050803060809060303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear authors, Can you please answer Dorothy's message, and progress this draft. Keep in mind that you pushed for a short deadline in the charter: Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC And I even recall that you wanted "Nov 2012", and I pushed back ;-) Regards, Benoit > Here are some additional comments from 802.11 members, gathered at the > IEEE 802.11 meeting, Nov 14, 2012. > > Dorothy Stanley > ---------------- > 1. in 2.4, change from > " the reason why a station has been dissaciated." > to > "the reasonwhy a station was refused network access and has been > disassociated" > > 2. In 2.4, delete "were added by the IEEE 802.11u-2011 amendment"; as > the reference 802.11-2012 includes the 11u amendment. > > 3. In 2.4 insert "(Reason Codes)" after "Table 8-36" as an additional > guide for the reader. > > 4. At the end of 2.14 and at the end of section 5, add two additional > reason codes, "1 Unspecified reason" and "29 Disassociated for > unspecified, QoS-related reason", renumbering intermediate values. > > 5. In section 3, in the entry for WLAN-Reason-Code, change the > Acct-Req value from "0" to "0-1". The reason code could be included in > the accounting record sent by the RADIUS client for diagnostic purposes. > > > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------050400050803060809060303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear authors,

Can you please answer Dorothy's message, and progress this draft.
Keep in mind that you pushed for a short deadline in the charter:
    Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
And I even recall that you wanted "Nov 2012", and I pushed back ;-)

Regards, Benoit
Here are some additional comments from 802.11 members, gathered at the IEEE 802.11 meeting, Nov 14, 2012.

Dorothy Stanley
----------------
1. in 2.4, change from
"  the reason why a station has been dissaciated."
to
"the reason why a station was refused network access and has been disassociated"

2. In 2.4, delete "were added by the IEEE 802.11u-2011 amendment"; as the reference 802.11-2012 includes the 11u amendment.

3. In 2.4 insert "(Reason Codes)" after "Table 8-36" as an additional guide for the reader.

4. At the end of 2.14 and at the end of section 5, add two additional
reason codes, "1 Unspecified reason" and "29 Disassociated for unspecified, QoS-related reason", renumbering intermediate values.

5. In section 3, in the entry for WLAN-Reason-Code, change the Acct-Req value from "0" to "0-1". The reason code could be included in the accounting record sent by the RADIUS client for diagnostic purposes.





_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------050400050803060809060303-- From aland@deployingradius.com Tue Feb 12 07:59:30 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D169D21F8EE2; Tue, 12 Feb 2013 07:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCGTsy1frwwG; Tue, 12 Feb 2013 07:59:30 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 29FBE21F8EE0; Tue, 12 Feb 2013 07:59:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id EF0A32240C42; Tue, 12 Feb 2013 16:59:28 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKZBzUnWsXVC; Tue, 12 Feb 2013 16:59:28 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1176121727.dsl.bell.ca [70.26.49.127]) by power.freeradius.org (Postfix) with ESMTPSA id 2AD4E2240B5A; Tue, 12 Feb 2013 16:59:28 +0100 (CET) Message-ID: <511A66DF.9090807@deployingradius.com> Date: Tue, 12 Feb 2013 10:59:27 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es>, <5117B84C.10405@deployingradius.com>, , <511A5014.6050503@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] Why not a URL? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 15:59:30 -0000 Bernard Aboba wrote: > Why can't we send a URL pointing to the {SAML Assertion, Certificate} > instead of sending the data itself? Sure. That may work. Sometimes. The RADIUS system may not be publicly accessible. So any web server has to be located somewhere else. And the RADIUS server needs a way to talk to it. Or, the firewall rules need to be updated to allow non-RADIUS requests to make it to the RADIUS server. And this has to be bi-directional, as both ends of the RADIUS conversation want to send large amounts of data to each other. I think the simplest answer is that RADIUS systems use RADIUS to exchange RADIUS data. Doing anything else requires talking to non-RADIUS people, which is hard. The downside of this draft is that some RADIUS implementations need to change. But they'd have to change *anyways* to use any URL scheme. Another issue is proxies. Some proxies are required to mangle the data they pass, for inter-operability reasons. Using RADIUS lets them do this. Using URLs means thet they either have to ignore the URL, or re-host it themselves. Relying on non-RADIUS systems means added complexity, and dependence on external systems. The RADIUS process becomes more fragile. > This is what was done in IKE to avoid fragmentation. I think the IPSec boxes are already "public" on the net. Requiring them to be closely tied to a public web server may be a simple step. Alan DeKok. From gabilm@um.es Tue Feb 12 08:19:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C560721F8F6E; Tue, 12 Feb 2013 08:19:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.791 X-Spam-Level: X-Spam-Status: No, score=-3.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUYhJijQgtTE; Tue, 12 Feb 2013 08:19:39 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id D650321F8F6C; Tue, 12 Feb 2013 08:19:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 58C3B5D524; Tue, 12 Feb 2013 17:19:37 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 9eyolz91A5X4; Tue, 12 Feb 2013 17:19:36 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (unknown [5.34.132.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPSA id C54B25D51C; Tue, 12 Feb 2013 17:19:32 +0100 (CET) Message-ID: <511A6B93.80702@um.es> Date: Tue, 12 Feb 2013 17:19:31 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Cantor, Scott" References: In-Reply-To: X-Enigmail-Version: 1.5 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Bernard Aboba , "radext@ietf.org" , "abfab@ietf.org" , Alan DeKok Subject: Re: [radext] [abfab] Why not a URL? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:19:43 -0000 El 12/02/13 17:07, Cantor, Scott escribió: > On 2/12/13 10:42 AM, "Bernard Aboba" wrote: > >> Let me ask a potentially stupid question: >> >> Why can't we send a URL pointing to the {SAML Assertion, Certificate} >> instead of sending the data itself? > In addition to all of Alan's comments, there's the fact that you have to > secure the exchange over the URL, or punt and rely on artifact-style > short-lived references as a replacement for securing it. And probably sometimes, URL making use of HTTP+TLS negotiation could require more roundtrips than fragmented attributes. > -- Scott > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de Ingenier’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From hartmans@painless-security.com Tue Feb 12 08:41:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84F5B21F8F09; Tue, 12 Feb 2013 08:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLf+epSKf68a; Tue, 12 Feb 2013 08:41:52 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5A81021F8F73; Tue, 12 Feb 2013 08:41:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 00E1C20115; Tue, 12 Feb 2013 11:37:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 233D243FD; Tue, 12 Feb 2013 11:41:36 -0500 (EST) From: Sam Hartman To: Bernard Aboba References: <20130208090148.7646.37273.idtracker@ietfa.amsl.com> <5114C394.7060303@um.es> <5117B84C.10405@deployingradius.com> <511A5014.6050503@deployingradius.com> Date: Tue, 12 Feb 2013 11:41:36 -0500 In-Reply-To: (Bernard Aboba's message of "Tue, 12 Feb 2013 07:42:50 -0800") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , "abfab@ietf.org" , Alan DeKok Subject: Re: [radext] Why not a URL? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:41:52 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> Let me ask a potentially stupid question: Why can't we send Bernard> a URL pointing to the {SAML Assertion, Certificate} instead Bernard> of sending the data itself? Hi. First, I'm a little nervous about a SAML specific proposal. In Kerberos, we found that even with compact representations of authorization data, when people really start taking advantage of dynamic authorization, the authorization data can get large. Kerberos ended up choosing to use TCP to solve its fragmentation issues. I suspect that SAML is only the most discussed use case for a fragmentation solution. However, let's explore URIs for SAML. so, several of us do not want to assume a PKI shared between the NAS and the home AAA server. That is, we want to bootstrap our trust based on the AAA fabric. (Note that some subset of that us wants to do interesting things to bootstrap AAA trust, but that also fails to involve a PKI). SAML assertions are not always public. That is, we may be unwilling to disclose a SAML assertion without authorization. So, we need to accomplish the following: 1) Prove authorization to get the SAML assertion 2) Protect the integrity of the SAML assertion 3) Provide optional confidentiality for the SAML assertion. (several of us want to use SAML with RADSEC) In addition, in several of these cases, the SAML assertion is generated as a dynamic artifact of the authentication, so you have to introduce the complexity of storing the SAML assertion for a while. URLs aren't very good at providing confidentiality and integrity unless you happen to share a PKI in common with the authority referenced in the URI. It's possible to design a solution based on references that meets these constraints. I think we discussed that in ABFAB, and that's definitely not where we ended up. I think that if someone wants to pursue a URI-based approach it would be best to have a concrete proposal on the table. Possibly something that included a URI and a hash of the content. Except that alone is not good enough because if knowing the URI is the authorization to get the assertion, how do you provide authentication of the server prior to disclosing the URI without depending on a shared PKI? --Sam From internet-drafts@ietf.org Tue Feb 12 11:01:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0201321F90CF; Tue, 12 Feb 2013 11:01:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.51 X-Spam-Level: X-Spam-Status: No, score=-102.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAbmQISUW4-q; Tue, 12 Feb 2013 11:01:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B42FA21F90D9; Tue, 12 Feb 2013 11:01:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130212190115.6663.82636.idtracker@ietfa.amsl.com> Date: Tue, 12 Feb 2013 11:01:15 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ipv6-access-16.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 19:01:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : RADIUS attributes for IPv6 Access Networks Author(s) : Wojciech Dec Behcet Sarikaya Glen Zorn David Miles Benoit Lourdelet Filename : draft-ietf-radext-ipv6-access-16.txt Pages : 14 Date : 2013-02-12 Abstract: This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement; assignment of a named IPv6 delegated prefix pool; and assignment of a named IPv6 pool for host DHCPv6 addressing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ipv6-access-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From cantor.2@osu.edu Tue Feb 12 08:07:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB40B21F8F22; Tue, 12 Feb 2013 08:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3BSRbkHG0HT; Tue, 12 Feb 2013 08:07:09 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3EA21F8F1B; Tue, 12 Feb 2013 08:07:09 -0800 (PST) Received: from mail136-va3-R.bigfish.com (10.7.14.245) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Feb 2013 16:07:08 +0000 Received: from mail136-va3 (localhost [127.0.0.1]) by mail136-va3-R.bigfish.com (Postfix) with ESMTP id A7ECD4A02B6; Tue, 12 Feb 2013 16:07:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.208; KIP:(null); UIP:(null); IPV:NLI; H:cio-krc-pf01; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1f42h1d77h1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275bhz2fh668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1155h) Received-SPF: pass (mail136-va3: domain of osu.edu designates 164.107.81.208 as permitted sender) client-ip=164.107.81.208; envelope-from=cantor.2@osu.edu; helo=cio-krc-pf01 ; cio-krc-pf01 ; Received: from mail136-va3 (localhost.localdomain [127.0.0.1]) by mail136-va3 (MessageSwitch) id 1360685227677550_2620; Tue, 12 Feb 2013 16:07:07 +0000 (UTC) Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.254]) by mail136-va3.bigfish.com (Postfix) with ESMTP id 94F6A3A0087; Tue, 12 Feb 2013 16:07:07 +0000 (UTC) Received: from cio-krc-pf01 (164.107.81.208) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server id 14.1.225.23; Tue, 12 Feb 2013 16:07:04 +0000 Received: from CIO-TNC-HT07.osuad.osu.edu (localhost [127.0.0.1]) by cio-krc-pf01 (Postfix) with ESMTP id 4667AA0053; Tue, 12 Feb 2013 11:07:04 -0500 (EST) Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0328.009; Tue, 12 Feb 2013 11:07:04 -0500 From: "Cantor, Scott" To: Bernard Aboba , Alan DeKok Thread-Topic: [abfab] [radext] Why not a URL? Thread-Index: AQHOCTej+Cvqzu4SCEmr/aH8rIRw75h2Y4oA Date: Tue, 12 Feb 2013 16:07:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.29.31] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Forward X-OriginatorOrg: osu.edu X-Mailman-Approved-At: Wed, 13 Feb 2013 09:36:03 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [radext] [abfab] Why not a URL? X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 16:07:10 -0000 On 2/12/13 10:42 AM, "Bernard Aboba" wrote: >Let me ask a potentially stupid question: > >Why can't we send a URL pointing to the {SAML Assertion, Certificate} >instead of sending the data itself? In addition to all of Alan's comments, there's the fact that you have to secure the exchange over the URL, or punt and rely on artifact-style short-lived references as a replacement for securing it. -- Scott From jouni.nospam@gmail.com Wed Feb 13 09:54:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89AB021F89EF for ; Wed, 13 Feb 2013 09:54:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMF6AjA+ruML for ; Wed, 13 Feb 2013 09:54:07 -0800 (PST) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 8342121F892D for ; Wed, 13 Feb 2013 09:54:02 -0800 (PST) Received: by mail-ee0-f47.google.com with SMTP id e52so829891eek.34 for ; Wed, 13 Feb 2013 09:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=bZwUezCXI3W3PenhefMleQxsPuRsUiHgiHs3DHdq/4U=; b=O71p5jJxF+xsXrqqTyRYDlca7lRS1l0l4rM7FlGqlTVAoGqjIHfP8HYh0qSHZzH6YW C1l7wEu3zb4mwi8EOyyqI8ZD4PEa/BOO2TdhTCGg5vhuSGWSFpa7taCDeiYBhwft9ZPh tIQvlH7sOKWc7LQ5fKux8X5tthIaVIr4HhxdL+5yNtMmRQE23wRpJWdryARcPfGs//Md JLtHPhyQAw6kqHQc3Gu2Y1/7ChKCwJPoWp034u+0y0tDCeBsnbihOVVfEwrILku1Oi9b DHo1Ve/BSDEDbNizoyYStft4/h+Mq941IaAmWr81mx8ViI5qr50Ao37j+4ymMuhGqJys GeQw== X-Received: by 10.14.193.134 with SMTP id k6mr8069097een.37.1360778041452; Wed, 13 Feb 2013 09:54:01 -0800 (PST) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id q5sm74428044eeo.17.2013.02.13.09.53.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Feb 2013 09:54:00 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <473C0020-09E7-40F8-A21E-D735C4CEA068@gmail.com> Date: Wed, 13 Feb 2013 19:53:58 +0200 Content-Transfer-Encoding: 7bit Message-Id: <8F1950C5-9346-4D21-9197-454478844D29@gmail.com> References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> <473C0020-09E7-40F8-A21E-D735C4CEA068@gmail.com> To: "radext@ietf.org" , Jouni Korhonen , Benoit Claise X-Mailer: Apple Mail (2.1499) Cc: Barry Leiba Subject: Re: [radext] please check draft-ietf-radext-radius-extensions-11 was Re: Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 17:54:07 -0000 Folks, I take the silence as a sign of agreement. The document is good to move forward on the IESG process. - Jouni On Feb 6, 2013, at 6:42 PM, Jouni Korhonen wrote: > > Folks, > > Everybody has already seen the proposal from Barry - thanks for it ;) > > So lets make it official. Since we all have seen the changes and the > discussion that lead to those, we should be OK with a one week review > time. Every WG member is encouraged to verify the latest -11 version > of the I-D whether the _changes_ are from -09. This is not a place for > new material etc. > > Express your OK/NOK/opinion by 13th Feb. If everything is fine, our > AD can do the required steps regarding IESG telechat agenda and we > are one step closer to publication. > > - Jouni & Mauricio > > > > > On Feb 3, 2013, at 4:49 AM, Barry Leiba wrote: > >>>> I'll go through the diffs between -09 and -11 now, while I wait for my >>>> flight to HKG, and double-check that we're all set on the other >>>> points. >>> >>> Verified. Please make any further changes that my last message moves >>> you to, and then make sure the working group is OK with the changes. >> >> FWIW, my suggestion: >> >> 1. Alan posts a -12 version if he has further changes. >> 2. Alan posts a message to the radext list, saying that he's made >> quite a bunch of changes in response to IESG Evaluation, and the WG >> should review them. Include a URL for the diff between -09 and -12 >> (or -11). >> 3. The chairs post a message to the radext list asking for any >> objections to the changes to be posted by, say, 15 Feb. The chairs >> might specifically note that this is a call for review of the changes >> only. >> 4. Benoit sticks the document on the 21 Feb telechat agenda (and >> remember to go back afterward and remove the "returning item" flag). >> I suggest doing this now; no need to wait. >> 5. When 15 Feb rolls around, Benoit changes the status back to "IESG >> Evaluation". >> >> Of course, this all assumes no significant objections from the WG, but >> you all know how to deal with that if it happens. :-) >> >> Barry >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From bclaise@cisco.com Wed Feb 13 15:09:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8727A21F8488 for ; Wed, 13 Feb 2013 15:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.548 X-Spam-Level: X-Spam-Status: No, score=-10.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgGupczYNLCV for ; Wed, 13 Feb 2013 15:09:51 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 46D8821F8480 for ; Wed, 13 Feb 2013 15:09:51 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1DN9aae012290; Thu, 14 Feb 2013 00:09:36 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1DN8pFF013686; Thu, 14 Feb 2013 00:09:01 +0100 (CET) Message-ID: <511C1D03.2020707@cisco.com> Date: Thu, 14 Feb 2013 00:08:51 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Jouni Korhonen References: <510BE42B.1060102@deployingradius.com> <510C6D0A.6020503@deployingradius.com> <473C0020-09E7-40F8-A21E-D735C4CEA068@gmail.com> <8F1950C5-9346-4D21-9197-454478844D29@gmail.com> In-Reply-To: <8F1950C5-9346-4D21-9197-454478844D29@gmail.com> Content-Type: multipart/alternative; boundary="------------070505080103010004030001" Cc: "radext@ietf.org" , Barry Leiba Subject: Re: [radext] please check draft-ietf-radext-radius-extensions-11 was Re: Issues with draft-ietf-radext-radius-extensions-09 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:09:52 -0000 This is a multi-part message in MIME format. --------------070505080103010004030001 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Jouni, Thanks for letting me know. The document status justt moved from IESG evaluation/AD follow up to IESG evaluation, and the draft is on the IESG agenda for Feb 21st. Let me point the YES ballot from Barry, along with his comment. *Comment (2013-02-05)* I had an excellent set of exchanges with Alan Dekok, in which he sorted out all my issues (reflected in the -11) version. There remain a couple of minor things we disagree on, but that will happen, and they are minor. Thanks very much to Alan for the quick turnaround and good work. Regards, Benoit > Folks, > > I take the silence as a sign of agreement. The document is good to > move forward on the IESG process. > > - Jouni > > On Feb 6, 2013, at 6:42 PM, Jouni Korhonen wrote: > >> Folks, >> >> Everybody has already seen the proposal from Barry - thanks for it ;) >> >> So lets make it official. Since we all have seen the changes and the >> discussion that lead to those, we should be OK with a one week review >> time. Every WG member is encouraged to verify the latest -11 version >> of the I-D whether the _changes_ are from -09. This is not a place for >> new material etc. >> >> Express your OK/NOK/opinion by 13th Feb. If everything is fine, our >> AD can do the required steps regarding IESG telechat agenda and we >> are one step closer to publication. >> >> - Jouni & Mauricio >> >> >> >> >> On Feb 3, 2013, at 4:49 AM, Barry Leiba wrote: >> >>>>> I'll go through the diffs between -09 and -11 now, while I wait for my >>>>> flight to HKG, and double-check that we're all set on the other >>>>> points. >>>> Verified. Please make any further changes that my last message moves >>>> you to, and then make sure the working group is OK with the changes. >>> FWIW, my suggestion: >>> >>> 1. Alan posts a -12 version if he has further changes. >>> 2. Alan posts a message to the radext list, saying that he's made >>> quite a bunch of changes in response to IESG Evaluation, and the WG >>> should review them. Include a URL for the diff between -09 and -12 >>> (or -11). >>> 3. The chairs post a message to the radext list asking for any >>> objections to the changes to be posted by, say, 15 Feb. The chairs >>> might specifically note that this is a call for review of the changes >>> only. >>> 4. Benoit sticks the document on the 21 Feb telechat agenda (and >>> remember to go back afterward and remove the "returning item" flag). >>> I suggest doing this now; no need to wait. >>> 5. When 15 Feb rolls around, Benoit changes the status back to "IESG >>> Evaluation". >>> >>> Of course, this all assumes no significant objections from the WG, but >>> you all know how to deal with that if it happens. :-) >>> >>> Barry >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > --------------070505080103010004030001 Content-Type: multipart/related; boundary="------------090104050203080501070006" --------------090104050203080501070006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Jouni,

Thanks for letting me know.
The document status justt moved from IESG evaluation/AD follow up to IESG evaluation, and the draft is on the IESG agenda for Feb 21st.
Let me point the YES ballot from Barry, along with his comment.

Comment (2013-02-05) 

I had an excellent set of exchanges with Alan Dekok, in which he sorted out all
my issues (reflected in the -11) version.  There remain a couple of minor
things we disagree on, but that will happen, and they are minor.  Thanks very
much to Alan for the quick turnaround and good work.

Regards, Benoit

Folks,

I take the silence as a sign of agreement. The document is good to
move forward on the IESG process.

- Jouni

On Feb 6, 2013, at 6:42 PM, Jouni Korhonen <jouni.nospam@gmail.com> wrote:


Folks,

Everybody has already seen the proposal from Barry - thanks for it ;)

So lets make it official. Since we all have seen the changes and the
discussion that lead to those, we should be OK with a one week review
time. Every WG member is encouraged to verify the latest -11 version
of the I-D whether the _changes_ are from -09. This is not a place for
new material etc.

Express your OK/NOK/opinion by 13th Feb. If everything is fine, our
AD can do the required steps regarding IESG telechat agenda and we
are one step closer to publication.

- Jouni & Mauricio




On Feb 3, 2013, at 4:49 AM, Barry Leiba <barryleiba@computer.org> wrote:


I'll go through the diffs between -09 and -11 now, while I wait for my
flight to HKG, and double-check that we're all set on the other
points.

Verified.  Please make any further changes that my last message moves
you to, and then make sure the working group is OK with the changes.

FWIW, my suggestion:

1. Alan posts a -12 version if he has further changes.
2. Alan posts a message to the radext list, saying that he's made
quite a bunch of changes in response to IESG Evaluation, and the WG
should review them.  Include a URL for the diff between -09 and -12
(or -11).
3. The chairs post a message to the radext list asking for any
objections to the changes to be posted by, say, 15 Feb.  The chairs
might specifically note that this is a call for review of the changes
only.
4. Benoit sticks the document on the 21 Feb telechat agenda (and
remember to go back afterward and remove the "returning item" flag).
I suggest doing this now; no need to wait.
5. When 15 Feb rolls around, Benoit changes the status back to "IESG
Evaluation".

Of course, this all assumes no significant objections from the WG, but
you all know how to deal with that if it happens.  :-)

Barry
_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext

--------------090104050203080501070006 Content-Type: image/png; name="comment.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="comment.png" iVBORw0KGgoAAAANSUhEUgAAAA4AAAAMCAYAAABSgIzaAAAA/ElEQVQoz6WSO27DMAyG0xym h+gFOvUI3YPMOYS7pkOBTjlBllzD74f8lC3Z1pbZ619RjYOoDYIAIUBAAz99pKjF4tFYOQLP r7ubSTU6nizo63sHIQRa3qKuaxRFgSzLkCQJwjCA53lwtnsbptuUUuj7Hl3XoWk4qqoCy3Ok aYIoiuD7PlzXNeZ/4DCMEPLXWl1Y45isobGewKUFKjWerZw32loiz5m2phqOEQSBDVLfzuf+ BGvzOECSudXzNtpclmCMmRprRjr8fdXVxwBhzNwA75vDDC2tdRB8mQRLKQ1E55f18c1axbWg wmmajGWG7voMc7t3Wa61favmB+KXRaNbDO3XAAAAAElFTkSuQmCC --------------090104050203080501070006-- --------------070505080103010004030001-- From iesg-secretary@ietf.org Wed Feb 13 15:54:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E3121E80A2; Wed, 13 Feb 2013 15:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgV6LougimUJ; Wed, 13 Feb 2013 15:54:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4C421E80BC; Wed, 13 Feb 2013 15:54:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130213235415.23797.44465.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 15:54:15 -0800 Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Protocol Action: 'RADIUS attributes for IPv6 Access Networks' to Proposed Standard (draft-ietf-radext-ipv6-access-16.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:54:17 -0000 The IESG has approved the following document: - 'RADIUS attributes for IPv6 Access Networks' (draft-ietf-radext-ipv6-access-16.txt) as Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access/ Technical Summary The I-D defines additional attributes for various IPv6 access network deployments (be that fixes or mobile network). The attributes complement already existing set of IPv6 attributes defined in e.g., RFC3162 and RFC4818. Furthermore, the I-D clarifies the use of some existing IPv6 related attributes and the relationship of those to the newly defined attributes. Working Group Summary The I-D has been discussed extensively in the RADEXT WG and has reached the overall working group consensus. There was a lengthy discussion regarding the Route-IPv6-Information attribute format and whether it should also contain the rest of the RFC4191 Route Information Option field in addition to the prefix. The WG reached a consensus that the other values are local to router configuration and not retrieved from the RADIUS server. Document Quality There is specific interest from the Broadband Forum to incorporate the attributes defined in this specification into their respective IPv6 standards. AAA Doctors have not reviewed the document yet. There is no need for MIB or other doctorate review. Once the document goes to IETF LC, a review from V6OPS should be requested. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise is the responsible AD From iesg-secretary@ietf.org Wed Feb 13 15:54:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C1821E80B1 for ; Wed, 13 Feb 2013 15:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.234 X-Spam-Level: X-Spam-Status: No, score=-102.234 tagged_above=-999 required=5 tests=[AWL=-0.235, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CjC6mD1kGCPY; Wed, 13 Feb 2013 15:54:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974A721E80A1; Wed, 13 Feb 2013 15:54:15 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40 X-IETF-Draft-string: draft-ietf-radext-ipv6-access X-IETF-Draft-revision: 16 Message-ID: <20130213235415.23797.88482.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2013 15:54:15 -0800 Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Protocol Action: 'RADIUS attributes for IPv6 Access Networks' to Proposed Standard (draft-ietf-radext-ipv6-access-16.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 23:54:17 -0000 The IESG has approved the following document: - 'RADIUS attributes for IPv6 Access Networks' (draft-ietf-radext-ipv6-access-16.txt) as Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access/ Technical Summary The I-D defines additional attributes for various IPv6 access network deployments (be that fixes or mobile network). The attributes complement already existing set of IPv6 attributes defined in e.g., RFC3162 and RFC4818. Furthermore, the I-D clarifies the use of some existing IPv6 related attributes and the relationship of those to the newly defined attributes. Working Group Summary The I-D has been discussed extensively in the RADEXT WG and has reached the overall working group consensus. There was a lengthy discussion regarding the Route-IPv6-Information attribute format and whether it should also contain the rest of the RFC4191 Route Information Option field in addition to the prefix. The WG reached a consensus that the other values are local to router configuration and not retrieved from the RADIUS server. Document Quality There is specific interest from the Broadband Forum to incorporate the attributes defined in this specification into their respective IPv6 standards. AAA Doctors have not reviewed the document yet. There is no need for MIB or other doctorate review. Once the document goes to IETF LC, a review from V6OPS should be requested. Personnel Who is the Document Shepherd? Who is the Responsible Area Director? Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise is the responsible AD From bclaise@cisco.com Wed Feb 13 16:05:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8E4421E80A2 for ; Wed, 13 Feb 2013 16:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.605 X-Spam-Level: X-Spam-Status: No, score=-9.605 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcyZ593v8cge for ; Wed, 13 Feb 2013 16:05:27 -0800 (PST) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 0075821E809B for ; Wed, 13 Feb 2013 16:05:26 -0800 (PST) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1E05OUC017006; Thu, 14 Feb 2013 01:05:26 +0100 (CET) Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r1E04nt7015504; Thu, 14 Feb 2013 01:04:59 +0100 (CET) Message-ID: <511C2A21.4040100@cisco.com> Date: Thu, 14 Feb 2013 01:04:49 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 References: <20130213235415.23797.44465.idtracker@ietfa.amsl.com> In-Reply-To: <20130213235415.23797.44465.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: radext mailing list , radext chair Subject: Re: [radext] Protocol Action: 'RADIUS attributes for IPv6 Access Networks' to Proposed Standard (draft-ietf-radext-ipv6-access-16.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 00:05:28 -0000 Congratulations to the authors and the WG chairs. Regards, Benoit > The IESG has approved the following document: > - 'RADIUS attributes for IPv6 Access Networks' > (draft-ietf-radext-ipv6-access-16.txt) as Proposed Standard > > This document is the product of the RADIUS EXTensions Working Group. > > The IESG contact persons are Benoit Claise and Ronald Bonica. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-radext-ipv6-access/ > > > > > Technical Summary > > The I-D defines additional attributes for various IPv6 > access network deployments (be that fixes or mobile network). > The attributes complement already existing set of IPv6 attributes > defined in e.g., RFC3162 and RFC4818. Furthermore, the I-D clarifies > the use of some existing IPv6 related attributes and the relationship > of those to the newly defined attributes. > > > Working Group Summary > > The I-D has been discussed extensively in the RADEXT WG and has > reached the overall working group consensus. There was a lengthy > discussion regarding the Route-IPv6-Information attribute format > and whether it should also contain the rest of the RFC4191 Route > Information Option field in addition to the prefix. The WG > reached a consensus that the other values are local to router > configuration and not retrieved from the RADIUS server. > > Document Quality > > There is specific interest from the Broadband Forum to incorporate > the attributes defined in this specification into their respective > IPv6 standards. > > AAA Doctors have not reviewed the document yet. There is no need > for MIB or other doctorate review. > > Once the document goes to IETF LC, a review from V6OPS should be > requested. > > Personnel > > Who is the Document Shepherd? Who is the Responsible Area > Director? > > Jouni Korhonen (jouni.nospam@gmail.com) is the document > shepherd. > Benoit Claise is the responsible AD > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > From jouni.nospam@gmail.com Fri Feb 15 04:11:58 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D978521F888C for ; Fri, 15 Feb 2013 04:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHVSCWjCaSBS for ; Fri, 15 Feb 2013 04:11:58 -0800 (PST) Received: from mail-ea0-f174.google.com (mail-ea0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id D7F9521F8887 for ; Fri, 15 Feb 2013 04:11:54 -0800 (PST) Received: by mail-ea0-f174.google.com with SMTP id 1so1292371eaa.33 for ; Fri, 15 Feb 2013 04:11:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=4me7Dhy1a6aHmorecWeDV3flUNzNwZMaKAx1fNIZ25U=; b=BIJl2ss/M/C1BGgtfVVC38jBm88H/zpK12b52EGH02igb6EfGokb/IkSsmt9OGzDaC zkKEciV9lPD2vmPFeuRDxQLwkmXLbFcjCB1xOhC8o0elgIJ4kZ0BfSsKZ9t9KPFu7fTI sTfQEY4pzbgu4lF2HujSdR/OCmrue8N02A4zMjhvWX5rWPzeNKjAn2KvQAv8aslo0bhe MhDjVp3EVlWUD3dBR3A8wq9mkLlaRXcu5CyByTCvLxXQeOyFjdZnZCfqMcyQOFxywg46 N+avbxSXbRmBqcvGgKzEXUpbu/9t+jgiczgx0Va68mHag+C3HQe/OtjopsXVvxq4C5Af RPTA== X-Received: by 10.14.213.199 with SMTP id a47mr7805821eep.31.1360930314010; Fri, 15 Feb 2013 04:11:54 -0800 (PST) Received: from [188.117.15.106] ([188.117.15.106]) by mx.google.com with ESMTPS id q5sm83324844eep.11.2013.02.15.04.11.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 15 Feb 2013 04:11:53 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 15 Feb 2013 14:11:51 +0200 Message-Id: <578A3743-A3D0-4C86-B33A-171D171ACC16@gmail.com> To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Cc: Jouni Korhonen , Mauricio Sanchez Subject: [radext] RADEXT agenda X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 12:11:59 -0000 Folks, We will have 1.5h slot for the RADEXT meeting. If you feel like presenting something, let the chairs know. - Jouni & Mauricio From internet-drafts@ietf.org Mon Feb 18 11:28:31 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFA521F8AB1; Mon, 18 Feb 2013 11:28:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTxdXxDvQP7E; Mon, 18 Feb 2013 11:28:30 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B523521F8B07; Mon, 18 Feb 2013 11:28:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130218192830.22249.82180.idtracker@ietfa.amsl.com> Date: Mon, 18 Feb 2013 11:28:30 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-12.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 19:28:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-12.txt Pages : 68 Date : 2013-02-18 Abstract: The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-12 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-extensions-12 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+radext@trac.tools.ietf.org Wed Feb 20 15:43:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF0421E8037 for ; Wed, 20 Feb 2013 15:43:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lgbPeteCEeE for ; Wed, 20 Feb 2013 15:43:02 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D0ED821E8030 for ; Wed, 20 Feb 2013 15:43:01 -0800 (PST) Received: from localhost ([127.0.0.1]:59743 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U8JJV-0006zM-0F; Thu, 21 Feb 2013 00:43:01 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Wed, 20 Feb 2013 23:43:00 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/133#comment:1 Message-ID: <078.01d3f7385685428d331d16fb9a12da59@trac.tools.ietf.org> References: <063.4294a006136b711f4ca314ecd6c2e84f@trac.tools.ietf.org> X-Trac-Ticket-ID: 133 In-Reply-To: <063.4294a006136b711f4ca314ecd6c2e84f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #133: Additional comments from IEEE 802.11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 23:43:02 -0000 #133: Additional comments from IEEE 802.11 Comment (by bernard_aboba@hotmail.com): I assume that "2.4" here actually means Section 2.14 WLAN-Reason-Code. Here the revised section: 2.14. WLAN-Reason-Code Description The WLAN-Reason-Code Attribute contains information on the reason why a station has been refused network access and has been disassociated or de-authenticated. This can occur due to policy or for reasons related to the user's subscription. A WLAN-Reason-Code Attribute MAY be included within an Access- Reject or Disconnect-Request packet. Upon receipt of an Access- Reject or Disconnect-Request packet containing a WLAN-Reason-Code Attribute, the WLAN-Reason-Code value is copied by the Access Point into the Reason Code field of a Disassociation or Deauthentication frame (see clause 8.3.3.4 and 8.3.3.12 respectively in [IEEE- 802.11]), which is subsequently transmitted to the station. In order to provide information within an Accounting-Request on why a station has been disassociated or de- authenticated, the Acct-Termination-Cause Attribute is used, rather than the WLAN-Reason-Code Attribute. A summary of the WLAN-Reason-Code Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Value +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code TBD13 Length 4 Value The Value field is a 32-bit unsigned integer drawn from Table 8-36 (Reason Codes) in clause 8.4.1.7 of [IEEE-802.11]. The Reason Codes values for public Wi-Fi access networks and the corresponding additional values of the Acct-Terminate-Cause Attribute are given below: Reason Acct- Description Code Terminate- Value Cause 1 24 Unspecified reason 27 25 Disassociated because session terminated by service provider request 28 26 Disassociated because of lack of service provider roaming agreement 29 27 Disassociated for unspecified, QoS-related reason 30 28 Requested service rejected because of service provider cipher suite or AKM requirement 31 29 Requested service not authorized in this location -- ----------------------------------+---------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com dstanley1389@gmail.com | Status: new Type: defect | Milestone: milestone1 Priority: major | Version: 1.0 Component: ieee802ext | Resolution: Severity: Active WG Document | Keywords: | ----------------------------------+---------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Feb 20 16:02:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A58721F8C55 for ; Wed, 20 Feb 2013 16:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E39MVsNMyvbM for ; Wed, 20 Feb 2013 16:02:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id C58B421F8C54 for ; Wed, 20 Feb 2013 16:02:15 -0800 (PST) Received: from localhost ([127.0.0.1]:33791 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U8Jby-0002pb-Oq; Thu, 21 Feb 2013 01:02:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 21 Feb 2013 00:02:06 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/131#comment:1 Message-ID: <074.95f5f67ecf34666df3ef123f947383b0@trac.tools.ietf.org> References: <059.5fa64705b71e550efc23f1a0377cbdc7@trac.tools.ietf.org> X-Trac-Ticket-ID: 131 In-Reply-To: <059.5fa64705b71e550efc23f1a0377cbdc7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20130221000215.C58B421F8C54@ietfa.amsl.com> Resent-Date: Wed, 20 Feb 2013 16:02:15 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #131: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:02:16 -0000 #131: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext Comment (by bernard_aboba@hotmail.com): Here is the new table in Section 2.14: Reason Acct- Description Code Terminate- Value Cause 1 24 Unspecified reason 23 25 IEEE 802.1X authenticated failed 27 26 Disassociated because session terminated by service provider request 28 27 Disassociated because of lack of service provider roaming agreement 29 28 Requested service rejected because of service provider cipher suite or AKM requirement 30 29 Requested service not authorized in this location 32 30 Disassociated for unspecified, QoS-related reason -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | ieee802ext@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: Severity: In WG Last | Resolution: Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Feb 20 16:02:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266AF21E804B for ; Wed, 20 Feb 2013 16:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTHu-X0lPQA8 for ; Wed, 20 Feb 2013 16:02:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9957E21E803C for ; Wed, 20 Feb 2013 16:02:26 -0800 (PST) Received: from localhost ([127.0.0.1]:33857 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U8JcC-0002xX-Ru; Thu, 21 Feb 2013 01:02:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 21 Feb 2013 00:02:20 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/131#comment:2 Message-ID: <074.45c41f42b64b1ef4779e7b9863ea618a@trac.tools.ietf.org> References: <059.5fa64705b71e550efc23f1a0377cbdc7@trac.tools.ietf.org> X-Trac-Ticket-ID: 131 In-Reply-To: <059.5fa64705b71e550efc23f1a0377cbdc7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20130221000226.9957E21E803C@ietfa.amsl.com> Resent-Date: Wed, 20 Feb 2013 16:02:26 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #131: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:02:27 -0000 #131: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext Changes (by bernard_aboba@hotmail.com): * status: new => closed * version: => 1.0 * resolution: => fixed -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | ieee802ext@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Feb 20 16:02:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA59D21F8C5D for ; Wed, 20 Feb 2013 16:02:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkKYOwUmzn2S for ; Wed, 20 Feb 2013 16:02:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6510D21F8C5B for ; Wed, 20 Feb 2013 16:02:53 -0800 (PST) Received: from localhost ([127.0.0.1]:33992 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U8Jci-0005sT-OU; Thu, 21 Feb 2013 01:02:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 21 Feb 2013 00:02:52 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/133#comment:2 Message-ID: <078.2d29af039bb5ce1dc367712ba9eb547a@trac.tools.ietf.org> References: <063.4294a006136b711f4ca314ecd6c2e84f@trac.tools.ietf.org> X-Trac-Ticket-ID: 133 In-Reply-To: <063.4294a006136b711f4ca314ecd6c2e84f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #133: Additional comments from IEEE 802.11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:02:54 -0000 #133: Additional comments from IEEE 802.11 Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- ----------------------------------+---------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com dstanley1389@gmail.com | Status: closed Type: defect | Milestone: milestone1 Priority: major | Version: 1.0 Component: ieee802ext | Resolution: fixed Severity: Active WG Document | Keywords: | ----------------------------------+---------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Feb 20 17:39:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A61021F84B9 for ; Wed, 20 Feb 2013 17:39:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kH-0Wndb0upo for ; Wed, 20 Feb 2013 17:39:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8F221F84B6 for ; Wed, 20 Feb 2013 17:39:31 -0800 (PST) Received: from localhost ([127.0.0.1]:43060 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U8L8F-0000O4-2I; Thu, 21 Feb 2013 02:39:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 21 Feb 2013 01:39:31 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/130#comment:2 Message-ID: <075.09e8952f8b75d5280246ebe7c02c6c4f@trac.tools.ietf.org> References: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> X-Trac-Ticket-ID: 130 In-Reply-To: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #130: Dan's Review X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:39:33 -0000 #130: Dan's Review Comment (by bernard_aboba@hotmail.com): I have added the following paragraphs to the Security Considerations section: While it is possible for a RADIUS server to make decisions on whether to Accept or Reject an Access-Request based on the values of the WLAN-Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite, WLAN-Group- Mgmt-Cipher and WLAN-RF-Band Attributes the value of doing this is limited. In general, an Access-Reject should not be necessary, except where Access Points and Stations are misconfigured so as to enable connections to be made with unacceptable values. Rather than rejecting access on an ongoing basis, users would be better served by fixing the misconfiguration. Where access does need to be rejected, the user should be provided with an indication of why the problem has occurred, or else they are likely to become frustrated. For example, if the values of the WLAN- Pairwise-Cipher, WLAN-Group-Cipher, WLAN-AKM-Suite or WLAN-Group- Mgmt-Cipher Attributes included in the Access-Request are not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 29 (Requested service rejected because of service provider cipher suite or AKM requirement) SHOULD be returned in the Access-Reject. Similarly, if the value of the WLAN-RF-Band Attribute included in the Access-Request is not acceptable to the RADIUS server, then a WLAN-Reason-Code Attribute with a value of 11 (Disassociated because the information in the Supported Channels element is unacceptable) SHOULD be returned in the Access-Reject. -- ---------------------------------+---------------------------------------- Reporter: dharkins@lounge.org | Owner: bernard_aboba@hotmail.com Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: Keywords: | ---------------------------------+---------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Feb 20 17:39:48 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4387221E8041 for ; Wed, 20 Feb 2013 17:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+FnpwZqqgIy for ; Wed, 20 Feb 2013 17:39:47 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id BC7D521F84C0 for ; Wed, 20 Feb 2013 17:39:47 -0800 (PST) Received: from localhost ([127.0.0.1]:43072 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U8L8V-0001vF-3Y; Thu, 21 Feb 2013 02:39:47 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 21 Feb 2013 01:39:47 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/130#comment:3 Message-ID: <075.066d38ede2294b1c4d5595ece6aab751@trac.tools.ietf.org> References: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> X-Trac-Ticket-ID: 130 In-Reply-To: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #130: Dan's Review X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:39:48 -0000 #130: Dan's Review Changes (by bernard_aboba@hotmail.com): * status: new => closed * resolution: => fixed -- ---------------------------------+---------------------------------------- Reporter: dharkins@lounge.org | Owner: bernard_aboba@hotmail.com Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------+---------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Wed Feb 20 18:17:04 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD4A721E805E; Wed, 20 Feb 2013 18:17:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wPky9J7dihud; Wed, 20 Feb 2013 18:17:04 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F4E721E8064; Wed, 20 Feb 2013 18:17:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130221021704.18718.81995.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 18:17:04 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ieee802ext-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 02:17:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : RADIUS Attributes for IEEE 802 Networks Author(s) : Bernard Aboba Jouni Malinen Paul Congdon Joseph Salowey Mark Jones Filename : draft-ietf-radext-ieee802ext-04.txt Pages : 28 Date : 2013-02-20 Abstract: RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as clarifications on the usage of the EAP- Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ieee802ext-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ieee802ext-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bernard_aboba@hotmail.com Wed Feb 20 18:56:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9711321F87AF for ; Wed, 20 Feb 2013 18:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.231 X-Spam-Level: X-Spam-Status: No, score=-101.231 tagged_above=-999 required=5 tests=[AWL=-0.933, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46NS14mdEOeY for ; Wed, 20 Feb 2013 18:56:23 -0800 (PST) Received: from blu0-omc3-s17.blu0.hotmail.com (blu0-omc3-s17.blu0.hotmail.com [65.55.116.92]) by ietfa.amsl.com (Postfix) with ESMTP id AB90121F863B for ; Wed, 20 Feb 2013 18:56:23 -0800 (PST) Received: from BLU002-W187 ([65.55.116.74]) by blu0-omc3-s17.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Feb 2013 18:56:23 -0800 X-EIP: [E6sm3h1FMM3IGEnyp0nYlzgft65wtSLc] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2a1cc21b-d1f3-4e29-a8eb-69d3754845d0_" From: Bernard Aboba To: Benoit Claise , "draft-ietf-radext-ieee802ext@tools.ietf.org" Date: Wed, 20 Feb 2013 18:56:23 -0800 Importance: Normal In-Reply-To: <511A6613.9090206@cisco.com> References: , <511A6613.9090206@cisco.com> MIME-Version: 1.0 X-OriginalArrivalTime: 21 Feb 2013 02:56:23.0391 (UTC) FILETIME=[086E8EF0:01CE0FDF] Cc: "radext@ietf.org" Subject: Re: [radext] Additional comments on draft-ietf-radext-ieee802ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 02:56:24 -0000 --_2a1cc21b-d1f3-4e29-a8eb-69d3754845d0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have submitted an -04 version of the document that I believe addresses th= e outstanding issues. Comments welcome.=20 Date: Tue=2C 12 Feb 2013 16:56:03 +0100 From: bclaise@cisco.com To: draft-ietf-radext-ieee802ext@tools.ietf.org CC: radext@ietf.org Subject: Re: [radext] Additional comments on draft-ietf-radext-ieee802ext-0= 3 =0A= =0A= =0A= =0A= =0A= Dear authors=2C =0A= =20 =0A= Can you please answer Dorothy's message=2C and progress this draft. =0A= Keep in mind that you pushed for a short deadline in the charter: =0A= Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed=0A= Standard RFC =0A= And I even recall that you wanted "Nov 2012"=2C and I pushed back=0A= =3B-) =0A= =20 =0A= Regards=2C Benoit =0A= =0A= Here are some additional comments from 802.11=0A= members=2C gathered at the IEEE 802.11 meeting=2C Nov=0A= 14=2C 2012. =0A= =20 =0A= Dorothy Stanley =0A= ---------------- =0A= 1. in 2.4=2C change from=20 =0A= " the reason why a station has been dissaciated." =0A= to =0A= "the=0A= reason=0A= why a station was refused network access=0A= and has been disassociated" =0A= =20 =0A= 2. In 2.4=2C delete "were=0A= added by the IEEE 802.11u-2011 amendment"=3B as the reference=0A= 802.11-2012 includes the 11u amendment. =0A= =20 =0A= 3. In 2.4 insert "(Reason Codes)" after "Table 8-36" as an=0A= additional guide for the reader. =0A= 4.=0A= At the end of 2.14 and at the end of section 5=2C add=0A= two additional =0A= reason codes=2C "1 Unspecified reason" and "29 Disassociated for= =0A= unspecified=2C QoS-related reason"=2C renumbering intermediate=0A= values.=0A= =0A= =0A= 5.=0A= In section 3=2C in the entry for WLAN-Reason-Code=2C=0A= change the Acct-Req value from "0" to "0-1". The reason code=0A= could be included in the accounting record sent by the RADIUS=0A= client for diagnostic purposes. =0A= =0A= =0A= =20 =0A= =0A= =20 =0A= =0A= =20 =0A= =0A= =20 =0A= _______________________________________________=0A= radext mailing list=0A= radext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/radext=0A= =0A= =0A= =20 = --_2a1cc21b-d1f3-4e29-a8eb-69d3754845d0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have submitted an -04 version = of the document that I believe addresses the outstanding issues.
Comment= s welcome.

Date: Tue=2C 12 Feb 2013 16:56:03 +0100
From: bclaise@cisco.c= om
To: draft-ietf-radext-ieee802ext@tools.ietf.org
CC: radext@ietf.or= g
Subject: Re: [radext] Additional comments on draft-ietf-radext-ieee802= ext-03

=0A= =0A= =0A= =0A= =0A=
Dear authors=2C
=0A=
=0A= Can you please answer Dorothy's message=2C and progress this draft.=0A= Keep in mind that you pushed for a short deadline in the charter:
= =0A=  =3B =3B =3B Dec 2012 IEEE 802 Attributes I-D submitted a= s a Proposed=0A= Standard RFC
=0A= And I even recall that you wanted "Nov 2012"=2C and I pushed back=0A= =3B-)
=0A=
=0A= Regards=2C Benoit
=0A=
=0A=
Here are some additional comments from 802.11=0A= members=2C gathered at the IEEE 802.11 meeting=2C Nov=0A= 14=2C 2012.
=0A=
=0A= Dorothy Stanley
=0A= ----------------
=0A= 1. in 2.4=2C change from
=0A= " =3B the reason why a station has been dissaciated."
=0A= to
=0A= "the=0A= reason=0A= why a station was refused network access=0A= and has been disassociated"
=0A=
=0A= 2. In 2.4=2C delete "were= =0A= added by the IEEE 802.11u-2011 amendment"=3B as the reference=0A= 802.11-2012 includes the 11u amendment.
=0A=
=0A= 3. In 2.4 insert "(Reason Codes)" after "Table 8-36" as an=0A= additional guide for the reader.
=0A= 4.=0A= At the end of 2.14 and at the end of section 5=2C add=0A= two additional
=0A= reason codes=2C "1 Unspecified reason" and "29 Disassociated for= =0A= unspecified=2C QoS-related reason"=2C renumbering intermediate=0A= values.
=0A= =0A=
=0A= 5.=0A= In section 3=2C in the entry for WLAN-Reason-Code=2C=0A= change the Acct-Req value from "0" to "0-1". The reason code=0A= could be included in the accounting record sent by the RADIUS=0A= client for diagnostic purposes.
=0A=
=0A= =0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A= 
_______________________________________________=0A=
radext mailing list=0A=
ra=
dext@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/ra=
dext=0A=
=0A=
=0A=
= --_2a1cc21b-d1f3-4e29-a8eb-69d3754845d0_-- From alex@um.es Fri Feb 22 03:46:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8014221F8EAE for ; Fri, 22 Feb 2013 03:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.191 X-Spam-Level: X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWKgF-Q8zbJz for ; Fri, 22 Feb 2013 03:46:53 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id C6D2121F8EAB for ; Fri, 22 Feb 2013 03:46:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 565B94C448 for ; Fri, 22 Feb 2013 12:46:51 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TgvqR2LL0Qh0 for ; Fri, 22 Feb 2013 12:46:51 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id E20404C42A for ; Fri, 22 Feb 2013 12:46:50 +0100 (CET) Message-ID: <51275AA9.4070306@um.es> Date: Fri, 22 Feb 2013 12:46:49 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130109 Thunderbird/17.0.2 MIME-Version: 1.0 To: radext@ietf.org References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 11:46:53 -0000 > I support adopting the previous version of this draft > (draft-perez-radext-radius-fragmentation-04) and would support adopting > the current version (draft-perez-radext-radius-fragmentation-05) if a > mechanism was added for fragmented information in access-request prior > to authentication. That is, I disagree with one of the changes the > authors made between 04 and 05. Hi Sam, we have been discussing this aspect internally, and we have concluded that the support of fragmentation prior to authentication will be re-incorporated into the next version of the document, though it will be noted that it may have the potential to allow DoS attacks. Best regards, Alejandro > > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From internet-drafts@ietf.org Mon Feb 25 06:15:03 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C2921F9212; Mon, 25 Feb 2013 06:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nKKGo0Gf+YP; Mon, 25 Feb 2013 06:15:02 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88A5321F92C7; Mon, 25 Feb 2013 06:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225141502.6085.40721.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 06:15:02 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-radius-extensions-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:15:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : Remote Authentication Dial In User Service (RADIUS) Prot= ocol Extensions Author(s) : Alan DeKok Avi Lior Filename : draft-ietf-radext-radius-extensions-13.txt Pages : 67 Date : 2013-02-25 Abstract: The Remote Authentication Dial In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes which can carry more than 253 octets of data. This document defines changes to RADIUS which address all of the above problems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-radius-extensions-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-radius-extensions-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+radext@trac.tools.ietf.org Mon Feb 25 06:27:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD7F21F933F for ; Mon, 25 Feb 2013 06:27:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BVSnbd8CpSG for ; Mon, 25 Feb 2013 06:27:00 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 95B8821F933E for ; Mon, 25 Feb 2013 06:26:59 -0800 (PST) Received: from localhost ([127.0.0.1]:58703 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U9z18-0001xH-Ex; Mon, 25 Feb 2013 15:26:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 25 Feb 2013 14:26:58 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/130#comment:4 Message-ID: <075.ee4f6f2da59a9123f994e821dba78c13@trac.tools.ietf.org> References: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> X-Trac-Ticket-ID: 130 In-Reply-To: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #130: Dan's Review X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:27:00 -0000 #130: Dan's Review Comment (by bernard_aboba@hotmail.com): comments on specific sections section 2.1 suggest making that the ":" delimiter exist even when no MAC address is added. Make the example be ":AP1". This will make for easier parsing. [BA] Done. section 2.2, 2.3 and 2.4 what does the NAS do if it requested the attr but didn't get one? I presume nothing but if there are guidelines on the NAS putting the attr in a Request then there should be guidelines on what to do when it gets back in an Accept that doesn't have it. What does a NAS do if it gets one when when it didn't ask for one? [BA] Text now says that the NAS ignores the attribute if it didn't ask for it. When one is requested and it isn't returned, the Access-Accept is treated as an Access-Reject. section 2.3 how are mutliple names demarked? Should there be a sub-structure or a delimiter (which cannot be part of the EAP-Peer-Id)? [BA] Only one name is included per attribute so there is no need for a sub-structure. section 2.9 what does a non-robust implemention do? What's wrong with just saying that "an implementation SHOULD..." or even "an implementation MUST support the field as undistinguished octets"? If it's a SHOULD then explain the conditions under which an implementation can legitimately not treat them that way. [BA] Text now says MUST. section 2.12 I am unwilling to pay 44 swiss francs to get ISO-14962-1997 to figure this out for myself, so how is a string encoded by that standard? Is there a length indication in the encodng to allow for multiple languages to be properly demarked and parsed? If not then I think there needs to be some delimiter between them. [BA] I believe it is a three letter code, so no delimiter is needed. secton 2.15, 2.16 and 2.17 what is a server supposed to do with this information? Reject the authentication because it used a different cipher/AKM suite? [BA] My assumption is that it is primarily for accounting purposes. While it could reject the authentication, that seems sub-optimal. section 2.18 where is "table ?" in IEEE 802.11-2012? [BA] Added reference to the correct table in IEEE 802.11-2012. misc. comments I question the validity of using ciphersuite information and RF band to decide whether to accept/deny an authentication. If the AP is beaconing out support for a cipher that is not acceptable for RADIUS authentication by any user then it indicates a configuration error on the AP. Why on earth would one prohibit a user from a certain band that the AP is operating in? I think there should be some text around the utility of these attrs. If you're gonna limit/prohibit people to/from "TV white space" then what channels in that space? Again, why? [BA] I have material to the security considerations section indicating why this is somewhat silly. The security considerations are pretty weak. Which of these new attributes need channel binding? What are the implications of not doing channel bindings with these attributes? [BA] Looking at these attributes, I could not find any that would be of value in crypto-binding. regards, Dan. -- ---------------------------------+---------------------------------------- Reporter: dharkins@lounge.org | Owner: bernard_aboba@hotmail.com Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------+---------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Feb 25 06:33:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2956221F934F for ; Mon, 25 Feb 2013 06:33:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.52 X-Spam-Level: X-Spam-Status: No, score=-101.52 tagged_above=-999 required=5 tests=[AWL=-1.221, BAYES_00=-2.599, MANGLED_TOOL=2.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b4h40UXkvNZ for ; Mon, 25 Feb 2013 06:33:49 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 6B1F221F934D for ; Mon, 25 Feb 2013 06:33:49 -0800 (PST) Received: from localhost ([127.0.0.1]:59501 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U9z7k-0005Al-P8; Mon, 25 Feb 2013 15:33:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 25 Feb 2013 14:33:48 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/132#comment:2 Message-ID: <081.5d04d1c609408e9aed0e0731ebe6c9c8@trac.tools.ietf.org> References: <066.c2fa1659af9d5ba32a31013b60eed836@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 In-Reply-To: <066.c2fa1659af9d5ba32a31013b60eed836@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: radext@ietf.org Subject: Re: [radext] #132: Additional comments from IEEE 802.11 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:33:50 -0000 #132: Additional comments from IEEE 802.11 Comment (by bernard_aboba@hotmail.com): in 2.4, change from " the reason why a station has been dissaciated." to "the reason why a station was refused network access and has been disassociated" [BA] Done. In 2.4, delete "were added by the IEEE 802.11u-2011 amendment"; as the reference 802.11-2012 includes the 11u amendment. In 2.4 insert "(Reason Codes)" after "Table 8-36" as an additional guide for the reader. At the end of 2.14 and at the end of section 5, add two additional [BA] Done. reason codes, "1 Unspecified reason" and "29 Disassociated for unspecified, QoS-related reason", renumbering intermediate values. In section 3, in the entry for WLAN-Reason-Code, change the Acct-Req value from "0" to "0-1". The reason code could be included in the accounting record sent by the RADIUS client for diagnostic purposes. [BA] I have changed the table in Section 3 to enable WLAN-Reason-Code to be sent in an Accounting-Request. Given that change, it no longer makes sense to also allocate values of Acc-Terminate-Cause. As a result, we don't really need the tables of WLAN-Reason-Code values. Since these values are defined by IEEE 802.11, and allocation is handled by the IEEE RAC, IANA shouldn't even need a registry for them. -- -------------------------------------+------------------------------------- Reporter: | Owner: bernard_aboba@hotmail.com | bernard_aboba@hotmail.com Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: Active WG Document | Resolution: duplicate Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Feb 25 06:37:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4D821F9354 for ; Mon, 25 Feb 2013 06:37:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbFS8P0Mgfvl for ; Mon, 25 Feb 2013 06:37:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEDD21F9350 for ; Mon, 25 Feb 2013 06:37:32 -0800 (PST) Received: from localhost ([127.0.0.1]:59861 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U9zBG-0007jP-IM; Mon, 25 Feb 2013 15:37:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 25 Feb 2013 14:37:26 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/131#comment:3 Message-ID: <074.72b0e67496d6e2a3f0e5622aecba4522@trac.tools.ietf.org> References: <059.5fa64705b71e550efc23f1a0377cbdc7@trac.tools.ietf.org> X-Trac-Ticket-ID: 131 In-Reply-To: <059.5fa64705b71e550efc23f1a0377cbdc7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, bernard_aboba@hotmail.com, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: bernard_aboba@hotmail.com, j@w1.fi, jsalowey@cisco.com, mark@azu.ca, paul_congdon@hp.com Resent-Message-Id: <20130225143732.8BEDD21F9350@ietfa.amsl.com> Resent-Date: Mon, 25 Feb 2013 06:37:32 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #131: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:37:34 -0000 #131: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext Comment (by bernard_aboba@hotmail.com): [BA] Since WLAN-Reason-Code is now allowed in Accounting Requests, there is no need to also support Acct-Terminate-Cause values. This in turn means that we can allow any value of WLAN-Reason-Code defined by IEEE 802.11 to be used, without an IANA allocation, since the IEEE RAC is handling allocation of these values. Therefore I don't think we need to explicitly add these values to the document -- since they are defined in IEEE 802.11-2012, that is all we need. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | ieee802ext@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From stefan.winter@restena.lu Mon Feb 25 06:37:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C702A21F935B for ; Mon, 25 Feb 2013 06:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZT-Ki0ctXj5c for ; Mon, 25 Feb 2013 06:37:36 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C42CA21F935A for ; Mon, 25 Feb 2013 06:37:35 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5D05F10584 for ; Mon, 25 Feb 2013 15:37:34 +0100 (CET) Received: from [IPv6:2001:a18:1:8:b10f:b762:565f:f0e5] (unknown [IPv6:2001:a18:1:8:b10f:b762:565f:f0e5]) by smtprelay.restena.lu (Postfix) with ESMTPS id 5178610583 for ; Mon, 25 Feb 2013 15:37:34 +0100 (CET) Message-ID: <512B772A.5050708@restena.lu> Date: Mon, 25 Feb 2013 15:37:30 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org>, <50F93987.4090302@restena.lu> <50F93E97.5070202@restena.lu>, In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CJTGBPNTOFCLFEIXFSRS" X-Virus-Scanned: ClamAV Subject: Re: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:37:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CJTGBPNTOFCLFEIXFSRS Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > But we do need to be clear about what is expected in the User-Name > attribute (e.g. U-labels, not A-labels). The text currently states: 2.3.1. Input For RADIUS Authentication and RADIUS Accounting server discovery, input I to the algorithm is the RADIUS User-Name attribute with content of the form "user@realm"; I think this is as specific as we can get; the content of that attribute is unvetted end-user input. The algorithm merely needs to be robust enough not to choke on invalid inputs. If the user sent garbage or a format that can not be understood by name resolution libraries - too bad; the algorithm will terminate with an empty result (step 4). If he sent something that was well-formed enough to be resolvable by name resolution - fine. The algorithm will then yield a target to forward to, or an empty set if no target exists. Greetings, Stefan >=20 >> From: hartmans@painless-security.com >> To: stefan.winter@restena.lu >> Date: Fri, 18 Jan 2013 15:14:20 -0500 >> CC: radext@ietf.org >> Subject: Re: [radext] #147: Internationalization and > draft-ietf-radext-dynamic-discovery >> >> >>>>> "Stefan" =3D=3D Stefan Winter writes:= >> >> Stefan> Hi again, >> Stefan> It is expected that in most cases, the label used for >> Stefan> the records is the DNS A-label representation of the literal >> Stefan> realm name for which the server is the authoritative RADIUS >> Stefan> server (i.e. the realm name after conversion according to >> Stefan> section 5 of [RFC5891]). >> >> I think that's good. >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2CJTGBPNTOFCLFEIXFSRS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlErdy4ACgkQ+jm90f8eFWbIGACdFJtW3NT4XEQiC2ckazu+FqUl NMYAoIp7Jg5LNoE4hY/ibwMImpvb8A6/ =VecU -----END PGP SIGNATURE----- ------enig2CJTGBPNTOFCLFEIXFSRS-- From trac+radext@trac.tools.ietf.org Mon Feb 25 06:38:41 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1EF21F920F for ; Mon, 25 Feb 2013 06:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tgSche5IimD2 for ; Mon, 25 Feb 2013 06:38:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 2A74121F9315 for ; Mon, 25 Feb 2013 06:38:41 -0800 (PST) Received: from localhost ([127.0.0.1]:59904 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U9zCR-0007lH-5Z; Mon, 25 Feb 2013 15:38:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 25 Feb 2013 14:38:39 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/147#comment:1 Message-ID: <081.657c0edd672ea13d3b43763875f016c3@trac.tools.ietf.org> References: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org> X-Trac-Ticket-ID: 147 In-Reply-To: <066.7bde70b0716a3259e78af5bfff386bfa@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mikem@open.com.au, stefan.winter@restena.lu Resent-Message-Id: <20130225143841.2A74121F9315@ietfa.amsl.com> Resent-Date: Mon, 25 Feb 2013 06:38:41 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #147: Internationalization and draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:38:41 -0000 #147: Internationalization and draft-ietf-radext-dynamic-discovery Changes (by stefan.winter@restena.lu): * status: new => closed * resolution: => fixed Comment: New text was provided in -06 for both snippets. I believe all issues raised in this ticket are addressed by the new text. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- bernard_aboba@hotmail.com | dynamic-discovery@tools.ietf.org Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: radext From mark@azu.ca Mon Feb 25 06:55:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1831321F937C for ; Mon, 25 Feb 2013 06:55:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.976 X-Spam-Level: X-Spam-Status: No, score=-4.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsXMJPvYeG5i for ; Mon, 25 Feb 2013 06:55:13 -0800 (PST) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 02BEF21F9372 for ; Mon, 25 Feb 2013 06:55:11 -0800 (PST) Received: by mail-lb0-f170.google.com with SMTP id ge1so2322009lbb.15 for ; Mon, 25 Feb 2013 06:55:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type:x-gm-message-state; bh=DkOWovCMY9Ekh3sNIZkE76dEgHxOAnwRZWp6DI3Srcg=; b=h+k0KJGG27HGrCbr8jlhvXzg+VFAbITpyzISclZ2fx1HyeKW9G6OQ+VMUwIEwyCUeT +pz7AzNsIlMf8K9ak8TPBiWAgk0W7HssVGbOXkBbSh1pjFUVcgrkEKfxybaWV6nra4Bn M2/9bljS7CXM85eywU9pr6Am+og1/XAiyMqtzZqCUgeeyRkCMO8NRrVF8n0MnhP7755I 1fpv6rQdZBKB1uhmJurM7NYaCRP3p23gHoQX3RaHpMzjXL37KdOqnkhmP8CrxmS0L5xD /ginnzb0hHW4xyORJ39lzA9aZeTJTZB9Uks8myHB7f28oKPVLf52oiH9VtRh361wuIQA w2yQ== MIME-Version: 1.0 X-Received: by 10.152.111.67 with SMTP id ig3mr10166825lab.41.1361804110315; Mon, 25 Feb 2013 06:55:10 -0800 (PST) Received: by 10.112.10.229 with HTTP; Mon, 25 Feb 2013 06:55:10 -0800 (PST) In-Reply-To: <075.ee4f6f2da59a9123f994e821dba78c13@trac.tools.ietf.org> References: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> <075.ee4f6f2da59a9123f994e821dba78c13@trac.tools.ietf.org> Date: Mon, 25 Feb 2013 09:55:10 -0500 Message-ID: From: Mark Jones To: radext@ietf.org Content-Type: multipart/alternative; boundary=f46d04088f173fe5f004d68dba0d X-Gm-Message-State: ALoCoQnbt3ltv+9x6Gym+GlGrfo69KJ34VoDXLplwluH4AyTbW4vM3hcwFpC+m3gZeJU/RqrXoJO Subject: Re: [radext] #130: Dan's Review X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 14:55:14 -0000 --f46d04088f173fe5f004d68dba0d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Dan, I've expanded on Bernard's response for the 802.11u AVPs. Regards Mark On Mon, Feb 25, 2013 at 9:26 AM, radext issue tracker < trac+radext@trac.tools.ietf.org> wrote: > #130: Dan's Review > > > Comment (by bernard_aboba@hotmail.com): > > comments on specific sections > > > section 2.1 > > suggest making that the ":" delimiter exist even when no MAC address > is added. Make the example be ":AP1". This will make for easier parsing. > > [BA] Done. > > > section 2.2, 2.3 and 2.4 > > what does the NAS do if it requested the attr but didn't get one? I > presume nothing but if there are guidelines on the NAS putting the attr = in > a Request then there should be guidelines on what to do when it gets bac= k > in an Accept that doesn't have it. What does a NAS do if it gets one whe= n > when it didn't ask for one? > > [BA] Text now says that the NAS ignores the attribute if it didn't ask f= or > it. When one is requested and it isn't returned, the Access-Accept is > treated as an Access-Reject. > > > section 2.3 > > how are mutliple names demarked? Should there be a sub-structure or = a > delimiter (which cannot be part of the EAP-Peer-Id)? > > [BA] Only one name is included per attribute so there is no need for a > sub-structure. > > section 2.9 > > what does a non-robust implemention do? What's wrong with just sayin= g > that "an implementation SHOULD..." or even "an implementation MUST suppo= rt > the field as undistinguished octets"? If it's a SHOULD then explain the > conditions under which an implementation can legitimately not treat them > that way. > > [BA] Text now says MUST. > > [mj] This was originally a =93SHOULD=94 meaning =93interpret at your own ri= sk=94. However, the draft does not define any structure for this field so there is no legitimate reason to parse it and I agree with tightening it to a MUST. Rev -04 still contains the "robust" qualifier and I think that can be deleted now. > section 2.12 > > I am unwilling to pay 44 swiss francs to get ISO-14962-1997 to figur= e > this out for myself, so how is a string encoded by that standard? Is the= re > a length indication in the encodng to allow for multiple languages to be > properly demarked and parsed? If not then I think there needs to be some > delimiter between them. > > [BA] I believe it is a three letter code, so no delimiter is needed. > > [mj] ISO-14962-1997 essentially documents ASCII so your 44 Swiss francs could be better spent elsewhere. 802.11u has this reference so I carried it forward for consistency. The value encoding is also kept consistent with 802.11u to avoid requiring NAS implementations to do translations. The value is a fixed length 3 octet field in 802.11u hence the =93null=94 paddi= ng required for a two character language code. This AVP contains a single ISO-639 language code so no delimiter is required. Multiple language support at the venue is expressed by including more than one WLAN-Venue-Language AVP in the Access-Request. > secton 2.15, 2.16 and 2.17 > > what is a server supposed to do with this information? Reject the > authentication because it used a different cipher/AKM suite? > > [BA] My assumption is that it is primarily for accounting purposes. Whil= e > it could reject the authentication, that seems sub-optimal. > > section 2.18 > > where is "table ?" in IEEE 802.11-2012? > > [BA] Added reference to the correct table in IEEE 802.11-2012. > > misc. comments > > > I question the validity of using ciphersuite information and RF band > to decide whether to accept/deny an authentication. If the AP is beaconi= ng > out support for a cipher that is not acceptable for RADIUS authenticatio= n > by any user then it indicates a configuration error on the AP. Why on > earth would one prohibit a user from a certain band that the AP is > operating in? I think there should be some text around the utility of > these attrs. > > If you're gonna limit/prohibit people to/from "TV white space" then > what channels in that space? Again, why? > > [BA] I have material to the security considerations section indicating w= hy > this is somewhat silly. > > The security considerations are pretty weak. Which of these new > attributes need channel binding? What are the implications of not doing > channel bindings with these attributes? > > [BA] Looking at these attributes, I could not find any that would be of > value in crypto-binding. > > regards, > > > Dan. > > -- > ---------------------------------+---------------------------------------= - > Reporter: dharkins@lounge.org | Owner: bernard_aboba@hotmail.co= m > Type: defect | Status: closed > Priority: major | Milestone: milestone1 > Component: ieee802ext | Version: 1.0 > Severity: In WG Last Call | Resolution: fixed > Keywords: | > ---------------------------------+---------------------------------------= - > > Ticket URL: < > https://wiki.tools.ietf.org/wg/radext/trac/ticket/130#comment:4> > radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > --f46d04088f173fe5f004d68dba0d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi Dan,

I've expanded on Bernard's respons= e for the 802.11u AVPs.

Regards
Mark
On Mon, Feb 25, 2013 at 9:26 AM, radext issue = tracker <trac+radext@trac.tools.ietf.org> wrot= e:
#130: Dan's Review


Comment (by bernard_aboba@hotm= ail.com):

=A0comments on specific sections


=A0section 2.1

=A0 =A0 =A0suggest making that the ":" de= limiter exist even when no MAC address
=A0is added. Make the example be ":AP1". This will make for easie= r parsing.

=A0[BA] Done.


=A0section 2.2, 2.3 and 2.4

=A0 =A0 =A0what does the NAS do if it requested the= attr but didn't get one? I
=A0presume nothing but if there are guidelines on the NAS putting the attr = in
=A0a Request then there should be guidelines on what to do when it gets bac= k
=A0in an Accept that doesn't have it. What does a NAS do if it gets one= when
=A0when it didn't ask for one?

=A0[BA] Text now says that the NAS ignores the attribute if it didn&#= 39;t ask for
=A0it. =A0When one is requested and it isn't returned, the Access-Accep= t is
=A0treated as an Access-Reject.


=A0section 2.3

=A0 =A0 =A0how are mutliple names demarked? Should there be a sub-structure= or a
=A0delimiter (which cannot be part of the EAP-Peer-Id)?

=A0[BA] Only one name is included per attribute so there is no need f= or a
=A0sub-structure.

=A0section 2.9

=A0 =A0 =A0what does a non-robust implemention do? What's wrong with ju= st saying
=A0that "an implementation SHOULD..." or even "an implementa= tion MUST support
=A0the field as undistinguished octets"? If it's a SHOULD then exp= lain the
=A0conditions under which an implementation can legitimately not treat them=
=A0that way.

=A0[BA] Text now says MUST.


[mj] This was originally a =93SHOULD= =94 meaning =93interpret at your own risk=94. However, the draft does not d= efine any structure for this field so there is no legitimate reason to pars= e it and I agree with tightening it to a MUST. Rev -04 still contains the &= quot;robust" qualifier and I think that can be deleted now.

=A0
=A0section 2.12

=A0 =A0 =A0I am unwilling to pay 44 swiss francs to get ISO-14962-1997 to f= igure
=A0this out for myself, so how is a string encoded by that standard? Is the= re
=A0a length indication in the encodng to allow for multiple languages to be=
=A0properly demarked and parsed? If not then I think there needs to be some=
=A0delimiter between them.

=A0[BA] I believe it is a three letter code, so no delimiter is neede= d.


[mj] ISO-14962= -1997 essentially documents ASCII so your 44 Swiss francs could be better s= pent elsewhere. 802.11u has this reference so I carried it forward for cons= istency. The value encoding is also kept consistent with 802.11u to avoid r= equiring NAS implementations to do translations. The value is a fixed lengt= h 3 octet field in 802.11u hence the =93null=94 padding required for a two = character language code. This AVP contains a single ISO-639 language code s= o no delimiter is required. Multiple language support at the venue is expre= ssed by including more than one WLAN-Venue-Language AVP in the Access-Reque= st.=A0

=A0
=A0secton 2.15, 2.16 and 2.17

=A0 =A0 =A0what is a server supposed to do with thi= s information? Reject the
=A0authentication because it used a different cipher/AKM suite?

=A0[BA] My assumption is that it is primarily for accounting purposes= . While
=A0it could reject the authentication, that seems sub-optimal.

=A0section 2.18

=A0 =A0 =A0where is "table ?" in IEEE 802.11-2012?

=A0[BA] Added reference to the correct table in IEEE 802.11-2012.

=A0 =A0 =A0misc. comments


=A0 =A0 =A0I question the validity of using ciphersuite information and RF = band
=A0to decide whether to accept/deny an authentication. If the AP is beaconi= ng
=A0out support for a cipher that is not acceptable for RADIUS authenticatio= n
=A0by any user then it indicates a configuration error on the AP. Why on =A0earth would one prohibit a user from a certain band that the AP is
=A0operating in? I think there should be some text around the utility of =A0these attrs.

=A0 =A0 =A0If you're gonna limit/prohibit peopl= e to/from "TV white space" then
=A0what channels in that space? Again, why?

=A0[BA] I have material to the security considerations section indica= ting why
=A0this is somewhat silly.

=A0 =A0 =A0The security considerations are pretty weak. Which of these new<= br> =A0attributes need channel binding? What are the implications of not doing<= br> =A0channel bindings with these attributes?

=A0[BA] Looking at these attributes, I could not find any that would = be of
=A0value in crypto-binding.

=A0 =A0 =A0regards,


=A0 =A0 =A0Dan.

--
---------------------------------+----------------------------------------<= br> =A0Reporter: =A0dharkins@lounge.org<= /a> =A0| =A0 =A0 =A0 Owner: =A0bernard_aboba@hotmail.com
=A0 =A0 =A0Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status:= =A0closed
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0| =A0 Milestone: =A0milestone1
Component: =A0ieee802ext =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version: =A01.0
=A0Severity: =A0In WG Last Call =A0 =A0 =A0| =A0Res= olution: =A0fixed
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 |
---------------------------------+----------------------------------------<= br>
Ticket URL: <https://wiki.tools.ietf.org/wg/rad= ext/trac/ticket/130#comment:4>
radext <http://tools.ietf.org/radext/>
_______________________________________________
radext mailing list
radext@ietf.org
= https://www.ietf.org/mailman/listinfo/radext

--f46d04088f173fe5f004d68dba0d-- From stefan.winter@restena.lu Mon Feb 25 07:42:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A34B21F92A4 for ; Mon, 25 Feb 2013 07:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fJG52hxmd19 for ; Mon, 25 Feb 2013 07:42:53 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id E42B921F9325 for ; Mon, 25 Feb 2013 07:42:52 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4E5EC10584 for ; Mon, 25 Feb 2013 16:42:52 +0100 (CET) Received: from [IPv6:2001:a18:1:8:b10f:b762:565f:f0e5] (unknown [IPv6:2001:a18:1:8:b10f:b762:565f:f0e5]) by smtprelay.restena.lu (Postfix) with ESMTPS id 423DE10581 for ; Mon, 25 Feb 2013 16:42:52 +0100 (CET) Message-ID: <512B8678.7030504@restena.lu> Date: Mon, 25 Feb 2013 16:42:48 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <02d201cdf76a$e04625a0$a0d270e0$@augustcellars.com> In-Reply-To: <02d201cdf76a$e04625a0$a0d270e0$@augustcellars.com> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2WECAPWTKXKOVDELKOLHL" X-Virus-Scanned: ClamAV Subject: Re: [radext] Comments on draft-ietf-radext-dynamic-discovery-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:42:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2WECAPWTKXKOVDELKOLHL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > First let me say that I probably don't understand all of the circumstan= ces > that this document is aimed at, so some of my comments may be way off b= ase. The new text for your issue 2 will hopefully give sufficient context. > 1. In the Abstract - it says that "It can be used in conjunction with.= =2E." > From what I have seen, it is only used in conjunction with one or the o= ther, > it cannot be used without one of them being there. Am I wrong? If so = then > suggest "It is used in conjunction with either RADIUS/TLS or RADIUS/DTL= S." Fixed, thanks. > 2. Please fill in some introduction - even if it is as bad as just cop= ying > the abstract. A problem statement about what you are trying to solve w= ould > be even better. How about this text: 1. Introduction RADIUS in all its current transport variants (RADIUS/UDP, RADIUS/TLS, RADIUS/DTLS) requires manual configuration of all peers (clients, servers). Where RADIUS forwarding servers are in use, the number of realms to be forwarded and the corresponding number of servers to configure may be significant. Where new realms with new servers are added or details of existing servers change on a regular basis, maintaining a single monolithic configuration file for all these details may prove too cumbersome to be useful. Furthermore, in cases where a roaming consortium consists of independently working branches, each with their own forwarding servers, and who add or change their realm lists at their own discretion, there is additional complexity in synchronising the changed data across all branches. These situations can benefit significantly from a distributed mechanism for storing realm and server reachability information. This document describes one such mechanism: storage of realm-to- server mappings in DNS. This document does not specify how to verify that server information which was retrieved from DNS was from an authorised party; e.g. an organisation which is not at all part of a given roaming consortium may alter its own DNS records to yield a result for its own realm. RADIUS/TLS and RADIUS/DTLS have their own ways how to verify that a contacted peer is authorised (e.g. by presenting PKIX certificates from a agreed-upon CA). > 3. In section 2.1 - I am unclear what the correct behavior would be if= I > have one user session open and I receive a new user Access-Request mess= age. > Should I re-resolve or use the cached information? That's what the tracking of TTL for results is good for: if a new request comes in, and an existing session to a home server exists, and the TTL for discovering that connection has not expired, then the connection should be re-used. This is (meant to be) expressed in section 2.3.4. Shall I add a forward-reference to 2.3.4 in 2.1? > 4. In section 2.2 - example b - you need to remove the quotes on the l= ast > field of the example. Fixed, thanks. > 5. In section 2.2. - I am lost on terminology - Just after Figure 3 y= ou > say "the label used for". I am unclear in this context what you mean b= y > label. This may be a deficiency of background for me. However are we > talking about the realm in the user name, the field in the SRV or NAPT= R > records? SRV and NAPTR. I've updated the text to be more explicit. > 6. In section 2.3.1 - This is purely personal preference. I find it ha= rd to > locate the "variables" of the algorithm when they are a single characte= r in > text. This is especially true with I as it is visually close to a grea= t > number of other characters. I request they get widened in some fashion= to > be more distinguishable. If you choose to ignore this, I can easily li= ve > with it. I prefer to see if later stages of review find that difficult as well (my choice of O could of course be confused with a 0; that would be bad).= > 7. In section 2.3.1 - not explicitly stated but implied by the pattern= is > that user cannot be the empty string. RADIUS attributes must be at least one byte long; so this case is not possible. > 8. In section 2.3.1 - the list of possible errors include "Usage of > multiple @ separators", however this is covered in the first paragraph = and a > deterministic algorithm is provided for dealing with it. Right, thanks. I took that entry out of the "unspecified" list for -06. > 9. In section 2.3.2 - s/set of the tuple/set of tuples/ Current text c= an be > read as the set being the tuple not being a setup of the tuples. Fixed, thanks. > 10. In section 2.3.3, step 4 - suggest s/O =3D { }/O=3D { empty set }/= I've replaced all occurences of { } with your suggestion, thanks. > 11. In section 2.3.3, step 4 - what is to be considered an error at th= is > point. For example, there are a number of odd conditions that can be > returned from DNSSEC, specifically the "indeterminate" state. This needs a more thorough answer than I have time before the cutoff :-) I'm creating a TRAC ticket so that this doesn't get forgotten. > 12. In section 2.3.3, step 6 - suggest s/no result/no records found/ Changed. > 13. In section 2.3.3, step 7 - text is unclear - is the set for all lo= okup > results or just for all hostnames in the final lookup result? Also, sh= ould > secondary lookups do just NAPTR lookups or should they be doing SRV loo= kups > as well? That depends on what the NAPTR record returned. If the result was a "s" NAPTR - the next step is to query that SRV (and then A/AAAA on the resulting hostnames). If the result was an "a" NAPTR - the next step is to query for the A/AAAA record directly. If the result was a "u" NAPTR, well, do what's inside the regex [I've never really understood that voodoo]. IOW, for the purposes of this draft, the initial NAPTR record provides the first step in a path that will *eventually* yield a A/AAAA and port. The exact steps how to perform the subsequent lookups is "normal DNS business" and is not/doesn't have to covered here. Do you think this should have text in the document itself? I had hoped the wording of step 7 was concise and yet understandable enough (the text looks really ugly with a huge text in this one step). > 14. In section 2.3.3, step 9 - text is unclear if I can do the lookup = with > each of the prefixes or just with one. As text is written I can only u= se > one prefix and can't do both. It's a non-XOR OR. :-) If the entity which executes the algorithm supports only one of the two, it would only make the query which fits. If it supports both, it could attempt both (the order to use would be a configuration item, like "preferred_transport =3D dtls"). Does this need extra text? > 15. In section 2.3.3, step 13 - What subsequent lookup steps am I supp= osed > to be performing? According to RFC 3958 section 5.1, SRV provides a s= ingle > layer of indirection; the outcome of an SRV lookup is a new domain name= for > which the A RR is to be found. Right; since it's only one layer, the SRV record of course results in hostnames immediately. Sorry about that, I'll purge step 13 from the face of the earth. > 16. In section 2.3.4 - Does the validity period of the TTL apply to a > currently open user validation session? Do you close that or do you ju= st > re-run the algorithm when a new ACCESS-REQUEST comes in for the realm? When it's the same realm, the connection should be re-used. I've clarified that for -06 now. > 17. In section 2.3.4 - Given that the above algorithm does not return = a TTL > value in the event of an empty set or define how to know the TTL value = - > what is the TTL value to be used in in paragraph 2 "negative TTL"? Hm. That would indeed require an overloading of the result set to either contain the tuple, or the negative TTL. I prefer to do that (if overloading is a good idea?) after the cutoff. I'm adding this issue to TRAC. > 18. In section 2.3.4 - This question is due to a lack of knowledge on = my > part - Is there a specific error that should be returned at the RADIUS = level > for the last two paragraphs in section 2.3.4 to indicate that I can't f= ind > the path, but somebody else might be able to? RADIUS has a very simple operational model; failure is failure :-) The best guess here would be to have a statically configured DEFAULT target with a lower priority than the dynamic discovery. Which in fact, we use in eduroam quite successfully (because NAPTR is not ubiquitous in all realms yet). However, this document describes only the algorithm; an empty set does not mean the user is rejected - it only means that DNS didn't give sufficient hints to find the destination. The RADIUS configuration in the server may well have other ways to forward requests. > 19. In section 2.3.5 - Does it make sense to return a result, but to > continue the algorithm and store the result after the timeouts for late= r > use? Possibly. I'll craft some text around that; but again I'll put it into TRAC to think about first. > 20. I find the security considerations to be completely inadequate for= this > document. =20 >=20 > Use of a certificate is only going to be valid if the original realm na= me > that is the input the validation routine is what is found and matched i= n the > certificate. In this case I would not know where in the name or alt na= me > fields of the certificate it would be found. You cannot validate to th= e > final DNS name as that is now an untrusted value. There are different trust models than just matching of CN/SubjectAltName:DNS. Something for further discussion -> TRAC. > The suggestion of out-of-band validation methods ignores the existence = of > DANE DANE is indeed an alternative; we're currently thinking about this in eduroam. I believe it's worthwhile to add text to that effect. > The NAI document suggests that the RADIUS peer is pre-configured with > information about certificates or TLS validation data. The suggested t= ext > works in the case that the table says do dynamic lookup and here is the= TLS > configuration data. But in other cases it is completely unclear how a > TLS-PSK would be found for a dynamic lookup. I'm arguing TLS-PSK cipher suites are not suitable for use in this context. The Trust Router people have some wonderful ideas about using TLS-PSK in a dynamic context though (but it doesn't involve DNS IIRC). > 21 - In the IANA consideration section - do you want to reserve the str= ing > "_radiusdtls" as well as "_radiustls" as Service labels? I do :-) Fixed, thanks. Stefan >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2WECAPWTKXKOVDELKOLHL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlErhnwACgkQ+jm90f8eFWZiWwCgie/ECWofH8+j2f1l0X7kL8Mg rdAAnR91rU0E0iBrL43D7R1BXSp9FKBm =0etA -----END PGP SIGNATURE----- ------enig2WECAPWTKXKOVDELKOLHL-- From trac+radext@trac.tools.ietf.org Mon Feb 25 07:43:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA15321F9488 for ; Mon, 25 Feb 2013 07:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-eLXCQRue30 for ; Mon, 25 Feb 2013 07:43:17 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id CD40E21F9480 for ; Mon, 25 Feb 2013 07:43:16 -0800 (PST) Received: from localhost ([127.0.0.1]:38346 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UA0Cx-0005Gj-ET; Mon, 25 Feb 2013 16:43:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "radext issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu X-Trac-Project: radext Date: Mon, 25 Feb 2013 15:43:15 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/148 Message-ID: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 148 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery@tools.ietf.org, stefan.winter@restena.lu, radext@ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mikem@open.com.au, stefan.winter@restena.lu Resent-Message-Id: <20130225154316.CD40E21F9480@ietfa.amsl.com> Resent-Date: Mon, 25 Feb 2013 07:43:16 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Reply-To: radext@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:43:17 -0000 #148: Review of dynamic-discovery by Jim Schaad 1) In section 2.3.3, step 4 - what is to be considered an error at this point. For example, there are a number of odd conditions that can be returned from DNSSEC, specifically the "indeterminate" state. 2) In section 2.3.4 - Given that the above algorithm does not return a TTL value in the event of an empty set or define how to know the TTL value - what is the TTL value to be used in in paragraph 2 "negative TTL"? 3) In section 2.3.5 - Does it make sense to return a result, but to continue the algorithm and store the result after the timeouts for later use? 4) I find the security considerations to be completely inadequate for this document. Use of a certificate is only going to be valid if the original realm name that is the input the validation routine is what is found and matched in the certificate. In this case I would not know where in the name or alt name fields of the certificate it would be found. You cannot validate to the final DNS name as that is now an untrusted value. The suggestion of out-of-band validation methods ignores the existence of DANE. The NAI document suggests that the RADIUS peer is pre-configured with information about certificates or TLS validation data. The suggested text works in the case that the table says do dynamic lookup and here is the TLS configuration data. But in other cases it is completely unclear how a TLS-PSK would be found for a dynamic lookup. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-radext- stefan.winter@restena.lu | dynamic-discovery@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dynamic-discovery | Version: 1.0 Severity: - | Keywords: -------------------------------------+------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Mon Feb 25 07:43:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D0D21F9488; Mon, 25 Feb 2013 07:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p6v5QnrDXBYa; Mon, 25 Feb 2013 07:43:39 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00EC021F948A; Mon, 25 Feb 2013 07:43:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.40 Message-ID: <20130225154339.32174.91921.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 07:43:39 -0800 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 15:43:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADI= US/DTLS Author(s) : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-06.txt Pages : 13 Date : 2013-02-25 Abstract: This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dynamic-discovery-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stefan.winter@restena.lu Mon Feb 25 12:36:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5839621F9224 for ; Mon, 25 Feb 2013 12:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRddDBiK4-V8 for ; Mon, 25 Feb 2013 12:36:00 -0800 (PST) Received: from smtp.restena.lu (legolas.restena.lu [IPv6:2001:a18:1::34]) by ietfa.amsl.com (Postfix) with ESMTP id A40DC21E8040 for ; Mon, 25 Feb 2013 12:36:00 -0800 (PST) Received: from smtp.restena.lu (localhost [127.0.0.1]) by smtp.restena.lu (Postfix) with ESMTP id 0C9F39DD33 for ; Mon, 25 Feb 2013 21:35:56 +0100 (CET) Received: from [IPv6:2001:4b88:108d::131] (unknown [IPv6:2001:4b88:108d::131]) by smtp.restena.lu (Postfix) with ESMTPSA id B28ED9DD2C for ; Mon, 25 Feb 2013 21:35:55 +0100 (CET) Message-ID: <512BCB29.20104@restena.lu> Date: Mon, 25 Feb 2013 21:35:53 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <20130225154339.32174.91921.idtracker@ietfa.amsl.com> In-Reply-To: <20130225154339.32174.91921.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-06.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 20:36:01 -0000 Hi, this draft takes Bernard Aboba's comments (TRAC #147) and a part of Jim Schaad's review into account. The rest of Jim's comments are filed under TRAC #148. It also contains new text about loop detection (which can and does occur when the representation of an authoritative realm in static configuration differs from what the user sends (server assumes "not mine, need to find a target") *and* DNS can normalise the input and finds out that the authoritative server to forward to is ... localhost! The new text is a final verification step in the output set O which checks whether the request was previously received on the same socket it's about to be sent to (or that socket is at least one of the candidates in the output set). I'll get back to Jim's remaining comments soon(-ish) for a - hopefully final - rev -07. Greetings, Stefan Winter On 25.02.2013 16:43, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the RADIUS EXTensions Working Group of the IETF. > > Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS > Author(s) : Stefan Winter > Mike McCauley > Filename : draft-ietf-radext-dynamic-discovery-06.txt > Pages : 13 > Date : 2013-02-25 > > Abstract: > This document specifies a means to find authoritative RADIUS servers > for a given realm. It is used in conjunction with either RADIUS/TLS > and RADIUS/DTLS. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dynamic-discovery-06 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From iesg-secretary@ietf.org Wed Feb 27 06:34:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D53C21F870A; Wed, 27 Feb 2013 06:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg5dlmTAhH-D; Wed, 27 Feb 2013 06:34:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 865F221F8721; Wed, 27 Feb 2013 06:34:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.40p1 Message-ID: <20130227143417.17584.74354.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2013 06:34:17 -0800 Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Protocol Action: 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions' to Proposed Standard (draft-ietf-radext-radius-extensions-13.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:34:18 -0000 The IESG has approved the following document: - 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions' (draft-ietf-radext-radius-extensions-13.txt) as Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ Technical Summary: draft-ietf-radext-radius-extensions-06 will be a Proposed Standard. The I-D adds substantial features to RADIUS protocol that are essential for the future of RADIUS and to meet the market demand. These new features extend, among other features, the standard attribute type space beyond the existing maximum limit of 256. Another remarkable area of improvement is the set of generic RADIUS attribute extension including long attributes with a value length greater than the current maximum of 253 octets and standard way of encoding type-length-values with possible nesting for creating grouped type attributes. Working Group Summary: Working group spent considerable long time on this document. The technical content and selected solutions have been extensively discussed in the WG. One of the technical points that faced long technical discussion related to concatenation of multiple attributes into a one long attribute. The current solution in the I-D reflects the WG consensus. Document Quality: There are multiple implementations already available. Also given the current I-D is the second incarnation of the design, we can say the described solution is mature. For the future support and implementations of RADIUS there is no much choice than implement the I-D since current RADIUS attribute type space has almost been exhausted. Personnel: Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise is the responsible AD. From iesg-secretary@ietf.org Wed Feb 27 06:34:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0C4121F870E for ; Wed, 27 Feb 2013 06:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4OFqdpCWUkq; Wed, 27 Feb 2013 06:34:18 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989D521F873C; Wed, 27 Feb 2013 06:34:17 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.40p1 X-IETF-Draft-string: draft-ietf-radext-radius-extensions X-IETF-Draft-revision: 13 Message-ID: <20130227143417.17584.72361.idtracker@ietfa.amsl.com> Date: Wed, 27 Feb 2013 06:34:17 -0800 Cc: radext mailing list , radext chair , RFC Editor Subject: [radext] Protocol Action: 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions' to Proposed Standard (draft-ietf-radext-radius-extensions-13.txt) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 14:34:18 -0000 The IESG has approved the following document: - 'Remote Authentication Dial In User Service (RADIUS) Protocol Extensions' (draft-ietf-radext-radius-extensions-13.txt) as Proposed Standard This document is the product of the RADIUS EXTensions Working Group. The IESG contact persons are Benoit Claise and Ronald Bonica. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-radext-radius-extensions/ Technical Summary: draft-ietf-radext-radius-extensions-06 will be a Proposed Standard. The I-D adds substantial features to RADIUS protocol that are essential for the future of RADIUS and to meet the market demand. These new features extend, among other features, the standard attribute type space beyond the existing maximum limit of 256. Another remarkable area of improvement is the set of generic RADIUS attribute extension including long attributes with a value length greater than the current maximum of 253 octets and standard way of encoding type-length-values with possible nesting for creating grouped type attributes. Working Group Summary: Working group spent considerable long time on this document. The technical content and selected solutions have been extensively discussed in the WG. One of the technical points that faced long technical discussion related to concatenation of multiple attributes into a one long attribute. The current solution in the I-D reflects the WG consensus. Document Quality: There are multiple implementations already available. Also given the current I-D is the second incarnation of the design, we can say the described solution is mature. For the future support and implementations of RADIUS there is no much choice than implement the I-D since current RADIUS attribute type space has almost been exhausted. Personnel: Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise is the responsible AD. From stefan.winter@restena.lu Wed Feb 27 07:19:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B829C21F867B for ; Wed, 27 Feb 2013 07:19:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RY9b4bEQvkYS for ; Wed, 27 Feb 2013 07:19:25 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id AAE6D21F858A for ; Wed, 27 Feb 2013 07:19:20 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id B768110584 for ; Wed, 27 Feb 2013 16:19:19 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c1a3:676a:f579:5714] (unknown [IPv6:2001:a18:1:8:c1a3:676a:f579:5714]) by smtprelay.restena.lu (Postfix) with ESMTPS id A1F4A1057F for ; Wed, 27 Feb 2013 16:19:19 +0100 (CET) Message-ID: <512E23F3.3000307@restena.lu> Date: Wed, 27 Feb 2013 16:19:15 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> In-Reply-To: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FNMKGLVDKSCDQIOPVVLP" X-Virus-Scanned: ClamAV Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:19:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FNMKGLVDKSCDQIOPVVLP Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On your issue about TLS / Certs / DANE > 4) I find the security considerations to be completely inadequate for = this > document. > Use of a certificate is only going to be valid if the original realm n= ame > that is the input the validation routine is what is found and matched = in > the certificate. In this case I would not know where in the name or a= lt > name fields of the certificate it would be found. You cannot validate= to > the final DNS name as that is now an untrusted value. That's correct; in eduroam, we've settled for a good-enough solution and deploy with that: certificates need to come from an agreed set of CAs and carry a common policy OID which stands for "this is a valid eduroam IdP" (and there's a second OID for "valid hotspot" for the other side of the mutual TLS auth). In combination with DNSSEC, that gives trusted results for the entire validation process. With DNS (no SEC), a holder of a eduroam IdP certificate could manipulate another realm's DNS to point to his own server; i.e. he, as an accredited member of the consortium, could steal another member's Access-Requests and the dynamic discovery infrastructure wouldn't notice. While that's suboptimal, we found that to be a reasonable tradeoff, partly because the atmosphere inside the consortium is not at all hostile, but also because such a hijacking would still be noticed by the wrong EAP termination and the supplicant complaining about an unexpected EAP server presenting a unexpected server-side credential. That is a decision for a deployer of the algorithm to make though: the security considerations say that it's only safe with DNSSEC - which is true; every deployer is free to draw his own consequences from that. > The suggestion of out-of-band validation methods ignores the existence= of > DANE. (Preface: I may very well be very mistaken about aspects of DANE. Please do correct me if I'm wrong!) We've investigated the opportunities of DANE and it seems much rather like: DANE ignores the possibility that TLS handshakes can be mutual. Which is a bummer for things like RADIUS/TLS which /require/ mutual auth.= The problem is that only one side of the job can be done with DANE: there's a an input to be looked up in DNS, and that input can also be used to look up TLSA records for use in the later TLS handshake. However, as soon as the TLS server presented his credential and the client has verified that this is what is expected, the TLS client sends his own TLS credential - with no DNS involved whatsoever. It is unclear to me what the server-side end would do with the incoming data, and where/how in the DNS tree it would verify that the incoming credential matches its expectations and that the connecting client is authorised as part-of-the-club. It's not like it's impossible; I could sketch a way how this potentially might work: - client is required to have a CN or SAN:DNS pointing to an "accredited hotspot" DNS tree; like CN=3Drestena.lu.hotspot.consortium.com; - server does TLSA lookup of that CN (and only if suffix is indeed "hotspot.consortium.com"); if it finds matching data, establish TLS connection - DNS domain hotspot.consortium.com is maintained as a registry of authorised clients, delegated to sub-branches as needed But unless I'm mistaken, none of this is written in the DANE specs. I would find it inadequate for the dynamic discovery document to make up lots of rules on implementing DANE-like things. If there were a document which specifies client-cert validation with DANE, it would be perfectly fine to add a pointer to that though. > The NAI document suggests that the RADIUS peer is pre-configured with > information about certificates or TLS validation data. The suggested = text > works in the case that the table says do dynamic lookup and here is th= e > TLS configuration data. But in other cases it is completely unclear h= ow a > TLS-PSK would be found for a dynamic lookup. I'd say: unless ABFAB people want to have text about the dynamic negotiation of TLS-PSK keying material with this algorithm (some ABFABs are known to read the radext list :-) ), I'd feel inclined to write that PSK cipher suites are not appropriate for use with DNS-based dynamic discovery. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2FNMKGLVDKSCDQIOPVVLP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEuI/cACgkQ+jm90f8eFWZbbwCfWDjTYbyn3q3eiOuHkfQjsDn8 QHgAoIGy7YFvg3G2dWk1MXBbdrDyPJef =YFe0 -----END PGP SIGNATURE----- ------enig2FNMKGLVDKSCDQIOPVVLP-- From hartmans@painless-security.com Wed Feb 27 07:24:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C63321F86BE for ; Wed, 27 Feb 2013 07:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhko+5IQrTxv for ; Wed, 27 Feb 2013 07:24:42 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 66C0C21F8585 for ; Wed, 27 Feb 2013 07:24:41 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 569AD201C1; Wed, 27 Feb 2013 10:19:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 614CD447B; Wed, 27 Feb 2013 10:24:40 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> Date: Wed, 27 Feb 2013 10:24:40 -0500 In-Reply-To: <512E23F3.3000307@restena.lu> (Stefan Winter's message of "Wed, 27 Feb 2013 16:19:15 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:24:44 -0000 >>>>> "Stefan" == Stefan Winter writes: Stefan> That is a decision for a deployer of the algorithm to make Stefan> though: the security considerations say that it's only safe Stefan> with DNSSEC - which is true; every deployer is free to draw Stefan> his own consequences from that. I disagree. In general, we require people to have a MTI solution that provides what we believe is generally adequate security. While it's fine for eduroam to say that one IDP impersonating another is OK for eduroam, I think that's not good enough as a MTI mechanism because there are a lot of environments where that distinction would be important. So, I do think we need to have rules about what implementations MUST be able to support in terms of cert validation and naming configuration. --Sam From stefan.winter@restena.lu Wed Feb 27 07:37:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E3121F87CC for ; Wed, 27 Feb 2013 07:37:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwf4koIsr3YL for ; Wed, 27 Feb 2013 07:37:53 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id D3D3521F87BA for ; Wed, 27 Feb 2013 07:37:50 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 0A11010584 for ; Wed, 27 Feb 2013 16:37:46 +0100 (CET) Received: from [IPv6:2001:a18:1:8:c1a3:676a:f579:5714] (unknown [IPv6:2001:a18:1:8:c1a3:676a:f579:5714]) by smtprelay.restena.lu (Postfix) with ESMTPS id EBC2B10583 for ; Wed, 27 Feb 2013 16:37:45 +0100 (CET) Message-ID: <512E2846.5090702@restena.lu> Date: Wed, 27 Feb 2013 16:37:42 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2IMKEGEGJIIQVMKJCVDTV" X-Virus-Scanned: ClamAV Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:37:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2IMKEGEGJIIQVMKJCVDTV Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I disagree. In general, we require people to have a MTI solution that > provides what we believe is generally adequate security. While it's > fine for eduroam to say that one IDP impersonating another is OK for > eduroam, I think that's not good enough as a MTI mechanism because ther= e > are a lot of environments where that distinction would be important. >=20 > So, I do think we need to have rules about what implementations MUST be= > able to support in terms of cert validation and naming configuration. That's reasonable indeed. I see two ways right now: - require a deterministic verification that the input I to the algorithm led to a server responsible for that realm (DNS as the discovery mechanism could be untrusted then) - require a trusted lookup i.e. DNSSEC on all lookups The first one sounds a bit difficult; it would probably have to take the form of: the realm from I needs to in a deterministic field of the presented server cert, e.g: SAN:othername=3D"RADIUS-realm:" The second one sounds much more straightforward: make DNSSEC required, fail discovery if non-vetted DNS had to be used. I'd appreciate a "mild" formulation then like that implementations can optionally be allowed to turn off the DNSSEC requirement if local deployment circumstances warrant it. With that said, the second variant sounds like the cleaner path to use to me. Comments welcome... Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2IMKEGEGJIIQVMKJCVDTV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEuKEkACgkQ+jm90f8eFWbDSQCffoOAKk/E2MTeBVYXH5zs9eNt EMsAnjN15zWaliJ+dJ6nvurMvcGoHTgt =EchJ -----END PGP SIGNATURE----- ------enig2IMKEGEGJIIQVMKJCVDTV-- From hartmans@painless-security.com Wed Feb 27 07:47:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 762FB21F87FB for ; Wed, 27 Feb 2013 07:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8grOvyrihHk5 for ; Wed, 27 Feb 2013 07:47:50 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB0621F87F6 for ; Wed, 27 Feb 2013 07:47:50 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 3A07F20348; Wed, 27 Feb 2013 10:42:55 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 32A84447B; Wed, 27 Feb 2013 10:47:49 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> Date: Wed, 27 Feb 2013 10:47:49 -0500 In-Reply-To: <512E2846.5090702@restena.lu> (Stefan Winter's message of "Wed, 27 Feb 2013 16:37:42 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 15:47:51 -0000 >>>>> "Stefan" == Stefan Winter writes: I strongly favor the first. I agree that it means that you need to have a field in the cert that contains the realm's name. There are fairly obvious ways this can be done in a SAN. RFc 4985 is an example of how microsoft does this. My concern with the dnssec approach is that while it's easy to specify, I'm concerned that dnssec APIs are not widely available enough at userspace levels outside the resolver that I'd have confidence radsecproxy or freeradius or other radsec implementations could actually implement dnssec validation in the radius proxy right now. From jouni.nospam@gmail.com Wed Feb 27 09:41:03 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76D821F8722 for ; Wed, 27 Feb 2013 09:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2amOVrJ6Rjk for ; Wed, 27 Feb 2013 09:41:03 -0800 (PST) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3E28C21F86D2 for ; Wed, 27 Feb 2013 09:41:03 -0800 (PST) Received: by mail-pa0-f54.google.com with SMTP id fa10so566953pad.13 for ; Wed, 27 Feb 2013 09:41:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=NpTvJ65hSR3mntCAuYVT3VIidr9oOulyk3LHX7WgtM8=; b=zg7/bbHzhaCqAdj79Tqo2Q6ZgAqSd7H0Ewrs2ZJlP0Dsz5bFjoHW2PHj18xwvkeY/0 KF3j8DN+lXEk0AU1phsHHrWQJW1XxJlXUyNmoStpmy+78OrG8DD8wJtQdVpng/1hLEl+ YK9Sz0LIbn/o3IjEAA4sTK8B/ubyMhfyP/NYUeUdgLxHMvU72j9vEIq8WrCIu2R4nZ0v a7KIhoUpXY9ULfEzIlCEnw8RLGUShvMb4nl2ztQbDVgU3R9A0FjJzYEVbRfVDy/KuKKv KbplcHaEKS2hs4s4+LF8R6utn7YLTjuV8SucPyKljXCLMSx32moivynEEW64s2PmePJu yU6A== X-Received: by 10.66.156.103 with SMTP id wd7mr8633650pab.127.1361986863015; Wed, 27 Feb 2013 09:41:03 -0800 (PST) Received: from [172.16.1.206] ([119.73.137.170]) by mx.google.com with ESMTPS id kl4sm5308141pbc.31.2013.02.27.09.41.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 27 Feb 2013 09:41:02 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 27 Feb 2013 19:41:00 +0200 To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [radext] draft agenda has been uploaded X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 17:41:04 -0000 Folks, The draft agenda is out: http://www.ietf.org/proceedings/86/agenda/agenda-86-radext - Jouni From ietf@augustcellars.com Wed Feb 27 12:42:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507A021F8901 for ; Wed, 27 Feb 2013 12:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.24 X-Spam-Level: X-Spam-Status: No, score=-3.24 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnbUoi6lt8-I for ; Wed, 27 Feb 2013 12:42:55 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6C721F887D for ; Wed, 27 Feb 2013 12:42:55 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id E873638F10; Wed, 27 Feb 2013 12:42:54 -0800 (PST) From: "Jim Schaad" To: "'Stefan Winter'" , References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> In-Reply-To: <512E23F3.3000307@restena.lu> Date: Wed, 27 Feb 2013 12:42:22 -0800 Message-ID: <026f01ce152a$f24ceb20$d6e6c160$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG6BiECksJl4xbIhvfkRt9hc11tPgGl6Lx2mKkX75A= Content-Language: en-us Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2013 20:42:57 -0000 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On = Behalf > Of Stefan Winter > Sent: Wednesday, February 27, 2013 7:19 AM > To: radext@ietf.org > Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad >=20 > On your issue about TLS / Certs / DANE >=20 > > 4) I find the security considerations to be completely inadequate = for > > this document. > > Use of a certificate is only going to be valid if the original = realm > > name that is the input the validation routine is what is found and > > matched in the certificate. In this case I would not know where in > > the name or alt name fields of the certificate it would be found. > > You cannot validate to the final DNS name as that is now an = untrusted > value. >=20 > That's correct; in eduroam, we've settled for a good-enough solution = and > deploy with that: certificates need to come from an agreed set of CAs = and > carry a common policy OID which stands for "this is a valid eduroam = IdP" (and > there's a second OID for "valid hotspot" for the other side of the = mutual TLS > auth). >=20 > In combination with DNSSEC, that gives trusted results for the entire > validation process. With DNS (no SEC), a holder of a eduroam IdP certificate > could manipulate another realm's DNS to point to his own server; i.e. = he, as > an accredited member of the consortium, could steal another member's > Access-Requests and the dynamic discovery infrastructure wouldn't = notice. >=20 > While that's suboptimal, we found that to be a reasonable tradeoff, = partly > because the atmosphere inside the consortium is not at all hostile, = but also > because such a hijacking would still be noticed by the wrong EAP termination > and the supplicant complaining about an unexpected EAP server = presenting a > unexpected server-side credential. This depends on specific properties of the EAP method being used. It = would not be true for a simple user name/password EAP method. I don't know = that there is anything that would prevent a man-in-the-middle attack from occurring in this situation would might result in leaked credentials and = no failure for the EAP peer to know about. See Sam's draft in the EMU WG for more details. >=20 > That is a decision for a deployer of the algorithm to make though: the > security considerations say that it's only safe with DNSSEC - which is true; > every deployer is free to draw his own consequences from that. Given the presence of the second sentence in the paragraph that is not a statement that I heard from the Security Considerations. >=20 > > The suggestion of out-of-band validation methods ignores the > > existence of DANE. >=20 > (Preface: I may very well be very mistaken about aspects of DANE. = Please do > correct me if I'm wrong!) >=20 > We've investigated the opportunities of DANE and it seems much rather > like: DANE ignores the possibility that TLS handshakes can be mutual. > Which is a bummer for things like RADIUS/TLS which /require/ mutual = auth. I don't know that I agree with this. A very simple way to use DANE for = this would be Server gets client certificate Server extracts client DNS name from certificate Server does a TLSA lookup on the client DNS name and sees if it matches = the certificate given per DANE rules Assuming that we are looking a this being a generic proxy, that = information is going to be in the DNS for lookups back. However I was really only looking at the use of DANE in the same forward direction that you are doing the discovery. This means that the mutual = auth question is an interesting one and should be discussed as a reason for perhaps not using the DANE work. >=20 > The problem is that only one side of the job can be done with DANE: > there's a an input to be looked up in DNS, and that input can also be = used to > look up TLSA records for use in the later TLS handshake. >=20 > However, as soon as the TLS server presented his credential and the = client > has verified that this is what is expected, the TLS client sends his = own TLS > credential - with no DNS involved whatsoever. It is unclear to me what = the > server-side end would do with the incoming data, and where/how in the > DNS tree it would verify that the incoming credential matches its > expectations and that the connecting client is authorised as part-of-the-club. >=20 > It's not like it's impossible; I could sketch a way how this = potentially might > work: >=20 > - client is required to have a CN or SAN:DNS pointing to an = "accredited > hotspot" DNS tree; like CN=3Drestena.lu.hotspot.consortium.com; > - server does TLSA lookup of that CN (and only if suffix is indeed > "hotspot.consortium.com"); if it finds matching data, establish TLS > connection > - DNS domain hotspot.consortium.com is maintained as a registry of > authorised clients, delegated to sub-branches as needed >=20 > But unless I'm mistaken, none of this is written in the DANE specs. I would > find it inadequate for the dynamic discovery document to make up lots = of > rules on implementing DANE-like things. If there were a document which > specifies client-cert validation with DANE, it would be perfectly fine = to add a > pointer to that though. >=20 > > The NAI document suggests that the RADIUS peer is pre-configured = with > > information about certificates or TLS validation data. The = suggested > > text works in the case that the table says do dynamic lookup and = here > > is the TLS configuration data. But in other cases it is completely > > unclear how a TLS-PSK would be found for a dynamic lookup. >=20 > I'd say: unless ABFAB people want to have text about the dynamic > negotiation of TLS-PSK keying material with this algorithm (some = ABFABs are > known to read the radext list :-) ), I'd feel inclined to write that = PSK cipher > suites are not appropriate for use with DNS-based dynamic discovery. Given that ABFAB is basically doing a completely different dynamic negotiation, I would be inclined to state that don't use PSK is a = reasonable position. Jim >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et de > la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 From jimsch@augustcellars.com Wed Feb 27 21:37:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAD9021F8B6E for ; Wed, 27 Feb 2013 21:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.772, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ha9GzKhYC00t for ; Wed, 27 Feb 2013 21:37:48 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 714F221F8B61 for ; Wed, 27 Feb 2013 21:37:39 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 39B862C9FD; Wed, 27 Feb 2013 21:37:30 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 27 Feb 2013 21:36:56 -0800 Message-ID: <029601ce1575$a21b0600$e6511200$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4VdBadCCEM/KuYS6WbsQ3AJmDsMQ== Content-Language: en-us X-Mailman-Approved-At: Thu, 28 Feb 2013 01:33:04 -0800 Cc: radext@ietf.org Subject: [radext] Comments on draft-ietf-radext-dynamic-discovery-06 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 05:37:51 -0000 A couple of new issues to think about 1. Should there be a potential privacy concern noted in this document surrounding the question of what information can leak based on the domain(s) being queried? I am not sure that there is any usable information leaking here but this is not even close to my forte. 2. In section 2.3.3 - May want to be a bit more detailed here about the subsequent lookup steps. Presumably this is not starting with step 8 but I could be wrong. I.e. do we take the set of result names and go back to step 4 with new values of R? 3. In section 2.3.3 - Please provide some text somewhere about the reasoning behind step 15. I can understand removing a single record from the record set but all of them? 4. In section 2.3.3 - Step 12 does not specify where the negative TTL comes from. ( referenced as something significant in 2.3.4) Jim From jimsch@augustcellars.com Wed Feb 27 22:04:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCF521F8433 for ; Wed, 27 Feb 2013 22:04:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=0.463, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OY1RvRHea5hl for ; Wed, 27 Feb 2013 22:04:44 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id C335B21F88DD for ; Wed, 27 Feb 2013 21:51:29 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 1AF4C2CA18; Wed, 27 Feb 2013 21:50:42 -0800 (PST) From: "Jim Schaad" To: Date: Wed, 27 Feb 2013 21:50:10 -0800 Message-ID: <029701ce1577$79b85c60$6d291520$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0298_01CE1534.6B962DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4VdjdKBuXWJJ6MSwqlVLkIzn/s8A== Content-Language: en-us X-Mailman-Approved-At: Thu, 28 Feb 2013 01:33:04 -0800 Cc: radext@ietf.org Subject: [radext] Comemnts on draft-ietf-radext-nai-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2013 06:04:45 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0298_01CE1534.6B962DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Alan, I need to do a real read through of this document although I have done so in the past. However looking at things I could only find one immediate problem with the document. I would encourage the chairs to issue a WGLC on this document. Jim Typos s/my be extended/may be extended/ ------=_NextPart_000_0298_01CE1534.6B962DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Alan,

 

I need to do = a real read through of this document although I have done so in the = past.  However looking at things I could only find one immediate = problem with the document.

 

I would = encourage the chairs to issue a WGLC on this document.

 

Jim

 

 

Typos

 

s/my be = extended/may be extended/

 

------=_NextPart_000_0298_01CE1534.6B962DD0--