From dharkins@lounge.org Fri Nov 2 15:48:48 2012 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 A907411E80FC for ; Fri, 2 Nov 2012 15:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 tYlHrIl2PGyH for ; Fri, 2 Nov 2012 15:48:48 -0700 (PDT) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC6F11E80F9 for ; Fri, 2 Nov 2012 15:48:48 -0700 (PDT) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id EE6301022400A for ; Fri, 2 Nov 2012 15:48:47 -0700 (PDT) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 2 Nov 2012 15:48:47 -0700 (PDT) Message-ID: <9d3d994de12d802c65f6de0b3d3e1f0b.squirrel@www.trepanning.net> Date: Fri, 2 Nov 2012 15:48:47 -0700 (PDT) From: "Dan Harkins" To: radext@ietf.org User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Subject: [radext] comments on draft-ietf-radext-ieee802ext 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, 02 Nov 2012 22:48:48 -0000 Hello, The chairman of the IEEE 802.11 WG received a request to review this draft; I have done just that. I hope these comments aren't too late. 1. 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. 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? 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)? 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. 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. 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? section 2.18 - where is "table ?" in IEEE 802.11-2012? 2. 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? - 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? regards, Dan. From trac+radext@trac.tools.ietf.org Fri Nov 2 16:41:35 2012 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 0160411E8102 for ; Fri, 2 Nov 2012 16:41:35 -0700 (PDT) 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 ngKAJ6VhoBKY for ; Fri, 2 Nov 2012 16:41:34 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 50B5211E8105 for ; Fri, 2 Nov 2012 16:41:34 -0700 (PDT) Received: from localhost ([127.0.0.1]:56313 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUQrV-0004Y1-Cf; Sat, 03 Nov 2012 00:41:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com, dharkins@lounge.org X-Trac-Project: radext Date: Fri, 02 Nov 2012 23:41:17 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/130 Message-ID: <060.708d98e0c7143f4f4b5959854a52a25c@trac.tools.ietf.org> X-Trac-Ticket-ID: 130 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, dharkins@lounge.org, 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: [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: Fri, 02 Nov 2012 23:41:35 -0000 #130: Dan's Review 1. 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. 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? 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)? 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. 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. 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? section 2.18 - where is "table ?" in IEEE 802.11-2012? 2. 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? - 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? regards, Dan. -- -----------------------------+----------------------------- Reporter: dharkins@… | Owner: bernard_aboba@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: In WG Last Call | Keywords: -----------------------------+----------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Fri Nov 2 16:59:30 2012 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 5064311E8101 for ; Fri, 2 Nov 2012 16:59:30 -0700 (PDT) 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 JXLRkb3-Kj03 for ; Fri, 2 Nov 2012 16:59:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0980E11E80E3 for ; Fri, 2 Nov 2012 16:59:28 -0700 (PDT) Received: from localhost ([127.0.0.1]:58513 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TUR8u-0005Qv-GE; Sat, 03 Nov 2012 00:59:26 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 02 Nov 2012 23:59:16 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/130#comment:1 Message-ID: <075.0ac4254d04644b99bb2667994927cdb9@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: Fri, 02 Nov 2012 23:59:30 -0000 #130: Dan's Review Comment (by bernard_aboba@…): [BA] Section 2.2 I believe that IEEE 802.1X-2010 requires the EAP-Key-Name attribute to calculate the encryption keys on a wired network, so that presumably without it the key agreement exchange will fail. Sections 2.3 - 2.4. I don't know of anything bad that will happen in any existing access technology if these attributes aren't returned by the RADIUS server. Section 2.9 I get your point. Crashing if an umlaut is included in the SSID is probably not an alternative ;) Sections 2.15-2.18 I agree that these attributes are more for "reporting" in an Access or Accounting-Request than something that would be used by a RADIUS server to make an access decision. Feel free to suggest text to make that clear. Security considerations. -- -----------------------------+------------------------------ Reporter: dharkins@… | Owner: bernard_aboba@… 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 Tue Nov 6 12:44:15 2012 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 3043321F8ADD for ; Tue, 6 Nov 2012 12:44:15 -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 jc3rkFRVbMfr for ; Tue, 6 Nov 2012 12:44:14 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9628121F8AD9 for ; Tue, 6 Nov 2012 12:44:14 -0800 (PST) Received: from localhost ([127.0.0.1]:48859 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVq06-0004c7-Av; Tue, 06 Nov 2012 21:44:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Tue, 06 Nov 2012 20:43:58 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/94#comment:1 Message-ID: <081.3566a0ecf59bed70b0f878d6ce86a81c@trac.tools.ietf.org> References: <066.ae2e3be1fcc1e6f3414e9b5a3033cc0c@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <066.ae2e3be1fcc1e6f3414e9b5a3033cc0c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.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] #94: Compliance with Crypto-Agility Requirements 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: Tue, 06 Nov 2012 20:44:15 -0000 #94: Compliance with Crypto-Agility Requirements Comment (by aland@…): Addresses in the next rev. -- --------------------------------+------------------------- Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: blocker | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Tue Nov 6 12:44:40 2012 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 3935521F8D31 for ; Tue, 6 Nov 2012 12:44:40 -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 PPGuImivYI7A for ; Tue, 6 Nov 2012 12:44:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7752B21F9117 for ; Tue, 6 Nov 2012 12:44:39 -0800 (PST) Received: from localhost ([127.0.0.1]:48912 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TVq0k-0000lR-3X; Tue, 06 Nov 2012 21:44:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Tue, 06 Nov 2012 20:44:38 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/94#comment:2 Message-ID: <081.9d82d6f08c4935470fd58dea333a5827@trac.tools.ietf.org> References: <066.ae2e3be1fcc1e6f3414e9b5a3033cc0c@trac.tools.ietf.org> X-Trac-Ticket-ID: 94 In-Reply-To: <066.ae2e3be1fcc1e6f3414e9b5a3033cc0c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.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] #94: Compliance with Crypto-Agility Requirements 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: Tue, 06 Nov 2012 20:44:40 -0000 #94: Compliance with Crypto-Agility Requirements Changes (by aland@…): * status: new => closed * resolution: => fixed -- --------------------------------+------------------------- Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------- Ticket URL: radext From bclaise@cisco.com Tue Nov 6 15:13:36 2012 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 8FC9921F8667; Tue, 6 Nov 2012 15:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.457 X-Spam-Level: X-Spam-Status: No, score=-10.457 tagged_above=-999 required=5 tests=[AWL=0.142, 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 JwxYU44ogBpa; Tue, 6 Nov 2012 15:13:36 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D921F85AD; Tue, 6 Nov 2012 15:13:35 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA6NDZWa001427; Tue, 6 Nov 2012 18:13:35 -0500 (EST) Received: from [10.82.209.54] (rtp-vpn4-310.cisco.com [10.82.209.54]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qA6NDY0x029737; Tue, 6 Nov 2012 18:13:34 -0500 (EST) Message-ID: <5099999F.4080308@cisco.com> Date: Tue, 06 Nov 2012 18:13:35 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "radext@ietf.org" , "aaa-doctors@ietf.org" , Martin Bjorklund , Andy Bierman , netmod-chairs@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [radext] RADIUS question in NETMOD 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, 06 Nov 2012 23:13:36 -0000 Dear RADIUS experts, During the NETMOD WG, part of the http://datatracker.ietf.org/doc/draft-ietf-netmod-system-mgmt/ discussion, there was one open issue. See http://www.ietf.org/proceedings/85/slides/slides-85-netmod-5.pdf And http://www.ietf.org/mail-archive/web/netmod/current/msg07410.html Martin and Andy really would like to meet a RADIUS expert during the IETF. The goal is to make sure that they do the right thing for RADIUS. However, please note that the draft is not supposed to configure every RADIUS options. Who would be available? Regards, Benoit From aland@deployingradius.com Wed Nov 7 05:54:33 2012 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 9AAE621F8B4D; Wed, 7 Nov 2012 05:54: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=[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 vkApjJQeVc3O; Wed, 7 Nov 2012 05:54:27 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B078A21F8AD6; Wed, 7 Nov 2012 05:54:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9E6F52240903; Wed, 7 Nov 2012 14:53:32 +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 08LrRjlgpuAZ; Wed, 7 Nov 2012 14:53:32 +0100 (CET) Received: from dhcp-5482.meeting.ietf.org (dhcp-5482.meeting.ietf.org [130.129.84.130]) by power.freeradius.org (Postfix) with ESMTPSA id 9C4D922404ED; Wed, 7 Nov 2012 14:53:31 +0100 (CET) Message-ID: <509A67DA.2050908@deployingradius.com> Date: Wed, 07 Nov 2012 08:53:30 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Benoit Claise References: <5099999F.4080308@cisco.com> In-Reply-To: <5099999F.4080308@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "aaa-doctors@ietf.org" , "radext@ietf.org" , Martin Bjorklund , Andy Bierman , netmod-chairs@tools.ietf.org Subject: Re: [radext] RADIUS question in NETMOD 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, 07 Nov 2012 13:54:33 -0000 Benoit Claise wrote: > Martin and Andy really would like to meet a RADIUS expert during the IETF. > The goal is to make sure that they do the right thing for RADIUS. > However, please note that the draft is not supposed to configure every > RADIUS options. OK. I took a quick look at it. I'm wary of having yet another registry. If at all possible, it would be preferable to leverage existing registries. There is an IANA registry for EAP types. Could netmod just reference that? e.g. just define a "radius-eap" type, with a "method" parameter that contains the actual EAP type to use. Alan DeKok. From mauricio.sanchez@hp.com Wed Nov 7 09:09:09 2012 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 A524821F8BD5 for ; Wed, 7 Nov 2012 09:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.201 X-Spam-Level: X-Spam-Status: No, score=-105.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 cpeX6zggbexI for ; Wed, 7 Nov 2012 09:09:09 -0800 (PST) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id DA6EF21F8BBE for ; Wed, 7 Nov 2012 09:09:08 -0800 (PST) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 4782B24448 for ; Wed, 7 Nov 2012 17:09:08 +0000 (UTC) Received: from G6W2639G.americas.hpqcorp.net (16.205.233.107) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 7 Nov 2012 17:08:00 +0000 Received: from G6W2500.americas.hpqcorp.net ([169.254.12.172]) by G6W2639G.americas.hpqcorp.net ([16.205.233.107]) with mapi id 14.02.0283.004; Wed, 7 Nov 2012 17:08:00 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: ietf85: Radext meeting notes - please review Thread-Index: AQHNvQpvtEQAAY5u50uOz/DH5Ku6RQ== Date: Wed, 7 Nov 2012 17:07:59 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [15.193.49.14] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3435134877_2272647" MIME-Version: 1.0 Subject: [radext] ietf85: Radext meeting notes - please 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: Wed, 07 Nov 2012 17:09:09 -0000 --B_3435134877_2272647 Content-type: multipart/alternative; boundary="B_3435134877_2297352" --B_3435134877_2297352 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Radext community, Meeting notes have been uploaded to proceedings. Please review and provide any updates, corrections, etc. Thank you for Dorothy for great note taking. http://www.ietf.org/proceedings/85/minutes/minutes-85-radext -Jouni and Mauricio --B_3435134877_2297352 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

Radext community,&n= bsp;

Meeting notes have been uploaded to proceedings= .  Please review and provide any updates, corrections, etc.  Thank= you for Dorothy for great note taking. 

http://www.ietf.org/p= roceedings/85/minutes/minutes-85-radext

-= Jouni and Mauricio 

--B_3435134877_2297352-- --B_3435134877_2272647 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg7qM69qC2iPLC6wU+AX60GH8V 9EJ7yMdJF6R8ktKC0T8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIxMTA3MTcwNzU3WjANBgkqhkiG9w0BAQEFAASCAQBiaK7kSOLQ7gJZdG5e3LdZ7vAy c7RzDO3X4fjr0te7xlbBLDrCTkuipRLCbxrf4ahIefRaSZZaDHyV5mjeJPgwzMWmX7VZr5ra ZtBFXIVIEQj+9P+5j7KfmibG3fFdK85r35URI+GZjdznGlef/l3oMdJo1zKwJS5I9mKKcA5/ ngt/Pgc2pNiZ6kxLQEWUEcQFXAjG1Zl+XDnjTaU7No/z61UmKLxqZl3rN7vfgxs05N5TKBRF gVYq+2D8GKOiwsrjIkYFLlp8BHIe6WrKmOqDBbcQWvU/I+H90wOI/gny1c0lZ8w0V6f2oL3T JAvllrK2Qf/+b2sf3OBPreXD4pK3 --B_3435134877_2272647-- From mauricio.sanchez@hp.com Wed Nov 7 09:22:52 2012 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 B76BA21F8BF1 for ; Wed, 7 Nov 2012 09:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.201 X-Spam-Level: X-Spam-Status: No, score=-105.201 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 Qt+PvTzC2j-R for ; Wed, 7 Nov 2012 09:22:51 -0800 (PST) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id A871721F8853 for ; Wed, 7 Nov 2012 09:22:50 -0800 (PST) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 6629624370 for ; Wed, 7 Nov 2012 17:22:50 +0000 (UTC) Received: from G6W2545G.americas.hpqcorp.net (16.205.233.30) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 7 Nov 2012 17:21:36 +0000 Received: from G6W2500.americas.hpqcorp.net ([169.254.12.172]) by G6W2545G.americas.hpqcorp.net ([16.205.233.30]) with mapi id 14.02.0283.004; Wed, 7 Nov 2012 17:21:36 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: RADEXT WG Last Call: DTLS as a Transport Layer for RADIUS Thread-Index: AQHNvQxWrwgIsA+e5EyCQMiTxJJuEg== Date: Wed, 7 Nov 2012 17:21:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [15.193.49.17] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3435135694_2348877" MIME-Version: 1.0 Subject: [radext] RADEXT WG Last Call: DTLS as a Transport Layer for RADIUS 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, 07 Nov 2012 17:22:52 -0000 --B_3435135694_2348877 Content-type: multipart/alternative; boundary="B_3435135693_2355943" --B_3435135693_2355943 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable This is an announcement of RADEXT WG last call on "DTLS as a Transport Laye= r for RADIUS", prior to sending the document to the IESG for publication as a Experimental RFC.=20 The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-dtls The RADEXT WG last call will last until Wednesday November 21, 2012. If you have comments on the document, please file using TRAC system. See belo= w for summary of instructions. Thanks, Mauricio and Jouni=20 =20 1. To submit an issue in TRAC, you first need to login to the RADEXT WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login 2. If you don=B9t already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can fil= e an issue by navigating to the ticket entry form:http://trac.tools.ietf.org/wg/radext/trac/newticket 4. When opening an issue: a. The Type: field should be set to =B3defect=B2 for an issue with the current document text, or =B3enhancement=B2 for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. Fo= r example, editorial issues are typically =B3minor=B2 or =B3trivial=B2. c. The Milestone: field should be set to milestone1 (useless, I know)= . d. The Component: field should be set to the document you are filing the issue on. =20 e. The Version: field should be set to =B31.0=B2. f. The Severity: field should be set to based on the status of the document (e.g. =B3In WG Last Call=B2 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you.=20 h. The Assign To: field is generally filled in with the email address of the editor.=20 5. Typically it won=B9t be necessary to enclose a file with the ticket, but if you need to, select =B3I have files to attach to this ticket=B2. 6. If you want to preview your Issue, click on the =B3Preview=B2 button. When you=B9re ready to submit the issue, click on the =B3Create Ticket=B2 button. 7. If you want to update an issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # you want to update, and then modify the ticket fields as required --B_3435135693_2355943 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

This is a= n announcement of RADEXT WG last call on "DTLS as a Transport Layer fo= r RADIUS", prior to sending the document to the IESG for publication = as a Experimental RFC. 

The d= ocument is available for inspection here:

http://tools.ietf.org/html/draft-ietf-radext-d= tls

The RADEXT WG last call will last unt= il Wednesday November 21, 2012.   If you have comments o= n the document, please file using TRAC system.  See below for summary o= f instructions.


Thanks,
Mauricio and Jo= uni 

 

<= font class=3D"Apple-style-span" face=3D"Consolas">1.    &nbs= p;  To submit an issue in TRAC, you first need to login to the RADEXT W= G site on the tools server:  http://tools.ietf.org/wg/radext/trac/l= ogin 
2.       If you don’t = already have a login ID, you can obtain one by navigating to this site: = ;  http://trac.tools.ietf.org/newlogin
3.    &n= bsp;  Once you have obtained an account, and have logged in, you can fi= le an issue by navigating to the  ticket entry form:http://trac= .tools.ietf.org/wg/radext/trac/newticket
4.    &n= bsp;  When opening an issue:
a.       = The Type: field should be set to “defect” for an issue with the = current document text, or “enhancement” for a proposed addition = of functionality (such as an additional requirement). 
b.  = ;    The Priority: field is set based on the severity of the = Issue.   For example, editorial issues are typically “minor&= #8221; or “trivial”. 
c.     &n= bsp; The Milestone: field should be set to milestone1 (useless, I know).&nbs= p;
d.      The Component: field should be set to= the document you are filing the issue on.  
e.  &nbs= p;   The Version: field should be set to “1.0”. <= br>f.        The Severity: field should b= e set to based on the status of the document (e.g. “In WG Last Call= 221; for a document in WG last call)
g.     &nbs= p;  The Keywords: and CC: fields can be left blank unless inspiration s= eizes you. 
h.      The Assign To: field is= generally filled in with the email address of the editor. 
5. =       Typically it won’t be necessary to encl= ose a file with the ticket, but if you need to, select “I have files t= o attach to this ticket”. 
6.     &nb= sp; If you want to preview your Issue, click on the “Preview” bu= tton.  When you’re ready to submit the issue, click on the “= ;Create Ticket” button. 
7.      = ; If you want to update an issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1  Click on the t= icket # you want to update, and then modify the ticket fields as required

--B_3435135693_2355943-- --B_3435135694_2348877 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgGbucFU017cKKV2MR2kOlP3co O8nI5OIlcVwYzvb3jUYwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIxMTA3MTcyMTMzWjANBgkqhkiG9w0BAQEFAASCAQAjoQyuu6PCdoDr6zPGRR/thpuC I4bOWPtma/y4pSX0jCiqLfHT8xoZU1UsytIW16oQx5zhl5hH71Vnvz3QDa9fd3IPn60xaEYs Nnn+QsRY8eXV/UMM06DaPfsuoRmSovdFY/vZjsGMzxmkVaCbxuDm6Rk1he/JVhO1YaufoqWn jvaA2MeGnWWSqhH8Fw8ghg6S3NqXNXucwk35FI++d1MJ0IAoZKxsXDd2lj0LGvZg7/BmKd+E G3ss2RNygM5t41z13wzvrczZStZ/HoErXXEiT23SR2S1cil1Z3NqcXTst3D3WXpLjC+KAPWj 3hgUiYYXJkQc5qu5hsnz9Gv1USLP --B_3435135694_2348877-- From mauricio.sanchez@hp.com Wed Nov 7 09:26:37 2012 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 823C421F8C19 for ; Wed, 7 Nov 2012 09:26:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.202 X-Spam-Level: X-Spam-Status: No, score=-105.202 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, 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 wPkVtDKNQtU8 for ; Wed, 7 Nov 2012 09:26:35 -0800 (PST) Received: from g6t0185.atlanta.hp.com (g6t0185.atlanta.hp.com [15.193.32.62]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2CF21F8C09 for ; Wed, 7 Nov 2012 09:26:35 -0800 (PST) Received: from G6W1798G.americas.hpqcorp.net (g6w1798g.atlanta.hp.com [16.230.17.175]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0185.atlanta.hp.com (Postfix) with ESMTPS id 3BB2424431 for ; Wed, 7 Nov 2012 17:26:35 +0000 (UTC) Received: from G6W2542G.americas.hpqcorp.net (16.205.233.27) by G6W1798G.americas.hpqcorp.net (16.230.17.175) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 7 Nov 2012 17:25:31 +0000 Received: from G6W2500.americas.hpqcorp.net ([169.254.12.172]) by G6W2542G.americas.hpqcorp.net ([16.205.233.27]) with mapi id 14.02.0283.004; Wed, 7 Nov 2012 17:25:30 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: RADEXT WG Last Call: NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Thread-Index: AQHNvQzi0u6xQO0fKECF8HOwhvwh1w== Date: Wed, 7 Nov 2012 17:25:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [15.193.49.20] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3435135928_2361155" MIME-Version: 1.0 Subject: [radext] RADEXT WG Last Call: NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 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, 07 Nov 2012 17:26:37 -0000 --B_3435135928_2361155 Content-type: multipart/alternative; boundary="B_3435135928_2346116" --B_3435135928_2346116 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable This is an announcement of RADEXT WG last call on "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", prior to sending the document to the IESG for publication as an Experimental RFC. The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery The RADEXT WG last call will last until Wednesday November 21, 2012. If you have comments on the document, please file using TRAC system. See belo= w for summary of instructions. Thanks, Mauricio and Jouni=20 =20 1. To submit an issue in TRAC, you first need to login to the RADEXT WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login 2. If you don=B9t already have a login ID, you can obtain one by navigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can fil= e an issue by navigating to the ticket entry form:http://trac.tools.ietf.org/wg/radext/trac/newticket 4. When opening an issue: a. The Type: field should be set to =B3defect=B2 for an issue with the current document text, or =B3enhancement=B2 for a proposed addition of functionality (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. Fo= r example, editorial issues are typically =B3minor=B2 or =B3trivial=B2. c. The Milestone: field should be set to milestone1 (useless, I know)= . d. The Component: field should be set to the document you are filing the issue on. =20 e. The Version: field should be set to =B31.0=B2. f. The Severity: field should be set to based on the status of the document (e.g. =B3In WG Last Call=B2 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration seizes you.=20 h. The Assign To: field is generally filled in with the email address of the editor.=20 5. Typically it won=B9t be necessary to enclose a file with the ticket, but if you need to, select =B3I have files to attach to this ticket=B2. 6. If you want to preview your Issue, click on the =B3Preview=B2 button. When you=B9re ready to submit the issue, click on the =B3Create Ticket=B2 button. 7. If you want to update an issue, go to the "View Tickets" page: http://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # you want to update, and then modify the ticket fields as required --B_3435135928_2346116 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable

This is an announce= ment of RADEXT WG last call on "NAI-based Dynamic Peer Discovery for R= ADIUS/TLS and RADIUS/DTLS", prior to sending the document to the IESG= for publication as an Experimental RFC. 

The document is available for inspection here:

http://tools.ietf.or= g/html/draft-ietf-radext-dynamic-discovery


The RADEXT WG last call will = last until Wednesday November 21, 2012.   If you have comments on = the document, please file using TRAC system.  See below for summary of = instructions.


T= hanks,
Mauricio and Jouni 

 

1.       To submi= t an issue in TRAC, you first need to login to the RADEXT WG site on the too= ls server:  http://tools.ietf.org/wg/radext/trac/login 2.       If you don’t already have a lo= gin ID, you can obtain one by navigating to this site:   http://trac.= tools.ietf.org/newlogin
3.       Once y= ou have obtained an account, and have logged in, you can file an issue by na= vigating to the  ticket entry form:http://trac.tools.ietf.org/w= g/radext/trac/newticket
4.       When o= pening an issue:
a.       The Type: field s= hould be set to “defect” for an issue with the current document = text, or “enhancement” for a proposed addition of functionality = (such as an additional requirement). 
b.    &nbs= p; The Priority: field is set based on the severity of the Issue.  = ; For example, editorial issues are typically “minor” or “= trivial”. 
c.       The Mileston= e: field should be set to milestone1 (useless, I know). 
d. &nb= sp;    The Component: field should be set to the document you= are filing the issue on.  
e.      Th= e Version: field should be set to “1.0”. 
f.  =       The Severity: field should be set to based on= the status of the document (e.g. “In WG Last Call” for a docume= nt in WG last call)
g.        The Keyw= ords: and CC: fields can be left blank unless inspiration seizes you. <= br>h.      The Assign To: field is generally filled= in with the email address of the editor. 
5.    = ;   Typically it won’t be necessary to enclose a file with t= he ticket, but if you need to, select “I have files to attach to this = ticket”. 
6.       If you want t= o preview your Issue, click on the “Preview” button.  When = you’re ready to submit the issue, click on the “Create Ticket= 221; button. 
7.       If you want to = update an issue, go to the "View Tickets" page: http://trac.tool= s.ietf.org/wg/radext/trac/report/1  Click on the ticket # you want = to update, and then modify the ticket fields as required

--B_3435135928_2346116-- --B_3435135928_2361155 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgAK3zXrFVUP01Hz6LDJMEPEL8 Anjuc0e45tsN0jDN6VIwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIxMTA3MTcyNTI4WjANBgkqhkiG9w0BAQEFAASCAQCRAchfjF19RV0DJ16V9E3Jnbw0 3iSvrEwZpMat12WiekRrsbBAD+FImqGc99cNOwo02uzBwDSOJ4KUbZfxUVQf1RZxmTCYllAV K//HYFcnFETHaEowQ7bPSWtk3EG/kJAr85fPJcnYSSnt351OY3c7v+RISbbpAJcPGpfqcBKB qC8J9zQMrdlTe+ENTWSccbxrI+kp6KPBzRmXpi3MQegq4qCq0AQNJb1vJtTLcbAKM3YGNYSJ 7SOsYg92Mm2GwkzXmjtXnRdm//vMlnjyLKkZWP1bfDXqlBd/k/o/wpo1KZVBPi422IlY8UUk HKargn3gcXwphVLxVbAJquMsv5pt --B_3435135928_2361155-- From mauricio.sanchez@hp.com Wed Nov 7 09:40:50 2012 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 7CDCB21F8C5A for ; Wed, 7 Nov 2012 09:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.202 X-Spam-Level: X-Spam-Status: No, score=-107.202 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 VrSJPnQeaxTf for ; Wed, 7 Nov 2012 09:40:49 -0800 (PST) Received: from g6t0184.atlanta.hp.com (g6t0184.atlanta.hp.com [15.193.32.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD1821F8C59 for ; Wed, 7 Nov 2012 09:40:49 -0800 (PST) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0184.atlanta.hp.com (Postfix) with ESMTPS id ABD48C340 for ; Wed, 7 Nov 2012 17:40:48 +0000 (UTC) Received: from G6W2542G.americas.hpqcorp.net (16.205.233.27) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 7 Nov 2012 17:39:44 +0000 Received: from G6W2500.americas.hpqcorp.net ([169.254.12.172]) by G6W2542G.americas.hpqcorp.net ([16.205.233.27]) with mapi id 14.02.0283.004; Wed, 7 Nov 2012 17:39:43 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: RADEXT recharter proposal Thread-Index: AQHNvQ7e/rCT9/yTIUeexf7vFvauOA== Date: Wed, 7 Nov 2012 17:39:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [15.193.49.20] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3435136781_2406176" MIME-Version: 1.0 Subject: [radext] RADEXT recharter 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: Wed, 07 Nov 2012 17:40:50 -0000 --B_3435136781_2406176 Content-type: multipart/alternative; boundary="B_3435136780_2432124" --B_3435136780_2432124 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Pasted below is the current recharter proposal for radext. The largest change from the previous circulated proposal is the remove of the traffic statistics work. After consultation with our AD, we the chairs have decided to postpone adding this work item until we have a clearer understanding for scope of problem and solution . Moreover, we already have a number of items that are severely overdue and several more solid individual submissions that are eminent work items (pending this recharter). We would like any feedback by EOB Friday as our AD is ready to run this recharter text through the process. -Jouni and Mauricio -------------------------------------------------------- Description of Working Group The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol required to expand and enrich the standard attribute space, address cryptographic algorithm agility, use of new secure transports and clarify its usage and definition. In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. Work Items The immediate goals of the RADEXT working group are to address the following issues: - RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes. - IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS. - Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases. In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies. In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS. - Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865. Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC May 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC --B_3435136780_2432124 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable
Pasted below is the cur= rent recharter proposal for radext.  The largest change from the previo= us circulated proposal is the remove of the traffic statistics work.  A= fter consultation with our AD, we the chairs have decided to postpone adding= this work item until we have a clearer understanding for scope of problem a= nd solution .   Moreover, we already have a number of items that are se= verely overdue and several more solid individual submissions that are eminen= t work items (pending this recharter).    We would like any feedba= ck by EOB Friday as our AD is ready to run this recharter text through the p= rocess.   

-Jouni and Mauricio 

-------------------------------------------------------= -
Description of Working Group

The RADIUS= Extensions Working Group will focus on extensions to the RADIUS  proto= col required to expand and enrich the standard attribute space, address &nbs= p;cryptographic algorithm agility, use of new secure transports and clarify = its usage and definition.

In order to maintain inte= roperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work = items except those that just define new attributes MUST contain a Diameter c= ompatibility section, outlining how interoperability with Diameter will be m= aintained.

Furthermore, to ensure backward compatib= ility with existing RADIUS  implementations, as well as compatibility b= etween RADIUS and Diameter, the following restrictions are imposed on extens= ions considered by the RADEXT WG:

- All documents p= roduced MUST specify means of interoperation with legacy RADIUS  and, i= f possible, be backward compatible with existing RADIUS RFCs, including RFCs= 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 615= 8. Transport profiles should, if possible, be compatible with RFC 3539.

Work Items
The immediate goals of the RADEXT = working group are to address the following issues:

= - RADIUS attribute space extension. The standard RADIUS attribute space is c= urrently being depleted. This document will provide additional standard attr= ibute space, while maintaining backward compatibility with existing attribut= es.

- IEEE 802 attributes. New attributes have been= proposed to support IEEE 802 standards for wired and wireless LANs. This wo= rk item will support authentication, authorization and accounting attributes= needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16= .

- New RADIUS transports. A reliable transport pro= file for RADIUS will be developed, as well as specifications for Secure tran= sports, including TCP/TLS (RADSEC) and UDP/DTLS.

- = Update and clarification of Network Access Identifiers (RFC4282).This work i= tem will correct and clarify issues present with RFC4282 in two phases. &nbs= p;In first phase, RFC4282bis will be issued to eliminate fundamental incompa= tibilities with RADIUS around character encoding and NAI modifications by pr= oxies.  In second phase, a fresh review of NAI internationalization req= uirements and behavior will be undertaken with a clear goal of maintaining c= ompatibility with RADIUS.

- Fragmentation of RADIUS= packets to support exchanges exceeding the existing 4KB limit imposed by RF= C2865.

Goals and Milestones
Done Updates = to RFC 2618-2621 RADIUS MIBs submitted for publication
Done SIP RA= DIUS authentication draft submitted as a Proposed Standard RFC
Don= e RFC 2486bis submitted as a Proposed Standard RFC
Done RFC 3576 M= IBs submitted as an Informational RFC
Done RADIUS VLAN and Priorit= y Attributes draft submitted as a Proposed Standard RFC (reduced in scope)
Done RADIUS Implementation Issues and Fixes draft submitted as an I= nformational RFC
Done RADIUS Filtering Attributes draft submitted = as a Proposed Standard RFC (split out from VLAN & Priority draft)
<= div>Done RFC 3576bis submitted as an Informational RFC (split out from Issue= s & Fixes draft)
Done RADIUS Redirection Attributes draft subm= itted as a Proposed Standard RFC (split out from VLAN & Priority draft)<= /div>
Done RADIUS Design Guidelines submitted as a Best Current Practice= RFC
Done RADIUS Management Authorization I-D submitted as a Propo= sed Standard RFC
Done Reliable Transport Profile for RADIUS I-D su= bmitted as a Proposed Standard RFC
Done Status-Server I-D submitte= d as a Proposed Standard RFC
Done RADIUS Crypto-agility Requiremen= ts submitted as an Informational RFC
Done RADSEC (RADIUS over TCP/= TLS) draft submitted as an Experimental RFC
Nov 2012 IPv6 Access I= -D submitted as a Proposed Standard RFC
Nov 2012 RFC 4282bis submi= tted as a Proposed Standard RFC
Dec 2012 Extended Attributes I-D s= ubmitted as a Proposed Standard RFC
Dec 2012 Dynamic Discovery I-D= submitted as a Proposed Standard RFC
Dec 2012 IEEE 802 Attributes= I-D submitted as a Proposed Standard RFC
Jan 2012 RADIUS over DTL= S I-D submitted as an Experimental RFC
Feb 2012 RADIUS packet frag= mentation submitted as an Experimental RFC
May 2013 RADIUS support= for NAI Internationalization I-D submitted as a Proposed Standard RFC
=

--B_3435136780_2432124-- --B_3435136781_2406176 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgP4fC+pJUYu9lsUiY40CDEh2h Qz12IOzIJXWBamxv//0wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIxMTA3MTczOTQwWjANBgkqhkiG9w0BAQEFAASCAQBiTfRUOEtZNnn+LH5WcXG+LUqE C6FtIRgp2+j6TijYNFDxfBl/A+58fHdHNhNjryP79fVoWnuPPK16wuzbUFGCE8B7S0bmPBOE ZFhoJ4Mj0mEixRNTR/6l4oQV0gAks5y1djDRdzV1vroDsNLCsBU4SAIrtrPOo8hQxUEyIXDd OlRRukz65Hrv6haJ81mFzhdWNVwFsN1107PMcka0tHc5Tr8yAUWRr6nLAKgpAHe+psOiLMPl nQ1yhu9YHk/g6mYLf4TNtsMdLyygmYDOK62FF3fc6n/J3Xv5yUck3xssS691Inb4dNwkjPN/ OLJLhFI2wK0jqxrBLrPBYD/hzVoM --B_3435136781_2406176-- From peterd@iea-software.com Wed Nov 7 09:57:32 2012 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 D5E0B21F8C58 for ; Wed, 7 Nov 2012 09:57:32 -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 cNC+Wy7omdat for ; Wed, 7 Nov 2012 09:57: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 46D7A21F8C56 for ; Wed, 7 Nov 2012 09:57: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 ; Wed, 7 Nov 2012 09:57:30 -0800 Date: Wed, 7 Nov 2012 09:57:28 -0800 (Pacific Standard Time) From: Peter Deacon To: "Sanchez, Mauricio (HP Networking)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="697751678-28779-1352311049=:2968" Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT WG Last Call: DTLS as a Transport Layer for RADIUS 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, 07 Nov 2012 17:57:32 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --697751678-28779-1352311049=:2968 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT On Wed, 7 Nov 2012, Sanchez, Mauricio (HP Networking) wrote: > This is an announcement of RADEXT WG last call on "DTLS as a Transport > Layer for RADIUS", prior to sending the document to the IESG for > publication as a Experimental RFC. > http://tools.ietf.org/html/draft-ietf-radext-dtls > The RADEXT WG last call will last until Wednesday November 21, 2012.   If > you have comments on the document, please file using TRAC system.  See > below for summary of instructions. I'm concerned last call may be premature. There are still several open tickets against this in the tracker. regards, Peter --697751678-28779-1352311049=:2968-- From jouni.nospam@gmail.com Wed Nov 7 10:12:46 2012 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 6F2D121F8C7A for ; Wed, 7 Nov 2012 10:12:46 -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 LA-g3+CTo0Do for ; Wed, 7 Nov 2012 10:12:46 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id E84ED21F8BDA for ; Wed, 7 Nov 2012 10:12:45 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so1451818pbb.31 for ; Wed, 07 Nov 2012 10:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=dKy5VsM7pFxBtVGt2GitFRA4sZYQkYb3tnXNbPcLFm8=; b=YksdcslSxJiTacGitnua4wPAOuBkr1MMzPC7BrfR1TxjTV5Qp2eY5vLAAIJlOTUdLg +5RqwlXPOD/QzPNxFzhdwaNFDGcrFjxb8jYKNOVVNzUapB//dF9OliqBUu7XGBKRxO2h hSeHwdPBeRZ19/sH/BZBF8qaUiOxvTi1SLss2rWJkYW4dm7BInaln5oJIrzKjgRrzFlz Q7DY5/Gg2qpsqvoU1Js0NdnE0modpDfDluvh6T9fcDdRY9jgXkW+JR62BC8/Dp+xQ586 iwz7ldQXVoircHGLqtl93IUwXCiMCEIjI+Sm7D2+zLL/q48ym1zrou66oQRCBwqZpfkD 0RQw== Received: by 10.68.234.201 with SMTP id ug9mr9464167pbc.63.1352311965736; Wed, 07 Nov 2012 10:12:45 -0800 (PST) Received: from ?IPv6:2001:df8::64:226:bbff:fe18:6e9c? ([2001:df8:0:64:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id j9sm14633784pav.15.2012.11.07.10.12.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 07 Nov 2012 10:12:45 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: jouni korhonen In-Reply-To: Date: Wed, 7 Nov 2012 20:12:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Deacon X-Mailer: Apple Mail (2.1084) Cc: "radext@ietf.org" , "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] RADEXT WG Last Call: DTLS as a Transport Layer for RADIUS 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, 07 Nov 2012 18:12:46 -0000 I see one ticket, which is marked as "closed". - JOuni On Nov 7, 2012, at 7:57 PM, Peter Deacon wrote: > On Wed, 7 Nov 2012, Sanchez, Mauricio (HP Networking) wrote: >=20 >> This is an announcement of RADEXT WG last call on "DTLS as a = Transport >> Layer for RADIUS", prior to sending the document to the IESG for >> publication as a Experimental RFC. >=20 >> http://tools.ietf.org/html/draft-ietf-radext-dtls >=20 >> The RADEXT WG last call will last until Wednesday November 21, 2012. = If >> you have comments on the document, please file using TRAC system. = See >> below for summary of instructions. >=20 > I'm concerned last call may be premature. There are still several = open tickets against this in the tracker. >=20 > regards, > Peter_______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From lionel.morand@orange.com Wed Nov 7 10:25:07 2012 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 D58DB21F8B71 for ; Wed, 7 Nov 2012 10:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=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 JZB-5TJtWxdE for ; Wed, 7 Nov 2012 10:25:05 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 38F7721F88DE for ; Wed, 7 Nov 2012 10:25:04 -0800 (PST) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id B29C0324BFE; Wed, 7 Nov 2012 19:25:02 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 6A15F4C076; Wed, 7 Nov 2012 19:25:02 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0318.004; Wed, 7 Nov 2012 19:25:02 +0100 From: To: "Sanchez, Mauricio (HP Networking)" , "radext@ietf.org" Thread-Topic: [radext] RADEXT WG Last Call: NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Thread-Index: AQHNvQzi0u6xQO0fKECF8HOwhvwh15fepC0w Date: Wed, 7 Nov 2012 18:25:02 +0000 Message-ID: <8013_1352312702_509AA77E_8013_3135_1_6B7134B31289DC4FAF731D844122B36E098517@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E098517PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.7.162416 Subject: Re: [radext] RADEXT WG Last Call: NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS 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, 07 Nov 2012 18:25:07 -0000 --_000_6B7134B31289DC4FAF731D844122B36E098517PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please consider these comments that are more for clarifications than highli= ghting new blocking issues. Regards, Lionel 1/ It is maybe obvious or defined in another document but the descriptions = of Service tags "aaa+auth", "aaa+acct" and "aaa+Dynauth" are missing. 2/ Maybe obvious too but it could be clarified that the SRV prefix defined = in this document corresponds to the "_Service._Proto" part of an SRV RR. S= RV prefix may have different meanings depending on the reader. 3/ We can find several instances of "AAA server" in the draft. It could be = replaced by RADIUS server that is more accurate, as only RADIUS is consider= ed. De : radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] De la part de= Sanchez, Mauricio (HP Networking) Envoy=E9 : mercredi 7 novembre 2012 18:25 =C0 : radext@ietf.org Objet : [radext] RADEXT WG Last Call: NAI-based Dynamic Peer Discovery for = RADIUS/TLS and RADIUS/DTLS This is an announcement of RADEXT WG last call on "NAI-based Dynamic Peer D= iscovery for RADIUS/TLS and RADIUS/DTLS", prior to sending the document to = the IESG for publication as an Experimental RFC. The document is available for inspection here: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery The RADEXT WG last call will last until Wednesday November 21, 2012. If y= ou have comments on the document, please file using TRAC system. See below= for summary of instructions. Thanks, Mauricio and Jouni 1. To submit an issue in TRAC, you first need to login to the RADEXT = WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login 2. If you don't already have a login ID, you can obtain one by naviga= ting to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account, and have logged in, you can fil= e an issue by navigating to the ticket entry form:http://trac.tools.ietf.o= rg/wg/radext/trac/newticket 4. When opening an issue: a. The Type: field should be set to "defect" for an issue with the cu= rrent document text, or "enhancement" for a proposed addition of functional= ity (such as an additional requirement). b. The Priority: field is set based on the severity of the Issue. Fo= r example, editorial issues are typically "minor" or "trivial". c. The Milestone: field should be set to milestone1 (useless, I know). d. The Component: field should be set to the document you are filing t= he issue on. e. The Version: field should be set to "1.0". f. The Severity: field should be set to based on the status of the d= ocument (e.g. "In WG Last Call" for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you. h. The Assign To: field is generally filled in with the email address = of the editor. 5. Typically it won't be necessary to enclose a file with the ticket,= but if you need to, select "I have files to attach to this ticket". 6. If you want to preview your Issue, click on the "Preview" button. = When you're ready to submit the issue, click on the "Create Ticket" button. 7. If you want to update an issue, go to the "View Tickets" page: htt= p://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # you = want to update, and then modify the ticket fields as required ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E098517PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please consider these comments that are more for clarificati= ons than highlighting new blocking issues.

 

Regards,

 

Lionel

 

1/ It is maybe obvious or defined in another document but th= e descriptions of Service tags “aaa+auth”, “aaa+a= cct” and “aaa+Dynauth” are missing.

 

2/ Maybe obvious too but it could be clarified that the SRV = prefix defined in this document corresponds to the “_Service._Proto&#= 8221; part of an SRV RR.  SRV prefix may have different meanings depending on the reader. =  

 

3/ We can find several instances of “AAA server”= in the draft. It could be replaced by RADIUS server that is more accurate,= as only RADIUS is considered.

 

De : rade= xt-bounces@ietf.org [mailto:radext-bounces@ietf.org] De la part de Sanchez, Mauricio (HP Networking)
Envoy=E9 : mercredi 7 novembre 2012 18:25
=C0 : radext@ietf.org
Objet : [radext] RADEXT WG Last Call: NAI-based Dynamic Peer Di= scovery for RADIUS/TLS and RADIUS/DTLS

 

 

= This is an announcement of RADEXT WG last call on "NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS", prior to sen= ding the document to the IESG for publication as an Experimental RFC. =

The document is available for inspection h= ere:

http://tools.ietf.org/html/draft-ietf-radext-dyna= mic-discovery

&n= bsp;

= The RADEXT WG last call will last until Wednesday November 21, 2012. &= nbsp; If you have comments on the document, please file using TRAC system.  See below for summary of instructions.<= /p>

&n= bsp;

Thanks,
Mauricio and Jouni 

 

1.       To submit an issue in TRAC, you fi= rst need to login to the RADEXT WG site on the tools server:  http://tools.ietf.org/w= g/radext/trac/login 
2.       If = you don’t already have a login ID, you can obtain one by navigating t= o this site:   http://trac.tools.ietf.org/newlogin
3.       Onc= e you have obtained an account, and have logged in, you can file an issue b= y navigating to the  ticket entry form:http://trac.tools.ietf.org/wg/radext/trac/= newticket
4.       Whe= n opening an issue:
a.       The= Type: field should be set to “defect” for an issue with the cu= rrent document text, or “enhancement” for a proposed addition o= f functionality (such as an additional requirement). 
b.      The Prior= ity: field is set based on the severity of the Issue.   For examp= le, editorial issues are typically “minor” or “trivial= 221;. 
c.       The= Milestone: field should be set to milestone1 (useless, I know). 
d.      The Compo= nent: field should be set to the document you are filing the issue on. = ; 
e.      The Versi= on: field should be set to “1.0”. 
f.      &nbs= p; The Severity: field should be set to based on the status of the document= (e.g. “In WG Last Call” for a document in WG last call)=
g.      &nbs= p; The Keywords: and CC: fields can be left blank unless inspiration seizes= you. 
h.      The Assig= n To: field is generally filled in with the email address of the editor.&nb= sp;
5.       Typ= ically it won’t be necessary to enclose a file with the ticket, but i= f you need to, select “I have files to attach to this ticket”.&= nbsp;
6.       If = you want to preview your Issue, click on the “Preview” button.&= nbsp; When you’re ready to submit the issue, click on the “Crea= te Ticket” button. 
7.       If = you want to update an issue, go to the "View Tickets" page: = http://trac.= tools.ietf.org/wg/radext/trac/report/1  Click on the ticket # you = want to update, and then modify the ticket fields as required

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete al=
tere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for message=
s that have been modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E098517PEXCVZYM13corpora_-- From peterd@iea-software.com Wed Nov 7 10:25:48 2012 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 3FB5221F8B74 for ; Wed, 7 Nov 2012 10:25:48 -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 yMO-c7TYDIFQ for ; Wed, 7 Nov 2012 10:25: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 B4AB521F88DE for ; Wed, 7 Nov 2012 10:25:43 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 7 Nov 2012 10:25:43 -0800 Date: Wed, 7 Nov 2012 10:25:42 -0800 (Pacific Standard Time) From: Peter Deacon To: jouni korhonen 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: "radext@ietf.org" , "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] RADEXT WG Last Call: DTLS as a Transport Layer for RADIUS 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, 07 Nov 2012 18:25:48 -0000 On Wed, 7 Nov 2012, jouni korhonen wrote: > I see one ticket, which is marked as "closed". Hi Jouni, After a quick check there seems to be duplicate components for RADIUS over DTLS ('RDTLS' and 'dtls') Additional tickets in RDTLS component. regards, Peter From trac+radext@trac.tools.ietf.org Wed Nov 7 11:30:26 2012 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 8E75521F8B7A for ; Wed, 7 Nov 2012 11:30:26 -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 7XCMRfyy83mV for ; Wed, 7 Nov 2012 11:30:25 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A304C21F880C for ; Wed, 7 Nov 2012 11:30:25 -0800 (PST) Received: from localhost ([127.0.0.1]:38862 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWBKA-0003CX-Ki; Wed, 07 Nov 2012 20:30:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 19:30:06 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:1 Message-ID: <079.386ecc579e949d44ee81ef4640e4e18b@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.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] #15: DTLS Comments 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, 07 Nov 2012 19:30:26 -0000 #15: DTLS Comments Changes (by aland@…): * status: new => closed * resolution: => wontfix * component: RDTLS => dtls Comment: This issue has 3 items in it. In order: 1) I wonder if a more general warning about the possibility of down- negotiation would be a better fit. Sure. Suggest text. Don't just say "do more". 2) Why is this still done when DTLS is used for a transport? Very simple. If you're not going to send RADIUS packets, then the RADIUS server shouldn't be talking to you. The issue of "unrelated exchanges" is a red herring. 3) Encouraging (change SHOULD NOT to MAY) can only shine light on the issue and force implementors to address appropriately. No. This is a security issue. NASes which implement DTLS should use it. Otherwise, the protocol would be subject to a downgrade attack. -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 11:31:38 2012 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 15DD121F8831 for ; Wed, 7 Nov 2012 11:31:38 -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 9bEidbJR9rPY for ; Wed, 7 Nov 2012 11:31:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 23A3621F8825 for ; Wed, 7 Nov 2012 11:31:37 -0800 (PST) Received: from localhost ([127.0.0.1]:38931 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWBLa-0008HM-B4; Wed, 07 Nov 2012 20:31:34 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 19:31:34 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/63#comment:2 Message-ID: <079.9f49f2d9fa65d7ec373176cd1825f4ce@trac.tools.ietf.org> References: <064.b889eb683731df8d67009e6e4f3d97eb@trac.tools.ietf.org> X-Trac-Ticket-ID: 63 In-Reply-To: <064.b889eb683731df8d67009e6e4f3d97eb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, 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] #63: 4.1 session inactivity management 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, 07 Nov 2012 19:31:38 -0000 #63: 4.1 session inactivity management Changes (by aland@…): * status: new => closed * resolution: => fixed * component: RDTLS => dtls Comment: No longer relevant. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 11:36:39 2012 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 D460A21F8ACD for ; Wed, 7 Nov 2012 11:36:39 -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 fPDPqteGb1pw for ; Wed, 7 Nov 2012 11:36:39 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id DF91921F8AAD for ; Wed, 7 Nov 2012 11:36:38 -0800 (PST) Received: from localhost ([127.0.0.1]:39567 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWBQC-0004HU-9Q; Wed, 07 Nov 2012 20:36:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 19:36:20 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/64#comment:2 Message-ID: <079.55ee454eba24b5498b8092ad3d489eac@trac.tools.ietf.org> References: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, 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] #64: 4.1 source port inclusion in the tracking table 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, 07 Nov 2012 19:36:40 -0000 #64: 4.1 source port inclusion in the tracking table Changes (by aland@…): * status: new => closed * resolution: => wontfix * component: RDTLS => dtls Comment: > Throughout the document it is recommended clients use connected socket options... Now what happens when a client tries to send a new Access- Request message using a different source port over a DTLS session that was already established? Then it's not using the existing DTLS session. Client-server communication in UDP involves the client sending traffic from one source port to a well-known port on the server. The server responds to that client port. If the client starts sending traffic from another port, then it is another session. > Judging by keys of the table such a request would be discarded since there is no known session in the table matching key. Yes. That's how it works. > If this is the intention it should be made clear clients can't switch their source ports unless they also open a new DTLS session. Client implementors (most of us:) tend to gloss over server specific areas and may not realize the implication. I welcome suggestions for text to make it clearer. It's already as clear as I know how. > If true and this is really the intention what stops clients from originating packets from different processes per sec 3 above? Nothing. It's permitted, but not recommended. > My recommendation is to remove the source port from the tracking table key and just allow DTLS session to be client specific so any source port can be used as we do traditionally to get around the ID limit mess. Then how will you identify a DTLS session? There is nothing in the DTLS header which identifies a particular session. You can only identify the session by looking at the 5-tuple from IP/UDP. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 11:38:32 2012 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 E858D21F898B for ; Wed, 7 Nov 2012 11:38:32 -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 OPGCXvSDq6da for ; Wed, 7 Nov 2012 11:38:32 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3F95821F8932 for ; Wed, 7 Nov 2012 11:38:32 -0800 (PST) Received: from localhost ([127.0.0.1]:39605 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWBSI-0001rN-F3; Wed, 07 Nov 2012 20:38:30 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 19:38:30 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/67#comment:2 Message-ID: <079.35b9a15bfa02f61ad8e5e3d4bce7e04d@trac.tools.ietf.org> References: <064.58be969279a7a702baa53f302f5c4a8b@trac.tools.ietf.org> X-Trac-Ticket-ID: 67 In-Reply-To: <064.58be969279a7a702baa53f302f5c4a8b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, 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] #67: RADIUS vs RDTLS disambiguation (TLS Alert) 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, 07 Nov 2012 19:38:33 -0000 #67: RADIUS vs RDTLS disambiguation (TLS Alert) Changes (by aland@…): * status: new => closed * resolution: => fixed * component: RDTLS => dtls Comment: The detailed algorithm has been removed in the latest rev of the document. Please check that your concerns are addressed. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 11:39:43 2012 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 BD44921F8C72 for ; Wed, 7 Nov 2012 11:39: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=[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 O1k6auib1-gF for ; Wed, 7 Nov 2012 11:39:43 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E2BF821F8C21 for ; Wed, 7 Nov 2012 11:39:38 -0800 (PST) Received: from localhost ([127.0.0.1]:39631 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWBTM-0005Gt-S6; Wed, 07 Nov 2012 20:39:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 19:39:36 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/66#comment:2 Message-ID: <079.9711e52527ac7a59c41cfb34a5e78780@trac.tools.ietf.org> References: <064.80191165a4c2451d567e1fbc35d02c77@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <064.80191165a4c2451d567e1fbc35d02c77@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, 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] #66: NAT nits 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, 07 Nov 2012 19:39:43 -0000 #66: NAT nits Changes (by aland@…): * status: new => closed * resolution: => invalid Comment: > There are no problems with full cone or ALGs acting as proxies. Then they're not acting like a NAT gateway. Application-layer proxies which don't do NAT aren't NAT gateways. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: RDTLS | Version: 1.0 Severity: Active WG Document | Resolution: invalid Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 12:14:37 2012 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 28A6D21F8CAE for ; Wed, 7 Nov 2012 12:14:37 -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 If+QiVR6IYPk for ; Wed, 7 Nov 2012 12:14:36 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 2BF7E21F8C98 for ; Wed, 7 Nov 2012 12:14:36 -0800 (PST) Received: from localhost ([127.0.0.1]:43334 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWC10-0003g5-Kw; Wed, 07 Nov 2012 21:14:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 20:14:22 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/65#comment:2 Message-ID: <079.e191c1476c5a75e96499034d737bb3d0@trac.tools.ietf.org> References: <064.b5fbc75965f33629034d4be3708706fb@trac.tools.ietf.org> X-Trac-Ticket-ID: 65 In-Reply-To: <064.b5fbc75965f33629034d4be3708706fb@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, 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] #65: Multiple dtls sessions in a tuple? 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, 07 Nov 2012 20:14:37 -0000 #65: Multiple dtls sessions in a tuple? Changes (by aland@…): * status: new => assigned * component: RDTLS => dtls Comment: > Section 4.1 does not provide guidance regarding what to do when there is a new session established against a tuple having an existing session. Point taken. Do you have suggested text? > Can it maintain multiple sessions and broadcast any subsequent datagrams or does it automatically trigger discard of the previous session(s)? Multiple sessions for a 5-tuple are not supported. I welcome suggestions for what to do in this case. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: enhancement | Status: assigned Priority: trivial | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: Keywords: | --------------------------------+------------------------- Ticket URL: radext From aland@deployingradius.com Wed Nov 7 12:14:40 2012 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 DD0C121F8C98 for ; Wed, 7 Nov 2012 12:14:40 -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 t6aek8tqfFUF for ; Wed, 7 Nov 2012 12:14:40 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB3A621F89FE for ; Wed, 7 Nov 2012 12:14:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 3765E2240E49; Wed, 7 Nov 2012 21:14: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 dANj4LU1zFqI; Wed, 7 Nov 2012 21:14:37 +0100 (CET) Received: from dhcp-5482.meeting.ietf.org (dhcp-5482.meeting.ietf.org [130.129.84.130]) by power.freeradius.org (Postfix) with ESMTPSA id 6A36B2240903; Wed, 7 Nov 2012 21:14:36 +0100 (CET) Message-ID: <509AC12B.1010501@deployingradius.com> Date: Wed, 07 Nov 2012 15:14:35 -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" , jouni korhonen , "Sanchez, Mauricio \(HP Networking\)" Subject: Re: [radext] RADEXT WG Last Call: DTLS as a Transport Layer for RADIUS 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, 07 Nov 2012 20:14:41 -0000 Peter Deacon wrote: > After a quick check there seems to be duplicate components for RADIUS > over DTLS ('RDTLS' and 'dtls') Additional tickets in RDTLS component. I've changed the issues to "dtls", and commented on them. Alan DeKok. From trac+radext@trac.tools.ietf.org Wed Nov 7 12:27:22 2012 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 9F11121F8B3A for ; Wed, 7 Nov 2012 12:27:22 -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 WsWc224yUPls for ; Wed, 7 Nov 2012 12:27:22 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E90D721F8AB5 for ; Wed, 7 Nov 2012 12:27:21 -0800 (PST) Received: from localhost ([127.0.0.1]:44377 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWCDO-0000Ks-DV; Wed, 07 Nov 2012 21:27:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 20:27:10 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/19#comment:1 Message-ID: <081.e722f7245ea7bc638993f2ac31707792@trac.tools.ietf.org> References: <066.77d3e9e9494e20d0d43a42cd41674a69@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <066.77d3e9e9494e20d0d43a42cd41674a69@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.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] #19: i18n Issues with RFC 4282 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, 07 Nov 2012 20:27:22 -0000 #19: i18n Issues with RFC 4282 Changes (by aland@…): * status: new => closed * resolution: => worksforme Comment: There doesn't seem to be a request to change anything in this issue. The later discussion was that the i18n issues in EAP are type-specific, and that 4282 doesn't apply to them. -- -----------------------------------+------------------------- Reporter: aland@… | Owner: aland@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Resolution: worksforme Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 12:30:30 2012 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 7480221F8B6E for ; Wed, 7 Nov 2012 12:30: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 pNvxDLq0g3Qy for ; Wed, 7 Nov 2012 12:30:28 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8421F8A26 for ; Wed, 7 Nov 2012 12:30:27 -0800 (PST) Received: from localhost ([127.0.0.1]:44472 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWCGX-0002kI-I2; Wed, 07 Nov 2012 21:30:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 20:30:25 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/20#comment:1 Message-ID: <068.4463a154f60d75f30685889fbdbed4aa@trac.tools.ietf.org> References: <053.962405b50413cf83ec5aba1e1eb971a0@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <053.962405b50413cf83ec5aba1e1eb971a0@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.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] #20: Errata for RFC 4282 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, 07 Nov 2012 20:30:30 -0000 #20: Errata for RFC 4282 Changes (by aland@…): * status: new => closed * resolution: => fixed Comment: I believe that the 4282bis document addresses all of these issues. The bulk of these comments indicate that the issues (if any) are not relevant for 4282bis. -- -----------------------------------+------------------------- Reporter: ah@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: RFC4282bis | Version: 1.0 Severity: Candidate WG Document | Resolution: fixed Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 13:47:18 2012 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 0775721F8C9C for ; Wed, 7 Nov 2012 13:47:18 -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 L3351+FsGXSo for ; Wed, 7 Nov 2012 13:47:17 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB8021F8AF0 for ; Wed, 7 Nov 2012 13:47:17 -0800 (PST) Received: from localhost ([127.0.0.1]:51531 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWDSe-0007tK-4T; Wed, 07 Nov 2012 22:47:09 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, peterd@iea-software.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 21:47:00 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:2 Message-ID: <079.46fb8fab81b39abacf70eed18c3609b5@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, peterd@iea-software.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] #15: DTLS Comments 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, 07 Nov 2012 21:47:18 -0000 #15: DTLS Comments Comment (by peterd@…): WRT 2) what is the reason or benefit for silent discard as opposed to maintaining parity with RADIUS/UDP behavior where the underlying transport currently need not be blessed or re-established? My concern with unnecessarily terminating DTLS sessions you increase the possibility of existing in the region where packet loss cannot be disambiguated from a closed session from perspective of the sender. This requires a longer delay than necessary before the client attempts a new DTLS session. If one is to require behavior with the strongest MUST language then an affirmative technical justification should be available as to why the behavior is NECESSARY. Separately this response further assumes silent discard means the request is somehow invalid. This is incorrect. Accounting request may be silently discarded if the RADIUS server is unable to take responsibility for logging or forwarding a particular accounting message to persistent storage. RADIUS messages may be silently discarded if they contain an unrecognized command code. With regards to "red herring" I believe my point is valid - any pending responses will in fact be discarded by UNECESSARY closure of DTLS session. -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 14:43:05 2012 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 62DAC21F84E0 for ; Wed, 7 Nov 2012 14:43:05 -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 HMRfDDm+zpWt for ; Wed, 7 Nov 2012 14:43:00 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id BFDDA21F84DF for ; Wed, 7 Nov 2012 14:43:00 -0800 (PST) Received: from localhost ([127.0.0.1]:56288 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWEKW-0001no-BN; Wed, 07 Nov 2012 23:42:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, peterd@iea-software.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 22:42:40 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:3 Message-ID: <079.f2f6bb822966bdb58a23595e923a50e8@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, peterd@iea-software.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] #15: DTLS Comments 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, 07 Nov 2012 22:43:05 -0000 #15: DTLS Comments Comment (by aland@…): > My concern with unnecessarily terminating DTLS sessions you increase the possibility of existing in the region where packet loss cannot be disambiguated from a closed session from perspective of the sender. My response is the same as before. If the sender doesn't implement RADIUS, he has NO BUSINESS talking to the RADIUS server. Please describe in detail why it's a good idea to maintain DTLS connections to a client which is sending you crap packets. It makes absolutely no sense. > Separately this response further assumes silent discard means the request is somehow invalid. This is incorrect. I disagree. The RFCs are clear on this topic. Only invalid packets are silently discarded. There is no text anywhere saying valid packets may be "silently discarded" > Accounting request may be silently discarded if the RADIUS server is unable to take responsibility for logging or forwarding a particular accounting message to persistent storage. Absolute nonsense. See RFC 2866. The accounting packets are "silently discarded" when they are malformed. The accounting server may choose to NOT RESPOND. However, it does not "silently discard" the request, as per the definition in Section 1.1. of RFC 2866. > RADIUS messages may be silently discarded if they contain an unrecognized command code. Yes. The RFCs make it clear which command codes are allowed to be sent to which ports. If the client violates that, > With regards to "red herring" I believe my point is valid - any pending responses will in fact be discarded by UNECESSARY closure of DTLS session. This is a security issue for me, which trumps being polite. A client which sends "good" RADIUS packets followed by garbage to the RADIUS server is misbehaving. It is not implementing the RADIUS protocol. It is potentially compromised, and is attacking the RADIUS server. The only sane thing to do when a client sends garbage is to stop talking to it. -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 14:58:20 2012 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 E22BE21F8550 for ; Wed, 7 Nov 2012 14:58:20 -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 QZ0xYlb0lc3p for ; Wed, 7 Nov 2012 14:58:16 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id B0C8E21F8903 for ; Wed, 7 Nov 2012 14:58:16 -0800 (PST) Received: from localhost ([127.0.0.1]:58122 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWEZP-0001dD-UX; Wed, 07 Nov 2012 23:58:08 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 22:58:03 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/66#comment:3 Message-ID: <079.28be0c0298e6308a43423e3743f0d487@trac.tools.ietf.org> References: <064.80191165a4c2451d567e1fbc35d02c77@trac.tools.ietf.org> X-Trac-Ticket-ID: 66 In-Reply-To: <064.80191165a4c2451d567e1fbc35d02c77@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.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] #66: NAT nits 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, 07 Nov 2012 22:58:21 -0000 #66: NAT nits Comment (by peterd@…): The phrase "Network Address Translation (NAT) is fundamentally incompatible with RADIUS" is inaccurate. Full cone NAT is still "NAT" yet shares none of the enumerated identity problems. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: RDTLS | Version: 1.0 Severity: Active WG Document | Resolution: invalid Keywords: | --------------------------------+------------------------- Ticket URL: radext From bernard_aboba@hotmail.com Wed Nov 7 15:02:11 2012 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 A662421F8944 for ; Wed, 7 Nov 2012 15:02:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[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 hvSX35RogGn0 for ; Wed, 7 Nov 2012 15:02:07 -0800 (PST) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by ietfa.amsl.com (Postfix) with ESMTP id 853CE21F894E for ; Wed, 7 Nov 2012 15:02:07 -0800 (PST) Received: from BLU002-W148 ([65.55.111.72]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 7 Nov 2012 15:02:06 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_f2ac1d45-0e0f-48cb-899a-634eb7b34567_" X-Originating-IP: [130.129.23.28] From: Bernard Aboba To: "radext@ietf.org" Date: Wed, 7 Nov 2012 15:02:06 -0800 Importance: Normal In-Reply-To: <509AD4C2.8070108@deployingradius.com> References: , <509AD4C2.8070108@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2012 23:02:06.0606 (UTC) FILETIME=[E88FA2E0:01CDBD3B] Subject: [radext] Review of draft-dekok-radext-nai 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, 07 Nov 2012 23:02:11 -0000 --_f2ac1d45-0e0f-48cb-899a-634eb7b34567_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of the issues with RFC 4282 was that it began with the assumption that = a single form of the NAI existed independent of the protocol and context in= which the NAI was used. This assumption was wrong. =20 Given the problems with RFC 4282=2C I am very wary of attempting to simult= aneously define the NAI as well as to talk about how it is internationalize= d in all protocols in a single document. My suggestion is that this docume= nt focus *solely* on the definition of the NAI=2C with other documents talk= ing about internationalization within specific protocols including RADIUS= =2C Diameter and EAP.=20 Here are examples of text that may not belong in this document:=0A= See [RFC5198] for a discussion of normalization=3B implementations of=0A= this specification MUST use the Normal Form Composed (NFC) for NAIs. [BA] There is context missing here. For what operations and protocols is N= FC to be used (e.g. comparison in RADIUS?) It may be best to discuss the de= tails within the context of specific protocols.=20 Internationalization of the realm portion of the=0A= NAI is based on "Internationalized Email Headers" [RFC5335]. [BA] This is another statement whose correctness may depend on the specific= protocol in which the NAI is used. =20 2.6. The Normalization Process=0A= =0A= All normalization MUST be performed by end systems that take "local"=0A= text as input. That is=2C text that is in an encoding other than=0A= UTF-8=2C or that has locale-specific variations. In a network access=0A= setting=2C such systems are typically the client (e.g. EAP supplicant)= =0A= and the Authentication=2C Authorization=2C and Accounting (AAA) server. [BA] This is a statement that may apply to specific protocols and not to ot= hers. For example=2C PPP peers may not normalize NAIs. So a general MUST d= oesn't make sense.=0A= =0A= All other AAA systems (proxies=2C etc.) MUST NOT perform=0A= normalization. These other systems do not have access to locale and=0A= character set information that is available to end systems.=0A= [BA] I don't believe that general statements about "AAA" are appropriate in= this document. Better to deal with specifics of RADIUS and Diameter in do= cuments created for that purpose. =0A= That is=2C all processing of NAIs from "local" character sets and=0A= locales to UTF-8 is performed by edge systems=2C prior to the NAIs=0A= entering the AAA system. Inside of an AAA system=2C NAIs are sent over= =0A= the wire in their canonical form=2C and this canonical form is used for= =0A= all NAI and/or realm comparisons.=0A= [BA] This is another general statement that probably should be removed and = made (or not) within a specific context. For example=2C not all EAP method= s will normalize NAIs as advocated here. =0A= In contrast to the comments in [RFC4282] Section 2.4=2C we expect AAA=0A= systems to perform NAI comparisons=2C matching=2C and AAA routing based= =0A= on the NAI as it is received. This specification provides a=0A= canonical representation=2C ensures that intermediate systems such as=0A= AAA proxies do not need to perform translations=2C and can be expected= =0A= to work through systems that are unaware of international character=0A= sets.=0A= =0A= For example=2C much of the common realm routing can be done on the=0A= "utf8-realm" portion of NAI=2C through simple checks for equality.=0A= This routing can be done even if the AAA proxy is unaware of=0A= internalized domain names. All that is required is for the AAA proxy=0A= to be able to enter=2C store=2C and compare 8-bit data.=0A= =0A= EAP supplicants MUST normalize user names that get placed in the EAP-=0A= Response/Identity field. They MUST NOT copy localized text into that=0A= field. This normalization SHOULD be performed once=2C and then cached= =0A= for subsequent use.=0A= [BA] It is not clear to me that this document should attempt to tackle AAA = and EAP internationalization as well as NAI definition.=20 = --_f2ac1d45-0e0f-48cb-899a-634eb7b34567_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One of the issues with RFC 4282 = was that it began with the assumption that a single form of the NAI existed= independent of the protocol and context in which the NAI was used.  = =3BThis assumption was wrong.  =3B

Given the problems with= RFC 4282=2C  =3BI am very wary of attempting to simultaneously define = the NAI as well as to talk about how it is internationalized in all protoco= ls in a single document.  =3BMy suggestion is that this document focus = *solely* on the definition of the NAI=2C with other documents talking about= internationalization within specific protocols including RADIUS=2C Diamete= r and EAP. =3B

Here are examples of text that may no= t belong in this document:
=0A=
   See [RFC5198] for a d=
iscussion of normalization=3B implementations of=0A=
   this specification MUST use the Normal Form Composed (NFC) for NAIs.

[BA] There is context missing here.  For what =
operations and protocols is NFC to be used (e.g. comparison in RADIUS?) It =
may be best to discuss the details within the context of specific protocols=
. 

   Internationalization of the realm p=
ortion of the=0A=
   NAI is based on "Internationalized Email Headers" [RFC5335].

=
[BA] This is another statement whose correctness may depend on the specific=
 protocol in which the NAI is used.  

2.6.  The Normalization Process
=0A=
=0A=
   All normalization MUST be performed by end systems that take "local"=0A=
   text as input.  That is=2C text that is in an encoding other than=0A=
   UTF-8=2C or that has locale-specific variations.  In a network access=0A=
   setting=2C such systems are typically the client (e.g. EAP supplicant)=
=0A=
   and the Authentication=2C Authorization=2C and Accounting (AAA) server.<=
/pre>

[BA] This is a statement that may apply t=
o specific protocols and not to others. For example=2C PPP peers may not no=
rmalize NAIs.  So a general MUST doesn't make sense.=0A=
=0A=
   All other AAA systems (proxies=2C etc.)  MUST NOT perform=0A=
   normalization.  These other systems do not have access to locale and=0A=
   character set information that is available to end systems.=0A=

[BA] I don't believ=
e that general statements about "AAA" are appropriate in this document.  Be=
tter to deal with specifics of RADIUS and Diameter in documents created for=
 that purpose. 
=0A=
   That is=2C all processing of NAIs from "local" character sets and=0A=
   locales to UTF-8 is performed by edge systems=2C prior to the NAIs=0A=
   entering the AAA system.  Inside of an AAA system=2C NAIs are sent over=
=0A=
   the wire in their canonical form=2C and this canonical form is used for=
=0A=
   all NAI and/or realm comparisons.=0A=

[BA] This is anothe=
r general statement that probably should be removed and made (or not) withi=
n a specific context.  For example=2C not all EAP methods will normalize NA=
Is as advocated here. 
=
=0A=
   In contrast to the comments in [RFC4282] Section =3B2.4=2C we expect AAA=0A=
   systems to perform NAI comparisons=2C matching=2C and AAA routing based=
=0A=
   on the NAI as it is received.  This specification provides a=0A=
   canonical representation=2C ensures that intermediate systems such as=0A=
   AAA proxies do not need to perform translations=2C and can be expected=
=0A=
   to work through systems that are unaware of international character=0A=
   sets.=0A=
=0A=
   For example=2C much of the common realm routing can be done on the=0A=
   "utf8-realm" portion of NAI=2C through simple checks for equality.=0A=
   This routing can be done even if the AAA proxy is unaware of=0A=
   internalized domain names.  All that is required is for the AAA proxy=0A=
   to be able to enter=2C store=2C and compare 8-bit data.=0A=
=0A=
   EAP supplicants MUST normalize user names that get placed in the EAP-=0A=
   Response/Identity field.  They MUST NOT copy localized text into that=0A=
   field.  This normalization SHOULD be performed once=2C and then cached=
=0A=
   for subsequent use.=0A=


[BA] It is not clear to me that this docume=
nt should attempt to tackle AAA and EAP internationalization as well as NAI=
 definition. =3B

= --_f2ac1d45-0e0f-48cb-899a-634eb7b34567_-- From trac+radext@trac.tools.ietf.org Wed Nov 7 15:07:58 2012 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 095B721F8B39 for ; Wed, 7 Nov 2012 15:07:58 -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 8-YBfNtXCajY for ; Wed, 7 Nov 2012 15:07:56 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id AB26B21F8B2F for ; Wed, 7 Nov 2012 15:07:56 -0800 (PST) Received: from localhost ([127.0.0.1]:59237 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWEip-0003Kd-6S; Thu, 08 Nov 2012 00:07:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 23:07:47 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/64#comment:3 Message-ID: <079.2179ec2326c8a5353f691c9daaefe77f@trac.tools.ietf.org> References: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.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] #64: 4.1 source port inclusion in the tracking table 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, 07 Nov 2012 23:07:58 -0000 #64: 4.1 source port inclusion in the tracking table Comment (by peterd@…): A solution is to assume a limited number of sessions from the same source IP address and send same UDP packet to each active DTLS session. Sessions for which the packet do not belong would simply be ignored by the DTLS stack. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 15:28:19 2012 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 5C32521F88EA for ; Wed, 7 Nov 2012 15:28:19 -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 UsgWhE5AbinI for ; Wed, 7 Nov 2012 15:28:15 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 29CC021F8B7C for ; Wed, 7 Nov 2012 15:28:15 -0800 (PST) Received: from localhost ([127.0.0.1]:60849 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWF2U-0004BF-Bu; Thu, 08 Nov 2012 00:28:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, peterd@iea-software.com X-Trac-Project: radext Date: Wed, 07 Nov 2012 23:28:06 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:4 Message-ID: <079.7fea71d3463416916743b04ac37afdfe@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, peterd@iea-software.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] #15: DTLS Comments 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, 07 Nov 2012 23:28:19 -0000 #15: DTLS Comments Comment (by peterd@…): Sec 1.1 of RFC 2866 "This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter." Sec 1.1 of draft-ietf-radext-dtls-02 "This means that the implementation discards the packet without further processing. See Section X.Y for additional requirements on packets being silently discarded." How does "ignoring" an accounting packet because you know you can't do anything with it differ from the definition of silent discard based on definitions referenced? How is the reader to understand difference between ignore and silent discard? Sec 4.1 draft-ietf-radext-dtls-02: "Last Packet A variable containing a timestamp which indicates when the last valid packet was received for this connection. Packets which are "silently discarded" MUST NOT update this variable." With regards to security client has already authenticated itself to server. To assume a security benefit one must assume ALL of the systems security has already failed in which case the well of value has already dried up. I think there is additional benefit in maintaining parity with RADIUS. RADIUS/UDP servers are not required to distrust any further communication if they receive a packet they don't like. -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 16:25:42 2012 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 4967E21F8C0C for ; Wed, 7 Nov 2012 16:25:42 -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 fs3u3AhOsHiq for ; Wed, 7 Nov 2012 16:25:41 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3909A21F8BF2 for ; Wed, 7 Nov 2012 16:25:41 -0800 (PST) Received: from localhost ([127.0.0.1]:38332 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWFvr-0007dj-RQ; Thu, 08 Nov 2012 01:25:29 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 00:25:19 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:5 Message-ID: <079.7cb19244ccfb3fd7493410b9b5883d73@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, peterd@iea-software.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] #15: DTLS Comments 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, 08 Nov 2012 00:25:42 -0000 #15: DTLS Comments Comment (by aland@…): > How does "ignoring" an accounting packet because you know you can't do anything with it differ from the definition of silent discard based on definitions referenced? Because "silently discard" has a well-defined meaning, as stated in Section 1.1, and used throughout the document. The discussion of not responding says this: If the RADIUS accounting server is unable to successfully record the accounting packet it MUST NOT send an Accounting-Response acknowledgment to the client. Note it doesn't say "silently discard" the request. It says it doesn't send a reply. > How is the reader to understand difference between ignore and silent discard? I can't really answer that. If the difference isn't obvious, I suggest asking the WG to re-write RFC 2866. > RADIUS/UDP servers are not required to distrust any further communication if they receive a packet they don't like. Sure. But there's no connection in UDP. -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 16:25:52 2012 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 B2B6321F8C0D for ; Wed, 7 Nov 2012 16:25:52 -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 gqZFrIAS3R4M for ; Wed, 7 Nov 2012 16:25:52 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 32B7921F8BF2 for ; Wed, 7 Nov 2012 16:25:52 -0800 (PST) Received: from localhost ([127.0.0.1]:38408 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWFwL-0002M8-9M; Thu, 08 Nov 2012 01:25:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 00:25:49 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/64#comment:4 Message-ID: <079.28d85ac5a6d96f47a1f4b819505149c0@trac.tools.ietf.org> References: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.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] #64: 4.1 source port inclusion in the tracking table 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, 08 Nov 2012 00:25:52 -0000 #64: 4.1 source port inclusion in the tracking table Comment (by aland@…): > A solution is to assume a limited number of sessions from the same source IP address and send same UDP packet to each active DTLS session. That is just not scalable. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 18:37:47 2012 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 5576B21F8A72 for ; Wed, 7 Nov 2012 18:37:47 -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 RNJ44XSLzNMk for ; Wed, 7 Nov 2012 18:37:46 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id BCF3421F8A69 for ; Wed, 7 Nov 2012 18:37:46 -0800 (PST) Received: from localhost ([127.0.0.1]:49883 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWHzn-00049K-4G; Thu, 08 Nov 2012 03:37:38 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 02:37:31 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:6 Message-ID: <079.394fb3305dec8265cfe64f60972cf27a@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, peterd@iea-software.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] #15: DTLS Comments 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, 08 Nov 2012 02:37:47 -0000 #15: DTLS Comments Comment (by peterd@…): Having quoted 1.1 in its entirety I observed no text dedicated to constraining underlying reason during definition of "silent discard". What seems to be implied since silent discard happens to be used to describe failures such as malformed requests or bad authenticators an implicit constraint is created against the meaning of the term. I disagree. I believe definitions exist on their own outside of their use. Regardless there still should be a valid technical justification to support a MUST requirement. The only technical justification provided was security which does not seem credible given TLS layer is completely responsible for security of the system. -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 19:11:11 2012 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 7766021F8A3B for ; Wed, 7 Nov 2012 19:11: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 aIkXcjr6Fspo for ; Wed, 7 Nov 2012 19:11:10 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9F521F8A31 for ; Wed, 7 Nov 2012 19:11:10 -0800 (PST) Received: from localhost ([127.0.0.1]:53134 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWIW8-0004Ko-Rk; Thu, 08 Nov 2012 04:11:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 03:10:56 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:7 Message-ID: <079.9cc418f7abb7091056d9f2457f4742bc@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, peterd@iea-software.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] #15: DTLS Comments 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, 08 Nov 2012 03:11:11 -0000 #15: DTLS Comments Comment (by aland@…): > Having quoted 1.1 in its entirety I observed no text dedicated to constraining underlying reason during definition of "silent discard". It would help to read the rest of RFC 2865. Section 1.1 defines what is meant by "silently discard". The rest of the document describes the situations (and reasons) why you "silently discard" a packet. I fail to see why there is ANY controversy here. RFC 2865 has been out for over a decade. It's predecessors are nearly 20 years old. This is the first indication that anyone has any issue with that text. > What seems to be implied since silent discard happens to be used to describe failures such as malformed requests or bad authenticators an implicit constraint is created against the meaning of the term. Inventing a straw man doesn't make your position stronger. > I disagree. I believe definitions exist on their own outside of their use. Straw man. > Regardless there still should be a valid technical justification to support a MUST requirement. Straw man. I've been explaining the technical justification. Have you been reading my messages? >The only technical justification provided was security which does not seem credible given TLS layer is completely responsible for security of the system. Nonsense. By that "logic", there's no need to verify the format of a RADIUS packet received via DTLS. After all, the TLS layer is completely responsible for security, so anything it sends you MUST be well formed, right? So there's no need to verify the packet format, the attribute size / content, etc. You can just rely on TLS security. By that "logic", we shouldn't worry about viruses spreading over HTTPS. After all, the connection is "secured" by TLS. One last time: When a RADIUS server has a DTLS connection to a client, the client is expected to send RADIUS packets inside of that DTLS connection. If, instead, the client sends non-RADIUS packets, then the connection is non- RADIUS. There is no reason for a RADIUS server to talk to a client that isn't doing RADIUS. Having a DTLS transport for non-RADIUS doesn't matter. The RADIUS server only talks RADIUS. And yes, I understand your position. There is little to no application cost to throw away a malformed RADIUS packet received inside of a DTLS datagram. The issue is I don't *care* about the application cost. I care about network security. I will not reply to any further comments on this topic. I have explained my position, and had it countered via straw-man arguments. I've asked for explanations of your position, and gotten little more than "just 'cause". -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 19:33:47 2012 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 E6A9B21F88B1 for ; Wed, 7 Nov 2012 19:33:47 -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 FRedqsH5+3Jh for ; Wed, 7 Nov 2012 19:33:47 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 52C2221F88A3 for ; Wed, 7 Nov 2012 19:33:47 -0800 (PST) Received: from localhost ([127.0.0.1]:55238 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWIrv-0007mk-OX; Thu, 08 Nov 2012 04:33:37 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 03:33:27 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/64#comment:5 Message-ID: <079.1401cbaf6b623c623863b8c5a2c44a4f@trac.tools.ietf.org> References: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.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] #64: 4.1 source port inclusion in the tracking table 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, 08 Nov 2012 03:33:48 -0000 #64: 4.1 source port inclusion in the tracking table Comment (by peterd@…): There are related unresolved problems such as what to do when multiple connections are attempted from the same source port from possibly recycled source port happening to still have an existing valid session. I realize with a many:1 NAT you could construct a scenario with lots of clients opening sessions from the same apparent address ... this scenario was always problematic with RADIUS due to keying of secret with source address. I think the solution of broadcasting UDP packet to each DTLS session per source address significantly simplifies implementations who also no longer need to worry about establishing and maintaining multiple DTLS sessions with the same server. With regards to scalability DTLS sequence window could be leveraged to effectively preselect candidate sessions minimizing any impact of large numbers of sessions from single source address. My first choice for resolution requires changes to wire format. A small 4 byte header before the DTLS header is added to each UDP packet. One byte to set a RADIUS command code reserved specifically for RADIUS/DTLS. Remaining three bytes used for DTLS session identification replacing source port in tuple. {{{ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DTLS ... }}} Clients establishing new DTLS sessions send Session-ID 0. When DTLS session is allocated server responds with Session-ID. In all subsequent requests Session-ID is sent by clients. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 7 20:28:02 2012 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 1C36021F8A3E for ; Wed, 7 Nov 2012 20:28: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=[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 OOYf2pWVU3p3 for ; Wed, 7 Nov 2012 20:28:01 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7052C21F8A0C for ; Wed, 7 Nov 2012 20:28:01 -0800 (PST) Received: from localhost ([127.0.0.1]:60208 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWJiO-0007l2-CR; Thu, 08 Nov 2012 05:27:55 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 04:27:40 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/15#comment:8 Message-ID: <079.7082f8d0bca275850f5c83967ca785c3@trac.tools.ietf.org> References: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <064.8c228afea28d3876f680fe81094a8ce8@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, peterd@iea-software.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] #15: DTLS Comments 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, 08 Nov 2012 04:28:02 -0000 #15: DTLS Comments Comment (by peterd@…): I have no problem with RFC 2865 definition of silently discard. I have a problem with a characterization of silently discard not supported by existing text. Unfortunately after going back and checking I see no technical justification for a MUST requirement other than the security reference. Obviously trust established using DTLS between client and server does not preclude server from acting in any way it deems appropriate to protect itself from the client. The problem no evidence has been supplied to support why this approach would in any way be effective in helping the server protect itself to justify a MUST requirement. While text requires disconnection of the TLS session nothing in this document prevents client from simply reconnecting and continuing its assault on the server with impunity. RADIUS does not specify punitive actions against peers it believes may be acting in bad faith other than what is necessary to ensure the integrity of the protocol. The integrity of RADIUS/DTLS is not credibly affected by unnecessarily disconnecting DTLS sessions to punish an implementation. I think it is important everything possible is done to minimize instances of server DTLS session closure to what is absolutely necessary to prevent unnecessary service delays. -- -----------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Candidate WG Document | Resolution: wontfix Keywords: | -----------------------------------+------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Thu Nov 8 06:31:54 2012 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 460C721F8B32 for ; Thu, 8 Nov 2012 06:31:54 -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 G2iZKdoHoEU3 for ; Thu, 8 Nov 2012 06:31:53 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7E24F21F8B50 for ; Thu, 8 Nov 2012 06:31:53 -0800 (PST) Received: from localhost ([127.0.0.1]:57158 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWT8o-0006gC-Rq; Thu, 08 Nov 2012 15:31:44 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 14:31:34 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/64#comment:6 Message-ID: <079.14e6a46e341e0294c04dc1b8116b81b6@trac.tools.ietf.org> References: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.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] #64: 4.1 source port inclusion in the tracking table 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, 08 Nov 2012 14:31:54 -0000 #64: 4.1 source port inclusion in the tracking table Comment (by aland@…): > There are related unresolved problems such as what to do when multiple connections are attempted from the same source port from possibly recycled source port happening to still have an existing valid session. As the document says, RADIUS is fundamentally incompatible with NAT. The problems therefore cannot be resolved. > My first choice for resolution requires changes to wire format. Which has its own set of issues. > Clients establishing new DTLS sessions send Session-ID 0. > When DTLS session is allocated server responds with Session-ID. In all subsequent requests Session-ID is sent by clients. And what do you do when you get multiple requests from the same source port with Session-ID 0? Putting bandaids on an unsolvable problem is just wasting everyones time. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------- Ticket URL: radext From diego@tid.es Thu Nov 8 06:35:03 2012 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 73BC721F8A78 for ; Thu, 8 Nov 2012 06:35:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.111 X-Spam-Level: X-Spam-Status: No, score=-6.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 iQxX7WZWNZBm for ; Thu, 8 Nov 2012 06:35:02 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 459FE21F85E2 for ; Thu, 8 Nov 2012 06:35:02 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MD600H46B69B8@tid.hi.inet> for radext@ietf.org; Thu, 08 Nov 2012 15:35:01 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 3E.F0.05494.413CB905; Thu, 08 Nov 2012 15:35:00 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MD600H4LB6CB8@tid.hi.inet> for radext@ietf.org; Thu, 08 Nov 2012 15:35:00 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0318.004; Thu, 08 Nov 2012 15:34:59 +0100 Date: Thu, 08 Nov 2012 14:34:59 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "Sanchez, Mauricio (HP Networking)" Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [radext] RADEXT recharter proposal Thread-index: AQHNvQ7e/rCT9/yTIUeexf7vFvauOJff8ZGA X-AuditID: 0a5f4e69-b7fc06d000001576-0b-509bc314cf8c X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNKsWRmVeSWpSXmKPExsXCFe9nqCt6eHaAwZZbTBYtr2ayOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+6H2+wFh7grbtz+yN7AOIe7i5GTQ0LAROLYh4VsELaYxIV7 64FsLg4hgW2MEv/3HmWHcH4ySpzY9JsJwpnGKPHqyGJmkBYWAVWJH8+XgLWzAdmPmn+zg9jC AvoSf7//ALM5BUwlPnzcA7VCQeLPuccsXYwcHCICjhILvjiChJkF1CUarrxlAbF5Bbwlpp/b ywgRN5O4dbWBHSIuKPFj8j2wVpD6KVNyIUrEJZpbb7JA2IoS0xY1gLUyCshKvJs/nxXEFhEw kJj/bR4jhG0k8f3NZ2aIawQkluw5D2WLSrx8/A+sXggYKFN737JPYJSYheSKWUiumIVwxSwk V8xCcsUCRtZVjGLFSUWZ6RkluYmZOekGRnoZmXqZeaklmxghMZe5g3H5TpVDjAIcjEo8vDcy ZgcIsSaWFVfmHmKU5GBSEuV9uB8oxJeUn1KZkVicEV9UmpNafIhRgoNZSYTXcx9QjjclsbIq tSgfJiXDwaEkwXv9IFBKsCg1PbUiLTMHmFhg0kwcnCDtPEDtyodA2osLEnOLM9Mh8qcYJaXE eS+ANAuAJDJK8+B6XzGKAx0pzPsAJMsDTIFwXa+ABjIBDSy+NgNkYEkiQkqqgbG2Yhr3pIz5 zhfmeP/svsV1meHIlLWdWX1q15fNWsPxozdKLe1Qv8nNxv+hkWfq9rfE2HzfHLf+TWTpt6P6 zx7dVbJe1JtswrWvbuW+uUeseXSyOapfZFeG32QIb75fXCCh+y6zKT3s30TlHUYibu9+J7qc trn38Xrj2z47hunhn2+mfA2unKzEUpyRaKjFXFScCAAU2xcXPgMAAA== References: Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter 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: Thu, 08 Nov 2012 14:35:03 -0000 SGkgTWF1cmljaW8sDQoNCkp1c3QgYSBtaW5vciBudWFuY2Ugb24gdGFyZ2V0IGRhdGVzLCB0byBh dm9pZCBhZGRpbmcgb3ZlcmR1ZSBpdGVtcyA6KQ0KDQpPbiA3IE5vdiAyMDEyLCBhdCAxMjozOSAs IFNhbmNoZXosIE1hdXJpY2lvIChIUCBOZXR3b3JraW5nKSB3cm90ZToNCg0KPiBKYW4gMjAxMiBS QURJVVMgb3ZlciBEVExTIEktRCBzdWJtaXR0ZWQgYXMgYW4gRXhwZXJpbWVudGFsIFJGQw0KPiBG ZWIgMjAxMiBSQURJVVMgcGFja2V0IGZyYWdtZW50YXRpb24gc3VibWl0dGVkIGFzIGFuIEV4cGVy aW1lbnRhbCBSRkMNCj4gTWF5IDIwMTMgUkFESVVTIHN1cHBvcnQgZm9yIE5BSSBJbnRlcm5hdGlv bmFsaXphdGlvbiBJLUQgc3VibWl0dGVkIGFzIGEgUHJvcG9zZWQgU3RhbmRhcmQgUkZDDQoNCkFs bCB0aGUgIjIwMTIiIGFib3ZlIHNob3VsZCBiZSAiMjAxMyIsIHJpZ2h0Pw0KDQpCZSBnb29kZQ0K DQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZpZXJubyINCg0KRHIgRGll Z28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxlLnRpZC5lcy9kaWVnby5s b3Blei8NCg0KZS1tYWlsOiBkaWVnb0B0aWQuZXMNClRlbDogICAgKzM0IDkxMyAxMjkgMDQxDQpN b2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpFc3RlIG1l bnNhamUgc2UgZGlyaWdlIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLiBQdWVkZSBj b25zdWx0YXIgbnVlc3RyYSBwb2zDrXRpY2EgZGUgZW52w61vIHkgcmVjZXBjacOzbiBkZSBjb3Jy ZW8gZWxlY3Ryw7NuaWNvIGVuIGVsIGVubGFjZSBzaXR1YWRvIG3DoXMgYWJham8uDQpUaGlzIG1l c3NhZ2UgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkgZm9yIGl0cyBhZGRyZXNzZWUuIFdlIG9ubHkg c2VuZCBhbmQgcmVjZWl2ZSBlbWFpbCBvbiB0aGUgYmFzaXMgb2YgdGhlIHRlcm1zIHNldCBvdXQg YXQ6DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From klaas@wierenga.net Thu Nov 8 07:38:07 2012 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 113A721F851C; Thu, 8 Nov 2012 07:38:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.318 X-Spam-Level: X-Spam-Status: No, score=-1.318 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 20CBPEzbs2z4; Thu, 8 Nov 2012 07:38:06 -0800 (PST) Received: from out43-ams.mf.surf.net (out43-ams.mf.surf.net [145.0.1.43]) by ietfa.amsl.com (Postfix) with ESMTP id 5F74F21F8A78; Thu, 8 Nov 2012 07:38:03 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qA8Fc1xn013563; Thu, 8 Nov 2012 16:38:01 +0100 Received: from dhcp-932d.meeting.ietf.org ([130.129.11.45]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWU5v-0001VP-Po; Thu, 08 Nov 2012 16:32:40 +0100 Mime-Version: 1.0 (1.0) From: Klaas Wierenga Content-Type: multipart/alternative; boundary=Apple-Mail-3E464818-CBF5-4B1E-B7C3-932341218BD0 X-Mailer: iPad Mail (10A523) Message-Id: Date: Thu, 8 Nov 2012 10:37:59 -0500 Content-Transfer-Encoding: 7bit To: "radext-chairs@ietf.org" X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vIl3C1PR - 5e315eb6bced - 20121108 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "radext@ietf.org" , Tomasz Wolniewicz , Stefan Winter Subject: [radext] Adopt draft-wierenga-ietf-eduroam? 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, 08 Nov 2012 15:38:07 -0000 --Apple-Mail-3E464818-CBF5-4B1E-B7C3-932341218BD0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Dear chairs, I would like https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/ t= o be considered for adoption as WG item.=20 We could also progress it as independent submission but given that a number o= f radext work items are inspired by implementation experience in eduroam and that we in particular are looking for document rev= iew of radext participants I think it makes sense to do it in radext. Please let me know what you think. Regards, Klaas= --Apple-Mail-3E464818-CBF5-4B1E-B7C3-932341218BD0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear chairs,

<= /div>
I would like https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/= to be considered for adoption as WG item. 
We could also progress it= as independent submission but given that a number of radext work items are i= nspired by implementation
<= span style=3D"font-size: 15px; line-height: 19px; white-space: nowrap; -webk= it-tap-highlight-color: rgba(26, 26, 26, 0.292969); -webkit-composition-fill= -color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba= (77, 128, 180, 0.230469);">experience in eduroam and that we in particular a= re looking for document review of radext participants I think it makes sense= to do it in radext.

Please let me know what you think.

Regards,

Klaas
= --Apple-Mail-3E464818-CBF5-4B1E-B7C3-932341218BD0-- From trac+radext@trac.tools.ietf.org Thu Nov 8 09:33:45 2012 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 1C4FF21F84D2 for ; Thu, 8 Nov 2012 09:33:45 -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 xJsQTHJN+W6U for ; Thu, 8 Nov 2012 09:33:44 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 81B4921F84C4 for ; Thu, 8 Nov 2012 09:33:44 -0800 (PST) Received: from localhost ([127.0.0.1]:46591 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TWVyo-0004Uc-TT; Thu, 08 Nov 2012 18:33:36 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.com X-Trac-Project: radext Date: Thu, 08 Nov 2012 17:33:26 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/64#comment:7 Message-ID: <079.ea705df3f39dd832594cd1aa72fb6782@trac.tools.ietf.org> References: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <064.279847c62a5711a6d450bc8cf8eaf8ff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: aland@deployingradius.com, bernard_aboba@hotmail.com, peterd@iea-software.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] #64: 4.1 source port inclusion in the tracking table 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, 08 Nov 2012 17:33:45 -0000 #64: 4.1 source port inclusion in the tracking table Comment (by peterd@…): There are no issues establishing a session due to use of stateless cookies within initial DTLS handshake. When server allocates state it also sets session id allowing multiple connection requests from the same source port to complete from its view without ambiguity. This change is intended to address long term problems dealing with recycling of source ports by NATs or local operating system..however any client wishing to attempt to establish multiple DTLS sessions concurrently using the same source port can successfully do so. -- --------------------------------+------------------------- Reporter: peterd@… | Owner: aland@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: Active WG Document | Resolution: wontfix Keywords: | --------------------------------+------------------------- Ticket URL: radext From aland@deployingradius.com Thu Nov 8 12:36:40 2012 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 7470021F866B for ; Thu, 8 Nov 2012 12:36:40 -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 JEalYp5MnDPY for ; Thu, 8 Nov 2012 12:36:39 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2873D21F8614 for ; Thu, 8 Nov 2012 12:36:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 973A722406B2 for ; Thu, 8 Nov 2012 21:35: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 diJdDWm7F1B7 for ; Thu, 8 Nov 2012 21:35:42 +0100 (CET) Received: from dhcp-5482.meeting.ietf.org (dhcp-5482.meeting.ietf.org [130.129.84.130]) by power.freeradius.org (Postfix) with ESMTPSA id A983522404DB for ; Thu, 8 Nov 2012 21:35:42 +0100 (CET) Message-ID: <509C179C.2080605@deployingradius.com> Date: Thu, 08 Nov 2012 15:35:40 -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] Asking for consensus on DTLS 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, 08 Nov 2012 20:36:40 -0000 There have been issues raised with DTLS. I'm asking for explicit statements from members of the WG on the following questions: 1) "silently discard". When RFC 2865, 2866, etc. says a RADIUS packet should be "silently discarded", what should happen with the DTLS session? a) nothing b) it should be closed If possible, I'd appreciate a one-sentence explanation as to why. 2) should we allow multiple independent, active, DTLS sessions from the same source IP/port to the same server destination IP / port? a) yes b) no Thanks. I'd like to get responses quickly, and I'll rev the doc next week. Alan DeKok. From hartmans@painless-security.com Thu Nov 8 12:57:50 2012 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 E632A21F8A48 for ; Thu, 8 Nov 2012 12:57:50 -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 mhNVh4oZ9sx9 for ; Thu, 8 Nov 2012 12:57: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 7286921F89D0 for ; Thu, 8 Nov 2012 12:57:50 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-917d.meeting.ietf.org [130.129.9.125]) (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 DD39B2021E; Thu, 8 Nov 2012 15:56:51 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5E2ED412A; Thu, 8 Nov 2012 15:57:49 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <509C179C.2080605@deployingradius.com> Date: Thu, 08 Nov 2012 15:57:49 -0500 In-Reply-To: <509C179C.2080605@deployingradius.com> (Alan DeKok's message of "Thu, 08 Nov 2012 15:35:40 -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] Asking for consensus on DTLS 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, 08 Nov 2012 20:57:51 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> 2) should we allow multiple independent, active, DTLS sessions Alan> from the same source IP/port to the same server destination IP Alan> / port? Alan> a) yes Alan> b) no No. This seems to introduce complexity and I don't see why it is needed. If you need multiple sessions use a new port. From peterd@iea-software.com Thu Nov 8 13:42:45 2012 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 A49A421F880A for ; Thu, 8 Nov 2012 13:42:45 -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 5Yt-LWkuA0Ht for ; Thu, 8 Nov 2012 13:42:45 -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 1FBEA21F8738 for ; Thu, 8 Nov 2012 13:42: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 ; Thu, 8 Nov 2012 13:42:39 -0800 Date: Thu, 8 Nov 2012 13:42:43 -0800 (Pacific Standard Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: <509C179C.2080605@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" , Alan DeKok Subject: Re: [radext] Asking for consensus on DTLS 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, 08 Nov 2012 21:42:45 -0000 On Thu, 8 Nov 2012, Sam Hartman wrote: >>>>>> "Alan" == Alan DeKok writes: > Alan> 2) should we allow multiple independent, active, DTLS sessions > Alan> from the same source IP/port to the same server destination IP > Alan> / port? > Alan> a) yes > Alan> b) no > No. This seems to introduce complexity and I don't see why it is needed. > If you need multiple sessions use a new port. To clarify I am not advocating a need for multiple DTLS sessions per IP/Port. I am advocating a solution to other issues which happen to allow this as a possibility. I believe following issues need to be addressed: 1. What happens when a client attempts a new DTLS session from IP/source for which a server already has an active association? 2. Added implementation complexity involved with having to maintain multiple DTLS sessions to server to workaround insufficient per port ID space. 3. Consequence of UDP NAT association lifetime and effect on otherwise perfectly good DTLS sessions. I am seeking to avoid problems caused by loss of synchronization between client and server view of DTLS session state. Each instance of such a problem can be costly in terms of unnecessary delay required to correct it. Clients have no way of tell the difference between packet loss and server ignoring requests due to (effective) DTLS session closure. regards, Peter From aland@deployingradius.com Thu Nov 8 15:01:22 2012 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 8C03821F8628 for ; Thu, 8 Nov 2012 15:01:22 -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 dP6qfSnuf1Nx for ; Thu, 8 Nov 2012 15:01:21 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5A821F85E2 for ; Thu, 8 Nov 2012 15:01:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DD4C822406B2; Fri, 9 Nov 2012 00:01:19 +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 qugBdMW2Xe3B; Fri, 9 Nov 2012 00:01:18 +0100 (CET) Received: from dhcp-5482.meeting.ietf.org (dhcp-5482.meeting.ietf.org [130.129.84.130]) by power.freeradius.org (Postfix) with ESMTPSA id 8AD4522404DB; Fri, 9 Nov 2012 00:01:17 +0100 (CET) Message-ID: <509C39BC.1090304@deployingradius.com> Date: Thu, 08 Nov 2012 18:01:16 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <509C179C.2080605@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Asking for consensus on DTLS 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, 08 Nov 2012 23:01:22 -0000 Peter Deacon wrote: > To clarify I am not advocating a need for multiple DTLS sessions per > IP/Port. I am advocating a solution to other issues which happen to > allow this as a possibility. I find it instructive that you responded to Sam, rather than answering the two simple questions I posed. i.e. your opinion is that you can ignore calls for WG consensus. Instead, you just repeat your position. I think that further discussion is pointless. I have responded to your comments in detail. You "respond" to mine by repeating your position, without referencing anything I said. I've asked you specific questions, and gotten silence in response. You are not respecting my attempt to engage you in a conversation. If your approach is to win the argument by simple attrition, it won't work. I've been doing this for 15 years. I'm not going away. Bringing up non-DTLS problems is a blatant attempt to derail this document. It won't work. This document is about DTLS. Other issues are out of scope. I've respected you enough to understand your position, and explain why I disagree. You need to do the same. Alan DeKok. From aland@deployingradius.com Thu Nov 8 15:06:21 2012 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 D2B1521F880A; Thu, 8 Nov 2012 15:06:21 -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 OV1+H2e-vLYP; Thu, 8 Nov 2012 15:06:21 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 576F121F87EE; Thu, 8 Nov 2012 15:06:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C195922406B2; Fri, 9 Nov 2012 00:05:27 +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 iOfkJBvVaM+4; Fri, 9 Nov 2012 00:05:27 +0100 (CET) Received: from dhcp-5482.meeting.ietf.org (dhcp-5482.meeting.ietf.org [130.129.84.130]) by power.freeradius.org (Postfix) with ESMTPSA id BB16B22404DB; Fri, 9 Nov 2012 00:05:26 +0100 (CET) Message-ID: <509C3AB5.30303@deployingradius.com> Date: Thu, 08 Nov 2012 18:05:25 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Klaas Wierenga References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , Stefan Winter , "radext-chairs@ietf.org" , Tomasz Wolniewicz Subject: Re: [radext] Adopt draft-wierenga-ietf-eduroam? 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, 08 Nov 2012 23:06:22 -0000 Klaas Wierenga wrote: > I would > like https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/ to be > considered for adoption as WG item. > We could also progress it as independent submission but given that a > number of radext work items are inspired by implementation > experience in eduroam and that we in particular are looking for document > review of radext participants I think it makes sense to do it in radext. Well, it's not on-charter. However, it's documenting existing practice, and falls well within the practice of previous standards. What do the authors see as the benefit by having it a WG item? The document can still be published as an information RFC, without having WG blessing. I'm willing to review it, whether it's a WG document or not. Alan DeKok. From peterd@iea-software.com Thu Nov 8 15:26:52 2012 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 2474121F889E for ; Thu, 8 Nov 2012 15:26:52 -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 jknmVAqHkrtL for ; Thu, 8 Nov 2012 15:26:51 -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 6661021F8786 for ; Thu, 8 Nov 2012 15:26:51 -0800 (PST) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 8 Nov 2012 15:26:50 -0800 Date: Thu, 8 Nov 2012 15:26:49 -0800 (Pacific Standard Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <509C39BC.1090304@deployingradius.com> Message-ID: References: <509C179C.2080605@deployingradius.com> <509C39BC.1090304@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] Asking for consensus on DTLS 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, 08 Nov 2012 23:26:52 -0000 On Thu, 8 Nov 2012, Alan DeKok wrote: > Peter Deacon wrote: >> To clarify I am not advocating a need for multiple DTLS sessions per >> IP/Port. I am advocating a solution to other issues which happen to >> allow this as a possibility. > I find it instructive that you responded to Sam, rather than answering > the two simple questions I posed. Hi Alan, I felt it necessary to respond because I felt the question posed was not representative of the underlying question at issue. Perhaps I could have done so with fewer characters. In the end my only goal is to support a robust specification for RADIUS over DTLS. regards, Peter From aland@deployingradius.com Thu Nov 8 15:50:23 2012 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 8694121F8681 for ; Thu, 8 Nov 2012 15:50:23 -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 I0J3vkhwR3YC for ; Thu, 8 Nov 2012 15:50:23 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id F393C21F84FF for ; Thu, 8 Nov 2012 15:50:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A40AC22406B2; Fri, 9 Nov 2012 00:49:35 +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 CA1ehxdCrcLP; Fri, 9 Nov 2012 00:49:35 +0100 (CET) Received: from dhcp-5482.meeting.ietf.org (dhcp-5482.meeting.ietf.org [130.129.84.130]) by power.freeradius.org (Postfix) with ESMTPSA id 2431C22404DB; Fri, 9 Nov 2012 00:49:35 +0100 (CET) Message-ID: <509C450E.4040306@deployingradius.com> Date: Thu, 08 Nov 2012 18:49:34 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <509C179C.2080605@deployingradius.com> <509C39BC.1090304@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Asking for consensus on DTLS 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, 08 Nov 2012 23:50:23 -0000 Peter Deacon wrote: > I felt it necessary to respond because I felt the question posed was not > representative of the underlying question at issue. You could have said that. You chose not to. I understand your position. I just don't think it's relevant. You clearly don't understand my position. Alan DeKok. From klaas@wierenga.net Sat Nov 10 12:37:03 2012 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 9D4D721F8622; Sat, 10 Nov 2012 12:37:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.984 X-Spam-Level: X-Spam-Status: No, score=-0.984 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, MIME_QP_LONG_LINE=1.396, 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 F8is5F1-HVLL; Sat, 10 Nov 2012 12:37:03 -0800 (PST) Received: from out48-ams.mf.surf.net (out48-ams.mf.surf.net [145.0.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id EE48721F85F3; Sat, 10 Nov 2012 12:37:02 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qAAKax7r005387; Sat, 10 Nov 2012 21:36:59 +0100 Received: from 5355039a.cm-6-6a.dynamic.ziggo.nl ([83.85.3.154] helo=[192.168.1.215]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TXHiJ-000PSR-TM; Sat, 10 Nov 2012 21:31:35 +0100 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable References: <509C3AB5.30303@deployingradius.com> From: Klaas Wierenga Mime-Version: 1.0 (1.0) In-Reply-To: <509C3AB5.30303@deployingradius.com> Message-Id: <615AE3BE-B993-4880-8E34-A4399A9CB26D@wierenga.net> Date: Fri, 9 Nov 2012 07:37:02 -0500 To: Alan DeKok X-Mailer: iPad Mail (10A523) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vIlUAXld - 2ae49705b8fd - 20121110 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "radext@ietf.org" , Stefan Winter , "radext-chairs@ietf.org" , Tomasz Wolniewicz Subject: Re: [radext] Adopt draft-wierenga-ietf-eduroam? 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, 10 Nov 2012 20:37:03 -0000 Hi Alan, On 8 nov. 2012, at 18:05, Alan DeKok wrote: > Klaas Wierenga wrote: >> I would >> like https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/ to be >> considered for adoption as WG item.=20 >> We could also progress it as independent submission but given that a >> number of radext work items are inspired by implementation >> experience in eduroam and that we in particular are looking for document >> review of radext participants I think it makes sense to do it in radext. >=20 > Well, it's not on-charter. >=20 > However, it's documenting existing practice, and falls well within the > practice of previous standards. >=20 > What do the authors see as the benefit by having it a WG item? The > document can still be published as an information RFC, without having WG > blessing. Yes, but that would put the burden on the sponsoring AD. Given the fact that= all of this is close to on-charter items I thought it made sense to see if w= e could run it through the regular WG process. >=20 > I'm willing to review it, whether it's a WG document or not. Great! Klaas >=20 > Alan DeKok. From bclaise@cisco.com Sun Nov 11 12:14:08 2012 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 8373E21F84B1 for ; Sun, 11 Nov 2012 12:14:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.552 X-Spam-Level: X-Spam-Status: No, score=-10.552 tagged_above=-999 required=5 tests=[AWL=0.046, 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 nWvtnGgQgpyI for ; Sun, 11 Nov 2012 12:14:07 -0800 (PST) Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA0921F84A2 for ; Sun, 11 Nov 2012 12:14:07 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABKE3rI010835; Sun, 11 Nov 2012 15:14:03 -0500 (EST) Received: from [10.82.242.230] (rtp-vpn2-742.cisco.com [10.82.242.230]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qABKDoxP025641; Sun, 11 Nov 2012 15:13:50 -0500 (EST) Message-ID: <50A006FE.6030401@cisco.com> Date: Sun, 11 Nov 2012 15:13:50 -0500 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000702020308020109090105" Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter 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: Sun, 11 Nov 2012 20:14:08 -0000 This is a multi-part message in MIME format. --------------000702020308020109090105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, The deadline is passed. Let me submit the new charter to the IESG. I changed the following dates to Dec 2012 Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC Not that I want to delay the work, but if, for whatever reason, the charter approval is delayed, it would not make sense to have a draft deadline in the past. Regardless, progress the drafts ASAP Regards, Benoit > Pasted below is the current recharter proposal for radext. The > largest change from the previous circulated proposal is the remove of > the traffic statistics work. After consultation with our AD, we the > chairs have decided to postpone adding this work item until we have a > clearer understanding for scope of problem and solution . Moreover, > we already have a number of items that are severely overdue and > several more solid individual submissions that are eminent work items > (pending this recharter). We would like any feedback by EOB Friday > as our AD is ready to run this recharter text through the process. > > -Jouni and Mauricio > > -------------------------------------------------------- > Description of Working Group > > The RADIUS Extensions Working Group will focus on extensions to the > RADIUS protocol required to expand and enrich the standard attribute > space, address cryptographic algorithm agility, use of new secure > transports and clarify its usage and definition. > > In order to maintain interoperation of heterogeneous RADIUS/Diameter > deployments, all RADEXT WG work items except those that just define > new attributes MUST contain a Diameter compatibility section, > outlining how interoperability with Diameter will be maintained. > > Furthermore, to ensure backward compatibility with existing RADIUS > implementations, as well as compatibility between RADIUS and > Diameter, the following restrictions are imposed on extensions > considered by the RADEXT WG: > > - All documents produced MUST specify means of interoperation with > legacy RADIUS and, if possible, be backward compatible with existing > RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, > 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, > if possible, be compatible with RFC 3539. > > Work Items > The immediate goals of the RADEXT working group are to address the > following issues: > > - RADIUS attribute space extension. The standard RADIUS attribute > space is currently being depleted. This document will provide > additional standard attribute space, while maintaining backward > compatibility with existing attributes. > > - IEEE 802 attributes. New attributes have been proposed to support > IEEE 802 standards for wired and wireless LANs. This work item will > support authentication, authorization and accounting attributes needed > by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16. > > - New RADIUS transports. A reliable transport profile for RADIUS will > be developed, as well as specifications for Secure transports, > including TCP/TLS (RADSEC) and UDP/DTLS. > > - Update and clarification of Network Access Identifiers > (RFC4282).This work item will correct and clarify issues present with > RFC4282 in two phases. In first phase, RFC4282bis will be issued to > eliminate fundamental incompatibilities with RADIUS around character > encoding and NAI modifications by proxies. In second phase, a fresh > review of NAI internationalization requirements and behavior will be > undertaken with a clear goal of maintaining compatibility with RADIUS. > > - Fragmentation of RADIUS packets to support exchanges exceeding the > existing 4KB limit imposed by RFC2865. > > Goals and Milestones > Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication > Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC > Done RFC 2486bis submitted as a Proposed Standard RFC > Done RFC 3576 MIBs submitted as an Informational RFC > Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed > Standard RFC (reduced in scope) > Done RADIUS Implementation Issues and Fixes draft submitted as an > Informational RFC > Done RADIUS Filtering Attributes draft submitted as a Proposed > Standard RFC (split out from VLAN & Priority draft) > Done RFC 3576bis submitted as an Informational RFC (split out from > Issues & Fixes draft) > Done RADIUS Redirection Attributes draft submitted as a Proposed > Standard RFC (split out from VLAN & Priority draft) > Done RADIUS Design Guidelines submitted as a Best Current Practice RFC > Done RADIUS Management Authorization I-D submitted as a Proposed > Standard RFC > Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed > Standard RFC > Done Status-Server I-D submitted as a Proposed Standard RFC > Done RADIUS Crypto-agility Requirements submitted as an Informational RFC > Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC > Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC > Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC > Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC > Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC > Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC > Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC > May 2013 RADIUS support for NAI Internationalization I-D submitted as > a Proposed Standard RFC > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext --------------000702020308020109090105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear all,

The deadline is passed.
Let me submit the new charter to the IESG.
I changed the following dates to Dec 2012
    Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
    Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Not that I want to delay the work, but if, for whatever reason, the charter approval is delayed, it would not make sense to have a draft deadline in the past. Regardless, progress the drafts ASAP

Regards, Benoit
Pasted below is the current recharter proposal for radext.  The largest change from the previous circulated proposal is the remove of the traffic statistics work.  After consultation with our AD, we the chairs have decided to postpone adding this work item until we have a clearer understanding for scope of problem and solution .   Moreover, we already have a number of items that are severely overdue and several more solid individual submissions that are eminent work items (pending this recharter).    We would like any feedback by EOB Friday as our AD is ready to run this recharter text through the process.   

-Jouni and Mauricio 

--------------------------------------------------------
Description of Working Group

The RADIUS Extensions Working Group will focus on extensions to the RADIUS  protocol required to expand and enrich the standard attribute space, address  cryptographic algorithm agility, use of new secure transports and clarify its usage and definition.

In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS  implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG:

- All documents produced MUST specify means of interoperation with legacy RADIUS  and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539.

Work Items
The immediate goals of the RADEXT working group are to address the following issues:

- RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes.

- IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

- Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases.  In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies.  In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS.

- Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865.

Goals and Milestones
Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Done RFC 2486bis submitted as a Proposed Standard RFC
Done RFC 3576 MIBs submitted as an Informational RFC
Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope)
Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC
Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft)
Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RADIUS Design Guidelines submitted as a Best Current Practice RFC
Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC
Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC
Done Status-Server I-D submitted as a Proposed Standard RFC
Done RADIUS Crypto-agility Requirements submitted as an Informational RFC
Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC
May 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC



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

--------------000702020308020109090105-- From jsalowey@cisco.com Mon Nov 12 09:51:46 2012 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 5DA2921F85A4 for ; Mon, 12 Nov 2012 09:51:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3z-M9FINvTZa for ; Mon, 12 Nov 2012 09:51:45 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C358121F8596 for ; Mon, 12 Nov 2012 09:51:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=162; q=dns/txt; s=iport; t=1352742706; x=1353952306; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Nz09dbXzAsa6nE//DEBotrEqE8pBspLNjhJvTXWpOq4=; b=RLyv9llszQDEr56lSMneJqXBA6z0FwHjE0BjTzhGHAPT+urnf9lIKTLm bXNBfEy8c/CK51zN4k/ut5H1zOMoQTEhf60OFwk1VRhCgfWwrQeuqDyfz kkYfOLHgR+9Wjpg8wzn09Uv+TPvx16f5UROBtym6CVVZiaeSOw8/I3ckl Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsIAIU2oVCtJV2b/2dsb2JhbABEw1qBAQeCIAEEEgEnPxIBKhRCJwQODRqHaJoIn3eRfmEDpFSBa4Jvghk X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141368104" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 12 Nov 2012 17:51:45 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qACHpje3012784 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 17:51:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.68]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 11:51:44 -0600 From: "Joseph Salowey (jsalowey)" To: "radext@ietf.org" Thread-Topic: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext Thread-Index: AQHNwP5gT+vWn1zuj0SX2HDW0Mom3Q== Date: Mon, 12 Nov 2012 17:51:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.147] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19356.005 x-tm-as-result: No--23.521000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bernard Aboba , "Dave Stephenson \(daves\)" Subject: [radext] Additional 802.11 reason code values for draft-ietf-radext-ieee802ext 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, 12 Nov 2012 17:51:46 -0000 The following reason codes also seem to be relevant reason codes 1 Unspecified Reason 32 Disassociated for unspecified, QoS-related reason Thanks, Joe From trac+radext@trac.tools.ietf.org Mon Nov 12 09:54:23 2012 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 E6A2C21F860C for ; Mon, 12 Nov 2012 09:54:23 -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 klqGXKcuyk8k for ; Mon, 12 Nov 2012 09:54:22 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A8D9221F85A4 for ; Mon, 12 Nov 2012 09:54:18 -0800 (PST) Received: from localhost ([127.0.0.1]:57242 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TXyD4-0003Uz-Bd; Mon, 12 Nov 2012 18:54:10 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-radext-ieee802ext@tools.ietf.org, jsalowey@cisco.com X-Trac-Project: radext Date: Mon, 12 Nov 2012 17:54:10 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/131 Message-ID: <059.5fa64705b71e550efc23f1a0377cbdc7@trac.tools.ietf.org> X-Trac-Ticket-ID: 131 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-ieee802ext@tools.ietf.org, jsalowey@cisco.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: <20121112175421.A8D9221F85A4@ietfa.amsl.com> Resent-Date: Mon, 12 Nov 2012 09:54:18 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [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, 12 Nov 2012 17:54:24 -0000 #131: Additional 802.11 reason code values for draft-ietf-radext-ieee802ext The following reason codes also seem to be relevant reason codes 1 Unspecified Reason 32 Disassociated for unspecified, QoS-related reason Thanks, Joe -- -----------------------------+-------------------------------------------- Reporter: jsalowey@… | Owner: draft-ietf-radext-ieee802ext@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: Severity: In WG Last Call | Keywords: -----------------------------+-------------------------------------------- Ticket URL: radext From bclaise@cisco.com Wed Nov 14 09:16:24 2012 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 AB4B221F878A for ; Wed, 14 Nov 2012 09:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.302 X-Spam-Level: X-Spam-Status: No, score=-10.302 tagged_above=-999 required=5 tests=[AWL=0.296, 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 o+a9gGHuWEUm for ; Wed, 14 Nov 2012 09:16:23 -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 0FD2E21F8784 for ; Wed, 14 Nov 2012 09:16:22 -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 qAEHGHEk000968; Wed, 14 Nov 2012 18:16:17 +0100 (CET) Received: from [10.60.67.87] (ams-bclaise-8916.cisco.com [10.60.67.87]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qAEHGGnu001156; Wed, 14 Nov 2012 18:16:17 +0100 (CET) Message-ID: <50A3D1E0.5040408@cisco.com> Date: Wed, 14 Nov 2012 18:16:16 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Sanchez, Mauricio (HP Networking)" References: <50A006FE.6030401@cisco.com> In-Reply-To: <50A006FE.6030401@cisco.com> Content-Type: multipart/alternative; boundary="------------040803040100020400060201" Cc: "radext@ietf.org" Subject: Re: [radext] RADEXT recharter 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: Wed, 14 Nov 2012 17:16:24 -0000 This is a multi-part message in MIME format. --------------040803040100020400060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit FYI, this is now on the IESG telechat for Nov 29th. It was too late for the IESG telechat tomorrow. Regards, Benoit > Dear all, > > The deadline is passed. > Let me submit the new charter to the IESG. > I changed the following dates to Dec 2012 > Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC > Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC > Not that I want to delay the work, but if, for whatever reason, the > charter approval is delayed, it would not make sense to have a draft > deadline in the past. Regardless, progress the drafts ASAP > > Regards, Benoit >> Pasted below is the current recharter proposal for radext. The >> largest change from the previous circulated proposal is the remove of >> the traffic statistics work. After consultation with our AD, we the >> chairs have decided to postpone adding this work item until we have a >> clearer understanding for scope of problem and solution . Moreover, >> we already have a number of items that are severely overdue and >> several more solid individual submissions that are eminent work items >> (pending this recharter). We would like any feedback by EOB Friday >> as our AD is ready to run this recharter text through the process. >> >> -Jouni and Mauricio >> >> -------------------------------------------------------- >> Description of Working Group >> >> The RADIUS Extensions Working Group will focus on extensions to the >> RADIUS protocol required to expand and enrich the standard attribute >> space, address cryptographic algorithm agility, use of new secure >> transports and clarify its usage and definition. >> >> In order to maintain interoperation of heterogeneous RADIUS/Diameter >> deployments, all RADEXT WG work items except those that just define >> new attributes MUST contain a Diameter compatibility section, >> outlining how interoperability with Diameter will be maintained. >> >> Furthermore, to ensure backward compatibility with existing RADIUS >> implementations, as well as compatibility between RADIUS and >> Diameter, the following restrictions are imposed on extensions >> considered by the RADEXT WG: >> >> - All documents produced MUST specify means of interoperation with >> legacy RADIUS and, if possible, be backward compatible with existing >> RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, >> 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, >> if possible, be compatible with RFC 3539. >> >> Work Items >> The immediate goals of the RADEXT working group are to address the >> following issues: >> >> - RADIUS attribute space extension. The standard RADIUS attribute >> space is currently being depleted. This document will provide >> additional standard attribute space, while maintaining backward >> compatibility with existing attributes. >> >> - IEEE 802 attributes. New attributes have been proposed to support >> IEEE 802 standards for wired and wireless LANs. This work item will >> support authentication, authorization and accounting attributes >> needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE >> 802.16. >> >> - New RADIUS transports. A reliable transport profile for RADIUS will >> be developed, as well as specifications for Secure transports, >> including TCP/TLS (RADSEC) and UDP/DTLS. >> >> - Update and clarification of Network Access Identifiers >> (RFC4282).This work item will correct and clarify issues present with >> RFC4282 in two phases. In first phase, RFC4282bis will be issued to >> eliminate fundamental incompatibilities with RADIUS around character >> encoding and NAI modifications by proxies. In second phase, a fresh >> review of NAI internationalization requirements and behavior will be >> undertaken with a clear goal of maintaining compatibility with RADIUS. >> >> - Fragmentation of RADIUS packets to support exchanges exceeding the >> existing 4KB limit imposed by RFC2865. >> >> Goals and Milestones >> Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication >> Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC >> Done RFC 2486bis submitted as a Proposed Standard RFC >> Done RFC 3576 MIBs submitted as an Informational RFC >> Done RADIUS VLAN and Priority Attributes draft submitted as a >> Proposed Standard RFC (reduced in scope) >> Done RADIUS Implementation Issues and Fixes draft submitted as an >> Informational RFC >> Done RADIUS Filtering Attributes draft submitted as a Proposed >> Standard RFC (split out from VLAN & Priority draft) >> Done RFC 3576bis submitted as an Informational RFC (split out from >> Issues & Fixes draft) >> Done RADIUS Redirection Attributes draft submitted as a Proposed >> Standard RFC (split out from VLAN & Priority draft) >> Done RADIUS Design Guidelines submitted as a Best Current Practice RFC >> Done RADIUS Management Authorization I-D submitted as a Proposed >> Standard RFC >> Done Reliable Transport Profile for RADIUS I-D submitted as a >> Proposed Standard RFC >> Done Status-Server I-D submitted as a Proposed Standard RFC >> Done RADIUS Crypto-agility Requirements submitted as an Informational RFC >> Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC >> Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC >> Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC >> Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC >> Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC >> Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC >> Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC >> Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC >> May 2013 RADIUS support for NAI Internationalization I-D submitted as >> a Proposed Standard RFC >> >> >> >> _______________________________________________ >> 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 --------------040803040100020400060201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
FYI, this is now on the IESG telechat for Nov 29th.
It was too late for the IESG telechat tomorrow.

Regards, Benoit
Dear all,

The deadline is passed.
Let me submit the new charter to the IESG.
I changed the following dates to Dec 2012
    Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
    Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Not that I want to delay the work, but if, for whatever reason, the charter approval is delayed, it would not make sense to have a draft deadline in the past. Regardless, progress the drafts ASAP

Regards, Benoit
Pasted below is the current recharter proposal for radext.  The largest change from the previous circulated proposal is the remove of the traffic statistics work.  After consultation with our AD, we the chairs have decided to postpone adding this work item until we have a clearer understanding for scope of problem and solution .   Moreover, we already have a number of items that are severely overdue and several more solid individual submissions that are eminent work items (pending this recharter).    We would like any feedback by EOB Friday as our AD is ready to run this recharter text through the process.   

-Jouni and Mauricio 

--------------------------------------------------------
Description of Working Group

The RADIUS Extensions Working Group will focus on extensions to the RADIUS  protocol required to expand and enrich the standard attribute space, address  cryptographic algorithm agility, use of new secure transports and clarify its usage and definition.

In order to maintain interoperation of heterogeneous RADIUS/Diameter deployments, all RADEXT WG work items except those that just define new attributes MUST contain a Diameter compatibility section, outlining how interoperability with Diameter will be maintained.

Furthermore, to ensure backward compatibility with existing RADIUS  implementations, as well as compatibility between RADIUS and Diameter, the following restrictions are imposed on extensions considered by the RADEXT WG:

- All documents produced MUST specify means of interoperation with legacy RADIUS  and, if possible, be backward compatible with existing RADIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539.

Work Items
The immediate goals of the RADEXT working group are to address the following issues:

- RADIUS attribute space extension. The standard RADIUS attribute space is currently being depleted. This document will provide additional standard attribute space, while maintaining backward compatibility with existing attributes.

- IEEE 802 attributes. New attributes have been proposed to support IEEE 802 standards for wired and wireless LANs. This work item will support authentication, authorization and accounting attributes needed by IEEE 802 groups including IEEE 802.1, IEEE 802.11 and IEEE 802.16.

- New RADIUS transports. A reliable transport profile for RADIUS will be developed, as well as specifications for Secure transports, including TCP/TLS (RADSEC) and UDP/DTLS.

- Update and clarification of Network Access Identifiers (RFC4282).This work item will correct and clarify issues present with RFC4282 in two phases.  In first phase, RFC4282bis will be issued to eliminate fundamental incompatibilities with RADIUS around character encoding and NAI modifications by proxies.  In second phase, a fresh review of NAI internationalization requirements and behavior will be undertaken with a clear goal of maintaining compatibility with RADIUS.

- Fragmentation of RADIUS packets to support exchanges exceeding the existing 4KB limit imposed by RFC2865.

Goals and Milestones
Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication
Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC
Done RFC 2486bis submitted as a Proposed Standard RFC
Done RFC 3576 MIBs submitted as an Informational RFC
Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Standard RFC (reduced in scope)
Done RADIUS Implementation Issues and Fixes draft submitted as an Informational RFC
Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RFC 3576bis submitted as an Informational RFC (split out from Issues & Fixes draft)
Done RADIUS Redirection Attributes draft submitted as a Proposed Standard RFC (split out from VLAN & Priority draft)
Done RADIUS Design Guidelines submitted as a Best Current Practice RFC
Done RADIUS Management Authorization I-D submitted as a Proposed Standard RFC
Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Standard RFC
Done Status-Server I-D submitted as a Proposed Standard RFC
Done RADIUS Crypto-agility Requirements submitted as an Informational RFC
Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC
Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC
Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC
Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC
Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC
Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC
Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC
Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC
May 2013 RADIUS support for NAI Internationalization I-D submitted as a Proposed Standard RFC



_______________________________________________
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

--------------040803040100020400060201-- From dstanley1389@gmail.com Wed Nov 14 15:57:26 2012 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 18A4821F86E4 for ; Wed, 14 Nov 2012 15:57:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, 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 w+DoAWgfp+z7 for ; Wed, 14 Nov 2012 15:57:25 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7F9EA21F85DF for ; Wed, 14 Nov 2012 15:57:25 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fl11so1186629vcb.31 for ; Wed, 14 Nov 2012 15:57:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=7vXjPTNSDS2asHk4pYZ4sMX2paXskD44gX0VOtDV5BY=; b=xwLsjmwN+cHv2E5w9P8ZHa/fk2qxy87iR1FFXnLQwzkicstCPew8wwk9t5TNCH2LMB RIFxZFxx4fcG0vsaHFjoY7X/7NVv6Pmbk+mxdwRqV2vYDcOSWnNvZZternkqkhbrOGEq 7ugWglvqeorkQpucCma1tTZJMwuvcf3nTOL5wnvi/KESu4VYdiW0maAmom5JCTH7DJgu uXT+D940s/HTjIgenXLRia/Jyfsb/2XhazviKmpu1WHbe5+wPRBEkADjgzaQs7V7bzpx OyvJE2Orljo1GhJQp9p9CTjk9epSwI+G/9046GGWEMtWgnWPJU8p0MsCUwuXWDrbRf7d PIKQ== MIME-Version: 1.0 Received: by 10.52.90.212 with SMTP id by20mr4199371vdb.118.1352937444829; Wed, 14 Nov 2012 15:57:24 -0800 (PST) Received: by 10.58.222.100 with HTTP; Wed, 14 Nov 2012 15:57:24 -0800 (PST) Date: Wed, 14 Nov 2012 15:57:24 -0800 Message-ID: From: Dorothy Stanley To: radext@ietf.org Content-Type: multipart/alternative; boundary=20cf307d0626cd68bd04ce7d4b89 Subject: [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: Wed, 14 Nov 2012 23:57:26 -0000 --20cf307d0626cd68bd04ce7d4b89 Content-Type: text/plain; charset=ISO-8859-1 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. --20cf307d0626cd68bd04ce7d4b89 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Here are some additional comments from 802.11 members, ga= thered at the IEEE 802.11 meeting, Nov 14, 2012.

Dorothy Stanl= ey
----------------
1. in 2.4, chan= ge from
"=A0 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 t= he IEEE 802.11u-2011 amendment"; as the reference 802.11-2012 inclu= des the 11u amendment.

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

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

5. In section 3, in the entry f= or 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.



--20cf307d0626cd68bd04ce7d4b89-- From trac+radext@trac.tools.ietf.org Wed Nov 14 16:04:01 2012 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 4E8F421F85C4 for ; Wed, 14 Nov 2012 16:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.449 X-Spam-Level: X-Spam-Status: No, score=-101.449 tagged_above=-999 required=5 tests=[AWL=-1.150, 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 UOrSrgWeQEDB for ; Wed, 14 Nov 2012 16:04:00 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id BA7CD21F854E for ; Wed, 14 Nov 2012 16:04:00 -0800 (PST) Received: from localhost ([127.0.0.1]:40486 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYmvq-0002Gn-CX; Thu, 15 Nov 2012 01:03:56 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 15 Nov 2012 00:03:46 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/radext/trac/ticket/132 Message-ID: <066.c2fa1659af9d5ba32a31013b60eed836@trac.tools.ietf.org> X-Trac-Ticket-ID: 132 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: [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: Thu, 15 Nov 2012 00:04:01 -0000 #132: Additional comments from IEEE 802.11 From dstanley1389@gmail.com: 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. -- --------------------------------+----------------------------- Reporter: bernard_aboba@… | Owner: bernard_aboba@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+----------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 14 16:04:10 2012 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 B963021F868D for ; Wed, 14 Nov 2012 16:04:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.406 X-Spam-Level: X-Spam-Status: No, score=-101.406 tagged_above=-999 required=5 tests=[AWL=-1.107, 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 low6LEJMlyNi for ; Wed, 14 Nov 2012 16:04:10 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3B01A21F859A for ; Wed, 14 Nov 2012 16:04:10 -0800 (PST) Received: from localhost ([127.0.0.1]:40568 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYmwB-0000Lk-Hs; Thu, 15 Nov 2012 01:04:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com, dstanley1389@gmail.com X-Trac-Project: radext Date: Thu, 15 Nov 2012 00:04:07 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/133 Message-ID: <063.4294a006136b711f4ca314ecd6c2e84f@trac.tools.ietf.org> X-Trac-Ticket-ID: 133 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, dstanley1389@gmail.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: [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, 15 Nov 2012 00:04:10 -0000 #133: Additional comments from IEEE 802.11 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. -- --------------------------------+----------------------------- Reporter: dstanley1389@… | Owner: bernard_aboba@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: ieee802ext | Version: 1.0 Severity: Active WG Document | Keywords: --------------------------------+----------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Wed Nov 14 16:04:50 2012 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 CBC9A21F859A for ; Wed, 14 Nov 2012 16:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, 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 pYUPEOCpsSCv for ; Wed, 14 Nov 2012 16:04:50 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E652B21F854E for ; Wed, 14 Nov 2012 16:04:49 -0800 (PST) Received: from localhost ([127.0.0.1]:40723 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TYmwr-0005Pm-77; Thu, 15 Nov 2012 01:04:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 15 Nov 2012 00:04:49 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/132#comment:1 Message-ID: <081.793ec86ce162c5c7c9b37a936bab0d48@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: Thu, 15 Nov 2012 00:04:50 -0000 #132: Additional comments from IEEE 802.11 Changes (by bernard_aboba@…): * status: new => closed * resolution: => duplicate -- --------------------------------+------------------------------ Reporter: bernard_aboba@… | Owner: bernard_aboba@… 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 Nov 19 09:48:49 2012 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 5032821F859D for ; Mon, 19 Nov 2012 09:48:49 -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 wRT+DZPq6xVU for ; Mon, 19 Nov 2012 09:48:48 -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 BA27221F8549 for ; Mon, 19 Nov 2012 09:48:47 -0800 (PST) Received: from localhost ([127.0.0.1]:38989 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TaVST-0001AR-Uq; Mon, 19 Nov 2012 18:48:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit 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-dtls@tools.ietf.org, ncamwing@cisco.com X-Trac-Project: radext Date: Mon, 19 Nov 2012 17:48:33 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/134 Message-ID: <059.262988ca8173de818e62ac830cb12bd1@trac.tools.ietf.org> X-Trac-Ticket-ID: 134 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, ncamwing@cisco.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: aland@freeradius.org Resent-Message-Id: <20121119174848.BA27221F8549@ietfa.amsl.com> Resent-Date: Mon, 19 Nov 2012 09:48:47 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #134: Editorial nits on radext-dtls-02 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, 19 Nov 2012 17:48:49 -0000 #134: Editorial nits on radext-dtls-02 The following are some editorial nits found on the draft: • section 1.1 "silently discard" has a dangling reference to "X.Y" • Section 2.1 should "radius/DTLS" in the last paragraph item (2) be capitalized for consistency? • Section 2.2.1 typo in reference to Section 3.3 has "TDLS" vs. "DTLS" • typo in the Copyright notice, page 2 "Section 4.e" should be "Section 4" • Section 3 has an extraneous "to" in the first line and bad reference to "Section X.Y" in first paragraph • Section 7.2 has a dangling "X.Y" reference -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- ncamwing@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: minor | Milestone: Component: dtls | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 19 09:51:02 2012 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 DAA6621F8683 for ; Mon, 19 Nov 2012 09:51: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 5jgZMGB4DgYN for ; Mon, 19 Nov 2012 09:51: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 53AE621F8678 for ; Mon, 19 Nov 2012 09:51:02 -0800 (PST) Received: from localhost ([127.0.0.1]:39137 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TaVUr-0000Jw-86; Mon, 19 Nov 2012 18:51: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: draft-ietf-radext-dtls@tools.ietf.org, ncamwing@cisco.com X-Trac-Project: radext Date: Mon, 19 Nov 2012 17:51:01 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/135 Message-ID: <059.18713e29caaa8e0bdab2aacfee526283@trac.tools.ietf.org> X-Trac-Ticket-ID: 135 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, ncamwing@cisco.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: aland@freeradius.org Resent-Message-Id: <20121119175102.53AE621F8678@ietfa.amsl.com> Resent-Date: Mon, 19 Nov 2012 09:51:02 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #135: Server policy handling should be informative 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, 19 Nov 2012 17:51:03 -0000 #135: Server policy handling should be informative Section 3 speaks to a RADIUS server's policy for how it wants to handle clients, as such this should be treated as informative text vs. normative. That is, I agree that the server must maintain state for when a client is to use RADIUS/DTLS; but how it is implemented is server specific and based on administrative policy. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- ncamwing@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: dtls | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 19 09:51:40 2012 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 4426F21F86B6 for ; Mon, 19 Nov 2012 09:51:40 -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 jIrPqitiSF-f for ; Mon, 19 Nov 2012 09:51:39 -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 A675821F8683 for ; Mon, 19 Nov 2012 09:51:39 -0800 (PST) Received: from localhost ([127.0.0.1]:39151 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TaVVR-0002nX-JK; Mon, 19 Nov 2012 18:51:37 +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-dtls@tools.ietf.org, ncamwing@cisco.com X-Trac-Project: radext Date: Mon, 19 Nov 2012 17:51:37 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/136 Message-ID: <059.d793aee480c4d789a537efce305ec9f7@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, ncamwing@cisco.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: aland@freeradius.org Resent-Message-Id: <20121119175139.A675821F8683@ietfa.amsl.com> Resent-Date: Mon, 19 Nov 2012 09:51:39 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #136: Table state management as security consideration? 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, 19 Nov 2012 17:51:40 -0000 #136: Table state management as security consideration? the Table State management is a recommended guideline for how to address DoS but perhaps not the only means to achieve this, so I suggest that sections 4.1.1 (and 4.1) be moved to the security considerations. How the connection management is achieved is implementation specific, but there are considerations that must be maintained; e.g. tracking of the port and IP adds of both source and destination as well as their designated security policy (e.g. whether DTLS is enforced or not) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- ncamwing@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: dtls | Version: Severity: - | Keywords: -------------------------+------------------------------------------------- Ticket URL: radext From jsalowey@cisco.com Tue Nov 20 21:10:22 2012 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 1162521F84B2 for ; Tue, 20 Nov 2012 21:10:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 6cWLmCCXif+6 for ; Tue, 20 Nov 2012 21:10:21 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 179AE21F84A1 for ; Tue, 20 Nov 2012 21:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5459; q=dns/txt; s=iport; t=1353474621; x=1354684221; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Yd3S6MOQl0U5HCJZAiqO34d6GxOeGzrZz1/yD4v550k=; b=cEKdcLFMBEP6GfCZho0KmgZMEVIkI/YgyUB0YNMvc8nscY/rlQNczxBE igBd/WJDmq97SeNjYNJ03EpuAQ1Y4YHxnUHItQEPRCrdKjGGGOEY/Jk0i qx0BzaQH+0RuqAZ7ka0tlBynCKYNONdreveXKW5gUp5lf67lv3kcsSdEf E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq0JADZhrFCtJXG+/2dsb2JhbABEwlYWbAeCIAEEOlEBKhRCJwQbiAWdWKFFkDVhA5JMk3OCb4FdJBg X-IronPort-AV: E=McAfee;i="5400,1158,6902"; a="144667864" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 21 Nov 2012 05:10:20 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qAL5AKLk011662 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 21 Nov 2012 05:10:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.196]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Tue, 20 Nov 2012 23:10:20 -0600 From: "Joseph Salowey (jsalowey)" To: "radext@ietf.org" Thread-Topic: Comments draft-ietf-radext-dtls-02 Thread-Index: AQHNx6aAtkZqo7u/T0iklfoHrT9DAA== Date: Wed, 21 Nov 2012 05:10:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.147] Content-Type: text/plain; charset="us-ascii" Content-ID: <95253BE8878658498137B4323D6C8D91@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [radext] Comments draft-ietf-radext-dtls-02 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, 21 Nov 2012 05:10:22 -0000 The document has a few issues that need to be resolved: 1. What is the expected behavior if the request authenticator or message au= thenticator verification fails? I believe the behavior is that the RADIUS = layer silently ignores the message and the DTLS session is torn down, but I= think this should be more explicitly stated.=20 2. The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wron= g. =20 - Section 2.2 in the RADIUS/TLS spec does not discuss cipher suites, but se= ction 2.3 does. =20 - Section 2.3 does apply to radius, except =20 -- bullet 1 I'm not sure if this applies -- bullet 2 applies except for TLS_RSA_WITH_RC4_128_SHA as already noted -- bullet 3 applies -- bullet 4 applies except the secret is different - section 2.4 applies to RADIUS/DTLS - section 2.5 probably does not apply; as noted in draft for section 2.4 - Section 3.3 should reference 3.4 Section 2.2.2 looks like it references the correct sections, but this shoul= d be validated. =20 3. Implementation specifics are mixed in with the normative text throughou= t the document. There should be a separate informative section in implemen= tation. THis includes - Section 3 Discussions of connected UDP sockets - Section 3 DIscussion of local proxy - Section 4.1 Discussion of connected sockets - Section 4.1 and 4.1.1 seems a bit implementation specific, I believe it s= hould discus DTLS session/state Management instead of Table management. an= informative description of the table is fine, but most of the text can be = described without reference to a table.=20 Here is some text that I think is more implementation neutral: =20 " DTLS implementations are subject to Denial of Service (DoS) attacks due to the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347] Section 4.2.1. the server SHOULD NOT allocate state until a ClientHello packet has been received with an appropriate Cookie value." " DTLS state MUST deleted when a TLS Closure Alert ([RFC5246] Section 7.2.1) or a Fatal TLS Error Alert ([RFC5246] Section 7.2.2) is received." The following text tries to clarify some ambiguity around the silent discar= d behavior (I'm not convinced that this is the right behavior, but that is = a separate issue).=20 "Where the RADIUS specifications require that a packet received via a DTLS session be "silently discarded", such as a failed me= ssage authenticator validation, the DTLS session MUST=20 be closed, and any TLS session resumption parameters for that session MUST be discarded. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter." " As UDP does not guarantee delivery of messages, RADIUS/DTLS servers MUST also maintain a "Last Packet" timestamp per DTLS session. The timestamp SHOULD be updated on reception of a valid DTLS packet. The timestamp MUST NOT be updated in other situations. When a session has not received a packet for a period of time, it is labelled "idle". The server SHOULD delete idle DTLS sessions after an "idle time= out".=20 The server MAY cache the TLS session parameters, in order to provide for fast session resumption." " This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum value useful value for this timer is determined by the application-layer watchdog mechanism defined in the following section." "RADIUS/DTLS servers SHOULD also keep track of the total number of DTLS sessions They SHOULD stop the creating of new sessions when a large number are already being tracked. This "maximum sessions" number SHOULD be exposed to administrators as a configurable setting." 5. Section 4.1.3 I'm not convinced that tearing down the DTLS session when there is an upper= layer discard is the right thing to do. For example its possible that a = packet is discard because of EAP processing. In this case the DTLS session= would be torn down. I would be possible for a network access client to ca= use the DTLS session between the RADIUS client and server to be torn down. = This doesn't seem like a good thing. =20 =20 6. Section 4.2 The discussion of connected sockets is implementation specific.=20 Should the client always initiate DTLS if it supports it? What will a lega= cy RADIUS server do if it receives a type code of 22? Will the client switc= h over after a timeout?=20 THere also is a DTLS heartbeat that can be used, which could be an alternat= ive. The DTLS heartbeat can go in the reverse direction as well.=20 It might be useful for servers to support RFC 5077 stateless session resump= tion.=20 7 Section 7.1 Should note that TLS-PSK is not resistant to dictionary attacks. Its not clear to me why you are recommending hashing the output of the CSPR= NG. I think it would be better to recommend that PSKs be at least 16 octet= s (or 32 if you prefer) generated from a strong random number generator. R= andomness recommendations are provided in BCP106(RFC4086) From mauricio.sanchez@hp.com Wed Nov 21 08:32:59 2012 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 11ACD21F8721 for ; Wed, 21 Nov 2012 08:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.4 X-Spam-Level: X-Spam-Status: No, score=-108.4 tagged_above=-999 required=5 tests=[AWL=2.199, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XuQsBA8KPxsO for ; Wed, 21 Nov 2012 08:32:58 -0800 (PST) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id 5D99921F8717 for ; Wed, 21 Nov 2012 08:32:58 -0800 (PST) Received: from G5W2206G.americas.hpqcorp.net (g5w2206g.atlanta.hp.com [16.228.43.185]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id E38E82C070; Wed, 21 Nov 2012 16:32:53 +0000 (UTC) Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G5W2206G.americas.hpqcorp.net (16.228.43.185) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 21 Nov 2012 16:31:43 +0000 Received: from G6W2500.americas.hpqcorp.net ([169.254.12.87]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.02.0283.004; Wed, 21 Nov 2012 16:31:42 +0000 From: "Sanchez, Mauricio (HP Networking)" To: Alan DeKok , Klaas Wierenga Thread-Topic: [radext] Adopt draft-wierenga-ietf-eduroam? Thread-Index: AQHNvccRu8ClS1K9MUidZHYCpQuoApfgj4SAgBN6LwA= Date: Wed, 21 Nov 2012 16:31:42 +0000 Message-ID: In-Reply-To: <509C3AB5.30303@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [15.193.49.26] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3436331500_2656348" MIME-Version: 1.0 Cc: "radext@ietf.org" , Tomasz Wolniewicz , Stefan Winter Subject: Re: [radext] Adopt draft-wierenga-ietf-eduroam? 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, 21 Nov 2012 16:32:59 -0000 --B_3436331500_2656348 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Klaas, As Alan points out this draft is not within our current charter. We just concluded discussion on the current recharter and we have a number of work items to keep us busy for the next couple of months. I expect that in the Spring of next year, we'll open the charter back up for discussion at which point we'd be happy to decide whether this work merits inclusion. In the meantime, I suggest you continue refining the draft and drumming up support (you've already got Alan on board). We'll make sure to keep a slot open for you at the next IETF meeting to present. -MS On 11/8/12 6:05 PM, "Alan DeKok" wrote: >Klaas Wierenga wrote: >> I would >> like https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/ to be >> considered for adoption as WG item. >> We could also progress it as independent submission but given that a >> number of radext work items are inspired by implementation >> experience in eduroam and that we in particular are looking for document >> review of radext participants I think it makes sense to do it in radext. > > Well, it's not on-charter. > > However, it's documenting existing practice, and falls well within the > practice of previous standards. > > What do the authors see as the benefit by having it a WG item? The >document can still be published as an information RFC, without having WG >blessing. > > I'm willing to review it, whether it's a WG document or not. > > Alan DeKok. >_______________________________________________ >radext mailing list >radext@ietf.org >https://www.ietf.org/mailman/listinfo/radext --B_3436331500_2656348 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgv97vGDtLLFfaCP3cYiJGuw09 ULZ8z2udnkexztAhdxwwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTIxMTIxMTYzMTQwWjANBgkqhkiG9w0BAQEFAASCAQA2OMHsP098gRIIWAMmOsHedteV 31WN4ltDz1931T51Xl/qwcO692PB+CKKjdqLCwoAckjlQzpr6lMrNZm9NXuKZ59aOMSd7sKa arC62C7v8C6pVANu+kZd2Mbi6REt8KOY6RZhwMw1zsAMd1ipMDqN9rm8pdw+Mr5Y+iNYgxjb GgysAjqLg/MCnAnyY4S6Cx/25HLgKZWcItpKFW0FX3ZyT9pe5tGJ8fOg37oFEvO0+5Y8qaxP PqaFN/Z1Z52pxSW6Jqi79LM4urYu5nbJaM20irKU1Em5YvkOIvA5F/WcMVtfHdUjpY13Hq1Q LyQJPj36NG94wKVjDAv61lrn/2o5 --B_3436331500_2656348-- From klaas@wierenga.net Thu Nov 22 03:32:12 2012 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 4628921F8820 for ; Thu, 22 Nov 2012 03:32:12 -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 1Gfdx2xVtEhw for ; Thu, 22 Nov 2012 03:32:11 -0800 (PST) Received: from out29-ams.mf.surf.net (out29-ams.mf.surf.net [145.0.1.29]) by ietfa.amsl.com (Postfix) with ESMTP id 64B8621F8818 for ; Thu, 22 Nov 2012 03:32:10 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing1-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qAMBVw1u016409; Thu, 22 Nov 2012 12:31:58 +0100 Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=dhcp-10-55-95-76.cisco.com) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TbUvH-000MKz-8j; Thu, 22 Nov 2012 12:26:23 +0100 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Klaas Wierenga In-Reply-To: Date: Thu, 22 Nov 2012 12:31:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <243CBF84-1D7E-4495-8087-16AD09A1F831@wierenga.net> References: To: "Sanchez, Mauricio (HP Networking)" X-Mailer: Apple Mail (2.1085) X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0uIqzvW2J - 490733eab262 - 20121122 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "radext@ietf.org" , Stefan Winter , Tomasz Wolniewicz , Alan DeKok Subject: Re: [radext] Adopt draft-wierenga-ietf-eduroam? 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, 22 Nov 2012 11:32:12 -0000 On Nov 21, 2012, at 5:31 PM, Sanchez, Mauricio (HP Networking) wrote: Hi Mauricio, >=20 > As Alan points out this draft is not within our current charter. We = just > concluded discussion on the current recharter and we have a number of = work > items to keep us busy for the next couple of months. I expect that in = the yeah , given the urgency of some of the work items that seems reasonable > Spring of next year, we'll open the charter back up for discussion at > which point we'd be happy to decide whether this work merits = inclusion. > In the meantime, I suggest you continue refining the draft and = drumming up > support (you've already got Alan on board). We'll make sure to keep a = slot > open for you at the next IETF meeting to present. yes, depending on how far we converge we might go the individual = submission route. Presentation slot appreciated! Thanks, Klaas >=20 > -MS =20 >=20 >=20 >=20 >=20 > On 11/8/12 6:05 PM, "Alan DeKok" wrote: >=20 >> Klaas Wierenga wrote: >>> I would >>> like https://datatracker.ietf.org/doc/draft-wierenga-ietf-eduroam/ = to be >>> considered for adoption as WG item. >>> We could also progress it as independent submission but given that a >>> number of radext work items are inspired by implementation >>> experience in eduroam and that we in particular are looking for = document >>> review of radext participants I think it makes sense to do it in = radext. >>=20 >> Well, it's not on-charter. >>=20 >> However, it's documenting existing practice, and falls well within = the >> practice of previous standards. >>=20 >> What do the authors see as the benefit by having it a WG item? The >> document can still be published as an information RFC, without having = WG >> blessing. >>=20 >> I'm willing to review it, whether it's a WG document or not. >>=20 >> Alan DeKok. >> _______________________________________________ >> 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 aland@deployingradius.com Sun Nov 25 06:36:00 2012 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 E63D521F8445 for ; Sun, 25 Nov 2012 06:36:00 -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 tflZyxJ+nsbl for ; Sun, 25 Nov 2012 06:36:00 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 08AAD21F8443 for ; Sun, 25 Nov 2012 06:36:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 94CB322408BE; Sun, 25 Nov 2012 15:35:56 +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 Xz7oQ5PbB1MD; Sun, 25 Nov 2012 15:35:56 +0100 (CET) Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id 98A4E22403DE; Sun, 25 Nov 2012 15:35:55 +0100 (CET) Message-ID: <50B22CCB.1020202@deployingradius.com> Date: Sun, 25 Nov 2012 09:35:55 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Comments draft-ietf-radext-dtls-02 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, 25 Nov 2012 14:36:01 -0000 Joseph Salowey (jsalowey) wrote: > The document has a few issues that need to be resolved: > > 1. What is the expected behavior if the request authenticator or message authenticator verification fails? I believe the behavior is that the RADIUS layer silently ignores the message and the DTLS session is torn down, but I think this should be more explicitly stated. That was the intention. I will clarify that in the document. > 2. The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wrong. I'll go cross-check the document and update the references. > 3. Implementation specifics are mixed in with the normative text throughout the document. There should be a separate informative section in implementation. THis includes I'm of two minds about this. > - Section 3 Discussions of connected UDP sockets That is a bit more implementation, yes. > - Section 3 DIscussion of local proxy That for me is more security related. > - Section 4.1 Discussion of connected sockets > - Section 4.1 and 4.1.1 seems a bit implementation specific, I believe it should discus DTLS session/state Management instead of Table management. an informative description of the table is fine, but most of the text can be described without reference to a table. The terminology here is less relevant than the requirements. Whether it's a table or just "Session management" is basically > The following text tries to clarify some ambiguity around the silent discard behavior (I'm not convinced that this is the right behavior, but that is a separate issue). Well, I'd appreciate productive discussion on that topic. I understand the interest in being graceful under "soft" failures. (e.g. unknown codes, but well-formed packets). But for malformed packets, there is no logical reason to keep speaking RADIUS to a non-RADIUS client. I'll take a look at your text, and try to integrate it into the document. > 5. Section 4.1.3 > > I'm not convinced that tearing down the DTLS session when there is an upper layer discard is the right thing to do. For example its possible that a packet is discard because of EAP processing. In this case the DTLS session would be torn down. I would be possible for a network access client to cause the DTLS session between the RADIUS client and server to be torn down. This doesn't seem like a good thing. RADIUS packets are never "silently discarded" by a server due to EAP. They RFC3579 says they're silently when there is no Message-Authenticator. If this is a sticking point for people, I welcome *specific* suggestions about what circumstances apply, and what to do in those circumstances. I'm wary of filling this document with "RFC X Section Y says silently discard, but the DTLS session stays up. RFC Z Section Q says silently discard, but the DTLS session should be torn down". That makes implementation difficult. > 6. Section 4.2 > > The discussion of connected sockets is implementation specific. OK. > Should the client always initiate DTLS if it supports it? What will a legacy RADIUS server do if it receives a type code of 22? Will the client switch over after a timeout? The document describes a "DTLS Required" flag, which is set by the administrator. A legacy server receiving a DTLS packet will silently discard it independent of the code, as the DTLS packet is not in the form of a RADIUS packet. > THere also is a DTLS heartbeat that can be used, which could be an alternative. The DTLS heartbeat can go in the reverse direction as well. OK. I'll mention that. > It might be useful for servers to support RFC 5077 stateless session resumption. OK. > 7 Section 7.1 > > Should note that TLS-PSK is not resistant to dictionary attacks. OK. > Its not clear to me why you are recommending hashing the output of the CSPRNG. I think it would be better to recommend that PSKs be at least 16 octets (or 32 if you prefer) generated from a strong random number generator. Randomness recommendations are provided in BCP106(RFC4086) Good point. I'll update the document. From bernard_aboba@hotmail.com Sun Nov 25 12:00:32 2012 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 EA64521F8658; Sun, 25 Nov 2012 12:00:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.479 X-Spam-Level: X-Spam-Status: No, score=-102.479 tagged_above=-999 required=5 tests=[AWL=0.119, 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 rOssbmuidoE7; Sun, 25 Nov 2012 12:00:32 -0800 (PST) Received: from blu0-omc4-s37.blu0.hotmail.com (blu0-omc4-s37.blu0.hotmail.com [65.55.111.176]) by ietfa.amsl.com (Postfix) with ESMTP id F089321F8683; Sun, 25 Nov 2012 12:00:31 -0800 (PST) Received: from BLU002-W217 ([65.55.111.135]) by blu0-omc4-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 25 Nov 2012 12:00:31 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_" X-Originating-IP: [24.16.96.166] From: Bernard Aboba To: "Joseph Salowey (jsalowey)" Date: Sun, 25 Nov 2012 12:00:30 -0800 Importance: Normal In-Reply-To: <50B2289A.8060402@deployingradius.com> References: , <50B2289A.8060402@deployingradius.com> MIME-Version: 1.0 X-OriginalArrivalTime: 25 Nov 2012 20:00:31.0027 (UTC) FILETIME=[85B9B830:01CDCB47] Cc: "radext@ietf.org" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" Subject: Re: [radext] [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07 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, 25 Nov 2012 20:00:33 -0000 --_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Joseph Salowey (jsalowey) wrote: >Therefore RADIUS messages using the 6rd attribute MUST include a =0A= message-authenticator attribute or another attribute that is capable of =0A= authenticating the RADIUS packet. =20 >=20 > I missed that. I agree with the requirement for a Message-Authenticato= r. [BA]=0A= Yes=2C as currently specified the Access-Request is not authenticated or = =0A= integrity protected=2C and is therefore susceptible to forgery. =20 > > 1. A RADIUS message used for call-check does not contain any informati= on that would authenticate the request. =20 [BA] There isn't even any information with which to authorize the request. = The "Call Check" Service-Type was designed for situations where authorizat= ion can be determined via the Called-Station-Id or Calling-Station-Id attri= butes=2C which originally contained telephone numbers. In RFC 3580=2C Call= ed/Calling-Station-Id could also contain a MAC address=2C but the principle= was similar -- an unique (non-authenticated) identifier which could be use= d to determine whether a call was authorized. Here is what RFC 2865 Sectio= n 5.6 says about Call Check: Call Check Used by the NAS in an Access-Request packet to=0A= indicate that a call is being received and=0A= that the RADIUS server should send back an=0A= Access-Accept to answer the call=2C or an=0A= Access-Reject to not accept the call=2C=0A= typically based on the Called-Station-Id or=0A= Calling-Station-Id attributes. It is=0A= recommended that such Access-Requests use the=0A= value of Calling-Station-Id as the value of=0A= the User-Name. However=2C this document does not say anything about use of the Calling-Sta= tion-Id or Called-Station-Id attributes=2C or the value of the User-Name at= tribute. Given that=2C the use of Service-Type =3D "Call Check" would not = seem to apply. > > 2. I'm not so familiar with the deployment scenario here so I have a = question. Is it possible that the BNG was involved in a previous transacti= on with the AAA server to authenticate a user? If this is the case then t= he BNG may have received a state attribute in the access-accept message. = Returning this state attribute to the AAA server allows the AAA server to l= ink the 6rd request with the original authentication transaction. If thi= s is a possible scenario the document should specify this since state attri= butes are not typically used with the call-check service. Also if its the = case that there could have been a related previous authentication session i= t seems that it should be possible to include this attribute in an access-r= equest as part of the authentication exchange. =20 >=20 > I *think* that the answer here is "no". The document previously used > Service-Type =3D Authorize-Only and a State attribute. After some > discussion=2C it was decided to change that to Call-Check=2C because ther= e > was no way to obtain a State attribute. [BA] As I understand it=2C at least one of the scenarios described in the d= ocument would involve the retrieval of DHCP information along with a user a= uthentication. In such a scenario=2C why would either Authorize-Only or Ca= ll Check be needed? > 3. It was not clear in the specification what is sent in the access-requ= est message is the BNG is looking to get a IPv6-6rd-configuration attribute= in the access accept. It seems that you would need to send this attribute= in the request if you expected it in the response or else the AAA server w= ould not be able to un-ambiguously be able to service the request=3B there = are other uses for the call-check service. I think you should specify tha= t the 6rd attribute must be in the request if you want to see it in the res= ponse. =20 >=20 [BA] Yes. Otherwise the RADIUS server would not know that an IPv6-6rd-conf= iguration attribute was needed. = --_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B Joseph Salowey (= jsalowey) wrote:

>=3BTherefore RADIUS messages using the 6rd attri= bute MUST include a =0A= message-authenticator attribute or another attribute that is capable of =0A= authenticating the RADIUS packet.
>=3B
>=3B I missed that. = I agree with the requirement for a Message-Authenticator.

[BA]=0A= Yes=2C as currently specified the Access-Request is not authenticated or = =0A= integrity protected=2C and is therefore susceptible to forgery. =3B
>=3B >=3B 1. A RADIUS message used for call-check does not contai= n any information that would authenticate the request.

[BA] There = isn't even any information with which to authorize the request. =3B The= "Call Check" Service-Type was designed for situations where authorization = can be determined via the Called-Station-Id or Calling-Station-Id attribute= s=2C which originally contained telephone numbers. =3B In RFC 3580=2C C= alled/Calling-Station-Id could also contain a MAC address=2C but the princi= ple was similar -- an unique (non-authenticated) identifier which could be = used to determine whether a call was authorized. =3B Here is what RFC 2= 865 Section 5.6 says about Call Check:

     C=
all Check          Used by the NAS in an Access-Request packet to=0A=
                          indicate that a call is being received and=0A=
                          that the RADIUS server should send back an=0A=
                          Access-Accept to answer the call=2C or an=0A=
                          Access-Reject to not accept the call=2C=0A=
                          typically based on the Called-Station-Id or=0A=
                          Calling-Station-Id attributes.  It is=0A=
                          recommended that such Access-Requests use the=0A=
                          value of Calling-Station-Id as the value of=0A=
                          the User-Name.

However=2C this document = does not say anything about use of the Calling-Station-Id or Called-Station= -Id attributes=2C or the value of the User-Name attribute. =3B Given th= at=2C the use of Service-Type =3D "Call Check" would not seem to apply.
=
>=3B >=3B 2. I'm not so familiar with the deployment scenario her= e so I have a question. Is it possible that the BNG was involved in a prev= ious transaction with the AAA server to authenticate a user? If this is t= he case then the BNG may have received a state attribute in the access-acce= pt message. Returning this state attribute to the AAA server allows the A= AA server to link the 6rd request with the original authentication transact= ion. If this is a possible scenario the document should specify this sin= ce state attributes are not typically used with the call-check service. Al= so if its the case that there could have been a related previous authentica= tion session it seems that it should be possible to include this attribute = in an access-request as part of the authentication exchange.
>=3B >=3B I *think* that the answer here is "no". The document previously= used
>=3B Service-Type =3D Authorize-Only and a State attribute. Aft= er some
>=3B discussion=2C it was decided to change that to Call-Check= =2C because there
>=3B was no way to obtain a State attribute.

= [BA] As I understand it=2C at least one of the scenarios described in the d= ocument would involve the retrieval of DHCP information along with a user a= uthentication. =3B In such a scenario=2C why would either Authorize-Onl= y or Call Check be needed?

>=3B 3. It was not clear in the specif= ication what is sent in the access-request message is the BNG is looking to= get a IPv6-6rd-configuration attribute in the access accept. It seems tha= t you would need to send this attribute in the request if you expected it i= n the response or else the AAA server would not be able to un-ambiguously b= e able to service the request=3B there are other uses for the call-check se= rvice. I think you should specify that the 6rd attribute must be in the r= equest if you want to see it in the response.
>=3B

[BA] Yes= . =3B Otherwise the RADIUS server would not know that an IPv6-6rd-confi= guration attribute was needed.
= --_1d696ece-3a08-4474-ba8e-6a3d8c3075ec_-- From aland@deployingradius.com Sun Nov 25 15:01:34 2012 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 1D8E821F846D; Sun, 25 Nov 2012 15:01:34 -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 RiaZSk2OYOpQ; Sun, 25 Nov 2012 15:01:33 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7B62021F846C; Sun, 25 Nov 2012 15:01:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 85ACF22408BE; Mon, 26 Nov 2012 00:00:32 +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 pkcW+HC8HDtp; Mon, 26 Nov 2012 00:00:32 +0100 (CET) Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id 1F95E22403DE; Mon, 26 Nov 2012 00:00:31 +0100 (CET) Message-ID: <50B2A30E.4020605@deployingradius.com> Date: Sun, 25 Nov 2012 18:00:30 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: , <50B2289A.8060402@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "Joseph Salowey \(jsalowey\)" , "iesg@ietf.org" , "draft-ietf-softwire-6rd-radius-attrib.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [radext] [secdir] Secdir review of draft-ietf-softwire-6rd-radius-attrib-07 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, 25 Nov 2012 23:01:34 -0000 Bernard Aboba wrote: > [BA] There isn't even any information with which to authorize the > request. The "Call Check" Service-Type was designed for situations > where authorization can be determined via the Called-Station-Id or > Calling-Station-Id attributes, which originally contained telephone > numbers. The issue I have is what else to use. IIRC, I suggested a new Service-Type at one point. But that didn't seem to fly. > [BA] As I understand it, at least one of the scenarios described in the > document would involve the retrieval of DHCP information along with a > user authentication. In such a scenario, why would either > Authorize-Only or Call Check be needed? It would seem useful to have a Service-Type in the packet. The alternative would be to delete it entirely. Alan DeKok. From jouni.nospam@gmail.com Mon Nov 26 01:26:16 2012 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 6951221F8538; Mon, 26 Nov 2012 01:26:14 -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 gRx1hbrelxln; Mon, 26 Nov 2012 01:26:12 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 26EAF21F8431; Mon, 26 Nov 2012 01:26:07 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id d3so8923448lah.31 for ; Mon, 26 Nov 2012 01:25:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=aj0q5wX8UlispN93rvxHVtb3o3TlSwpuDyVTs3vyClA=; b=ClyNa6JYTTV+usTpU3CJkXe71NdDyKu41zuDPQn/BdU7GAv+kgvVZyzB/ZNG75ptJY zkbQLAJc0HMTJXxRYOYnpPOfhqflY5AXNgLq9p+MAPbypR1w45KRBgkBIsTJy6ltrWaV GAK+ppGwaX1QKiMkvtbRqTvqwc+SRBmcasQjTu2Zildpb1uCaGdhFIE/EekGESxz4SiC LNWbNG4qoutX5Lbuidj5pI0Wx3EGb2XyV3hc/BFNX7FGKRt2/1khFdnZDLGdkQkz/yYn twrcSrHS8gg95nofeve/lZEOYHX4SZmcH4FupmV4FjOS6bhZK5bd5dtGa9gzLvm8mf1X oH8A== Received: by 10.112.29.9 with SMTP id f9mr4887846lbh.22.1353921958282; Mon, 26 Nov 2012 01:25:58 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:226:bbff:fe18:6e9c? ([2001:1bc8:101:f101:226:bbff:fe18:6e9c]) by mx.google.com with ESMTPS id g5sm5305628lbk.7.2012.11.26.01.25.55 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 01:25:57 -0800 (PST) From: jouni korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 26 Nov 2012 11:25:53 +0200 Message-Id: To: iesg-secretary@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) Cc: Benoit Claise , radext@ietf.org Subject: [radext] Publication request for draft-ietf-radext-radius-extensions-06 as Standard Track RFC 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, 26 Nov 2012 09:26:16 -0000 Dear secretary, This is a request for publication of = draft-ietf-radext-radius-extensions-06 as a standard track RFC. - Jouni (RADEXT co-chair) 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=20 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. AAA Doctors have not reviewed the document yet. There is no need for = MIB or other doctorate review. Personnel: Jouni Korhonen (jouni.nospam@gmail.com) is the document shepherd. Benoit Claise is the responsible AD. (3) Briefly describe the review of this document that was performed by = the Document Shepherd. If this version of the document is not ready for = publication, please explain why the document is being forwarded to the = IESG. The document shepherd has reviewed the document after it has = concluded the WGLC. The document shepherd thinks the document is ready for = publication and there is no reason to delay the publication anymore, since the = solutions defined in this document are needed by the industry. The remaining = non-technical editorial nits can be handled in subsequent revisions of the I-D = during the publication process. (4) Does the document Shepherd have any concerns about the depth or = breadth of the reviews that have been performed? No. (5) Do portions of the document need review from a particular or from = broader perspective, e.g., security, operational complexity, AAA, DNS, = DHCP, XML, or internationalization? If so, describe the review that took = place. The document should be reviewed by AAA Directorate once it goes to = IETF LC. (6) Describe any specific concerns or issues that the Document Shepherd = has with this document that the Responsible Area Director and/or the = IESG should be aware of? For example, perhaps he or she is uncomfortable = with certain parts of the document, or has concerns whether there really = is a need for it. In any event, if the WG has discussed those issues and = has indicated that it still wishes to advance the document, detail those = concerns here. The document shepherd has no specific concerns. (7) Has each author confirmed that any and all appropriate IPR = disclosures required for full conformance with the provisions of BCP 78 = and BCP 79 have already been filed. If not, explain why? No IPRs have been declared. (8) Has an IPR disclosure been filed that references this document? If = so, summarize any WG discussion and conclusion regarding the IPR = disclosures. No IPRs have been declared. (9) How solid is the WG consensus behind this document? Does it = represent the strong concurrence of a few individuals, with others being = silent, or does the WG as a whole understand and agree with it? The WG consensus is solid and does not represent only the opinion of few individuals. (10) Has anyone threatened an appeal or otherwise indicated extreme = discontent? If so, please summarise the areas of conflict in separate = email messages to the Responsible Area Director. (It should be in a = separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this = document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts = Checklist). Boilerplate checks are not enough; this check needs to be = thorough. The ID nits reports three warnings, which all are either bogus or due = to lack of "NOT RECOMMENDED" in the standard RFC2119 text provided by = the=20 xml2rfc template. The ID nits reports multiple comments on the document abstract (lack = of "updates RFC xyz" text) but these can be included latest during the = document=20 edit time. Other than the above, the document passes ID nits. (12) Describe how the document meets any required formal review = criteria, such as the MIB Doctor, media type, and URI type reviews. The document does not define MIBs, media types, URIs etc. (13) Have all references within this document been identified as either = normative or informative? Yes. (14) Are there normative references to documents that are not ready for = advancement or are otherwise in an unclear state? If such normative = references exist, what is the plan for their completion? No. (15) Are there downward normative references references (see RFC 3967)? = If so, list these downward references to support the Area Director in = the Last Call procedure. No. however, RFC5226 (BCP) is currently listed as a Normative = Reference and it is typically been listed as an Informative Reference. (16) Will publication of this document change the status of any existing = RFCs? Are those RFCs listed on the title page header, listed in the = abstract, and discussed in the introduction? If the RFCs are not listed = in the Abstract and Introduction, explain why, and point to the part of = the document where the relationship of this document to the other RFCs = is discussed. If this information is not in the document, explain why = the WG considers it unnecessary. Yes. RFCs 2865, 2866, 3575, 5176, 6158 will be updated. These RFCs = listed in the title page header but not in the abstract or in the introduction. = The most important updates RFC3575 and RFC6158 are discussed in the main = text. The missing abstract text is plain editorial and can be added if seen=20= necessary. (17) Describe the Document Shepherd's review of the IANA considerations = section, especially with regard to its consistency with the body of the = document. Confirm that all protocol extensions that the document makes = are associated with the appropriate reservations in IANA registries. = Confirm that any referenced IANA registries have been clearly = identified. Confirm that newly created IANA registries include a = detailed specification of the initial contents for the registry, that = allocations procedures for future registrations are defined, and a = reasonable name for the new registry has been suggested (see RFC 5226). The IANA section is clear and extensive regarding to the new = allocation practices. The I-D allocates six attributes for the extended types and long = extended types. Initial assignment for the new style extended attributes is also = done. The IANA considerations also give detailed instructions how the = allocations are to be done from the extended type space. (18) List any new IANA registries that require Expert Review for future = allocations. Provide any public guidance that the IESG would find useful = in selecting the IANA Experts for these new registries. There are no new registries per se. However, the I-D describes = clearly how the new style dotted attribute type tree is to be constructed. It is = up to IANA to decide how the dotted attribute type tree is arranged in the existing RADIUS registry i.e., whether they are placed separately or part of the existing Radius Attribute Types registry. The existing IANA experts are recommended but they need to get = familiar with the new style of type tree layout. (19) Describe reviews and automated checks performed by the Document = Shepherd to validate sections of the document written in a formal = language, such as XML code, BNF rules, MIB definitions, etc. Checked with ID nits. There are no additional concerns.= From leaf.y.yeh@huawei.com Mon Nov 26 03:27:05 2012 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 2284421F84FB for ; Mon, 26 Nov 2012 03:27:05 -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 gFj0SueqgpF7 for ; Mon, 26 Nov 2012 03:27:04 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F380821F84F3 for ; Mon, 26 Nov 2012 03:27:01 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AND61574; Mon, 26 Nov 2012 11:26:58 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Nov 2012 11:26:51 +0000 Received: from SZXEML443-HUB.china.huawei.com (10.82.67.181) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 26 Nov 2012 11:26:54 +0000 Received: from SZXEML546-MBX.china.huawei.com ([169.254.3.214]) by SZXEML443-HUB.china.huawei.com ([10.82.67.181]) with mapi id 14.01.0323.003; Mon, 26 Nov 2012 19:26:24 +0800 From: Leaf yeh To: "Sanchez, Mauricio (HP Networking)" , jouni korhonen , "aland@deployingradius.com" Thread-Topic: [radext] RADEXT recharter proposal Thread-Index: AQHNvQ7e/rCT9/yTIUeexf7vFvauOJfkkeYAgBIrwWA= Date: Mon, 26 Nov 2012 11:26:21 +0000 Message-ID: References: <50A006FE.6030401@cisco.com> In-Reply-To: <50A006FE.6030401@cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.83.152] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Benoit Claise , "radext@ietf.org" , "mohamed.boucadair@orange.com" Subject: Re: [radext] RADEXT recharter 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, 26 Nov 2012 11:27:05 -0000 Jouni and Mauricio - Pasted below is the current recharter proposal for rad= ext. =A0The largest change from the previous circulated proposal is the rem= ove of the traffic statistics work. =A0After consultation with our AD, we t= he chairs have decided to postpone adding this work item until we have a cl= earer understanding for scope of problem and solution . After reading this, my curious question turns to be how long we will need = to figure out the 'scope of problem and solution' for the potential work it= em of 'traffic statistics'? Best Regards, Leaf ------------------------------------------------------ From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= Benoit Claise Sent: Monday, November 12, 2012 4:14 AM To: Sanchez, Mauricio (HP Networking) Cc: radext@ietf.org Subject: Re: [radext] RADEXT recharter proposal Dear all, The deadline is passed. Let me submit the new charter to the IESG. I changed the following dates to Dec 2012 =A0=A0=A0 Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC =A0=A0=A0 Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC Not that I want to delay the work, but if, for whatever reason, the charter= approval is delayed, it would not make sense to have a draft deadline in t= he past. Regardless, progress the drafts ASAP Regards, Benoit Pasted below is the current recharter proposal for radext. =A0The largest c= hange from the previous circulated proposal is the remove of the traffic st= atistics work. =A0After consultation with our AD, we the chairs have decide= d to postpone adding this work item until we have a clearer understanding f= or scope of problem and solution . =A0 Moreover, we already have a number o= f items that are severely overdue and several more solid individual submiss= ions that are eminent work items (pending this recharter). =A0 =A0We would = like any feedback by EOB Friday as our AD is ready to run this recharter te= xt through the process. =A0=A0 -Jouni and Mauricio=A0 -------------------------------------------------------- Description of Working Group The RADIUS Extensions Working Group will focus on extensions to the RADIUS = =A0protocol required to expand and enrich the standard attribute space, add= ress =A0cryptographic algorithm agility, use of new secure transports and c= larify its usage and definition. In order to maintain interoperation of heterogeneous RADIUS/Diameter deploy= ments, all RADEXT WG work items except those that just define new attribute= s MUST contain a Diameter compatibility section, outlining how interoperabi= lity with Diameter will be maintained. Furthermore, to ensure backward compatibility with existing RADIUS =A0imple= mentations, as well as compatibility between RADIUS and Diameter, the follo= wing restrictions are imposed on extensions considered by the RADEXT WG: - All documents produced MUST specify means of interoperation with legacy R= ADIUS =A0and, if possible, be backward compatible with existing RADIUS RFCs= , including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5= 090, 5176 and 6158. Transport profiles should, if possible, be compatible w= ith RFC 3539. Work Items The immediate goals of the RADEXT working group are to address the followin= g issues: - RADIUS attribute space extension. The standard RADIUS attribute space is = currently being depleted. This document will provide additional standard at= tribute space, while maintaining backward compatibility with existing attri= butes. - IEEE 802 attributes. New attributes have been proposed to support IEEE 80= 2 standards for wired and wireless LANs. This work item will support authen= tication, authorization and accounting attributes needed by IEEE 802 groups= including IEEE 802.1, IEEE 802.11 and IEEE 802.16. - New RADIUS transports. A reliable transport profile for RADIUS will be de= veloped, as well as specifications for Secure transports, including TCP/TLS= (RADSEC) and UDP/DTLS. - Update and clarification of Network Access Identifiers (RFC4282).This wor= k item will correct and clarify issues present with RFC4282 in two phases. = =A0In first phase, RFC4282bis will be issued to eliminate fundamental incom= patibilities with RADIUS around character encoding and NAI modifications by= proxies. =A0In second phase, a fresh review of NAI internationalization re= quirements and behavior will be undertaken with a clear goal of maintaining= compatibility with RADIUS. - Fragmentation of RADIUS packets to support exchanges exceeding the existi= ng 4KB limit imposed by RFC2865. Goals and Milestones Done Updates to RFC 2618-2621 RADIUS MIBs submitted for publication Done SIP RADIUS authentication draft submitted as a Proposed Standard RFC Done RFC 2486bis submitted as a Proposed Standard RFC Done RFC 3576 MIBs submitted as an Informational RFC Done RADIUS VLAN and Priority Attributes draft submitted as a Proposed Stan= dard RFC (reduced in scope) Done RADIUS Implementation Issues and Fixes draft submitted as an Informati= onal RFC Done RADIUS Filtering Attributes draft submitted as a Proposed Standard RFC= (split out from VLAN & Priority draft) Done RFC 3576bis submitted as an Informational RFC (split out from Issues &= Fixes draft) Done RADIUS Redirection Attributes draft submitted as a Proposed Standard R= FC (split out from VLAN & Priority draft) Done RADIUS Design Guidelines submitted as a Best Current Practice RFC Done RADIUS Management Authorization I-D submitted as a Proposed Standard R= FC Done Reliable Transport Profile for RADIUS I-D submitted as a Proposed Stan= dard RFC Done Status-Server I-D submitted as a Proposed Standard RFC Done RADIUS Crypto-agility Requirements submitted as an Informational RFC Done RADSEC (RADIUS over TCP/TLS) draft submitted as an Experimental RFC Nov 2012 IPv6 Access I-D submitted as a Proposed Standard RFC Nov 2012 RFC 4282bis submitted as a Proposed Standard RFC Dec 2012 Extended Attributes I-D submitted as a Proposed Standard RFC Dec 2012 Dynamic Discovery I-D submitted as a Proposed Standard RFC Dec 2012 IEEE 802 Attributes I-D submitted as a Proposed Standard RFC Jan 2012 RADIUS over DTLS I-D submitted as an Experimental RFC Feb 2012 RADIUS packet fragmentation submitted as an Experimental RFC May 2013 RADIUS support for NAI Internationalization I-D submitted as a Pro= posed Standard RFC _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Nov 26 07:20:44 2012 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 3201A21F845D for ; Mon, 26 Nov 2012 07:20:44 -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 7t0tLqsUZVfh for ; Mon, 26 Nov 2012 07:20:43 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6AFEE21F845B for ; Mon, 26 Nov 2012 07:20:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A4ED522406D2; Mon, 26 Nov 2012 16:19:40 +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 e2H05+Oqqd9P; Mon, 26 Nov 2012 16:19:40 +0100 (CET) Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id 83DF2224062C; Mon, 26 Nov 2012 16:19:39 +0100 (CET) Message-ID: <50B3888C.2000003@deployingradius.com> Date: Mon, 26 Nov 2012 10:19:40 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf yeh References: <50A006FE.6030401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Benoit Claise , "radext@ietf.org" , jouni korhonen , "Sanchez, Mauricio \(HP Networking\)" , "mohamed.boucadair@orange.com" Subject: Re: [radext] RADEXT recharter 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, 26 Nov 2012 15:20:44 -0000 Leaf yeh wrote: > After reading this, my curious question turns to be how long we will need to figure out the 'scope of problem and solution' for the potential work item of 'traffic statistics'? That depends on the cooperation of the people involved. As an example, I've reviewed your proposal, and Stefan's. Perhaps you could review my IPFIX proposal. Alan DeKok. From trac+radext@trac.tools.ietf.org Mon Nov 26 21:19:02 2012 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 2AFF321F845D for ; Mon, 26 Nov 2012 21:19: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 DuuPBWaUvU+N for ; Mon, 26 Nov 2012 21:19:01 -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 8D29021F843A for ; Mon, 26 Nov 2012 21:19:01 -0800 (PST) Received: from localhost ([127.0.0.1]:57194 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdDZC-0005Iv-S7; Tue, 27 Nov 2012 06:18:57 +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-dtls@tools.ietf.org, jsalowey@cisco.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 05:18:42 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/137 Message-ID: <059.513cd3e1d604956d1a2ee59762f5c594@trac.tools.ietf.org> X-Trac-Ticket-ID: 137 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, jsalowey@cisco.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: aland@freeradius.org Resent-Message-Id: <20121127051901.8D29021F843A@ietfa.amsl.com> Resent-Date: Mon, 26 Nov 2012 21:19:01 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #137: Clarify behavior if request authenticator or message authenticator fails 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: Tue, 27 Nov 2012 05:19:02 -0000 #137: Clarify behavior if request authenticator or message authenticator fails Joseph Salowey (jsalowey) wrote: The document has a few issues that need to be resolved: 1. What is the expected behavior if the request authenticator or message authenticator verification fails? I believe the behavior is that the RADIUS layer silently ignores the message and the DTLS session is torn down, but I think this should be more explicitly stated. Alan DeKok: That was the intention. I will clarify that in the document. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: dtls | Version: Severity: Active WG | Keywords: Document | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 26 21:21:03 2012 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 4E6B121F8468 for ; Mon, 26 Nov 2012 21:21:03 -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 rLbfgGNSb7-H for ; Mon, 26 Nov 2012 21:21: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 5CD3C21F8465 for ; Mon, 26 Nov 2012 21:21:02 -0800 (PST) Received: from localhost ([127.0.0.1]:57283 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdDbQ-000674-EX; Tue, 27 Nov 2012 06:21:00 +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-dtls@tools.ietf.org, jsalowey@cisco.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 05:21:00 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/138 Message-ID: <059.d09147c3ec8e9a49d033b446fa28cd0c@trac.tools.ietf.org> X-Trac-Ticket-ID: 138 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, jsalowey@cisco.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: aland@freeradius.org Resent-Message-Id: <20121127052102.5CD3C21F8465@ietfa.amsl.com> Resent-Date: Mon, 26 Nov 2012 21:21:02 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #138: The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wrong. 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: Tue, 27 Nov 2012 05:21:03 -0000 #138: The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are wrong. - Section 2.2 in the RADIUS/TLS spec does not discuss cipher suites, but section 2.3 does. - Section 2.3 does apply to radius, except -- bullet 1 I'm not sure if this applies -- bullet 2 applies except for TLS_RSA_WITH_RC4_128_SHA as already noted -- bullet 3 applies -- bullet 4 applies except the secret is different - section 2.4 applies to RADIUS/DTLS - section 2.5 probably does not apply; as noted in draft for section 2.4 - Section 3.3 should reference 3.4 Section 2.2.2 looks like it references the correct sections, but this should be validated. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 26 21:22:55 2012 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 D9D5021F8762 for ; Mon, 26 Nov 2012 21:22:55 -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 jPxAhooVXbku for ; Mon, 26 Nov 2012 21:22:55 -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 1390121F8472 for ; Mon, 26 Nov 2012 21:22:55 -0800 (PST) Received: from localhost ([127.0.0.1]:57414 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdDdF-0000X0-Vp; Tue, 27 Nov 2012 06:22:53 +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-dtls@tools.ietf.org, jsalowey@cisco.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 05:22:53 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/139 Message-ID: <059.9806a99b0f12b9d57b996380e0596169@trac.tools.ietf.org> X-Trac-Ticket-ID: 139 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, jsalowey@cisco.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: aland@freeradius.org Resent-Message-Id: <20121127052255.1390121F8472@ietfa.amsl.com> Resent-Date: Mon, 26 Nov 2012 21:22:55 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #139: Implementation specifics should be informative 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: Tue, 27 Nov 2012 05:22:56 -0000 #139: Implementation specifics should be informative - Section 3 Discussions of connected UDP sockets - Section 3 DIscussion of local proxy - Section 4.1 Discussion of connected sockets - Section 4.1 and 4.1.1 seems a bit implementation specific, I believe it should discus DTLS session/state Management instead of Table management. an informative description of the table is fine, but most of the text can be described without reference to a table. Here is some text that I think is more implementation neutral: " DTLS implementations are subject to Denial of Service (DoS) attacks due to the ability of an attacker to forge UDP traffic. RADIUS/DTLS servers SHOULD use the stateless cookie tracking technique described in [RFC6347] Section 4.2.1. the server SHOULD NOT allocate state until a ClientHello packet has been received with an appropriate Cookie value." " DTLS state MUST deleted when a TLS Closure Alert ([RFC5246] Section 7.2.1) or a Fatal TLS Error Alert ([RFC5246] Section 7.2.2) is received." The following text tries to clarify some ambiguity around the silent discard behavior (I'm not convinced that this is the right behavior, but that is a separate issue). "Where the RADIUS specifications require that a packet received via a DTLS session be "silently discarded", such as a failed message authenticator validation, the DTLS session MUST be closed, and any TLS session resumption parameters for that session MUST be discarded. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter." " As UDP does not guarantee delivery of messages, RADIUS/DTLS servers MUST also maintain a "Last Packet" timestamp per DTLS session. The timestamp SHOULD be updated on reception of a valid DTLS packet. The timestamp MUST NOT be updated in other situations. When a session has not received a packet for a period of time, it is labelled "idle". The server SHOULD delete idle DTLS sessions after an "idle timeout". The server MAY cache the TLS session parameters, in order to provide for fast session resumption." " This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. It SHOULD NOT be set to less than 60 seconds, and SHOULD NOT be set to more than 600 seconds (10 minutes). The minimum value useful value for this timer is determined by the application-layer watchdog mechanism defined in the following section." "RADIUS/DTLS servers SHOULD also keep track of the total number of DTLS sessions They SHOULD stop the creating of new sessions when a large number are already being tracked. This "maximum sessions" number SHOULD be exposed to administrators as a configurable setting." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 26 21:24:41 2012 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 C809F21F84BC for ; Mon, 26 Nov 2012 21:24:41 -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 AU3AbzD8Rh2W for ; Mon, 26 Nov 2012 21:24: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 4233F21F84BA for ; Mon, 26 Nov 2012 21:24:41 -0800 (PST) Received: from localhost ([127.0.0.1]:57654 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdDei-0008DD-F4; Tue, 27 Nov 2012 06:24: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-dtls@tools.ietf.org, jsalowey@cisco.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 05:24:24 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/140 Message-ID: <059.87e56adba24d4b08070371420152228c@trac.tools.ietf.org> X-Trac-Ticket-ID: 140 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, jsalowey@cisco.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: aland@freeradius.org Resent-Message-Id: <20121127052441.4233F21F84BA@ietfa.amsl.com> Resent-Date: Mon, 26 Nov 2012 21:24:41 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #140: tearing down the DTLS session when there is an upper layer discard 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: Tue, 27 Nov 2012 05:24:41 -0000 #140: tearing down the DTLS session when there is an upper layer discard 5. Section 4.1.3 I'm not convinced that tearing down the DTLS session when there is an upper layer discard is the right thing to do. For example its possible that a packet is discard because of EAP processing. In this case the DTLS session would be torn down. I would be possible for a network access client to cause the DTLS session between the RADIUS client and server to be torn down. This doesn't seem like a good thing. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 26 21:25:35 2012 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 6AD8E21F84BC for ; Mon, 26 Nov 2012 21:25:35 -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 IyMiBPCwqTb9 for ; Mon, 26 Nov 2012 21:25:35 -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 DB11921F84BA for ; Mon, 26 Nov 2012 21:25:34 -0800 (PST) Received: from localhost ([127.0.0.1]:57882 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdDfp-0005ES-S4; Tue, 27 Nov 2012 06:25:33 +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-dtls@tools.ietf.org, jsalowey@cisco.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 05:25:33 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/141 Message-ID: <059.d403121a5ea392593c0e3b1e9c21df0a@trac.tools.ietf.org> X-Trac-Ticket-ID: 141 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, jsalowey@cisco.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: aland@freeradius.org Resent-Message-Id: <20121127052534.DB11921F84BA@ietfa.amsl.com> Resent-Date: Mon, 26 Nov 2012 21:25:34 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #141: Comments on Section 4.2 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: Tue, 27 Nov 2012 05:25:35 -0000 #141: Comments on Section 4.2 Section 4.2 The discussion of connected sockets is implementation specific. Should the client always initiate DTLS if it supports it? What will a legacy RADIUS server do if it receives a type code of 22? Will the client switch over after a timeout? THere also is a DTLS heartbeat that can be used, which could be an alternative. The DTLS heartbeat can go in the reverse direction as well. It might be useful for servers to support RFC 5077 stateless session resumption. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Mon Nov 26 21:26:27 2012 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 7BEB721F84D9 for ; Mon, 26 Nov 2012 21:26: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 VVln-dwfPwwk for ; Mon, 26 Nov 2012 21:26: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 3A4DF21F84D0 for ; Mon, 26 Nov 2012 21:26:26 -0800 (PST) Received: from localhost ([127.0.0.1]:57920 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdDgd-0000dj-VP; Tue, 27 Nov 2012 06:26:23 +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-dtls@tools.ietf.org, jsalowey@cisco.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 05:26:23 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/142 Message-ID: <059.c0739674d0e5476266bd9815c8bbac4d@trac.tools.ietf.org> X-Trac-Ticket-ID: 142 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, jsalowey@cisco.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: aland@freeradius.org Resent-Message-Id: <20121127052626.3A4DF21F84D0@ietfa.amsl.com> Resent-Date: Mon, 26 Nov 2012 21:26:26 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: [radext] #142: Comments on Section 7.1 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: Tue, 27 Nov 2012 05:26:27 -0000 #142: Comments on Section 7.1 7 Section 7.1 Should note that TLS-PSK is not resistant to dictionary attacks. Its not clear to me why you are recommending hashing the output of the CSPRNG. I think it would be better to recommend that PSKs be at least 16 octets (or 32 if you prefer) generated from a strong random number generator. Randomness recommendations are provided in BCP106(RFC4086) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: radext From jsalowey@cisco.com Mon Nov 26 21:53:33 2012 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 4F62E21F865F for ; Mon, 26 Nov 2012 21:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 54vkWr8yubM3 for ; Mon, 26 Nov 2012 21:53:32 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2163221F8658 for ; Mon, 26 Nov 2012 21:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5696; q=dns/txt; s=iport; t=1353995612; x=1355205212; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=CX8fvlbVWGFdxKr+e8IoWARM2H6BcrY2LjUsb14yIR8=; b=VuS3lvPP9r3SI1hcRAW2enyddKkLV+EKMyusO9vcY0BzPovks+6RvwCy Eo+ECvHDIFvKEJdzfEIjFieg1LbYXot3S+UkZX3epJKmlJwWuw4G+Wos6 P1qUde+EcSV/G9jfLEalp/NcKJggo1DXDFMqFK3eQ8stiJVqxzZSg0hYs 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAEBUtFCtJXG//2dsb2JhbABEwCuBCYIeAQEBAwF5BQsCAQgYCiQyJQIEDg2HfwawApA6jDODYGEDiCmeHIJvgh0 X-IronPort-AV: E=McAfee;i="5400,1158,6908"; a="146507344" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 27 Nov 2012 05:53:31 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qAR5rVBb015532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 27 Nov 2012 05:53:31 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.22]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.001; Mon, 26 Nov 2012 23:53:31 -0600 From: "Joseph Salowey (jsalowey)" To: Alan DeKok Thread-Topic: [radext] Comments draft-ietf-radext-dtls-02 Thread-Index: AQHNx6aAtkZqo7u/T0iklfoHrT9DAJf7CaKAgAKSloA= Date: Tue, 27 Nov 2012 05:53:30 +0000 Message-ID: References: <50B22CCB.1020202@deployingradius.com> In-Reply-To: <50B22CCB.1020202@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.147] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3EB9B025A7BA81459E87672C84D064A4@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" Subject: Re: [radext] Comments draft-ietf-radext-dtls-02 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, 27 Nov 2012 05:53:33 -0000 On Nov 25, 2012, at 6:35 AM, Alan DeKok wrote: > Joseph Salowey (jsalowey) wrote: >> The document has a few issues that need to be resolved: >>=20 >> 1. What is the expected behavior if the request authenticator or message= authenticator verification fails? I believe the behavior is that the RADI= US layer silently ignores the message and the DTLS session is torn down, bu= t I think this should be more explicitly stated.=20 >=20 > That was the intention. I will clarify that in the document. >=20 >> 2. The sections referenced in the RADIUS/TLS RFC in section 2.2.1 are w= rong. =20 >=20 > I'll go cross-check the document and update the references. >=20 >> 3. Implementation specifics are mixed in with the normative text throug= hout the document. There should be a separate informative section in imple= mentation. THis includes >=20 > I'm of two minds about this. >=20 >> - Section 3 Discussions of connected UDP sockets >=20 > That is a bit more implementation, yes. >=20 >> - Section 3 DIscussion of local proxy >=20 > That for me is more security related. >=20 [Joe] Maybe it would be better in the security considerations. =20 >> - Section 4.1 Discussion of connected sockets >> - Section 4.1 and 4.1.1 seems a bit implementation specific, I believe i= t should discus DTLS session/state Management instead of Table management. = an informative description of the table is fine, but most of the text can = be described without reference to a table.=20 >=20 > The terminology here is less relevant than the requirements. Whether > it's a table or just "Session management" is basically >=20 [Joe] The text currently has some normative RFC2119 language that is fairly= specific about implementing a table. I think the section can convey the b= ehavior without the implementation specifics. If you want help with text l= et me know and I'll provide more comprehensive text. =20 >> The following text tries to clarify some ambiguity around the silent dis= card behavior (I'm not convinced that this is the right behavior, but that = is a separate issue).=20 >=20 > Well, I'd appreciate productive discussion on that topic. >=20 > I understand the interest in being graceful under "soft" failures. > (e.g. unknown codes, but well-formed packets). But for malformed > packets, there is no logical reason to keep speaking RADIUS to a > non-RADIUS client. >=20 > I'll take a look at your text, and try to integrate it into the document= . >=20 >> 5. Section 4.1.3 >>=20 >> I'm not convinced that tearing down the DTLS session when there is an up= per layer discard is the right thing to do. For example its possible that= a packet is discard because of EAP processing. In this case the DTLS sess= ion would be torn down. I would be possible for a network access client to= cause the DTLS session between the RADIUS client and server to be torn dow= n. This doesn't seem like a good thing. =20 >=20 > RADIUS packets are never "silently discarded" by a server due to EAP. > They RFC3579 says they're silently when there is no Message-Authenticator= . >=20 [Joe] OK, but what happens when an EAP method decides to discard a message = form the peer/client? =20 > If this is a sticking point for people, I welcome *specific* > suggestions about what circumstances apply, and what to do in those > circumstances. >=20 > I'm wary of filling this document with "RFC X Section Y says silently > discard, but the DTLS session stays up. RFC Z Section Q says silently > discard, but the DTLS session should be torn down". >=20 > That makes implementation difficult. >=20 [Joe] My suggestion would be to tear down the session in the following sit= uations (does the client tear down DTLS as well?) - failure in message authenticator - failure in response authenticator - invalid packet length - invalid attribute length I'm not sure about these, but I think it would be OK to tear down the sessi= on - invalid code - invalid identifier for other cases I'd leave it up to the implementation, but I'm not sure wha= t the other cases may be. =20 >> 6. Section 4.2 >>=20 >> The discussion of connected sockets is implementation specific.=20 >=20 > OK. >=20 >> Should the client always initiate DTLS if it supports it? What will a l= egacy RADIUS server do if it receives a type code of 22? Will the client sw= itch over after a timeout?=20 >=20 > The document describes a "DTLS Required" flag, which is set by the > administrator. A legacy server receiving a DTLS packet will silently > discard it independent of the code, as the DTLS packet is not in the > form of a RADIUS packet. >=20 [Joe] Currently, the DTLS required flag refers to the server. Maybe there = should be an equivalent flag for the client? perhaps DTLS require and DTLS = optional?=20 >> THere also is a DTLS heartbeat that can be used, which could be an alter= native. The DTLS heartbeat can go in the reverse direction as well.=20 >=20 > OK. I'll mention that. >=20 >> It might be useful for servers to support RFC 5077 stateless session res= umption.=20 >=20 > OK. >=20 >> 7 Section 7.1 >>=20 >> Should note that TLS-PSK is not resistant to dictionary attacks. >=20 > OK. >=20 >> Its not clear to me why you are recommending hashing the output of the C= SPRNG. I think it would be better to recommend that PSKs be at least 16 oc= tets (or 32 if you prefer) generated from a strong random number generator.= Randomness recommendations are provided in BCP106(RFC4086) >=20 > Good point. I'll update the document. >=20 From trac+radext@trac.tools.ietf.org Tue Nov 27 04:47:53 2012 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 343F721F84C8 for ; Tue, 27 Nov 2012 04:47: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 HeItcG2arhJm for ; Tue, 27 Nov 2012 04:47:52 -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 7FC7821F84BC for ; Tue, 27 Nov 2012 04:47:52 -0800 (PST) Received: from localhost ([127.0.0.1]:44390 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdKZa-0003Uv-BI; Tue, 27 Nov 2012 13:47:44 +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-dtls@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 12:47:34 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/137#comment:1 Message-ID: <074.f7eefa9a2f46f8a706dc450b0c260066@trac.tools.ietf.org> References: <059.513cd3e1d604956d1a2ee59762f5c594@trac.tools.ietf.org> X-Trac-Ticket-ID: 137 In-Reply-To: <059.513cd3e1d604956d1a2ee59762f5c594@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.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: aland@freeradius.org Resent-Message-Id: <20121127124752.7FC7821F84BC@ietfa.amsl.com> Resent-Date: Tue, 27 Nov 2012 04:47:52 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #137: Clarify behavior if request authenticator or message authenticator fails 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: Tue, 27 Nov 2012 12:47:53 -0000 #137: Clarify behavior if request authenticator or message authenticator fails Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: Suggested text: Sessions MUST also be deleted when a RADIUS packet fails validation due to a packet being malformed, or when it has an invalid Message-Authenticator, or invalid Request Authenticator. With similar text for clients and Response Authenticator. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: dtls | Version: Severity: Active WG | Resolution: fixed Document | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Tue Nov 27 04:49:21 2012 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 1C4F721F84D0 for ; Tue, 27 Nov 2012 04:49:21 -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 hMOdjXP8qdNm for ; Tue, 27 Nov 2012 04:49:20 -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 753D021F84C8 for ; Tue, 27 Nov 2012 04:49:20 -0800 (PST) Received: from localhost ([127.0.0.1]:44441 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdKbG-0005OA-2o; Tue, 27 Nov 2012 13:49:18 +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-dtls@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 12:49:18 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/139#comment:1 Message-ID: <074.88ced5737026b84df093f7024cf10d27@trac.tools.ietf.org> References: <059.9806a99b0f12b9d57b996380e0596169@trac.tools.ietf.org> X-Trac-Ticket-ID: 139 In-Reply-To: <059.9806a99b0f12b9d57b996380e0596169@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.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: aland@freeradius.org Resent-Message-Id: <20121127124920.753D021F84C8@ietfa.amsl.com> Resent-Date: Tue, 27 Nov 2012 04:49:20 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #139: Implementation specifics should be informative 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: Tue, 27 Nov 2012 12:49:21 -0000 #139: Implementation specifics should be informative Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: Suggested new section: 5. Implementation Guidelines The text above describes the protocol. In this section, we give additional implementation guidelines. These guidelines are not part of the protocol, but may help implementors create simple, secure, and inter-operable implementations. With sub-sections for server and client. All implementation-specific guidelines have been moved here. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Tue Nov 27 04:53:06 2012 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 DB29D21F8444 for ; Tue, 27 Nov 2012 04:53:05 -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 3HqWIwItp4-u for ; Tue, 27 Nov 2012 04:53:05 -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 7A59521F843E for ; Tue, 27 Nov 2012 04:53:04 -0800 (PST) Received: from localhost ([127.0.0.1]:44686 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdKef-0006LZ-UX; Tue, 27 Nov 2012 13:52:59 +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-dtls@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 12:52:49 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/140#comment:1 Message-ID: <074.f2c3f3fd88a6b33c92861aee04170eef@trac.tools.ietf.org> References: <059.87e56adba24d4b08070371420152228c@trac.tools.ietf.org> X-Trac-Ticket-ID: 140 In-Reply-To: <059.87e56adba24d4b08070371420152228c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.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: aland@freeradius.org Resent-Message-Id: <20121127125304.7A59521F843E@ietfa.amsl.com> Resent-Date: Tue, 27 Nov 2012 04:53:04 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #140: tearing down the DTLS session when there is an upper layer discard 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: Tue, 27 Nov 2012 12:53:06 -0000 #140: tearing down the DTLS session when there is an upper layer discard Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: RFC 3579 Section 2.2 says: Pending EAP Responses that do not match the current Identifier value are silently discarded by the NAS. That seems a bad reason to tear down the DTLS session. As a result, it can be left up in that situation. Suggested text: There are other cases when the specifications require that a packet received via a DTLS session be "silently discarded". In those cases, implementations MAY delete the underlying session as described above. There are few reasons to communicate with a NAS which is not implementing RADIUS. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Tue Nov 27 05:00:30 2012 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 201AE21F84BA for ; Tue, 27 Nov 2012 05:00: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 kcg9HVreukBk for ; Tue, 27 Nov 2012 05:00:29 -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 9242C21F849A for ; Tue, 27 Nov 2012 05:00:29 -0800 (PST) Received: from localhost ([127.0.0.1]:45761 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdKlx-0004Fb-7N; Tue, 27 Nov 2012 14:00: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-dtls@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 13:00:21 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/141#comment:1 Message-ID: <074.8586d9dd486c14142f7606fee111eb27@trac.tools.ietf.org> References: <059.d403121a5ea392593c0e3b1e9c21df0a@trac.tools.ietf.org> X-Trac-Ticket-ID: 141 In-Reply-To: <059.d403121a5ea392593c0e3b1e9c21df0a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.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: aland@freeradius.org Resent-Message-Id: <20121127130029.9242C21F849A@ietfa.amsl.com> Resent-Date: Tue, 27 Nov 2012 05:00:29 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #141: Comments on Section 4.2 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: Tue, 27 Nov 2012 13:00:30 -0000 #141: Comments on Section 4.2 Comment (by aland@deployingradius.com): - socket text has been moved to the Implementation Guidelines section. - clients also need a "DTLS Required" flag. This will be added to the document, along with discussions of timeouts - legacy RADIUS servers discard non-RADIUS packets. The first byte is thus irrelevant. - the client will not switch protocols automatically. If it is configured to do DTLS, it will do DTLS. - references to RFC 6520 (heartbeat) and 5077 will be added. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Resolution: Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From trac+radext@trac.tools.ietf.org Tue Nov 27 05:03:54 2012 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 2EBB821F849A for ; Tue, 27 Nov 2012 05:03:54 -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 uikvNOuml0Ta for ; Tue, 27 Nov 2012 05:03: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 0221721F8472 for ; Tue, 27 Nov 2012 05:03:49 -0800 (PST) Received: from localhost ([127.0.0.1]:46248 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TdKpB-0006yz-RO; Tue, 27 Nov 2012 14:03:46 +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-dtls@tools.ietf.org, aland@deployingradius.com X-Trac-Project: radext Date: Tue, 27 Nov 2012 13:03:41 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/radext/trac/ticket/142#comment:1 Message-ID: <074.0974d3bb9a1a55b0c6c38f521dc9bc53@trac.tools.ietf.org> References: <059.c0739674d0e5476266bd9815c8bbac4d@trac.tools.ietf.org> X-Trac-Ticket-ID: 142 In-Reply-To: <059.c0739674d0e5476266bd9815c8bbac4d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-radext-dtls@tools.ietf.org, aland@deployingradius.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: aland@freeradius.org Resent-Message-Id: <20121127130349.0221721F8472@ietfa.amsl.com> Resent-Date: Tue, 27 Nov 2012 05:03:49 -0800 (PST) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #142: Comments on Section 7.1 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: Tue, 27 Nov 2012 13:03:54 -0000 #142: Comments on Section 7.1 Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: Suggested text: Where a TLS pre-shared key (PSK) method is used, implementations MUST support keys of at least 16 octets in length. Implementations SHOULD support key lengths of 32 octets, and SHOULD allow for longer keys. The key data MUST be capable of being any value (0 through 255, inclusive). Implementations MUST NOT limit themselves to using textual keys. It is RECOMMENDED that the administration interface allos for the keys to be entered as hex strings. It is RECOMMENDED that keys be derived from a cryptographically secure pseudo-random number generator (CSPRNG). If managing keys is too complicated, a certificate-based TLS method SHOULD be used instead. ... TLS-PSK methods are susceptible to dictionary attacks. Section X.Y, above, recommends deriving TLS-PSK keys from a CSPRNG, which makes dictionary attacks significantly more difficult. Servers SHOULD track failed client connections by TLS-PSK ID, and block TLS-PSK IDs which seem to be attempting brute-force searchs of the keyspace. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: dtls | Version: 1.0 Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From aland@deployingradius.com Tue Nov 27 05:18:27 2012 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 4F8EE21F84C5 for ; Tue, 27 Nov 2012 05:18: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=[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 WJykpWkcIC+a for ; Tue, 27 Nov 2012 05:18:26 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 417DA21F845B for ; Tue, 27 Nov 2012 05:18:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 57DF522406D4; Tue, 27 Nov 2012 14:17: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 X5rBoLBRPjwB; Tue, 27 Nov 2012 14:17:36 +0100 (CET) Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id B936622404AC; Tue, 27 Nov 2012 14:17:35 +0100 (CET) Message-ID: <50B4BD71.7080803@deployingradius.com> Date: Tue, 27 Nov 2012 08:17:37 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <50B22CCB.1020202@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Comments draft-ietf-radext-dtls-02 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, 27 Nov 2012 13:18:27 -0000 Joseph Salowey (jsalowey) wrote: >>> - Section 3 DIscussion of local proxy >> That for me is more security related > > [Joe] Maybe it would be better in the security considerations. I'll add a section there. > [Joe] The text currently has some normative RFC2119 language that is fairly specific about implementing a table. I think the section can convey the behavior without the implementation specifics. If you want help with text let me know and I'll provide more comprehensive text. For me, "table" is just a word. The important thing is that a key maps to data. How it's done is less relevant. In any case, I've removed the word "table" from the document. It makes the text a bit more awkward, but still readable. > [Joe] OK, but what happens when an EAP method decides to discard a message form the peer/client? Section 2.2 of RFC 3579 is the only situation where that happens. That's the one case where I agree tearing down the DTLS session is the wrong thing to do. I'll update the document. > [Joe] My suggestion would be to tear down the session in the following situations (does the client tear down DTLS as well?) > - failure in message authenticator > - failure in response authenticator > - invalid packet length > - invalid attribute length I agree. > I'm not sure about these, but I think it would be OK to tear down the session > - invalid code > - invalid identifier OK. > for other cases I'd leave it up to the implementation, but I'm not sure what the other cases may be. I've gone over the RFCs. There don't seem to be too many other cases. > [Joe] Currently, the DTLS required flag refers to the server. Maybe there should be an equivalent flag for the client? perhaps DTLS require and DTLS optional? Yes. I'll add text for the client. Alan DeKok.