From hartmans@painless-security.com Mon Apr 1 10:04:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 822D511E80D3 for ; Mon, 1 Apr 2013 10:04:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCy-RSS0mgD5 for ; Mon, 1 Apr 2013 10:04:27 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id EE60C11E80D1 for ; Mon, 1 Apr 2013 10:04:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 485DB2033A; Mon, 1 Apr 2013 13:03:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3841E4497; Mon, 1 Apr 2013 13:04:24 -0400 (EDT) From: Sam Hartman To: Xueli References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> <515596D8.1000209@restena.lu> <01FE63842C181246BBE4CF183BD159B4482A1FAE@NKGEML512-MBS.china.huawei.com> Date: Mon, 01 Apr 2013 13:04:24 -0400 In-Reply-To: <01FE63842C181246BBE4CF183BD159B4482A1FAE@NKGEML512-MBS.china.huawei.com> (xueli@huawei.com's message of "Sat, 30 Mar 2013 06:32:52 +0000") 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: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:04:27 -0000 >>>>> "Xueli" == Xueli writes: Xueli> Actually, the issue is when the authenticator is in access Xueli> router instead of AC, the PMK should be announced to AC. What is the use case for putting the authenticator in the access router rather than an access point controller? From trac+radext@trac.tools.ietf.org Tue Apr 2 07:00:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4718A21F8ADC for ; Tue, 2 Apr 2013 07:00:01 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3-vD735XBTu for ; Tue, 2 Apr 2013 07:00:00 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id B5B8121F8AD8 for ; Tue, 2 Apr 2013 07:00:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:48319 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UN1kj-0007TF-Nl; Tue, 02 Apr 2013 15:59:57 +0200 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, 02 Apr 2013 13:59:57 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/136#comment:2 Message-ID: <074.dfea2851d26bfdc96288acbfcdd93f63@trac.tools.ietf.org> References: <059.d793aee480c4d789a537efce305ec9f7@trac.tools.ietf.org> X-Trac-Ticket-ID: 136 In-Reply-To: <059.d793aee480c4d789a537efce305ec9f7@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: <20130402140000.B5B8121F8AD8@ietfa.amsl.com> Resent-Date: Tue, 2 Apr 2013 07:00:00 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [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: Tue, 02 Apr 2013 14:00:01 -0000 #136: Table state management as security consideration? Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: The draft has been updated to clarify that the session tracking method is suggested, but not required. No other method has been offered, so it's probably best to leave that text where it is. It's also been updated to note that the suggested tracking table is an extension of the cache mandated in RFC 5080 Section 2.2.2. The security considerations has been updated to note that the tracking table changes things, but the earlier text has DoS mitigation strategies. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- ncamwing@cisco.com | dtls@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: dtls | Version: Severity: - | Resolution: fixed Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From internet-drafts@ietf.org Tue Apr 2 07:00:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A734521F8B08; Tue, 2 Apr 2013 07:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fdu1FclKFUiL; Tue, 2 Apr 2013 07:00:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 39EC821F8AE8; Tue, 2 Apr 2013 07:00:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130402140007.15227.501.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 07:00:07 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-04.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 14:00:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : DTLS as a Transport Layer for RADIUS Author(s) : Alan DeKok Filename : draft-ietf-radext-dtls-04.txt Pages : 24 Date : 2013-04-02 Abstract: The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dtls-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dtls-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jouni.nospam@gmail.com Tue Apr 2 13:38:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B51B21F8629 for ; Tue, 2 Apr 2013 13:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0F-fEfAW1LVk for ; Tue, 2 Apr 2013 13:38:17 -0700 (PDT) Received: from mail-ea0-x22c.google.com (mail-ea0-x22c.google.com [IPv6:2a00:1450:4013:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 51DF321F8624 for ; Tue, 2 Apr 2013 13:38:17 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id z7so424088eaf.31 for ; Tue, 02 Apr 2013 13:38:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=oJa2YJjIuQtbbel++11j25uhFm4Vo6pYfK/yDmPW9FU=; b=ALhhqUKumXTp5KUZqfwvXnlZWGePEAKQ3qRJwQiTe7NIzVeLvLTI/7Xv1dFo8WYnZO Cau2OLT5zaj97VLDlRVFIS18Dk3E2aFEebkcwj2WjwyHJeSy+GhmdROIjnAIXBmBOgma iMUFgRykbU1gGAJDEwR6Lax/08Qh1yLZ3dwE0vBDgHiJkjURA9wP/yI1+Re9QkTxWFct YDKULgTkopm6OMsjoFiESaRkWTX+iwdWnGDb8HBUoTRhovk35hAQNe5G+bGQjU7FThqX oh+atLuuXspBJAC/d9W71ErEVDT1bc2YQH4bmnyYQIEUXiJm67MjWuRkthH8JubdsWFo iklg== X-Received: by 10.15.35.193 with SMTP id g41mr52778139eev.45.1364935096402; Tue, 02 Apr 2013 13:38:16 -0700 (PDT) Received: from [188.117.15.110] ([188.117.15.110]) by mx.google.com with ESMTPS id a1sm4913419eep.2.2013.04.02.13.38.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Apr 2013 13:38:15 -0700 (PDT) From: Jouni Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 2 Apr 2013 23:38:12 +0300 Message-Id: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> To: radext@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Cc: radext-chairs@tools.ietf.org Subject: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 02 Apr 2013 20:38:18 -0000 Folks, This email starts a quick one week WGLC #2 for draft-ietf-radext-dtls-04; "DTLS as a Transport Layer for RADIUS". The WGLC ends on Tuesday, 9th April. Post your comments to the list and enter them also into Issue Tracker. - Jouni & Mauricio From peterd@iea-software.com Tue Apr 2 18:14:41 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D16021E803A for ; Tue, 2 Apr 2013 18:14:41 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFukCiMQ5Zg4 for ; Tue, 2 Apr 2013 18:14:40 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF2E1F0D0C for ; Tue, 2 Apr 2013 18:14:40 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 2 Apr 2013 18:14:39 -0700 Date: Tue, 2 Apr 2013 18:14:38 -0700 (Pacific Daylight Time) From: Peter Deacon To: radext@ietf.org In-Reply-To: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 03 Apr 2013 01:14:41 -0000 On Tue, 2 Apr 2013, Jouni wrote: > This email starts a quick one week WGLC #2 for > draft-ietf-radext-dtls-04; "DTLS as a Transport Layer for RADIUS". The > WGLC ends on Tuesday, 9th April. > Post your comments to the list and enter them also into Issue Tracker. 2.1 says min and max packet length MUST be unchanged when using RADIUS/DTLS. Section 2.1 continues: "We note that the DTLS encapsulation of RADIUS means that RADIUS packets have an additional overhead due to DTLS. Implementations MUST support DTLS packets totalling 4096 octets in length, with a corrsponding decrease in the maximum size of the encapsulated packets. Implementations SHOULD support encapsulated RADIUS packets of 4096 in length, with a corresponding increase in the maximum size of the encapsulated DTLS packets." s/corrsponding/corresponding/ s/totalling/totaling/ It is confusing to say decrease is allowed while also previously saying min/max packet lengths MUST be unchanged. Would expect there be no difference in min/max size of RADIUS payload within DTLS period. 2.2.2 "We re-iterate that much of [RFC6614] applies to this document. Specifically, Section 4 and Section 6 of that document are applicable in their entirety to RADIUS/DTLS." RFC 6614 section 6 dedicates a few sentences to TCP specific properties which do not apply to RADIUS/DTLS. 4. "Adding these parameters means that the client MUST start using DTLS to the server for all new requests. The client MUST, however, accept RADIUS/UDP responses to any outstanding requests." MUST does not seem appropriate. We have no business in what client elect to do with outstanding requests after a security configuration change. 5. "We note that [RFC5080] Section 2.2.2 already mandates a duplicate detection cache. The connection tracking described below can be seen as an extension of that cache, where entries contain DTLS sessions instead of RADIUS/UDP packets." I think bringing this up is likely to cause more confusion than necessary. Tuples and authenticator usage are different, session lifecycle is different and state logic is different (You would not ignore anything while a response is pending) I think it might be helpful to note RFC5080 in the context of continuing to support this mechanism and to continue to do it at the RADIUS packet layer rather than DTLS or you're likely to end up on the wrong side of the DTLS sequence window. 5.1 "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." As long as the packet was valid while being silently discarded it should count for the purpose of last packet. 5.1.1 - I still think we can do better on the UDP / DTLS disambiguation using the 4 byte header I described earlier or by explicitly requiring a server knob to declare what protocol would be accepted from a given source address. "Sessions (both key and entry) MUST deleted when a TLS Closure Alert ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section 7.2.2) is received. When a session is deleted due to failed security, the DTLS session MUST be closed, and any TLS session resumption parameters for that session MUST be discarded, and all tracking information MUST be deleted." Not all TLS Error Alerts are fatal. Recommend "or a fatal TLS Error Alert" "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. 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. The above paragraph can be rephrased more generically. A session MUST be deleted when non-RADIUS traffic is received over it. This specification is for RADIUS, and there is no reason to allow non- RADIUS traffic over a RADIUS/DTLS connection. A session MUST be deleted when RADIUS traffic fails to pass security checks. There is no reason to permit insecure networks. A session SHOULD NOT be deleted when a well-formed, but "unexpected" RADIUS packet is received over it. Future specifications may extend RADIUS/DTLS, and we do not want to forbid those specifications." This is redundant. "Once a DTLS session is established, a RADIUS/DTLS server SHOULD use DTLS Heartbeats [RFC6520] to determine connectivity between the two servers." s/server(s)/peer(s)/ ? "A server may also use watchdog packets from the client to determine that the connection is still active." "The timestamp SHOULD be updated on reception of a valid RADIUS/DTLS packet. The timestamp MUST NOT be updated in other situations." The RADIUS packet layer does not see heartbeats. Should this cause a change in Last Packet? Do you intent for sessions to idle out and expire even with active DTLS layer keepalives? "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." The recommended maximum idle timeout is too low in my view. Resetting connections should be as rare as possible as clients now have the added burden of correctly guessing whether packets were dropped on wire or dropped on DTLS stack in addition to possibility server may not be alive. There are no timing guidelines provided for transition to "idle" state. Mismatch of idle expectations between client and server could trigger unnecessary delay which could be mitigated by separating client and server expectations so there is no overlap in the recommended settings. Clients severely outnumber servers. 5.1.3 "For RADIUS/DTLS, any RADIUS packets which are subsequently silently discarded MUST result in the removal of the associated entry and key." 5.1.1 "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." These statements appear to conflict with MUST vs MAY language. regards, Peter From jouni.nospam@gmail.com Wed Apr 3 00:41:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CE621F8617 for ; Wed, 3 Apr 2013 00:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=1.276, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yzekqsx2PZIi for ; Wed, 3 Apr 2013 00:41:54 -0700 (PDT) Received: from mail-lb0-f179.google.com (mail-lb0-f179.google.com [209.85.217.179]) by ietfa.amsl.com (Postfix) with ESMTP id DC6F521F860A for ; Wed, 3 Apr 2013 00:41:53 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id t1so1263183lbd.24 for ; Wed, 03 Apr 2013 00:41:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=N2Mw0/BYCBI6kFozj4BnyE7kMVeeJf8eyBsOIfC4WEg=; b=CP2ce43KLTBF6BzsEO+4wt4/KheHzCy4XxORCtkUC//S2ZJheGS9hHXeitcJRFXOlO IVo9eEJkUBuS/cFju3SxwngjQkX+dovwrTcYz2PvBcHwqcqi+OfMkRFEu8gSV12EP5EO XMthIh24diZeyyyGNQWzUD9TJb11QJD/6l0JM7qydcXFwSRgF71Ye7HY1nYzEauWTztb rWbCz8Ckj2fy9hmWjT7EF9j3cnJb0RMeS3PZKKRdbP8uolww1QVGhZFxidWZsrm2a3Za Um1l2ujQgkxwtt044vBE+jWXTeWoAJIuHtycRH9AlgWT6Sx3jC6yiUfj4BVQwGKlIR1q 7quw== X-Received: by 10.152.87.212 with SMTP id ba20mr360263lab.0.1364974912695; Wed, 03 Apr 2013 00:41:52 -0700 (PDT) Received: from [192.168.250.157] ([194.100.71.98]) by mx.google.com with ESMTPS id fq10sm1900610lbb.14.2013.04.03.00.41.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Apr 2013 00:41:51 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Apr 2013 10:41:50 +0300 Message-Id: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com> To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "radext-chairs@tools.ietf.org" Subject: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 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, 03 Apr 2013 07:41:55 -0000 Folks, This email starts a quick one week WGLC #2 for "RADIUS Attributes for = IEEE 802 Networks" I-D (draft-ietf-radext-ieee802ext-04). The WGLC ends 10-Apr-2013. Send = your comments to the mailer and please also use the IssueTracker. No comments would this = time also imply that everybody agrees with the content. - Jouni & Mauricio= From aland@deployingradius.com Wed Apr 3 07:01:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4596021F8E58 for ; Wed, 3 Apr 2013 07:01:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wBH4270DZTK for ; Wed, 3 Apr 2013 07:01:09 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25BA021F8E4C for ; Wed, 3 Apr 2013 07:01:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D756E2240D8B; Wed, 3 Apr 2013 16:00:39 +0200 (CEST) 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 QPFiV4JxEQYB; Wed, 3 Apr 2013 16:00:38 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id E687D2240939; Wed, 3 Apr 2013 16:00:37 +0200 (CEST) Message-ID: <515C3604.3040406@deployingradius.com> Date: Wed, 03 Apr 2013 10:00:36 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 03 Apr 2013 14:01:10 -0000 Peter Deacon wrote: > 2.1 says min and max packet length MUST be unchanged when using > RADIUS/DTLS. ... > s/corrsponding/corresponding/ > s/totalling/totaling/ Fixed. > It is confusing to say decrease is allowed while also previously saying > min/max packet lengths MUST be unchanged. Would expect there be no > difference in min/max size of RADIUS payload within DTLS period. It's a trade-off with implementations. The specs say max 4K RADIUS packets. However, implementations may interpret this as max 4K buffer for UDP application data. In which case the DTLS overhead requires that the encapsulated RADIUS packet is smaller. Any choice here isn't perfect. Do you have suggestions for better text? > 2.2.2 "We re-iterate that much of [RFC6614] applies to this document. > Specifically, Section 4 and Section 6 of that document are applicable > in their entirety to RADIUS/DTLS." > > RFC 6614 section 6 dedicates a few sentences to TCP specific properties > which do not apply to RADIUS/DTLS. Do you have suggested text for the draft? > 4. "Adding these > parameters means that the client MUST start using DTLS to the server > for all new requests. The client MUST, however, accept RADIUS/UDP > responses to any outstanding requests." > > MUST does not seem appropriate. We have no business in what client > elect to do with outstanding requests after a security configuration > change. Yes, we do. We're writing the standards here, which means we must address security, migration, implementation cost, etc. In this case, there are no known issues with a client accepting responses to packets it previously sent. The goal here is to ensure a safe and productive transition between RADIUS/UDP and RADIUS/DTLS. > 5. "We note that [RFC5080] Section 2.2.2 already mandates a duplicate > detection cache. The connection tracking described below can be seen > as an extension of that cache, where entries contain DTLS sessions > instead of RADIUS/UDP packets." > > I think bringing this up is likely to cause more confusion than > necessary. Tuples and authenticator usage are different, session > lifecycle is different and state logic is different (You would not > ignore anything while a response is pending) Do you have suggested text for the draft? > I think it might be helpful to note RFC5080 in the context of continuing > to support this mechanism and to continue to do it at the RADIUS packet > layer rather than DTLS or you're likely to end up on the wrong side of > the DTLS sequence window. I'm not sure what that means. > 5.1 "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." > > As long as the packet was valid while being silently discarded it should > count for the purpose of last packet. Why? What benefit does that offer? > 5.1.1 - I still think we can do better on the UDP / DTLS disambiguation > using the 4 byte header I described earlier or by explicitly requiring a > server knob to declare what protocol would be accepted from a given > source address. The draft already defines a "DTLS Required" flag. Servers use it to decide which protocol is accepted from a given client. > "Sessions (both key and entry) MUST deleted when a TLS Closure Alert > ([RFC5246] Section 7.2.1) or a TLS Error Alert ([RFC5246] Section > 7.2.2) is received. When a session is deleted due to failed > security, the DTLS session MUST be closed, and any TLS session > resumption parameters for that session MUST be discarded, and all > tracking information MUST be deleted." > > Not all TLS Error Alerts are fatal. Recommend "or a fatal TLS Error Alert" OK. > "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. 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. > > The above paragraph can be rephrased more generically. A session > MUST be deleted when non-RADIUS traffic is received over it. This > specification is for RADIUS, and there is no reason to allow non- > RADIUS traffic over a RADIUS/DTLS connection. A session MUST be > deleted when RADIUS traffic fails to pass security checks. There is > no reason to permit insecure networks. A session SHOULD NOT be > deleted when a well-formed, but "unexpected" RADIUS packet is > received over it. Future specifications may extend RADIUS/DTLS, and > we do not want to forbid those specifications." > > This is redundant. As is noted in the text. > "Once a DTLS session is established, a RADIUS/DTLS server SHOULD use > DTLS Heartbeats [RFC6520] to determine connectivity between the two > servers." > > s/server(s)/peer(s)/ ? Maybe "systems". > "A server may also use watchdog packets from the client to > determine that the connection is still active." > > "The > timestamp SHOULD be updated on reception of a valid RADIUS/DTLS > packet. The timestamp MUST NOT be updated in other situations." > > The RADIUS packet layer does not see heartbeats. Should this cause a > change in Last Packet? No. That is for RADIUS packets, not DTLS heartbeats. > Do you intent for sessions to idle out and > expire even with active DTLS layer keepalives? Yes. If there's no RADIUS traffic for a long time, there are few reasons to keep the session up. > "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." > > The recommended maximum idle timeout is too low in my view. Resetting > connections should be as rare as possible as clients now have the added > burden of correctly guessing whether packets were dropped on wire or > dropped on DTLS stack in addition to possibility server may not be alive. Did you read the text about RADIUS watchdog packets and DTLS heartbeats? No "guessing" is required. > There are no timing guidelines provided for transition to "idle" state. Do you have suggested text for the draft? > Mismatch of idle expectations between client and server could trigger > unnecessary delay which could be mitigated by separating client and > server expectations so there is no overlap in the recommended settings. > Clients severely outnumber servers. Do you have suggested text for the draft? > 5.1.3 > > "For RADIUS/DTLS, any RADIUS packets which are subsequently silently > discarded MUST result in the removal of the associated entry and key." > > 5.1.1 > > "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." > > These statements appear to conflict with MUST vs MAY language. I'll delete the text in 5.1.3. It's redundant. Alan DeKok. From hartmans@painless-security.com Wed Apr 3 07:45:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E91721F8C74 for ; Wed, 3 Apr 2013 07:45:27 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVGb1B+SF7GZ for ; Wed, 3 Apr 2013 07:45:26 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A149621F8C03 for ; Wed, 3 Apr 2013 07:45:26 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id E604E2016B; Wed, 3 Apr 2013 10:44:13 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 401564497; Wed, 3 Apr 2013 10:45:25 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> Date: Wed, 03 Apr 2013 10:45:25 -0400 In-Reply-To: <515C3604.3040406@deployingradius.com> (Alan DeKok's message of "Wed, 03 Apr 2013 10:00:36 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Peter Deacon , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 03 Apr 2013 14:45:27 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> It's a trade-off with implementations. The specs say max 4K Alan> RADIUS packets. However, implementations may interpret this Alan> as max 4K buffer for UDP application data. In which case the Alan> DTLS overhead requires that the encapsulated RADIUS packet is Alan> smaller. My preference is that the spec forbid receivers from making this choice. That is, I'd prefer that receivers MUST support a 4k RADIUS payload and thus MUST support the necessary room for the DTLS overhead. From jouni.nospam@gmail.com Thu Apr 4 05:13:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E8821F845A for ; Thu, 4 Apr 2013 05:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.961 X-Spam-Level: X-Spam-Status: No, score=-2.961 tagged_above=-999 required=5 tests=[AWL=0.638, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpps6GhYE9Zn for ; Thu, 4 Apr 2013 05:13:33 -0700 (PDT) Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) by ietfa.amsl.com (Postfix) with ESMTP id F364A21F844F for ; Thu, 4 Apr 2013 05:13:32 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id v10so2603754lbd.2 for ; Thu, 04 Apr 2013 05:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=ZeH1FUpt6z6ehUry3VAw+WK/89d/rwNVO/Fk469yBOY=; b=lLWXzN9xGOASjju/aHLy4Pw1EJolqKF+SrYeL+syNCNdl5NlyjY4STWlPEWQN4iySB 2BKNa/NKYN6nl+kEhdAl/H0GqcyI2Nb+8wHObKxNth7bUx0XNXWbFSIzw/Q91GF9d21B k7T1ClCCf3jn0o16vkAWKZKzh/4nad1qn5bN3TFihddhbHSL+GVfGg+CMMk46QSR4Vnl a4nzpoCKXm//SvAnreFDieLTmFRHqSXB5miQg3pS7ir+RvFbGGzgMYJWq50pje1fleqk NSf+oSh+lEX5fOvjKMkga9HWHZ0dtA0fzRSwdmKzxc3tIqvAj3WPt7rr5/YZPoZbhNKm whJg== X-Received: by 10.112.74.193 with SMTP id w1mr3249217lbv.125.1365077611934; Thu, 04 Apr 2013 05:13:31 -0700 (PDT) Received: from [192.168.250.45] ([194.100.71.98]) by mx.google.com with ESMTPS id fq10sm3867119lbb.14.2013.04.04.05.13.29 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 04 Apr 2013 05:13:30 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 4 Apr 2013 15:13:29 +0300 Message-Id: To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 12:13:34 -0000 Folks, draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC WG. RADEXT WG is solicited for review. We can provide input as part of the IETF LC once it is started. Remember to CC the RADEXT so we can keep track of the (possible) comments better. - Jouni & Mauricio From aland@deployingradius.com Thu Apr 4 05:59:04 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B998021F8BA1 for ; Thu, 4 Apr 2013 05:59:04 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs6olKDEPmLd for ; Thu, 4 Apr 2013 05:59:03 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1EF21F8B9F for ; Thu, 4 Apr 2013 05:59:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 280A02240F53; Thu, 4 Apr 2013 14:59:03 +0200 (CEST) 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 gTD+U6NtW7GR; Thu, 4 Apr 2013 14:59:03 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 5BBEC2240777; Thu, 4 Apr 2013 14:59:02 +0200 (CEST) Message-ID: <515D7914.4090509@deployingradius.com> Date: Thu, 04 Apr 2013 08:59:00 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Peter Deacon , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 04 Apr 2013 12:59:04 -0000 Sam Hartman wrote: > My preference is that the spec forbid receivers from making this choice. > That is, I'd prefer that receivers MUST support a 4k RADIUS payload and > thus MUST support the necessary room for the DTLS overhead. That's reasonable. Unless there are objections, I'll update the draft accordingly. From aland@deployingradius.com Thu Apr 4 06:08:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD6F21F84E3 for ; Thu, 4 Apr 2013 06:08:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zh3xsxLll67c for ; Thu, 4 Apr 2013 06:08:32 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2F6A21F84E2 for ; Thu, 4 Apr 2013 06:08:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E5AF72240F53; Thu, 4 Apr 2013 15:08:31 +0200 (CEST) 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 jTBO8r0JJEpO; Thu, 4 Apr 2013 15:08:31 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 0D8962240777; Thu, 4 Apr 2013 15:08:30 +0200 (CEST) Message-ID: <515D7B4D.7090201@deployingradius.com> Date: Thu, 04 Apr 2013 09:08:29 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 13:08:32 -0000 Jouni Korhonen wrote: > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC > in DHC WG. RADEXT WG is solicited for review. We can provide > input as part of the IETF LC once it is started. Remember to > CC the RADEXT so we can keep track of the (possible) comments > better. A quick review: 4. DHCPv6 RADIUS option option-len Length of the option-data in octets Q: Can it encode more than 256 octets of RADIUS attributes? If so, what happens then? ... Only the attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option' SHOULD be included in the OPTION_RADIUS. That should be a MUST. There's no sense in permitting non-RADIUS traffic in this option. 8. Security Considerations Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY Using "MAY" here is probably wrong. It should be "may". From leaf.yeh.sdo@gmail.com Thu Apr 4 09:54:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE1921F8BC0; Thu, 4 Apr 2013 09:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.053 X-Spam-Level: X-Spam-Status: No, score=-0.053 tagged_above=-999 required=5 tests=[AWL=2.546, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UwTZTyZzuSg; Thu, 4 Apr 2013 09:54:43 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1D721F8BBC; Thu, 4 Apr 2013 09:54:43 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id v14so1316273pde.4 for ; Thu, 04 Apr 2013 09:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=7jLnhIoskYEOvLFrvPJ5NsMjgeTgVKi3x5UPcppSROM=; b=0/PqdNEfXum7iGlZ/oMjFnfXWRtGCEF/aYOkxyYQnHTEZQWjDZFS29eTWpurpAEg+l wEdN7wBMo+6xFl1QCxPw2BhZUlxB5JVsfQ9wQ5ZkHtL+UC2wJpE/AHGQX0V/KcMcqAPL yJvgfnFH36VjBNxX8mATaxRHQrlwAiWY34tRq/+UBMPakH/GFE7Qs/iky6wi8ZqSYX39 NpQ39TZs+OnFEJEUZsF+Bn44Li2nzxHxLghd7MofcwaiKagtxBjGIV8Wbskd6ozQUZIK Rcr2z9ehtnnE3FgAWyhWcPQFS8eP+bqlQ/o6+4FijFfgPNElHLODGh7GPMnXHkdaxdIf 5Zww== X-Received: by 10.66.8.34 with SMTP id o2mr10246555paa.182.1365094483157; Thu, 04 Apr 2013 09:54:43 -0700 (PDT) Received: from PC ([111.193.205.188]) by mx.google.com with ESMTPS id yz4sm5830974pbc.11.2013.04.04.09.54.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Apr 2013 09:54:42 -0700 (PDT) From: "Leaf Yeh" To: "'Alan DeKok'" , "'Jouni Korhonen'" References: <515D7B4D.7090201@deployingradius.com> In-Reply-To: <515D7B4D.7090201@deployingradius.com> Date: Fri, 5 Apr 2013 00:54:33 +0800 Message-ID: <515db052.24fa440a.4c16.ffff93c2@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4xNYeyVSG79PrhReiNj3Ln9NlMtAAFIhyw Content-Language: zh-cn Cc: radext@ietf.org, 'dhcwg' Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 16:54:44 -0000 Alan - option-len Length of the option-data in octets Q: Can it encode more than 256 octets of RADIUS attributes? If so, what happens then? --- The 'option-len' is 2-octet field. It permit the length of 'option-data' is larger than 256, when the OPTION_RADIUS includes a number of RADIUS attributes. I think the RADIUS attribute here can also be the attribute of Long_Extended_Type newly defined in draft-ietf-radext-radius-extensions-13. Alan - ... Only the attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option' SHOULD be included in the OPTION_RADIUS. That should be a MUST. There's no sense in permitting non-RADIUS traffic in this option. --- Do you want the text to be 'Only the attributes listed in ....MUST be included in ...."? How about turn that 'SHOULD' to be 'should' ? Alan - 8. Security Considerations Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY Using "MAY" here is probably wrong. It should be "may". ---- Accepted. That 'MAY' will update to be 'may'. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Thursday, April 04, 2013 9:08 PM To: Jouni Korhonen Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Jouni Korhonen wrote: > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC > WG. RADEXT WG is solicited for review. We can provide input as part of > the IETF LC once it is started. Remember to CC the RADEXT so we can > keep track of the (possible) comments better. A quick review: 4. DHCPv6 RADIUS option option-len Length of the option-data in octets Q: Can it encode more than 256 octets of RADIUS attributes? If so, what happens then? ... Only the attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option' SHOULD be included in the OPTION_RADIUS. That should be a MUST. There's no sense in permitting non-RADIUS traffic in this option. 8. Security Considerations Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY Using "MAY" here is probably wrong. It should be "may". _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From ietf@augustcellars.com Thu Apr 4 10:09:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D8B21F8C74 for ; Thu, 4 Apr 2013 10:09:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gMeEGKWCzFy for ; Thu, 4 Apr 2013 10:09:21 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id EF0AB21F8C66 for ; Thu, 4 Apr 2013 10:09:20 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 86F0538EF1; Thu, 4 Apr 2013 10:09:20 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Alan DeKok'" References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> In-Reply-To: Date: Thu, 4 Apr 2013 10:08:43 -0700 Message-ID: <011601ce3157$103d4650$30b7d2f0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIaRpfN0dt2jFAPTnJJfl3J6VKbMAHCZSTeAubPd40COmWxapf3At3g Content-Language: en-us Cc: radext@ietf.org, 'Peter Deacon' , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 04 Apr 2013 17:09:22 -0000 Sam, While I understand your preference, it does mean that there cannot be a max 4K buffer in a server that supports both DTLS and non-DTLS clients in the UDP processing code. The UDP processing code does not know if this is a DTLS or a non-DTLS message and thus you can end up in a situation where a >4K buffer is received in the UDP processing code and passed directly to the non-DTLS processing and have a potential buffer overflow. Using a maximum buffer size on the wire does prevent that problem. On the other hand, I think you might be correct that requiring a 4K buffer on the data is correct behavior since if you go from a non-DTLS link to a DTLS link then you go from a 4K data buffer to a less than 4K data buffer size then leading to delivery problems. On the whole I do support this but it could be an implementation issue. Alan do you think this is a major implementation problem? Jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, April 03, 2013 7:45 AM > To: Alan DeKok > Cc: radext@ietf.org; Peter Deacon; radext-chairs@tools.ietf.org > Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 > > >>>>> "Alan" == Alan DeKok writes: > > > Alan> It's a trade-off with implementations. The specs say max 4K > Alan> RADIUS packets. However, implementations may interpret this > Alan> as max 4K buffer for UDP application data. In which case the > Alan> DTLS overhead requires that the encapsulated RADIUS packet is > Alan> smaller. > > My preference is that the spec forbid receivers from making this choice. > That is, I'd prefer that receivers MUST support a 4k RADIUS payload and thus > MUST support the necessary room for the DTLS overhead. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From ietf@augustcellars.com Thu Apr 4 10:12:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA0D21F8EDE for ; Thu, 4 Apr 2013 10:12:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ixmBetLT9wF for ; Thu, 4 Apr 2013 10:12:50 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5658C21F8E2E for ; Thu, 4 Apr 2013 10:12:50 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id EDF272CA2B; Thu, 4 Apr 2013 10:12:49 -0700 (PDT) From: "Jim Schaad" To: "'Alan DeKok'" , "'Jouni Korhonen'" References: <515D7B4D.7090201@deployingradius.com> In-Reply-To: <515D7B4D.7090201@deployingradius.com> Date: Thu, 4 Apr 2013 10:12:13 -0700 Message-ID: <011701ce3157$8d1c4900$a754db00$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHeMUCySghpWabMjAXlQ7CQqOxydwChOzqJmKFCjMA= Content-Language: en-us Cc: radext@ietf.org, draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 17:12:50 -0000 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Alan DeKok > Sent: Thursday, April 04, 2013 6:08 AM > To: Jouni Korhonen > Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org > Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > > Jouni Korhonen wrote: > > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC > > WG. RADEXT WG is solicited for review. We can provide input as part of > > the IETF LC once it is started. Remember to CC the RADEXT so we can > > keep track of the (possible) comments better. > > A quick review: > > 4. DHCPv6 RADIUS option > > option-len Length of the option-data in octets > > Q: Can it encode more than 256 octets of RADIUS attributes? If so, what > happens then? > > > ... Only the attributes listed in the IANA Registry of 'RADIUS > attributes permitted in DHCPv6 RADIUS option' SHOULD be included in > the OPTION_RADIUS. > > That should be a MUST. There's no sense in permitting non-RADIUS traffic in > this option. Alan, I have not looked at the registry in question yet, however should there be the ability to send vender defined traffic? Jim > > > > 8. Security Considerations > > Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY > > > Using "MAY" here is probably wrong. It should be "may". > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Apr 4 10:43:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C13421F8BBB for ; Thu, 4 Apr 2013 10:43:32 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ed9tZF6mIbi2 for ; Thu, 4 Apr 2013 10:43:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71CA921F8BA6 for ; Thu, 4 Apr 2013 10:43:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CEAAD2240F53; Thu, 4 Apr 2013 19:42:42 +0200 (CEST) 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 h2x8gIg27rZ2; Thu, 4 Apr 2013 19:42:40 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 461762240C73; Thu, 4 Apr 2013 19:42:40 +0200 (CEST) Message-ID: <515DBB8E.7000305@deployingradius.com> Date: Thu, 04 Apr 2013 13:42:38 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <515D7B4D.7090201@deployingradius.com> <011701ce3157$8d1c4900$a754db00$@augustcellars.com> In-Reply-To: <011701ce3157$8d1c4900$a754db00$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, 'Jouni Korhonen' , draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 17:43:32 -0000 Jim Schaad wrote: > Alan, I have not looked at the registry in question yet, however should > there be the ability to send vender defined traffic? That's what VSAs are for. If the option is defined as transporting RADIUS, then it (IMHO) transports RADIUS. Anything else is wrong. Alan DeKok. From aland@deployingradius.com Thu Apr 4 10:44:21 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663CF21F8F0E for ; Thu, 4 Apr 2013 10:44:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFuwP+8stGY1 for ; Thu, 4 Apr 2013 10:44:21 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 795E921F8FD3 for ; Thu, 4 Apr 2013 10:44:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 76EAE2240F53; Thu, 4 Apr 2013 19:44:19 +0200 (CEST) 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 YWJCOMMt9jJb; Thu, 4 Apr 2013 19:44:19 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id A199E2240C73; Thu, 4 Apr 2013 19:44:18 +0200 (CEST) Message-ID: <515DBBF1.9090102@deployingradius.com> Date: Thu, 04 Apr 2013 13:44:17 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <011601ce3157$103d4650$30b7d2f0$@augustcellars.com> In-Reply-To: <011601ce3157$103d4650$30b7d2f0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Sam Hartman' , 'Peter Deacon' , radext-chairs@tools.ietf.org, radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 04 Apr 2013 17:44:21 -0000 Jim Schaad wrote: > On the other hand, I think you might be correct that requiring a 4K buffer > on the data is correct behavior since if you go from a non-DTLS link to a > DTLS link then you go from a 4K data buffer to a less than 4K data buffer > size then leading to delivery problems. Yes. Any choice is non-optimal. > On the whole I do support this but it could be an implementation issue. > Alan do you think this is a major implementation problem? It's annoying, but no. It's pretty easy to change buffer sizes. If it's not, you're probably not going to implement any parts of DTLS. Alan DeKok. From leaf.yeh.sdo@gmail.com Thu Apr 4 10:49:12 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1DE21F8FD3; Thu, 4 Apr 2013 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.826 X-Spam-Level: X-Spam-Status: No, score=-1.826 tagged_above=-999 required=5 tests=[AWL=1.773, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oo63mYeqiWy; Thu, 4 Apr 2013 10:49:12 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1ADDF21F8EED; Thu, 4 Apr 2013 10:49:12 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id up7so1553368pbc.29 for ; Thu, 04 Apr 2013 10:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=fnd0HqJLfYaqKrV+2Zsir0EoBZPda+zT6CMKIO/MyJM=; b=MR3et63OkPab9DiMJtOwBZW2kZPqH3Bda0Am/uOLFiCVbtdsLozn3RB/07ZRjbJluQ yAppXD6rly2XfQJg7hM4JCPIQJzjRTm0IKyZ28pozp38vlYBeWunHh6RYA1LLHG7vf8m mqs0+MxSaMOXoVWPpjeBbuDjrDgJa7VMeYRgcifqFyENClUdgQktwDd0lA8YZTmTc7Nu yBzjyNk4Pj86RJmw90hxqdwWjYFemJWXVDxxmCkzDTFKWrk7s1sWV+/f5uKZdzjjZP48 FBUW2YTfDHgQBHSIII0V0A3HSlkVV8/a0dm7U16lQFJKTI21q4jBV75MOwXJXj53TPHz 0jPQ== X-Received: by 10.67.1.39 with SMTP id bd7mr10453929pad.194.1365097751804; Thu, 04 Apr 2013 10:49:11 -0700 (PDT) Received: from PC ([111.193.205.188]) by mx.google.com with ESMTPS id yz4sm5980959pbc.11.2013.04.04.10.49.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Apr 2013 10:49:11 -0700 (PDT) From: "Leaf Yeh" To: "'Jim Schaad'" , "'Alan DeKok'" , "'Jouni Korhonen'" References: <515D7B4D.7090201@deployingradius.com> <011701ce3157$8d1c4900$a754db00$@augustcellars.com> In-Reply-To: <011701ce3157$8d1c4900$a754db00$@augustcellars.com> Date: Fri, 5 Apr 2013 01:49:01 +0800 Message-ID: <515dbd17.24fa440a.4c16.ffff9e13@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHeMUCySghpWabMjAXlQ7CQqOxydwChOzqJmKFCjMCAAAPOQA== Content-Language: zh-cn Cc: radext@ietf.org, 'dhcwg' Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 17:49:12 -0000 Jim - ...however should there be the ability to send vender defined traffic? The VSA (26) has recommended in the proposed IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. (Section 4.1) Do you want more? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Jim Schaad Sent: Friday, April 05, 2013 1:12 AM To: 'Alan DeKok'; 'Jouni Korhonen' Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > Behalf Of Alan DeKok > Sent: Thursday, April 04, 2013 6:08 AM > To: Jouni Korhonen > Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org > Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > > Jouni Korhonen wrote: > > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC > > WG. RADEXT WG is solicited for review. We can provide input as part > > of the IETF LC once it is started. Remember to CC the RADEXT so we > > can keep track of the (possible) comments better. > > A quick review: > > 4. DHCPv6 RADIUS option > > option-len Length of the option-data in octets > > Q: Can it encode more than 256 octets of RADIUS attributes? If so, > what happens then? > > > ... Only the attributes listed in the IANA Registry of 'RADIUS > attributes permitted in DHCPv6 RADIUS option' SHOULD be included in > the OPTION_RADIUS. > > That should be a MUST. There's no sense in permitting non-RADIUS > traffic in > this option. Alan, I have not looked at the registry in question yet, however should there be the ability to send vender defined traffic? Jim > > > > 8. Security Considerations > > Known security vulnerabilities of the DHCPv6 and RADIUS protocol > MAY > > > Using "MAY" here is probably wrong. It should be "may". > _______________________________________________ > 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 Thu Apr 4 10:50:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F61C21F8D1C; Thu, 4 Apr 2013 10:50:32 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBxrmeftqqOb; Thu, 4 Apr 2013 10:50:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7567521F8548; Thu, 4 Apr 2013 10:50:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D07132240F53; Thu, 4 Apr 2013 19:49:46 +0200 (CEST) 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 0rRYt5VSLx1L; Thu, 4 Apr 2013 19:49:46 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 1AB3A224041B; Thu, 4 Apr 2013 19:49:46 +0200 (CEST) Message-ID: <515DBD38.2020607@deployingradius.com> Date: Thu, 04 Apr 2013 13:49:44 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Leaf Yeh References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> In-Reply-To: <515db052.24fa440a.4c16.ffff93c2@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, 'Jouni Korhonen' , 'dhcwg' Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 17:50:32 -0000 Leaf Yeh wrote: > The 'option-len' is 2-octet field. It permit the length of 'option-data' is > larger than 256, when the OPTION_RADIUS includes a number of RADIUS > attributes. Ah, I didn't see that. It's OK, then. > I think the RADIUS attribute here can also be the attribute of > Long_Extended_Type newly defined in draft-ietf-radext-radius-extensions-13. Sure... or you may want to limit the number of allowed attributes. > > Alan - ... Only the attributes listed in the IANA Registry of 'RADIUS > attributes permitted in DHCPv6 RADIUS option' SHOULD be included in > the OPTION_RADIUS. > That should be a MUST. There's no sense in permitting non-RADIUS traffic > in this option. > --- > > Do you want the text to be 'Only the attributes listed in ....MUST be > included in ...."? How about turn that 'SHOULD' to be 'should' ? I'd say: This option MUST carry RADIUS attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. Alan DeKok. From Ted.Lemon@nominum.com Thu Apr 4 10:59:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9686721F95DA; Thu, 4 Apr 2013 10:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKbcqOstuWD9; Thu, 4 Apr 2013 10:59:16 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 240B821F958A; Thu, 4 Apr 2013 10:59:16 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUV2/c5o/Ze+OBtdgOjoU6RDCALstud1t@postini.com; Thu, 04 Apr 2013 10:59:16 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 956F5108080; Thu, 4 Apr 2013 10:59:15 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 892CC19005D; Thu, 4 Apr 2013 10:59:15 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 10:59:15 -0700 From: Ted Lemon To: Alan DeKok Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: Ac4xNYeyVSG79PrhReiNj3Ln9NlMtAAFIhywABNZngAAAFUWgA== Date: Thu, 4 Apr 2013 17:59:15 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> In-Reply-To: <515DBD38.2020607@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Leaf Yeh , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 17:59:16 -0000 On Apr 4, 2013, at 1:49 PM, Alan DeKok wrote: > This option MUST carry RADIUS attributes listed in the IANA Registry > of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. I don't think that sentence means what you think it means. This would req= uire that these options be sent even if no values for them were configured = on the RADIUS server. From peterd@iea-software.com Thu Apr 4 11:20:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12AE821F958A for ; Thu, 4 Apr 2013 11:20:07 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wT9Q3-UBoiC0 for ; Thu, 4 Apr 2013 11:20:06 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFC421F8D1C for ; Thu, 4 Apr 2013 11:20:06 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 4 Apr 2013 11:20:05 -0700 Date: Thu, 4 Apr 2013 11:20:00 -0700 (Pacific Daylight Time) From: Peter Deacon To: Jim Schaad In-Reply-To: <011601ce3157$103d4650$30b7d2f0$@augustcellars.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <011601ce3157$103d4650$30b7d2f0$@augustcellars.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: 'Sam Hartman' , radext@ietf.org, radext-chairs@tools.ietf.org, 'Alan DeKok' Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 04 Apr 2013 18:20:07 -0000 On Thu, 4 Apr 2013, Jim Schaad wrote: > While I understand your preference, it does mean that there cannot be a > max 4K buffer in a server that supports both DTLS and non-DTLS clients > in the UDP processing code. The UDP processing code does not know if > this is a DTLS or a non-DTLS message and thus you can end up in a > situation where a 4K buffer is received in the UDP processing code and > passed directly to the non-DTLS processing and have a potential buffer > overflow. Using a maximum buffer size on the wire does prevent that > problem. Currently you still need to cross check UDP message length with RADIUS packet length fields and apply maximum limits before processing anything. Not sure how this would be a problem unless an implementation was already insecure. Nothing prevents use of compression within DTLS to create an inner RADIUS packet exceeding 4k so these checks are still necessary regardless of where they are handed off. I don't see anything inherently more dangerous in the design of protocol with inner packet limits maintained. I don't see new validation requirements that didn't already exist before. regards, Peter From peterd@iea-software.com Thu Apr 4 11:44:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E9221F8DAC for ; Thu, 4 Apr 2013 11:44:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6sSS4DztQFda for ; Thu, 4 Apr 2013 11:44:06 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6858C21F8D14 for ; Thu, 4 Apr 2013 11:44:06 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 4 Apr 2013 11:44:05 -0700 Date: Thu, 4 Apr 2013 11:44:00 -0700 (Pacific Daylight Time) From: Peter Deacon To: "radext@ietf.org" 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: draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 18:44:07 -0000 On Thu, 4 Apr 2013, Jouni Korhonen wrote: > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC WG. > RADEXT WG is solicited for review. We can provide input as part of the > IETF LC once it is started. Remember to CC the RADEXT so we can keep > track of the (possible) comments better. I like this scheme. Just have two questions. With the DHCPv6 relay forwarding should relays forward attributes it does not know about to server? From my read (section 5) it seems to say attributes are forwarded if the relay validates value which seems to imply it can't forward attributes it does not know about? The DHCP analogue (RFC 4014 sec 4) lists other attributes just wondering what is different here that makes the attribute lists different ...IPv6 specific company excluded of course. regards, Peter From maximilian.riegel@nsn.com Thu Apr 4 12:55:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6484821F9530 for ; Thu, 4 Apr 2013 12:55:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdCA21ViIfwz for ; Thu, 4 Apr 2013 12:55:25 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9228421F8BF8 for ; Thu, 4 Apr 2013 12:55:18 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r34JtEKk026484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 4 Apr 2013 21:55:14 +0200 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r34JtDH6007495 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Apr 2013 21:55:14 +0200 Received: from DEMUHTC010.nsn-intra.net (10.159.42.41) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 4 Apr 2013 21:55:13 +0200 Received: from DEMUMBX008.nsn-intra.net ([169.254.8.58]) by DEMUHTC010.nsn-intra.net ([10.159.42.41]) with mapi id 14.03.0123.003; Thu, 4 Apr 2013 21:55:13 +0200 From: "Riegel, Maximilian (NSN - DE/Munich)" To: ext Jouni Korhonen , "radext@ietf.org" Thread-Topic: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 Thread-Index: AQHOMD67KcBlpXeW0UuH4RxXW+ebSZjGepQg Date: Thu, 4 Apr 2013 19:55:13 +0000 Message-ID: References: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com> In-Reply-To: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.122] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 3971 X-purgate-ID: 151667::1365105314-000077CC-12C43168/0-0/0-0 Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 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, 04 Apr 2013 19:55:26 -0000 There may be a couple of minor, mostly editorial issues in draft-ietf-radex= t-ieee802ext-04: - 2.9. WLAN-SSID The usage statement is missing. >> add 'A single WLAN-SSID Attribute is permitted within an Access-Accept o= r Accounting-Request packet.' - 2.10. WLAN-HESSID The usage statement is missing. >> add 'A single WLAN-HESSID Attribute is permitted within an Access-Accept= or Accounting-Request packet.' In line 763 the term 'subscription service provider network (SSPN)' is used= without any indication, that the term has special meaning in IEEE 802.11 >> adding 'as described in [IEEE-802.11].' may provide more clarity.=20 - 2.11. WLAN-Venue-Info WLAN Venue Group and Venue Type is defined without binding dashes in IEEE 8= 02.11, however shown as Venue-Group and Venue-Type in the radext-ieee802ext= specification. Furthermore the Length of this attribute is 6 bytes instead= of 4 as written. >> correct Length to '6' >> use 'Venue Group' and 'Venue Type' instead of 'Venue-Group' and 'Venue-T= ype', respectively. >> probably it would be better to make direct reference to clause 8.4.1.34 = of [IEEE-802.11] instead of re-specifying the attribute elements in radext-= ieee802ext - 2.12. WLAN-Venue-Language The attribute may appear in Accounting-Request messages as well >>add 'or Accounting-Request' - 2.13. WLAN-Venue-Name The attribute may appear in Accounting-Request messages as well >>add 'or Accounting-Request' - 2.14. WLAN-Reason-Code The length of this attribute is 6 bytes instead of 4 bytes as written The usage statement is missing. >> add 'A single WLAN-Reason-Code Attribute is permitted within a RADIUS Ac= cess-Reject or Accounting-Request packet.' >> correct Length to '6' - 2.15. WLAN-Pairwise-Cipher The length of this attribute is 6 bytes instead of 4 bytes as written >> correct Length to '6' - 2.16. WLAN-Group-Cipher The length of this attribute is 6 bytes instead of 4 bytes as written >> correct Length to '6' - 2.17. WLAN-AKM-Suite The length of this attribute is 6 bytes instead of 4 bytes as written >> correct Length to '6' - 2.18. WLAN-Group-Mgmt-Cipher The length of this attribute is 6 bytes instead of 4 bytes as written >> correct Length to '6' - 2.19. WLAN-RF-Band IEEE 802.11ad-2012 is meanwhile available. Therefore the note in lines 1185= -1191 can be removed with insertion of the proper reference to IEEE 802.11a= d-2012. Furthermore the value field should be directly adopted from Table 8-53a of = IEEE 802.11ad-2012 instead of defining specific values in the radext-ieee80= 2ext specification. Please take into account that the Table 8-53a defines s= ingle octet values, while a 4 octets field is defined for this attribute. How are access points handled supporting multiple bands? Shouldn't the attr= ibute be allowed multiple times within an Access Request message? - 3. Table of attributes The definition of WLAN-Venue-Language and WLAN-Venue-Name allows multiple e= ntries within an Access-Request or Accounting-Request message. The table st= ates that zero or one are present is the Access-Request or Accounting-Reque= st message Bye Max -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of= ext Jouni Korhonen Sent: Wednesday, April 03, 2013 09:42 To: radext@ietf.org Cc: radext-chairs@tools.ietf.org Subject: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 Folks, This email starts a quick one week WGLC #2 for "RADIUS Attributes for IEEE = 802 Networks" I-D (draft-ietf-radext-ieee802ext-04). The WGLC ends 10-Apr-2013. Send your= comments to the mailer and please also use the IssueTracker. No comments would this tim= e also imply that everybody agrees with the content. - Jouni & Mauricio _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Apr 4 13:44:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5997C21F8C14; Thu, 4 Apr 2013 13:44:39 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbXunrrOZ3pT; Thu, 4 Apr 2013 13:44:38 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED60721F8556; Thu, 4 Apr 2013 13:44:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B868A2240F53; Thu, 4 Apr 2013 22:44:34 +0200 (CEST) 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 6fn8FCACWa-V; Thu, 4 Apr 2013 22:44:27 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 46FE12240D8B; Thu, 4 Apr 2013 22:44:27 +0200 (CEST) Message-ID: <515DE629.6070706@deployingradius.com> Date: Thu, 04 Apr 2013 16:44:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ted Lemon References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , Leaf Yeh , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 20:44:39 -0000 Ted Lemon wrote: > On Apr 4, 2013, at 1:49 PM, Alan DeKok wrote: >> This option MUST carry RADIUS attributes listed in the IANA Registry >> of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. > > I don't think that sentence means what you think it means. This would require that these options be sent even if no values for them were configured on the RADIUS server. It doesn't say the option MUST be present. It doesn't say the option MUST carry ALL of the RADIUS attributes. It tries to say if you choose to use the option, its contents MUST be RADIUS attributes, and nothing else. Alan DeKok. From ietf@augustcellars.com Thu Apr 4 13:49:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F06521F85C2 for ; Thu, 4 Apr 2013 13:49:00 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXN7CUld2ybd for ; Thu, 4 Apr 2013 13:48:59 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id DB98721F8910 for ; Thu, 4 Apr 2013 13:48:59 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 248D838F06; Thu, 4 Apr 2013 13:48:59 -0700 (PDT) From: "Jim Schaad" To: "'Alan DeKok'" , "'Jouni Korhonen'" References: <515D7B4D.7090201@deployingradius.com> In-Reply-To: <515D7B4D.7090201@deployingradius.com> Date: Thu, 4 Apr 2013 13:48:23 -0700 Message-ID: <015001ce3175$c00794a0$4016bde0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHeMUCySghpWabMjAXlQ7CQqOxydwChOzqJmKF+sCA= Content-Language: en-us Cc: radext@ietf.org, draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 20:49:00 -0000 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Alan DeKok > Sent: Thursday, April 04, 2013 6:08 AM > To: Jouni Korhonen > Cc: radext@ietf.org; draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org > Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > > Jouni Korhonen wrote: > > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC > > WG. RADEXT WG is solicited for review. We can provide input as part of > > the IETF LC once it is started. Remember to CC the RADEXT so we can > > keep track of the (possible) comments better. > > A quick review: > > 4. DHCPv6 RADIUS option > > option-len Length of the option-data in octets > > Q: Can it encode more than 256 octets of RADIUS attributes? If so, what > happens then? > > > ... Only the attributes listed in the IANA Registry of 'RADIUS > attributes permitted in DHCPv6 RADIUS option' SHOULD be included in > the OPTION_RADIUS. > > That should be a MUST. There's no sense in permitting non-RADIUS traffic in > this option. The SHOULD looks better if you are thinking of the upgrade path. That is what happens to an old implementation if a new item is added to the registry and it starts receiving it. Should it be ignored, passed on or what? I would agree that it makes sense to say that they MUST be only those items in the registry, but text should be included to deal with items which are not in the registry (or are not known to be in the registry). Jim > > > > 8. Security Considerations > > Known security vulnerabilities of the DHCPv6 and RADIUS protocol MAY > > > Using "MAY" here is probably wrong. It should be "may". > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From Ted.Lemon@nominum.com Thu Apr 4 13:49:29 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C363521F85A1; Thu, 4 Apr 2013 13:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YMP3Bu6YGFhx; Thu, 4 Apr 2013 13:49:28 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3464221F85DC; Thu, 4 Apr 2013 13:49:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUV3nVRIBhNUOKZhXdj5jOy9BUf0Ik7x1@postini.com; Thu, 04 Apr 2013 13:49:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 573FA10809F; Thu, 4 Apr 2013 13:49:19 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3E66119005D; Thu, 4 Apr 2013 13:49:19 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 13:49:19 -0700 From: Ted Lemon To: Alan DeKok Thread-Topic: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMXU4e/gVjJrlEkiGtY0x3ZKBYpjG/i2A Date: Thu, 4 Apr 2013 20:49:17 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> In-Reply-To: <515DE629.6070706@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2CB4E1903E51FC499B8E2400F834383B@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Leaf Yeh , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 20:49:29 -0000 On Apr 4, 2013, at 4:44 PM, Alan DeKok wrote: >> On Apr 4, 2013, at 1:49 PM, Alan DeKok wrote= : >>> This option MUST carry RADIUS attributes listed in the IANA Registry >>> of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. >>=20 > It tries to say if you choose to use the option, its contents MUST be > RADIUS attributes, and nothing else. While it can definitely be read that way, it doesn't exclude other readings= . To do that, perhaps: This option MUST NOT carry RADIUS attributes not listed in the IANA Regist= ry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. When we discussed this in the DHC working group, there was some controversy= as to whether we need to even have such a restriction; I take it that you = agree that there should be such a restriction? From aland@deployingradius.com Thu Apr 4 13:58:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FE621F899E; Thu, 4 Apr 2013 13:58:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FqMR10oyTdN6; Thu, 4 Apr 2013 13:58:32 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC2321F8556; Thu, 4 Apr 2013 13:58:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 9747B2240F53; Thu, 4 Apr 2013 22:58:03 +0200 (CEST) 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 xmOMGnBz5-S1; Thu, 4 Apr 2013 22:58:01 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 4B7FD2240C73; Thu, 4 Apr 2013 22:58:01 +0200 (CEST) Message-ID: <515DE957.1060202@deployingradius.com> Date: Thu, 04 Apr 2013 16:57:59 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ted Lemon References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , Leaf Yeh , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 20:58:33 -0000 Ted Lemon wrote: > While it can definitely be read that way, it doesn't exclude other readings. To do that, perhaps: > > This option MUST NOT carry RADIUS attributes not listed in the IANA Registry > of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. Positive statements are usually clearer to understand. > When we discussed this in the DHC working group, there was some controversy as to whether we need to even have such a restriction; I take it that you agree that there should be such a restriction? The intention is for the option to carry RADIUS attributes. Making that a requirement rather than a suggestion is a good idea. Alan DeKok. From Ted.Lemon@nominum.com Thu Apr 4 14:04:03 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6866B21F86FA; Thu, 4 Apr 2013 14:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7B3-zLP8yL+u; Thu, 4 Apr 2013 14:04:03 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id C3F9721F862A; Thu, 4 Apr 2013 14:04:02 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUV3qwu/QmZ2bXFd1qJ+XhiOvId1kssSD@postini.com; Thu, 04 Apr 2013 14:04:02 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 6F2FF1080A0; Thu, 4 Apr 2013 14:04:02 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 6822519005D; Thu, 4 Apr 2013 14:04:02 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 14:04:02 -0700 From: Ted Lemon To: Alan DeKok Thread-Topic: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMXU4e/gVjJrlEkiGtY0x3ZKBYpjG/i2AgAACboCAAAGvgA== Date: Thu, 4 Apr 2013 21:04:01 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> In-Reply-To: <515DE957.1060202@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Leaf Yeh , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 04 Apr 2013 21:04:03 -0000 On Apr 4, 2013, at 4:57 PM, Alan DeKok wrote: > Positive statements are usually clearer to understand. Yes, and when I read your statement, I understood it to mean the exact oppo= site of what you intended. Easier to understand doesn't help if the state= ment is ambiguous. > The intention is for the option to carry RADIUS attributes. Making > that a requirement rather than a suggestion is a good idea. This isn't what the text says. It says that the option must only carry a = subset of RADIUS attributes; those listed in a special registry. If you don't like the double negative, here's a precise way to say it that = doesn't contain a double negative: This option MUST NOT carry any RADIUS attribute unless it is listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. But what the text that means what you said in the second quote above would = read like this: This option MUST NOT carry any RADIUS attribute unless it is listed in the IANA Registry Radius Types registry in the section titled 'Radius Attribut= e Types'. From ietf@augustcellars.com Thu Apr 4 14:28:48 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9DE21F8BBB for ; Thu, 4 Apr 2013 14:28:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7XFBSSvtehR for ; Thu, 4 Apr 2013 14:28:47 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF821F8BA4 for ; Thu, 4 Apr 2013 14:28:47 -0700 (PDT) Received: from Philemon (173-160-230-154-Washington.hfc.comcastbusiness.net [173.160.230.154]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 3F6D52CA3D; Thu, 4 Apr 2013 14:28:47 -0700 (PDT) From: "Jim Schaad" To: "Alan DeKok" References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> In-Reply-To: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> Date: Thu, 4 Apr 2013 14:28:11 -0700 Message-ID: <015401ce317b$4f1ad4e0$ed507ea0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIaRpfN0dt2jFAPTnJJfl3J6VKbMJguaJ9Q Content-Language: en-us Cc: radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 04 Apr 2013 21:28:48 -0000 Alan, I am having a problem with the following new text The client MUST, however, accept RADIUS/UDP responses to any outstanding requests. Under what circumstances do you believe that it would be a good idea to accept a RADIUS/UDP response to a RADIUS/DTLS request? This text appears to imply that there is one but I have a hard time understanding this as anything but a security problem. s/practive/practice/ jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Jouni > Sent: Tuesday, April 02, 2013 1:38 PM > To: radext@ietf.org > Cc: radext-chairs@tools.ietf.org > Subject: [radext] WGLC #2 for draft-ietf-radext-dtls-04 > > Folks, > > This email starts a quick one week WGLC #2 for draft-ietf-radext-dtls-04; > "DTLS as a Transport Layer for RADIUS". The WGLC ends on Tuesday, 9th April. > > Post your comments to the list and enter them also into Issue Tracker. > > > - Jouni & Mauricio > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Apr 4 14:50:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC02E21F901E for ; Thu, 4 Apr 2013 14:50:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9nbIZRXqmeS for ; Thu, 4 Apr 2013 14:50:10 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id F056A21F8D8F for ; Thu, 4 Apr 2013 14:50:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2FD912240F53; Thu, 4 Apr 2013 23:49:30 +0200 (CEST) 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 26Q2y+ibv-2i; Thu, 4 Apr 2013 23:49:29 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 836FE2240D8B; Thu, 4 Apr 2013 23:49:29 +0200 (CEST) Message-ID: <515DF567.3010504@deployingradius.com> Date: Thu, 04 Apr 2013 17:49:27 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad , "radext@ietf.org" References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <015401ce317b$4f1ad4e0$ed507ea0$@augustcellars.com> In-Reply-To: <015401ce317b$4f1ad4e0$ed507ea0$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 04 Apr 2013 21:50:11 -0000 Jim Schaad wrote: > Alan, > > I am having a problem with the following new text > > The client MUST, however, accept RADIUS/UDP > responses to any outstanding requests. > > Under what circumstances do you believe that it would be a good idea to > accept a RADIUS/UDP response to a RADIUS/DTLS request? Never. The idea was to allow transition from UDP to DTLS. There will be outstanding UDP packets, and the client should accept responses to those packets. > s/practive/practice/ Fixed, thanks. Alan DeKok. From ietf@augustcellars.com Thu Apr 4 17:31:29 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0CD21F90F3 for ; Thu, 4 Apr 2013 17:31:29 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmdBljsar8RV for ; Thu, 4 Apr 2013 17:31:29 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0A721F8E49 for ; Thu, 4 Apr 2013 17:31:29 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id DF6962CA28; Thu, 4 Apr 2013 17:31:28 -0700 (PDT) From: "Jim Schaad" To: "'Alan DeKok'" , References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <015401ce317b$4f1ad4e0$ed507ea0$@augustcellars.com> <515DF567.3010504@deployingradius.com> In-Reply-To: <515DF567.3010504@deployingradius.com> Date: Thu, 4 Apr 2013 17:30:52 -0700 Message-ID: <017f01ce3194$d4c25730$7e470590$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIaRpfN0dt2jFAPTnJJfl3J6VKbMAGwh6eoAupRcI6YCcWW0A== Content-Language: en-us Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 00:31:29 -0000 > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Thursday, April 04, 2013 2:49 PM > To: Jim Schaad; radext@ietf.org > Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 > > Jim Schaad wrote: > > Alan, > > > > I am having a problem with the following new text > > > > The client MUST, however, accept RADIUS/UDP > > responses to any outstanding requests. > > > > Under what circumstances do you believe that it would be a good idea > > to accept a RADIUS/UDP response to a RADIUS/DTLS request? > > Never. The idea was to allow transition from UDP to DTLS. There will be > outstanding UDP packets, and the client should accept responses to those > packets. What are you trying to say with this sentence, because I don't understand it. Jim > > > s/practive/practice/ > > Fixed, thanks. > > Alan DeKok. From hartmans@painless-security.com Thu Apr 4 17:35:47 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8642E21F8F08 for ; Thu, 4 Apr 2013 17:35:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u3AbSlpFehg for ; Thu, 4 Apr 2013 17:35:46 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C9E4F21F8E6C for ; Thu, 4 Apr 2013 17:35:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 6052F20144; Thu, 4 Apr 2013 20:34:31 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6E25E4497; Thu, 4 Apr 2013 20:35:45 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <015401ce317b$4f1ad4e0$ed507ea0$@augustcellars.com> <515DF567.3010504@deployingradius.com> <017f01ce3194$d4c25730$7e470590$@augustcellars.com> Date: Thu, 04 Apr 2013 20:35:45 -0400 In-Reply-To: <017f01ce3194$d4c25730$7e470590$@augustcellars.com> (Jim Schaad's message of "Thu, 4 Apr 2013 17:30:52 -0700") 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, 'Alan DeKok' Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 00:35:47 -0000 Consider what happens when you enable support for DTLS between client a and server b while both are running and exchanging packets. Alan wants to permit packets sent with UDP to be answered with UDP. This situation seems to only come up in live upgrades. From aland@deployingradius.com Thu Apr 4 18:51:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2051121F9677 for ; Thu, 4 Apr 2013 18:51:32 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rRE1ruRqeU-Y for ; Thu, 4 Apr 2013 18:51:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF4421F9673 for ; Thu, 4 Apr 2013 18:51:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A7CD92240D25; Fri, 5 Apr 2013 03:51:29 +0200 (CEST) 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 hsGbief8EUYm; Fri, 5 Apr 2013 03:51:26 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id DE7AC2240C73; Fri, 5 Apr 2013 03:51:25 +0200 (CEST) Message-ID: <515E2E1C.30902@deployingradius.com> Date: Thu, 04 Apr 2013 21:51:24 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <015401ce317b$4f1ad4e0$ed507ea0$@augustcellars.com> <515DF567.3010504@deployingradius.com> <017f01ce3194$d4c25730$7e470590$@augustcellars.com> In-Reply-To: <017f01ce3194$d4c25730$7e470590$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 01:51:32 -0000 Jim Schaad wrote: > What are you trying to say with this sentence, because I don't understand > it. What Sam said. Configuring DTLS on a running RADIUS client. a) Send Access-Request 1 b) admin configures DTLS c) Send DTLS encapsulated Access-Request 2 d) Receive Access-Accept 1 ---> do ????? I think it should accept the Access-Request 1 from step (d). After all, it's a signed response to an Access-Request sent by the client. It would be bad to ignore the Access-Request because "DTLS is now configured". i.e. When DTLS is configured, it means that *new* Access-Requests should use DTLS. It doesn't mean that all traffic is required to be DTLS. That will happen over time as RADIUS/UDP traffic gets responses, or is timed out. Suggestions for clear text in the document are welcomed. Alan DeKok. From jsalowey@cisco.com Thu Apr 4 21:39:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D73721F95E6 for ; Thu, 4 Apr 2013 21:39:01 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIGRiY+KyygO for ; Thu, 4 Apr 2013 21:38:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 667AB21F95E1 for ; Thu, 4 Apr 2013 21:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1584; q=dns/txt; s=iport; t=1365136739; x=1366346339; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Of4nq83vypzsOLAlAWY/dspECNqPsnb1a+Qd5z6/Uyw=; b=G2eFXeHSRobBLgBXe1YxZw9IXHVHNObya6opYj3i6wG5KKZ8B1t4OCjn GZCaw04ZKNesQQFmknru1nnaYFPzmkswju73jEty9PubVVZqm3M0Vrs8n HIInhV7/LuyheujLn/ulDhh9/63JoZpQrm3AxBDin4JvBvulcZk3NWdpq Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAJpUXlGtJV2d/2dsb2JhbABDgwY2wQ+BBxZ0gh8BAQEDAQEBATc0CwULAgEIIhQQIQYLJQIEDgUIh3oDCQYMtx8NiVcEjEmBEIEPAjEHgl9hA5UOjVKFG4MLgXM1 X-IronPort-AV: E=Sophos;i="4.87,412,1363132800"; d="scan'208";a="195085369" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 05 Apr 2013 04:38:58 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r354cvRg015438 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Apr 2013 04:38:57 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Thu, 4 Apr 2013 23:38:56 -0500 From: "Joseph Salowey (jsalowey)" To: Jouni Thread-Topic: [radext] WGLC #2 for draft-ietf-radext-dtls-04 Thread-Index: AQHOMbd6Cx0Qf/Ug8E+/+XqhjvqB8w== Date: Fri, 5 Apr 2013 04:38:55 +0000 Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> In-Reply-To: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.151] Content-Type: text/plain; charset="us-ascii" Content-ID: <0E5376CC08510149B03222C309014E25@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 04:39:02 -0000 As I mentioned in the Orlando meeting I am becoming less convinced that mul= tiplexing RADIUS over UDP and RADIUS over DTLS is the appropriate path to t= ake. It would be better to use multiplexing at the UDP level port instead= . Using UDP ports allows existing network devices to differentiate betwee= n encrypted and unencrypted RADIUS and enforce a security policy that allow= s only encrypted traffic. Using the same port also increases the probabil= ity that there will be more implementation errors that impact the system se= curity. The overloading of command code 22 is somewhat of a kludge, it is= possible that TLS could introduce new message codes that could make new en= hancements to TLS incompatible with this specification. The only argumen= t that I have heard for running insecure and secure on the same port is tha= t you will not have to modify firewall rules, however If you are already us= ing a firewall to filter RADIUS traffic you will want to differentiate betw= een insecure and secure RADIUS. =20 Joe On Apr 2, 2013, at 1:38 PM, Jouni wrote: > Folks, >=20 > This email starts a quick one week WGLC #2 for draft-ietf-radext-dtls-04; > "DTLS as a Transport Layer for RADIUS". The WGLC ends on Tuesday, 9th Apr= il. >=20 > Post your comments to the list and enter them also into Issue Tracker. >=20 >=20 > - Jouni & Mauricio >=20 >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From trac+radext@trac.tools.ietf.org Thu Apr 4 21:39:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 975BF21F9681 for ; Thu, 4 Apr 2013 21:39:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdJGYuRNrTrb for ; Thu, 4 Apr 2013 21:39:17 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0821F964C for ; Thu, 4 Apr 2013 21:39:12 -0700 (PDT) Received: from localhost ([127.0.0.1]:43214 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UNyQd-0006yd-3i; Fri, 05 Apr 2013 06:39:07 +0200 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: jsalowey@cisco.com X-Trac-Project: radext Date: Fri, 05 Apr 2013 04:39:05 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/149 Message-ID: <059.ad1c3a15fdae56f93fecef9b0fcb1ac6@trac.tools.ietf.org> X-Trac-Ticket-ID: 149 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: 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 Cc: radext@ietf.org Subject: [radext] #149: Multiplexing secure and insecure on the same port 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, 05 Apr 2013 04:39:19 -0000 #149: Multiplexing secure and insecure on the same port As I mentioned in the Orlando meeting I am becoming less convinced that multiplexing RADIUS over UDP and RADIUS over DTLS is the appropriate path to take. It would be better to use multiplexing at the UDP level port instead. Using UDP ports allows existing network devices to differentiate between encrypted and unencrypted RADIUS and enforce a security policy that allows only encrypted traffic. Using the same port also increases the probability that there will be more implementation errors that impact the system security. The overloading of command code 22 is somewhat of a kludge, it is possible that TLS could introduce new message codes that could make new enhancements to TLS incompatible with this specification. The only argument that I have heard for running insecure and secure on the same port is that you will not have to modify firewall rules, however If you are already using a firewall to filter RADIUS traffic you will want to differentiate between insecure and secure RADIUS. -- --------------------------------+----------------- Reporter: jsalowey@cisco.com | Owner: Type: defect | Status: new Priority: major | Milestone: Component: RDTLS | Version: Severity: In WG Last Call | Keywords: --------------------------------+----------------- Ticket URL: radext From jouni.nospam@gmail.com Fri Apr 5 00:19:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03F4421F86CE; Fri, 5 Apr 2013 00:19:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paZ2iAZWenF7; Fri, 5 Apr 2013 00:19:42 -0700 (PDT) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id AA15821F8510; Fri, 5 Apr 2013 00:19:41 -0700 (PDT) Received: by mail-la0-f49.google.com with SMTP id fs13so3153084lab.22 for ; Fri, 05 Apr 2013 00:19:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=k+VnuTUbAHx3dsSO+rz8qiJC7SmLitAElkO5AnAH0fs=; b=kn/6UkaruogVzdnJcyZaGR2VMk2T7uTpD5ieT52MqRxcID0vjfJFme+lvXJ7nQL3Il UX5g9f4jxC1WaueNCjT67Dw919oUtOSobVokfz+9KKahwSho/DwJMsI1OwdbMEBM55/v ilPo0LRTDwH8hlFKDqDV1J4cMm6Pu15RNlMeL4grn3fFnXHQPEo0WY7j0mIL0SY7wTQn 0Ds4D9zAqgWYJ+/CTSbheeeZf6itK9QvlcAfrObHzalilPcY4tMXGJKbGPfRxFvW8f8x h0qvH8pLPbyqKyx6PorYtb16kE3NzJRRMAkfX1omcWYnRQvQiJbnQKqJOQEzUiVBtaGi PO7Q== X-Received: by 10.152.87.243 with SMTP id bb19mr5260590lab.12.1365146380379; Fri, 05 Apr 2013 00:19:40 -0700 (PDT) Received: from [192.168.250.119] ([194.100.71.98]) by mx.google.com with ESMTPS id w6sm2322943lad.5.2013.04.05.00.19.37 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 00:19:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> Date: Fri, 5 Apr 2013 10:19:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "" , dhcwg , Alan DeKok Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 07:19:43 -0000 On Apr 5, 2013, at 12:04 AM, Ted Lemon wrote: > On Apr 4, 2013, at 4:57 PM, Alan DeKok = wrote: >> Positive statements are usually clearer to understand. >=20 > Yes, and when I read your statement, I understood it to mean the exact = opposite of what you intended. Easier to understand doesn't help if = the statement is ambiguous. >=20 >> The intention is for the option to carry RADIUS attributes. Making >> that a requirement rather than a suggestion is a good idea. >=20 > This isn't what the text says. It says that the option must only = carry a subset of RADIUS attributes; those listed in a special registry. >=20 > If you don't like the double negative, here's a precise way to say it = that doesn't contain a double negative: >=20 > This option MUST NOT carry any RADIUS attribute unless it is = listed in the > IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS = option'. I don't think this is any improvement over the text Alan provided = originally. My suggestion would be: The option-data of OPTION_RADIUS is a list of one or more RADIUS attributes received in the Access-Accept message from the RADIUS server. The OPTION_RADIUS can only contain RADIUS attributes listed in the IANA Registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. The next question I have is what happens when a relay includes an = attribute that the server does not understand or is not listed in the registry? = There is no versioning thus it is possible that relay and server have a = different understanding what the IANA registry is. Now the text in Section 6 only addresses the case where the server does not understand the DHCP option. - Jouni >=20 > But what the text that means what you said in the second quote above = would read like this: >=20 > This option MUST NOT carry any RADIUS attribute unless it is = listed in the > IANA Registry Radius Types registry in the section titled = 'Radius Attribute Types'. >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From peterd@iea-software.com Fri Apr 5 00:24:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F065621F96E8 for ; Fri, 5 Apr 2013 00:24:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVPpCpxy0bEi for ; Fri, 5 Apr 2013 00:24:32 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id D96FC21F96E6 for ; Fri, 5 Apr 2013 00:24:31 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 5 Apr 2013 00:24:31 -0700 Date: Fri, 5 Apr 2013 00:24:28 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <515C3604.3040406@deployingradius.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@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, radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 07:24:33 -0000 On Wed, 3 Apr 2013, Alan DeKok wrote: >> 2.2.2 "We re-iterate that much of [RFC6614] applies to this document. >> Specifically, Section 4 and Section 6 of that document are applicable >> in their entirety to RADIUS/DTLS." >> RFC 6614 section 6 dedicates a few sentences to TCP specific properties >> which do not apply to RADIUS/DTLS. > Do you have suggested text for the draft? Recommend removing "in their entirety" >> 4. "Adding these >> parameters means that the client MUST start using DTLS to the server >> for all new requests. The client MUST, however, accept RADIUS/UDP >> responses to any outstanding requests." >> MUST does not seem appropriate. We have no business in what client >> elect to do with outstanding requests after a security configuration >> change. > Yes, we do. We're writing the standards here, which means we must > address security, migration, implementation cost, etc. What security, migration or implementation concern does this "MUST" address? I can think of a couple drawbacks.. If an operator is deciding they want to improve the security of their system they would be *required* to accept responses with lower security after they have declared otherwise. Increased client implementation complexity as a short term security exception has to be made for receiving non DTLS packets including protocol disambiguation procedure for clients not specified in draft. > In this case, there are no known issues with a client accepting > responses to packets it previously sent. The goal here is to ensure a > safe and productive transition between RADIUS/UDP and RADIUS/DTLS. I am looking for specific technical justifications. What safety or productivity implications does the MUST requirement provide? If it did not exist how would safety or productivity be negatively impacted? >> 5. "We note that [RFC5080] Section 2.2.2 already mandates a duplicate >> detection cache. The connection tracking described below can be seen >> as an extension of that cache, where entries contain DTLS sessions >> instead of RADIUS/UDP packets." >> I think bringing this up is likely to cause more confusion than >> necessary. Tuples and authenticator usage are different, session >> lifecycle is different and state logic is different (You would not >> ignore anything while a response is pending) > Do you have suggested text for the draft? I would suggest as properties of the state tracking are discussed in detail in section 5 removing RFC 5080 paragraph. >> I think it might be helpful to note RFC5080 in the context of continuing >> to support this mechanism and to continue to do it at the RADIUS packet >> layer rather than DTLS or you're likely to end up on the wrong side of >> the DTLS sequence window. > I'm not sure what that means. Normally with RFC 5080 replay system an implementation will store a response for a given request and simply resend a stored response (UDP message) on wire. With DTLS implementations RADIUS packets must be resent thru new DTLS messages rather than storing a previous DTLS response and resending. The reason for this is DTLS replay protection uses a sequence window where only a fixed number of previously unaccepted packets are accepted. Retry timers on orders of seconds on a busy client are likely lead to retransmitted messages being too stale to be accepted on DTLS stack unless retransmissions are performed by retransmitting stored RADIUS response thru DTLS. Suggest a short text: Any duplicate detection strategy such as [RFC5080] section 2.2.2 where previously transmitted RADIUS packets are replayed MUST be replayed thru DTLS creating a new DTLS packet before transmission. Previously transmitted DTLS packets MUST NOT be retransmitted. >> 5.1 "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." >> As long as the packet was valid while being silently discarded it should >> count for the purpose of last packet. > Why? What benefit does that offer? My concern is in minimizing situations where client accounting of idle timeout becomes unsynchronized with server view of same. >> 5.1.1 - I still think we can do better on the UDP / DTLS disambiguation >> using the 4 byte header I described earlier or by explicitly requiring a >> server knob to declare what protocol would be accepted from a given >> source address. > The draft already defines a "DTLS Required" flag. Servers use it to > decide which protocol is accepted from a given client. My suggestion the mechanism to automatically migrate clients to DTLS after successful DTLS handshake is not necessary. We already need manual knobs to make this work. Perhaps simply requiring a knob in client and server is the best approach. This would remove RADIUS/UDP to RADIUS/DTLS migration and RADIUS/DTLS disambiguation. Explicit configuration in client AND server would be necessary to successfully speak RADIUS/DTLS. >> "A server may also use watchdog packets from the client to >> determine that the connection is still active." >> >> "The >> timestamp SHOULD be updated on reception of a valid RADIUS/DTLS >> packet. The timestamp MUST NOT be updated in other situations." >> >> The RADIUS packet layer does not see heartbeats. Should this cause a >> change in Last Packet? > No. That is for RADIUS packets, not DTLS heartbeats. >> Do you intent for sessions to idle out and >> expire even with active DTLS layer keepalives? > Yes. If there's no RADIUS traffic for a long time, there are few > reasons to keep the session up. We see lots of NASes with only a few if any concurrent users. It is not uncommon for new RADIUS traffic to be seen on orders of tens of minutes to hours. Having a connection open hurts nobody and prevents delay including possibly additional delay to failover for users coming online. It also prevents state sync problems..(see my comments below) >> "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." >> The recommended maximum idle timeout is too low in my view. Resetting >> connections should be as rare as possible as clients now have the added >> burden of correctly guessing whether packets were dropped on wire or >> dropped on DTLS stack in addition to possibility server may not be alive. > Did you read the text about RADIUS watchdog packets and DTLS > heartbeats? No "guessing" is required. Heartbeats do not effect last packet and watchdog is for detection of server failure rather than communication of compatible session timeout parameters. The following example explains my concern: RADIUS/DTLS server - 60 second idle timeout. RADIUS/DTLS client - 90 second idle timeout. (5.2 "RADIUS/DTLS clients SHOULD pro-actively close sessions when they have been idle for a period of time") For the sake of this example RADIUS client is connected to a NAS that sees only a few concurrent sessions and only sparse activity every few minutes...From our experience typical AP in a low traffic environment. At 75 seconds the client sends a RADIUS request to RADIUS/DTLS server. Server promptly ignores this request because the session was torn down due to exceeding idle timeout. The client runs thru all of its retries and timeouts IGNORED by the server before it either picks a different RADIUS server or tries to open a new RADIUS/DTLS session to the same server. None of the active probing mechanisms work at these timescales and they should not be necessary to prevent this sort of problem from occurring. TCP TLS provides reliable notification of shutdown DTLS does not. I recommend that recommended client idle parameters be specified and not overlap with recommended server idle parameters. For example something like clients may close the connection at 60-600 seconds. Servers may close the connection after >600 seconds. Other thoughts to minimize this problem have client enforce an idle timeout algorithm based on usage but allow server idle timer to be refreshed by DTLS heartbeats. The server can take other actions if there is pressure on resources to manage DTLS sessions but normally it is important to do EVERYTHING possible to make sure RADIUS/DTLS is as reliable as RADIUS/UDP with no delays for clients to figure out and react to rug being pulled out from under them. >> There are no timing guidelines provided for transition to "idle" state. > Do you have suggested text for the draft? What does the idle state actually do? What is the difference vs using "idle timeout" since last packet without an "idle" transition? >> Mismatch of idle expectations between client and server could trigger >> unnecessary delay which could be mitigated by separating client and >> server expectations so there is no overlap in the recommended settings. >> Clients severely outnumber servers. > Do you have suggested text for the draft? 5.2... RADIUS/DTLS clients MAY proactively close sessions when they have been idle for 60-86400 seconds if DTLS heartbeats or active watchdog probes are used. When unused RADIUS/DTLS client SHOULD close sessions idle for 60 to no longer than 600 seconds. 5.1.1... This session "idle timeout" SHOULD be exposed to the administrator as a configurable setting. RADIUS servers SHOULD timeout after at least 600 seconds. As UDP does not guarantee delivery of messages, RADIUS/DTLS servers MUST also maintain a "Last Packet" timestamp per DTLS session. The timestamp MUST be updated on reception of a valid RADIUS/DTLS packet or DTLS heartbeat. The timestamp MUST NOT be updated in other situations. The server SHOULD delete idle DTLS sessions after an "idle timeout". 10.2 While total number of sessions tracked exceeds the configured limit servers SHOULD close idle sessions starting with highest idle time until a sufficient number of sessions have been closed or lower idle timeout threshold of 60 seconds or more has been reached. regards, Peter From leaf.yeh.sdo@gmail.com Fri Apr 5 03:15:13 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A15221F9743; Fri, 5 Apr 2013 03:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=1.182, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwGrDbWNGf7H; Fri, 5 Apr 2013 03:15:12 -0700 (PDT) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id B3A9721F9740; Fri, 5 Apr 2013 03:15:12 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id xa7so1933210pbc.27 for ; Fri, 05 Apr 2013 03:15:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=Pstwb3DvG18PePUpsyez9O8sipEbFaehH9gq4MRI9lI=; b=w0Pv930FSaN9gABwsTraCURnyPdhcEOJ4PuOdD595a2R2HvrDamtfYgRBdANqaQ+1y CMgo736Dy2KoLhYBnmbdOqfsuQ3I+Nd9dRAn6iazzjGiVjdJsBJcgkId2+pvXHAOK2M9 hJnIl/9cxKz8toKW1YjBkQuLH+2btOHDgGR5qr0FDg1raIHy1TNkawzZJS+unhJKeWqs jtlSrPkFjM2eyS0AwnzNSiaizF9h5p6oVUMwsvvIkza60eOGVoPWs5CN/XVr7+Yg7XwI lK0d9ZGWWZkfNf2M1Q6mWZTD9157p6jdb4SyZbzq6iZ+ZFiqy79Sqj0wcfjkHcKtGKx9 NPRw== X-Received: by 10.66.122.97 with SMTP id lr1mr14237249pab.147.1365156912382; Fri, 05 Apr 2013 03:15:12 -0700 (PDT) Received: from PC ([111.193.205.188]) by mx.google.com with ESMTPS id t5sm13914550pbi.10.2013.04.05.03.15.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Apr 2013 03:15:11 -0700 (PDT) From: "Leaf Yeh" To: "'Peter Deacon'" , References: In-Reply-To: Date: Fri, 5 Apr 2013 18:15:01 +0800 Message-ID: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4xZGO6qHzaALX1QfiJLr6UMIrzDwAApjaQ Content-Language: zh-cn Cc: 'dhcwg' Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 10:15:13 -0000 Peter - With the DHCPv6 relay forwarding should relays forward attributes it does not know about to server? From my read (section 5) it seems to say attributes are forwarded if the relay validates value which seems to imply it can't forward attributes it does not know about? Good question. I think the point here is the DHCPv6 relay only forward those valid attribute in the registry of 'RADIUS attributes permitted in DHCPv6 RADIUS option'. If the DHCPv6 server supports OPTION_RADIUS defined here, it should know all the attributes received from the relay. If the DHCPv6 server still does not know the attributes in OPTION_RADIUS, the server just ignore those attributes per the Postel's Law. Peter - The DHCP analogue (RFC 4014 sec 4) lists other attributes just wondering what is different here that makes the attribute lists different ...IPv6 specific company excluded of course. I guess you are talking about the following attributes (in the table of the section 4 in RFC 4014): 1 User-Name (RFC 2865 [3]) 6 Service-Type (RFC 2865) 27 Session-Timeout (RFC 2865) I still have not got the points (or understood the use case) for: a. User-Name : why the User-Name of AAA (or RADIUS) will be necessary to forward the DHCPv6 server; the standard DHCPv6 server sounds never use it before; b. Service-Type : what kind of service-type of AAA (or RADIUS, http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-4 ) will be necessary to forward the DHCPv6 server; c. Session-Timeout : I think the NAS (DHCPv6 relay + RADIUS client) can be the 1st control point of trusted network , it can decide whether to forward the DHCPv6 messages from the client to the server. After the session is timeout, it just stop forward the DHCPv6 messages from the client to the server. This RADIUS attribute also sounds not necessary to forward to the DHCPv6 server. Right? Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Peter Deacon Sent: Friday, April 05, 2013 2:44 AM To: radext@ietf.org Cc: draft-ietf-dhc-dhcpv6-radius-opt@tools.ietf.org Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 On Thu, 4 Apr 2013, Jouni Korhonen wrote: > draft-ietf-dhc-dhcpv6-radius-opt-10 has recently passed WGLC in DHC WG. > RADEXT WG is solicited for review. We can provide input as part of the > IETF LC once it is started. Remember to CC the RADEXT so we can keep > track of the (possible) comments better. I like this scheme. Just have two questions. With the DHCPv6 relay forwarding should relays forward attributes it does not know about to server? From my read (section 5) it seems to say attributes are forwarded if the relay validates value which seems to imply it can't forward attributes it does not know about? The DHCP analogue (RFC 4014 sec 4) lists other attributes just wondering what is different here that makes the attribute lists different ...IPv6 specific company excluded of course. regards, Peter _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From Ted.Lemon@nominum.com Fri Apr 5 04:43:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1420A21F9767; Fri, 5 Apr 2013 04:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbuGBSXBxtIS; Fri, 5 Apr 2013 04:43:00 -0700 (PDT) Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 74A9521F9765; Fri, 5 Apr 2013 04:43:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKUV64w9Gzo03tjCPak2KTXLV5be3qJsLf@postini.com; Fri, 05 Apr 2013 04:43:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id B8D4A108177; Fri, 5 Apr 2013 04:42:59 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id AC87919005D; Fri, 5 Apr 2013 04:42:59 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 04:42:59 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMc3xheg1Y2HRokOypXMokVkn6ZjH9y6A Date: Fri, 5 Apr 2013 11:42:58 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> In-Reply-To: <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <505BF77EABF0DA4E91BAFC9B71A9B946@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg , Alan DeKok Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 11:43:01 -0000 On Apr 5, 2013, at 3:19 AM, Jouni Korhonen wrote: > The option-data of OPTION_RADIUS is a list of one or more RADIUS > attributes received in the Access-Accept message from the RADIUS > server. The OPTION_RADIUS can only contain RADIUS attributes > listed in the IANA Registry of 'RADIUS attributes permitted in > DHCPv6 RADIUS option'. So you took out the normative language, right? Was that intentional? > The next question I have is what happens when a relay includes an attribu= te > that the server does not understand or is not listed in the registry? The= re > is no versioning thus it is possible that relay and server have a differe= nt > understanding what the IANA registry is. Now the text in Section 6 only > addresses the case where the server does not understand the DHCP option. Good question. I think the right answer is that that RADIUS attribute is = silently ignored, because, as you say, the server might not be up to date. From hartmans@painless-security.com Fri Apr 5 05:33:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D34221F85DA for ; Fri, 5 Apr 2013 05:33:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npURIAtXijgd for ; Fri, 5 Apr 2013 05:33:17 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9201721F843E for ; Fri, 5 Apr 2013 05:33:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id EF10020219; Fri, 5 Apr 2013 08:32:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 17DE94497; Fri, 5 Apr 2013 08:33:15 -0400 (EDT) From: Sam Hartman To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> Date: Fri, 05 Apr 2013 08:33:15 -0400 In-Reply-To: (Peter Deacon's message of "Fri, 5 Apr 2013 00:24:28 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, radext-chairs@tools.ietf.org, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 12:33:18 -0000 I'm confused about the transition issue. It seems like the draft is spending a lot of complexity on what's a very corner case. As I understand it, the only case where you have to accept both normal UDP and DTLS responses is the case where you transition with outstanding requests. We're talking about a period of less than a few seconds, right, while requests are in flight? So, this issue only comes up in operational environments where a single NAS or proxy cannot afford an outage of the maximum lifetime of a RADIUS request. Am I missing something? From jouni.nospam@gmail.com Fri Apr 5 05:50:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 909E521F9777; Fri, 5 Apr 2013 05:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.052 X-Spam-Level: X-Spam-Status: No, score=-3.052 tagged_above=-999 required=5 tests=[AWL=0.547, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sz00tMGHvqY6; Fri, 5 Apr 2013 05:50:44 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2F21F9763; Fri, 5 Apr 2013 05:50:43 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id x11so3730915lbi.29 for ; Fri, 05 Apr 2013 05:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=qKWcUOYooKMuEDY63xPIjXLHD8cr7iEOSENLBMOxOPw=; b=ABfBm5lZhFyr6sjdqMzEC159qDUAns0iJx31uIn7kPyI+S2TBWXEBy5nSda74sV9+b JJm0pXNshrs/1KsalwsOkxos5+5/k3o/boOcZ8brDmWNI1E7kOlEd+tZjo9s7rJ3qrhk /Ik9o9geOQEsLGUv8cjUuhv+QJ6jN5VDf5ktZBByBbc5+c9OqDkmFi9lE3s9bvFxJZ37 e0sNBPyHrQbBm/xzijuXpDpOZ+IzPasFao1vdP8+fbN9eo0CYlBj2I0ukSTa+NAFnQhX ovI9kBSaaKxlLFZvzaTLD4PK1vLi5JNtZpEZfBF1v6/MlL0EhEYX7tyaY69wQBQ6eDNM a8Ww== X-Received: by 10.112.7.10 with SMTP id f10mr5957683lba.126.1365166242551; Fri, 05 Apr 2013 05:50:42 -0700 (PDT) Received: from [192.168.250.119] ([194.100.71.98]) by mx.google.com with ESMTPS id ng6sm5633000lab.2.2013.04.05.05.50.40 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 05:50:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> Date: Fri, 5 Apr 2013 15:50:36 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> To: Ted Lemon X-Mailer: Apple Mail (2.1503) Cc: "" , Jouni Korhonen , dhcwg , Alan DeKok Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 12:50:44 -0000 On Apr 5, 2013, at 2:42 PM, Ted Lemon wrote: > On Apr 5, 2013, at 3:19 AM, Jouni Korhonen = wrote: >> The option-data of OPTION_RADIUS is a list of one or more RADIUS >> attributes received in the Access-Accept message from the RADIUS >> server. The OPTION_RADIUS can only contain RADIUS attributes >> listed in the IANA Registry of 'RADIUS attributes permitted in >> DHCPv6 RADIUS option'. >=20 > So you took out the normative language, right? Was that intentional? That was intentional. If that is a concern one can always change the "can only" to "MUST". That works too, since the previous sentence already points out that the option contains one or more attributes, not all. >> The next question I have is what happens when a relay includes an = attribute >> that the server does not understand or is not listed in the registry? = There >> is no versioning thus it is possible that relay and server have a = different >> understanding what the IANA registry is. Now the text in Section 6 = only >> addresses the case where the server does not understand the DHCP = option. >=20 > Good question. I think the right answer is that that RADIUS = attribute is silently ignored, because, as you say, the server might not = be up to date. Blindly dropping an attribute might not work in all cases. For example, = in some cases the server might not then be able to provide all information the relay needs.. That is more of a DHCP specification issue but what I would like to see in this I-D is some text pointing out that the server and the relay may have a different idea of the registry and the protocol design need to take that into account. - Jouni >=20 From aland@deployingradius.com Fri Apr 5 05:57:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9755721F977F for ; Fri, 5 Apr 2013 05:57:45 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGebg0xIB3XR for ; Fri, 5 Apr 2013 05:57:44 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id AD99E21F977E for ; Fri, 5 Apr 2013 05:57:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 983EB22410F7; Fri, 5 Apr 2013 14:57:44 +0200 (CEST) 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 22QFE+kzknWb; Fri, 5 Apr 2013 14:57:44 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id A1E052240C73; Fri, 5 Apr 2013 14:57:43 +0200 (CEST) Message-ID: <515ECA45.8040209@deployingradius.com> Date: Fri, 05 Apr 2013 08:57:41 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Peter Deacon , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 12:57:45 -0000 Sam Hartman wrote: > As I understand it, the only case where you have to accept both normal > UDP and DTLS responses is the case where you transition with > outstanding requests. Yes. When a server has a client marked as "DTLS required", it only accepts DTLS. > Am I missing something? No. I'll see if I can come up with some clarifying language. Alan DeKok. From Ted.Lemon@nominum.com Fri Apr 5 06:12:28 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 994B121F9781; Fri, 5 Apr 2013 06:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBvtthUxhxTU; Fri, 5 Apr 2013 06:12:28 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0823521F9780; Fri, 5 Apr 2013 06:12:28 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKUV7Nuz/NQsNMTLeEBg1BCHTX7tVbJivZ@postini.com; Fri, 05 Apr 2013 06:12:28 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id BCEB4108195; Fri, 5 Apr 2013 06:12:27 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id B19F319005D; Fri, 5 Apr 2013 06:12:27 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 06:12:27 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMc3xheg1Y2HRokOypXMokVkn6ZjH9y6AgAAS5ACAAAYcAA== Date: Fri, 5 Apr 2013 13:12:27 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <1ADC18F33AA52545BAADE6583215783D@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , dhcwg , Alan DeKok Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 13:12:28 -0000 On Apr 5, 2013, at 8:50 AM, Jouni Korhonen wrote: > Blindly dropping an attribute might not work in all cases. For example, i= n > some cases the server might not then be able to provide all information > the relay needs.. Well, I did say "silently ignored," not "dropped," but yeah. If the serve= r doesn't support that attribute, it's not going to have any effect anyway.= It seems like silently ignoring it is better than dropping the whole mes= sage, although I suppose you could argue the opposite, since a misconfigura= tion of this sort is probably something the administrator wants to fix imme= diately, not discover by accident years later. From aland@deployingradius.com Fri Apr 5 06:23:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A391321F88BF for ; Fri, 5 Apr 2013 06:23:57 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqBzyMSNWZao for ; Fri, 5 Apr 2013 06:23:57 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 64BFF21F87E4 for ; Fri, 5 Apr 2013 06:23:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B0F4022410F7; Fri, 5 Apr 2013 15:23:21 +0200 (CEST) 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 Ff5TqMzyuaO9; Fri, 5 Apr 2013 15:23:21 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id A969D2240C73; Fri, 5 Apr 2013 15:23:20 +0200 (CEST) Message-ID: <515ED047.3040200@deployingradius.com> Date: Fri, 05 Apr 2013 09:23:19 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Peter Deacon , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 13:23:57 -0000 Sam Hartman wrote: > We're talking about a period of less than a few seconds, right, while > requests are in flight? > So, this issue only comes up in operational environments where a single > NAS or proxy cannot afford an outage of the maximum lifetime of a > RADIUS request. How about this text below. It clarifies that the transition path is meant to be temporary. The text around transition is there only to ensure we get it right. 3. Transition Path Transitioning to DTLS is a process which needs to be done carefully. A poorly handled transition is complex for administrators, and potentially subject to security downgrade attacks. It is not sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That approach would result in timeouts, lost traffic, and network instabilities. The end result of this specification is that nearly all RADIUS/UDP implementations should transition to using RADIUS/DTLS. In some cases, RADIUS/UDP may remain where IPSec is used as a transport, or where implementation and/or business reasons preclude a change. However, long-term use of RADIUS/UDP is NOT RECOMMENDED. This section describes how clients and servers should transition to DTLS. There is a fair amount of discussion around this transition, as it is critical to get it correct. We expect that once implementations have transitioned to RADIUS/DTLS, the text in this section will no longer be relevant. 3.1 Server Transition to DTLS As this specification permits server implementations to accept both RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a method to disambiguate packets between the two protocols. This method is applicable only to RADIUS/DTLS servers. The disambiguation method leverages the RADIUS/UDP requirement that clients be known by source IP address. RADIUS/DTLS servers MUST treat packets from unknown IP addresses as being DTLS. This requirement does not mean that the server is required to accept these packets. It means that if the server chooses to accept them, they are to be treated as being DTLS. For packets from known IP addresses RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for each client that indicates if it requires a client to use RADIUS/DTLS. If the flag is "true" then all packets from that client MUST be processed as RADIUS/DTLS. The transition to RADIUS/DTLS is performed only when the "DTLS Required" flag is "false". This setting means that the client is known to support RADIUS/UDP, but may also support RADIUS/DTLS. Packets from the client need to be examined to see if they are RADIUS/UDP or RADIUS/DTLS. The protocol disambiguation method outlined below in Section 5.1.2 MUST be used to determine how received packets are treated. From hartmans@painless-security.com Fri Apr 5 06:33:47 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2AE821F977B for ; Fri, 5 Apr 2013 06:33:47 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVqdrUPtwHVU for ; Fri, 5 Apr 2013 06:33:47 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1360C21F9680 for ; Fri, 5 Apr 2013 06:33:47 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 8E1C020219; Fri, 5 Apr 2013 09:32:30 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A88404497; Fri, 5 Apr 2013 09:33:44 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> Date: Fri, 05 Apr 2013 09:33:44 -0400 In-Reply-To: <515ED047.3040200@deployingradius.com> (Alan DeKok's message of "Fri, 05 Apr 2013 09:23:19 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Peter Deacon , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 13:33:47 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Transitioning to DTLS is a process which needs to be done Alan> carefully. A poorly handled transition is complex for Alan> administrators, and potentially subject to security downgrade Alan> attacks. It is not sufficient to just disable RADIUS/UDP and Alan> enable RADIUS/DTLS. That approach would result in timeouts, Alan> lost traffic, and network instabilities. Alternative: MOST clients can transition to RADIUS/DTLS by disabling UDP and enabling RADIUS/DTLS. Any UDP requests active during the transition will not receive a response. Servers need a way to indicate that a particular client is permitted to send both UDP and DTLS requests during a transition so that timing of transitions is not closely coordinated on the server and client. there Alan> The end result of this specification is that nearly all Alan> RADIUS/UDP implementations should transition to using Alan> RADIUS/DTLS. In some cases, RADIUS/UDP may remain where IPSec Alan> is used as a transport, or where implementation and/or Alan> business reasons preclude a change. However, long-term use of Alan> RADIUS/UDP is NOT RECOMMENDED. I'm uncomfortable with the above statement. I'm not sure that RADIUS/DTLS is better than RADIUS/TLS. It seems a lot more complex, it doesn't provide a solution to fragmentation, and I'm not convinced by the arguments RFC 2865 makes against TCP. So, I'm not sure I'd support a claim about where the world should go other than to say away from RADIUS/UDP. From aland@deployingradius.com Fri Apr 5 07:12:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 934E921F97DE for ; Fri, 5 Apr 2013 07:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.979 X-Spam-Level: X-Spam-Status: No, score=-101.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aCGCCB5Jada for ; Fri, 5 Apr 2013 07:12:16 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C56421F97DD for ; Fri, 5 Apr 2013 07:12:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 47DC922410F7; Fri, 5 Apr 2013 16:12:14 +0200 (CEST) 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 UfhUWCLLVhUm; Fri, 5 Apr 2013 16:12:11 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id DB7A22240C73; Fri, 5 Apr 2013 16:12:10 +0200 (CEST) Message-ID: <515EDBB8.2020101@deployingradius.com> Date: Fri, 05 Apr 2013 10:12:08 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 14:12:17 -0000 Peter Deacon wrote: > Recommend removing "in their entirety" OK. > What security, migration or implementation concern does this "MUST" > address? It allows a transition. If you're fine with having a "flag day" with no RADIUS traffic, you don't need a transition path. > I can think of a couple drawbacks.. > > If an operator is deciding they want to improve the security of their > system they would be *required* to accept responses with lower security > after they have declared otherwise. Uh... they declared that RADIUS/UDP packets were acceptable. The DTLS flag is for *new* traffic. It makes no sense to send RADIUS/UDP packets, and then ignore the responses because DTLS is now required. > Increased client implementation complexity as a short term security > exception has to be made for receiving non DTLS packets including > protocol disambiguation procedure for clients not specified in draft. Nonsense. There is no need for protocol disambiguation on the client. Clients already keep track of requests/responses. The protocol used by the request is the protocol used by the response. The draft never says that clients should accept RADIUS/DTLS responses to RADIUS/UDP requests. That would be a horrible idea. >> In this case, there are no known issues with a client accepting >> responses to packets it previously sent. The goal here is to ensure a >> safe and productive transition between RADIUS/UDP and RADIUS/DTLS. > > I am looking for specific technical justifications. Allowing people to transition to DTLS isn't a technical justification? > What safety or > productivity implications does the MUST requirement provide? If it did > not exist how would safety or productivity be negatively impacted? Network stability. The client would have to either time-out all RADIUS/UDP traffic, or pro-actively re-transmit it all as DTLS. That leads to either network instability due to no responses, or network spikes due to duplicate requests. >>> 5. "We note that [RFC5080] Section 2.2.2 already mandates a duplicate >>> detection cache. The connection tracking described below can be seen >>> as an extension of that cache, where entries contain DTLS sessions >>> instead of RADIUS/UDP packets." > >>> I think bringing this up is likely to cause more confusion than >>> necessary. Tuples and authenticator usage are different, session >>> lifecycle is different and state logic is different (You would not >>> ignore anything while a response is pending) > >> Do you have suggested text for the draft? > > I would suggest as properties of the state tracking are discussed in > detail in section 5 removing RFC 5080 paragraph. We're into competing requirements here. The text was added to address concerns of how DTLS session tracking interacted with existing tracking. > With DTLS implementations RADIUS packets must be resent thru new DTLS > messages rather than storing a previous DTLS response and resending. Yes, that's true. > Suggest a short text: OK. > My concern is in minimizing situations where client accounting of idle > timeout becomes unsynchronized with server view of same. There is no mechanism for exchanging idle timeout values. The server could be set at 30 seconds, and the client at 10. So they will always be unsynchronised. > My suggestion the mechanism to automatically migrate clients to DTLS > after successful DTLS handshake is not necessary. It also involves changing the protocol, and changing multiple interoperable implementations. > We already need manual knobs to make this work. Perhaps simply > requiring a knob in client and server is the best approach. This would > remove RADIUS/UDP to RADIUS/DTLS migration and RADIUS/DTLS > disambiguation. Explicit configuration in client AND server would be > necessary to successfully speak RADIUS/DTLS. The draft already describes explicit configuration to make RADIUS/DTLS. The point of the transition path is to *allow* a transition path. Otherwise an administrator needs to modify both ends simultaneously. He also needs to deal with dropped traffic due to the human "simultaneous" having a different timescale from the computer "simultaneous". i.e. there may be seconds to minutes where the two systems are out of sync, and *all* RADIUS traffic is dropped. For someone who is worried about idle timeout synchronization, it's surprising that you're OK with having no protocol synchronization. One works in the real world and causes no real-world problems. The other causes network outages and potentially loss of revenue. > We see lots of NASes with only a few if any concurrent users. It is not > uncommon for new RADIUS traffic to be seen on orders of tens of minutes > to hours. Having a connection open hurts nobody and prevents delay > including possibly additional delay to failover for users coming > online. It also prevents state sync problems..(see my comments below) This is related to the RFC2865 issue of "keep alive considered harmful". If there's no traffic to the RADIUS server for hours, having DTLS heartbeats have little benefit. I think the arguments against this are best summarized by the 20 year-old argument against keep-alives. > Heartbeats do not effect last packet and watchdog is for detection of > server failure I would guess that both DTLS and watchdog packets are handled by the same process. In which case... the same process is responsible for both heartbeat and watchdog. It's unclear to me how it would respond to one and not to the other. > rather than communication of compatible session timeout > parameters. Well, the draft doesn't propose communication of session timeout parameters. > The following example explains my concern: > > RADIUS/DTLS server - 60 second idle timeout. > RADIUS/DTLS client - 90 second idle timeout. > > (5.2 "RADIUS/DTLS clients SHOULD pro-actively close sessions when they > have been idle for a period of time") > > For the sake of this example RADIUS client is connected to a NAS that > sees only a few concurrent sessions and only sparse activity every few > minutes...From our experience typical AP in a low traffic environment. > > At 75 seconds the client sends a RADIUS request to RADIUS/DTLS server. > Server promptly ignores this request because the session was torn down > due to exceeding idle timeout. The client runs thru all of its retries > and timeouts IGNORED by the server before it either picks a different > RADIUS server or tries to open a new RADIUS/DTLS session to the same > server. That is an issue. It's mitigated by the suggestion to use an application-layer watchdog. While keep-alives are harmful, the client can use the watchdog to ensure that the server is up. If the client doesn't use a watchdog, then it can't rely on DTLS hearbeats. Or so you say above. > Other thoughts to minimize this problem have client enforce an idle > timeout algorithm based on usage but allow server idle timer to be > refreshed by DTLS heartbeats. Which is what the draft suggests. > The server can take other actions if there is pressure on resources to > manage DTLS sessions but normally it is important to do EVERYTHING > possible to make sure RADIUS/DTLS is as reliable as RADIUS/UDP with no > delays for clients to figure out and react to rug being pulled out from > under them. Of course. But if the client isn't sending traffic... there's no reason for the server to keep the session alive. I think the only disagreement here is whether the "idle timeout" values are large or small. > What does the idle state actually do? What is the difference vs using > "idle timeout" since last packet without an "idle" transition? That is what I meant by "idle". > 5.2... > > RADIUS/DTLS clients MAY proactively close sessions when they have been > idle for 60-86400 seconds if DTLS heartbeats or active watchdog probes > are used. When unused RADIUS/DTLS client SHOULD close sessions idle for > 60 to no longer than 600 seconds. Which still has the problem you noted. Clients have an idle timeout of 600s, and servers of 60s. Changing the suggested timers works around the problem without solving it. Suggesting that the client use the watchdog algorithm solves the problem. > 5.1.1... > > This session "idle timeout" SHOULD be exposed to the administrator as a > configurable setting. RADIUS servers SHOULD timeout after at least 600 > seconds. > > As UDP does not guarantee delivery of messages, RADIUS/DTLS servers > MUST also maintain a "Last Packet" timestamp per DTLS session. The > timestamp MUST be updated on reception of a valid RADIUS/DTLS > packet or DTLS heartbeat. The timestamp MUST NOT be updated in other > situations. The server SHOULD delete idle DTLS sessions after > an "idle timeout". Hmm... OK. I'll work on some text. > 10.2 > > While total number of sessions tracked exceeds the configured limit > servers SHOULD close idle sessions starting with highest idle time until > a sufficient number of sessions have been closed or lower idle timeout > threshold of 60 seconds or more has been reached. That's not clear to me. I'll work on some text. Alan DeKok. From Ted.Lemon@nominum.com Fri Apr 5 07:27:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A10C21F97D0; Fri, 5 Apr 2013 07:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yJI0pjmNO6I; Fri, 5 Apr 2013 07:27:53 -0700 (PDT) Received: from exprod7og128.obsmtp.com (exprod7og128.obsmtp.com [64.18.2.121]) by ietfa.amsl.com (Postfix) with ESMTP id 935F921F97B6; Fri, 5 Apr 2013 07:27:53 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob128.postini.com ([64.18.6.12]) with SMTP ID DSNKUV7faWWlOSpc3c9slrXFrKCWDQY/uiqQ@postini.com; Fri, 05 Apr 2013 07:27:53 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 178F61B8225; Fri, 5 Apr 2013 07:27:53 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 0DAAA19005D; Fri, 5 Apr 2013 07:27:53 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 07:27:53 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHOMc3xheg1Y2HRokOypXMokVkn6ZjH9y6AgAAS5ACAAAYcAIAAEe+AgAADJAA= Date: Fri, 5 Apr 2013 14:27:52 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> <515EDCC7.5010708@gmail.com> In-Reply-To: <515EDCC7.5010708@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <2E75FA08C390B04A814EB664E28B07C1@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dhcwg , "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 14:27:54 -0000 On Apr 5, 2013, at 10:16 AM, Tomek Mrugalski w= rote: > "Server MAY ignore received RADIUS attributes that it does not support." > seems like a reasonable text here. Some implementors will ignore unknown > attribute, some may produce a warning and some my try to handle it in a > generic way. Generally speaking, this sort of language is a recipe for attack. I think= the draft should just say that the administrator should be able to update = the list of acceptable options. From aland@deployingradius.com Fri Apr 5 07:28:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9371821F970E; Fri, 5 Apr 2013 07:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8kHKIDcpy0BH; Fri, 5 Apr 2013 07:28:49 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2E4F21F9701; Fri, 5 Apr 2013 07:28:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 20B9A22410F7; Fri, 5 Apr 2013 16:28:31 +0200 (CEST) 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 zMjtRT-DDiEo; Fri, 5 Apr 2013 16:28:30 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.204]) by power.freeradius.org (Postfix) with ESMTPSA id 439B02240F50; Fri, 5 Apr 2013 16:28:30 +0200 (CEST) Message-ID: <515EDF8C.90104@deployingradius.com> Date: Fri, 05 Apr 2013 10:28:28 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Ted Lemon References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> <515EDCC7.5010708@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Tomek Mrugalski , dhcwg , "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 14:28:49 -0000 Ted Lemon wrote: > Generally speaking, this sort of language is a recipe for attack. I think the draft should just say that the administrator should be able to update the list of acceptable options. That's probably best. From peterd@iea-software.com Fri Apr 5 09:11:37 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A543121F97AE; Fri, 5 Apr 2013 09:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibqEdphDfMiV; Fri, 5 Apr 2013 09:11:37 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id C2BB921F976F; Fri, 5 Apr 2013 09:11:36 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 5 Apr 2013 09:11:36 -0700 Date: Fri, 5 Apr 2013 09:11:31 -0700 (Pacific Daylight Time) From: Peter Deacon To: Leaf Yeh In-Reply-To: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> Message-ID: References: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.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, 'dhcwg' Subject: Re: [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 16:11:37 -0000 On Fri, 5 Apr 2013, Leaf Yeh wrote: > Peter - With the DHCPv6 relay forwarding should relays forward attributes it > does not know about to server? From my read (section 5) it seems to say > attributes are forwarded if the relay validates value which seems to imply > it can't forward attributes it does not know about? > Good question. I think the point here is the DHCPv6 relay only forward > those valid attribute in the registry of 'RADIUS attributes permitted in > DHCPv6 RADIUS option'. If the DHCPv6 server supports OPTION_RADIUS > defined here, it should know all the attributes received from the relay. > If the DHCPv6 server still does not know the attributes in > OPTION_RADIUS, the server just ignore those attributes per the Postel's > Law. Hi Leaf, Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6 servers in number and vendors involved. It might be difficult to ever add new attributes in production as you would have to touch all relays to allow a new attribute to pass. My guess VSAs would likely end up filling any gaps anyway. > Peter - The DHCP analogue (RFC 4014 sec 4) lists other attributes just > wondering what is different here that makes the attribute lists different > ...IPv6 specific company excluded of course. > I guess you are talking about the following attributes (in the table of the > section 4 in RFC 4014): > 1 User-Name (RFC 2865 [3]) > 6 Service-Type (RFC 2865) > 27 Session-Timeout (RFC 2865) > I still have not got the points (or understood the use case) for: > a. User-Name : why the User-Name of AAA (or RADIUS) will be necessary to > forward the DHCPv6 server; the standard DHCPv6 server sounds never use it > before; > b. Service-Type : what kind of service-type of AAA (or RADIUS, > http://www.iana.org/assignments/radius-types/radius-types.xml#radius-types-4 > ) will be necessary to forward the DHCPv6 server; > c. Session-Timeout : I think the NAS (DHCPv6 relay + RADIUS client) can be > the 1st control point of trusted network , it can decide whether to forward > the DHCPv6 messages from the client to the server. After the session is > timeout, it just stop forward the DHCPv6 messages from the client to the > server. This RADIUS attribute also sounds not necessary to forward to the > DHCPv6 server. Right? Yes, I can't think of much either. User-Name might be used to correlate any user specific settings stored in DHCP server or just logging purposes to understand end user associated with DHCP queries. regards, Peter From Ted.Lemon@nominum.com Fri Apr 5 09:18:06 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7EA21F9838; Fri, 5 Apr 2013 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2H3ieUuu4kCm; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC4621F9835; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKUV75PIz5P8RUE7qATDSMUtovzRsvzAei@postini.com; Fri, 05 Apr 2013 09:18:04 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 463F81081C0; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) Received: from webmail.nominum.com (cas-02.win.nominum.com [64.89.228.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 3A9C319005D; Fri, 5 Apr 2013 09:18:04 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-02.WIN.NOMINUM.COM ([64.89.228.132]) with mapi id 14.02.0318.004; Fri, 5 Apr 2013 09:18:04 -0700 From: Ted Lemon To: Peter Deacon Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: Ac4xZGO6VSG79PrhReiNj3Ln9NlMtAAApjaQADr6/IAAADrcAA== Date: Fri, 5 Apr 2013 16:18:03 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B6307751336B3@mbx-01.win.nominum.com> References: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <05F797F04784824AB252DF5AB6BD323A@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Leaf Yeh , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 16:18:06 -0000 On Apr 5, 2013, at 12:11 PM, Peter Deacon wrote: > Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6= servers in number and vendors involved. It might be difficult to ever add= new attributes in production as you would have to touch all relays to allo= w a new attribute to pass. My guess VSAs would likely end up filling any g= aps anyway. What's a VSA? Should the document specify that the list of attributes to = forward be customizable by the administrator? I think the main purpose that the list of options not to forward serves is = to have a default setting, and to exclude on a protocol specification level= the use of options that we don't specifically intend be used; if an admini= strator configures some option that's not on the list, I think that's harml= ess. From peterd@iea-software.com Fri Apr 5 11:18:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4173921F97AE for ; Fri, 5 Apr 2013 11:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.475 X-Spam-Level: X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvu5QfoL+BBg for ; Fri, 5 Apr 2013 11:18:24 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8066821F8681 for ; Fri, 5 Apr 2013 11:18:24 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 5 Apr 2013 11:18:23 -0700 Date: Fri, 5 Apr 2013 11:18:18 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <515ED047.3040200@deployingradius.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Sam Hartman , radext-chairs@tools.ietf.org, radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 18:18:25 -0000 On Fri, 5 Apr 2013, Alan DeKok wrote: > 3. Transition Path > Transitioning to DTLS is a process which needs to be done carefully. > A poorly handled transition is complex for administrators, and > potentially subject to security downgrade attacks. It is not > sufficient to just disable RADIUS/UDP and enable RADIUS/DTLS. That > approach would result in timeouts, lost traffic, and network > instabilities. > The end result of this specification is that nearly all RADIUS/UDP > implementations should transition to using RADIUS/DTLS. In some > cases, RADIUS/UDP may remain where IPSec is used as a transport, or > where implementation and/or business reasons preclude a change. > However, long-term use of RADIUS/UDP is NOT RECOMMENDED. > This section describes how clients and servers should transition to > DTLS. There is a fair amount of discussion around this transition, as > it is critical to get it correct. We expect that once implementations > have transitioned to RADIUS/DTLS, the text in this section will no > longer be relevant. > 3.1 Server Transition to DTLS > As this specification permits server implementations to accept both > RADIUS/UDP and RADIUS/DTLS packets on the same port, we require a > method to disambiguate packets between the two protocols. This method > is applicable only to RADIUS/DTLS servers. > The disambiguation method leverages the RADIUS/UDP requirement that > clients be known by source IP address. RADIUS/DTLS servers MUST treat > packets from unknown IP addresses as being DTLS. This requirement > does not mean that the server is required to accept these packets. It > means that if the server chooses to accept them, they are to be > treated as being DTLS. I don't think this will work for us. This is data that people use to flag/report possible new clients they should have known about, existing clients with changed addresses and plain old configuration errors. It can be a configuration option, done conditionally within the context protocol disambiguation or even a recommendation but not something unconditionally required. > For packets from known IP addresses RADIUS/DTLS servers MUST maintain > a boolean "DTLS Required" flag for each client that indicates if it > requires a client to use RADIUS/DTLS. If the flag is "true" then all > packets from that client MUST be processed as RADIUS/DTLS. > The transition to RADIUS/DTLS is performed only when the "DTLS > Required" flag is "false". This setting means that the client is > known to support RADIUS/UDP, but may also support RADIUS/DTLS. > Packets from the client need to be examined to see if they are > RADIUS/UDP or RADIUS/DTLS. The protocol disambiguation method > outlined below in Section 5.1.2 MUST be used to determine how received > packets are treated. Suggest reversing this. Have the client maintain the flag. If DTLS handshake has succeeded then client uses DTLS from then on for any inquiries without the option of automatically falling back to UDP. Servers would still maintain flag but it would only be a manually turned knob to indicate security level it is willing to accept. This causes less breakage for the case of multiple clients behind a single IP where they can not all be upgraded at once to DTLS. Whether client or server does the enforcement seems moot as the same outcome is realized either way. The more I think about it the more I agree with Joe's points on separate UDP ports. regards, Peter From peterd@iea-software.com Fri Apr 5 11:25:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3493921F984E; Fri, 5 Apr 2013 11:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G47LwWoMra8H; Fri, 5 Apr 2013 11:25:19 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 932BF21F9849; Fri, 5 Apr 2013 11:25:19 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 5 Apr 2013 11:25:19 -0700 Date: Fri, 5 Apr 2013 11:25:14 -0700 (Pacific Daylight Time) From: Peter Deacon To: Ted Lemon In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307751336B3@mbx-01.win.nominum.com> Message-ID: References: <515ea42f.c521440a.26ee.ffffcc8e@mx.google.com> <8D23D4052ABE7A4490E77B1A012B6307751336B3@mbx-01.win.nominum.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "" , Leaf Yeh , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 18:25:20 -0000 On Fri, 5 Apr 2013, Ted Lemon wrote: > On Apr 5, 2013, at 12:11 PM, Peter Deacon wrote: >> Ok, my only concern here is relays tend to be "dumb" and outnumber DHCPv6 servers in number and vendors involved. It might be difficult to ever add new attributes in production as you would have to touch all relays to allow a new attribute to pass. My guess VSAs would likely end up filling any gaps anyway. > What's a VSA? Should the document specify that the list of attributes > to forward be customizable by the administrator? Hi Ted Lemon, The configuration options sound good. VSA = Vendor Specific Attribute (Vendor-Specific in table sec 4.1) regards, Peter From ietf@augustcellars.com Fri Apr 5 16:08:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48A321F9029 for ; Fri, 5 Apr 2013 16:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.979 X-Spam-Level: X-Spam-Status: No, score=-2.979 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IsQfjSvf3pB4 for ; Fri, 5 Apr 2013 16:08:45 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id A506521F8F6C for ; Fri, 5 Apr 2013 16:08:45 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 1D11738EF0; Fri, 5 Apr 2013 16:08:45 -0700 (PDT) From: "Jim Schaad" To: "'Peter Deacon'" , "'Alan DeKok'" References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> In-Reply-To: Date: Fri, 5 Apr 2013 16:08:07 -0700 Message-ID: <007601ce3252$6fd489b0$4f7d9d10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIaRpfN0dt2jFAPTnJJfl3J6VKbMAHCZSTeAubPd40CF5j825f6EJ3g Content-Language: en-us Cc: radext@ietf.org, radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 05 Apr 2013 23:08:46 -0000 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Peter Deacon > Sent: Friday, April 05, 2013 12:24 AM > To: Alan DeKok > Cc: radext@ietf.org; radext-chairs@tools.ietf.org > Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 > > On Wed, 3 Apr 2013, Alan DeKok wrote: > > >> 2.2.2 "We re-iterate that much of [RFC6614] applies to this document. > >> Specifically, Section 4 and Section 6 of that document are applicable > >> in their entirety to RADIUS/DTLS." > > >> RFC 6614 section 6 dedicates a few sentences to TCP specific > >> properties which do not apply to RADIUS/DTLS. > > > Do you have suggested text for the draft? > > Recommend removing "in their entirety" > > >> 4. "Adding these > >> parameters means that the client MUST start using DTLS to the server > >> for all new requests. The client MUST, however, accept RADIUS/UDP > >> responses to any outstanding requests." > > >> MUST does not seem appropriate. We have no business in what client > >> elect to do with outstanding requests after a security configuration > >> change. > > > Yes, we do. We're writing the standards here, which means we must > > address security, migration, implementation cost, etc. > > What security, migration or implementation concern does this "MUST" > address? > > I can think of a couple drawbacks.. > > If an operator is deciding they want to improve the security of their system > they would be *required* to accept responses with lower security after they > have declared otherwise. > > Increased client implementation complexity as a short term security > exception has to be made for receiving non DTLS packets including protocol > disambiguation procedure for clients not specified in draft. > > > In this case, there are no known issues with a client accepting > > responses to packets it previously sent. The goal here is to ensure a > > safe and productive transition between RADIUS/UDP and RADIUS/DTLS. > > I am looking for specific technical justifications. What safety or productivity > implications does the MUST requirement provide? If it did not exist how > would safety or productivity be negatively impacted? > > >> 5. "We note that [RFC5080] Section 2.2.2 already mandates a duplicate > >> detection cache. The connection tracking described below can be seen > >> as an extension of that cache, where entries contain DTLS sessions > >> instead of RADIUS/UDP packets." > > >> I think bringing this up is likely to cause more confusion than > >> necessary. Tuples and authenticator usage are different, session > >> lifecycle is different and state logic is different (You would not > >> ignore anything while a response is pending) > > > Do you have suggested text for the draft? > > I would suggest as properties of the state tracking are discussed in detail in > section 5 removing RFC 5080 paragraph. > > >> I think it might be helpful to note RFC5080 in the context of > >> continuing to support this mechanism and to continue to do it at the > >> RADIUS packet layer rather than DTLS or you're likely to end up on > >> the wrong side of the DTLS sequence window. > > > I'm not sure what that means. > > Normally with RFC 5080 replay system an implementation will store a > response for a given request and simply resend a stored response (UDP > message) on wire. > > With DTLS implementations RADIUS packets must be resent thru new DTLS > messages rather than storing a previous DTLS response and resending. > > The reason for this is DTLS replay protection uses a sequence window where > only a fixed number of previously unaccepted packets are accepted. Retry > timers on orders of seconds on a busy client are likely lead to retransmitted > messages being too stale to be accepted on DTLS stack unless retransmissions > are performed by retransmitting stored RADIUS response thru DTLS. > > > Suggest a short text: > > Any duplicate detection strategy such as [RFC5080] section 2.2.2 where > previously transmitted RADIUS packets are replayed MUST be replayed thru > DTLS creating a new DTLS packet before transmission. Previously transmitted > DTLS packets MUST NOT be retransmitted. > > >> 5.1 "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." > > >> As long as the packet was valid while being silently discarded it > >> should count for the purpose of last packet. > > > Why? What benefit does that offer? > > My concern is in minimizing situations where client accounting of idle timeout > becomes unsynchronized with server view of same. > > >> 5.1.1 - I still think we can do better on the UDP / DTLS > >> disambiguation using the 4 byte header I described earlier or by > >> explicitly requiring a server knob to declare what protocol would be > >> accepted from a given source address. > > > The draft already defines a "DTLS Required" flag. Servers use it to > > decide which protocol is accepted from a given client. > > My suggestion the mechanism to automatically migrate clients to DTLS after > successful DTLS handshake is not necessary. > > We already need manual knobs to make this work. Perhaps simply requiring a > knob in client and server is the best approach. This would remove > RADIUS/UDP to RADIUS/DTLS migration and RADIUS/DTLS disambiguation. > Explicit configuration in client AND server would be necessary to successfully > speak RADIUS/DTLS. > > >> "A server may also use watchdog packets from the client to > >> determine that the connection is still active." > >> > >> "The > >> timestamp SHOULD be updated on reception of a valid RADIUS/DTLS > >> packet. The timestamp MUST NOT be updated in other situations." > >> > >> The RADIUS packet layer does not see heartbeats. Should this cause a > >> change in Last Packet? > > > No. That is for RADIUS packets, not DTLS heartbeats. > > >> Do you intent for sessions to idle out and expire even with active > >> DTLS layer keepalives? > > > Yes. If there's no RADIUS traffic for a long time, there are few > > reasons to keep the session up. > > We see lots of NASes with only a few if any concurrent users. It is not > uncommon for new RADIUS traffic to be seen on orders of tens of minutes to > hours. Having a connection open hurts nobody and prevents delay including > possibly additional delay to failover for users coming online. It also prevents > state sync problems..(see my comments below) > > >> "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." > > >> The recommended maximum idle timeout is too low in my view. > >> Resetting connections should be as rare as possible as clients now > >> have the added burden of correctly guessing whether packets were > >> dropped on wire or dropped on DTLS stack in addition to possibility server > may not be alive. > > > Did you read the text about RADIUS watchdog packets and DTLS > > heartbeats? No "guessing" is required. > > Heartbeats do not effect last packet and watchdog is for detection of server > failure rather than communication of compatible session timeout parameters. > > The following example explains my concern: > > RADIUS/DTLS server - 60 second idle timeout. > RADIUS/DTLS client - 90 second idle timeout. > > (5.2 "RADIUS/DTLS clients SHOULD pro-actively close sessions when they have > been idle for a period of time") > > For the sake of this example RADIUS client is connected to a NAS that sees > only a few concurrent sessions and only sparse activity every few > minutes...From our experience typical AP in a low traffic environment. > > At 75 seconds the client sends a RADIUS request to RADIUS/DTLS server. > Server promptly ignores this request because the session was torn down due > to exceeding idle timeout. The client runs thru all of its retries and timeouts > IGNORED by the server before it either picks a different RADIUS server or > tries to open a new RADIUS/DTLS session to the same server. But you are also going assume that the teardown message on the DTLS link is also going to be lost. In the more common case the close_notify alert is going to get sent from the server to the client (or the other way) and both sides are going to know that the session has been shut down. Jim > > None of the active probing mechanisms work at these timescales and they > should not be necessary to prevent this sort of problem from occurring. > > TCP TLS provides reliable notification of shutdown DTLS does not. > > I recommend that recommended client idle parameters be specified and not > overlap with recommended server idle parameters. > > For example something like clients may close the connection at 60-600 > seconds. Servers may close the connection after >600 seconds. > > Other thoughts to minimize this problem have client enforce an idle timeout > algorithm based on usage but allow server idle timer to be refreshed by DTLS > heartbeats. > > The server can take other actions if there is pressure on resources to manage > DTLS sessions but normally it is important to do EVERYTHING possible to make > sure RADIUS/DTLS is as reliable as RADIUS/UDP with no delays for clients to > figure out and react to rug being pulled out from under them. > > >> There are no timing guidelines provided for transition to "idle" state. > > > Do you have suggested text for the draft? > > What does the idle state actually do? What is the difference vs using "idle > timeout" since last packet without an "idle" transition? > > >> Mismatch of idle expectations between client and server could trigger > >> unnecessary delay which could be mitigated by separating client and > >> server expectations so there is no overlap in the recommended settings. > >> Clients severely outnumber servers. > > > Do you have suggested text for the draft? > > 5.2... > > RADIUS/DTLS clients MAY proactively close sessions when they have been idle > for 60-86400 seconds if DTLS heartbeats or active watchdog probes are used. > When unused RADIUS/DTLS client SHOULD close sessions idle for 60 to no > longer than 600 seconds. > > 5.1.1... > > This session "idle timeout" SHOULD be exposed to the administrator as a > configurable setting. RADIUS servers SHOULD timeout after at least 600 > seconds. > > As UDP does not guarantee delivery of messages, RADIUS/DTLS servers > MUST also maintain a "Last Packet" timestamp per DTLS session. The > timestamp MUST be updated on reception of a valid RADIUS/DTLS > packet or DTLS heartbeat. The timestamp MUST NOT be updated in other > situations. The server SHOULD delete idle DTLS sessions after > an "idle timeout". > > > 10.2 > > While total number of sessions tracked exceeds the configured limit servers > SHOULD close idle sessions starting with highest idle time until a sufficient > number of sessions have been closed or lower idle timeout threshold of 60 > seconds or more has been reached. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Fri Apr 5 17:22:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2F921F8B15 for ; Fri, 5 Apr 2013 17:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0nn9imXJHI0 for ; Fri, 5 Apr 2013 17:22:32 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6F51121F8AC3 for ; Fri, 5 Apr 2013 17:22:32 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 5 Apr 2013 17:22:31 -0700 Date: Fri, 5 Apr 2013 17:22:30 -0700 (Pacific Daylight Time) From: Peter Deacon To: Jim Schaad In-Reply-To: <007601ce3252$6fd489b0$4f7d9d10$@augustcellars.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <007601ce3252$6fd489b0$4f7d9d10$@augustcellars.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, radext-chairs@tools.ietf.org, 'Alan DeKok' Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 06 Apr 2013 00:22:33 -0000 On Fri, 5 Apr 2013, Jim Schaad wrote: >> For the sake of this example RADIUS client is connected to a NAS that sees >> only a few concurrent sessions and only sparse activity every few >> minutes...From our experience typical AP in a low traffic environment. >> >> At 75 seconds the client sends a RADIUS request to RADIUS/DTLS server. >> Server promptly ignores this request because the session was torn down due >> to exceeding idle timeout. The client runs thru all of its retries and > timeouts >> IGNORED by the server before it either picks a different RADIUS server or >> tries to open a new RADIUS/DTLS session to the same server. > But you are also going assume that the teardown message on the DTLS link is > also going to be lost. In the more common case the close_notify alert is > going to get sent from the server to the client (or the other way) and both > sides are going to know that the session has been shut down. > Jim >> None of the active probing mechanisms work at these timescales and they >> should not be necessary to prevent this sort of problem from occurring. >> TCP TLS provides reliable notification of shutdown DTLS does not. Hi Jim, Apologize if I gave a different impression than intended. Did not intend to exclude or imply no notification only notification is unreliable. Advocating mitigating with small changes to default settings or idle algorithm as in suggested text. regards, Peter >>> Do you have suggested text for the draft? >> >> 5.2... >> >> RADIUS/DTLS clients MAY proactively close sessions when they have been > idle >> for 60-86400 seconds if DTLS heartbeats or active watchdog probes are > used. >> When unused RADIUS/DTLS client SHOULD close sessions idle for 60 to no >> longer than 600 seconds. >> >> 5.1.1... >> >> This session "idle timeout" SHOULD be exposed to the administrator as a >> configurable setting. RADIUS servers SHOULD timeout after at least 600 >> seconds. >> >> As UDP does not guarantee delivery of messages, RADIUS/DTLS servers >> MUST also maintain a "Last Packet" timestamp per DTLS session. The >> timestamp MUST be updated on reception of a valid RADIUS/DTLS >> packet or DTLS heartbeat. The timestamp MUST NOT be updated in other >> situations. The server SHOULD delete idle DTLS sessions after >> an "idle timeout". >> >> >> 10.2 >> >> While total number of sessions tracked exceeds the configured limit > servers >> SHOULD close idle sessions starting with highest idle time until a > sufficient >> number of sessions have been closed or lower idle timeout threshold of 60 >> seconds or more has been reached. From peterd@iea-software.com Sat Apr 6 00:28:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C69A421F940F for ; Sat, 6 Apr 2013 00:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mN4MTvf8lu7 for ; Sat, 6 Apr 2013 00:28:43 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 753E121F940D for ; Sat, 6 Apr 2013 00:28:43 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sat, 6 Apr 2013 00:28:42 -0700 Date: Sat, 6 Apr 2013 00:28:39 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <515EDBB8.2020101@deployingradius.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515EDBB8.2020101@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, radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 06 Apr 2013 07:28:44 -0000 On Fri, 5 Apr 2013, Alan DeKok wrote: >> If an operator is deciding they want to improve the security of their >> system they would be *required* to accept responses with lower security >> after they have declared otherwise. > Uh... they declared that RADIUS/UDP packets were acceptable. The DTLS > flag is for *new* traffic. It makes a decision for the operator by assuming past configuration is still desired or applicable. > It makes no sense to send RADIUS/UDP packets, and then ignore the > responses because DTLS is now required. When switching to DTLS clients may no longer be capable or willing to touch RADIUS/UDP. I'm not arguing against the behavior. I just think the MUST requirement is too strong. > The point of the transition path is to *allow* a transition path. > Otherwise an administrator needs to modify both ends simultaneously. > He also needs to deal with dropped traffic due to the human > "simultaneous" having a different timescale from the computer > "simultaneous". > i.e. there may be seconds to minutes where the two systems are out of > sync, and *all* RADIUS traffic is dropped. > For someone who is worried about idle timeout synchronization, it's > surprising that you're OK with having no protocol synchronization. One > works in the real world and causes no real-world problems. The other > causes network outages and potentially loss of revenue. At some point the operator would have had to update firmware or software taking the system offline to obtain RADIUS/DTLS functionality. These kinds of things are handled normally within a planned maintenance window. As draft points out in section 10.3 this automatic scheme causes breakage while there are multiple clients behind a single IP. When just one of them upgrades all other clients break causing network outage and potential loss of revenue. The simple manual server knobs without migration behavior in this case prevents migration from *causing* an outage. Having thought about this a bit more perhaps it would be better simply to move migration procedure from server to client. This would fix NAT problems and server "flag" would only be used to declare level of security it is willing to accept. >> We see lots of NASes with only a few if any concurrent users. It is not >> uncommon for new RADIUS traffic to be seen on orders of tens of minutes >> to hours. Having a connection open hurts nobody and prevents delay >> including possibly additional delay to failover for users coming >> online. It also prevents state sync problems..(see my comments below) > This is related to the RFC2865 issue of "keep alive considered > harmful". If there's no traffic to the RADIUS server for hours, having > DTLS heartbeats have little benefit. > I think the arguments against this are best summarized by the 20 > year-old argument against keep-alives. RFC 2865 makes this argument in context of probing server availability. DTLS heartbeat communicates DTLS session availability. Now that there are sessions to be managed and connect first constraints on source port usage have to be careful with context of RFC 2865 keepalive philosophy. The main reason I see a need to use heartbeats is to thread the needle keeping UDP NAT associations from expiring, letting servers know our session is not forgotten and detecting session termination. None of these concerns apply to RADIUS/UDP. I would be happy if DTLS heartbeats were able to reset server idle timeout. Thats all I want. In my view the only "application layer" thing that works for purpose of determining useful overall systems availability is still passive observation of response to client requests in the spirit of RFC 2865. regards, Peter From dnelson@elbrys.com Sat Apr 6 05:46:12 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A0621F8E51 for ; Sat, 6 Apr 2013 05:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HCM04nyPoCil for ; Sat, 6 Apr 2013 05:46:10 -0700 (PDT) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by ietfa.amsl.com (Postfix) with ESMTP id 78B8421F8E46 for ; Sat, 6 Apr 2013 05:46:10 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id c11so4643873wgh.20 for ; Sat, 06 Apr 2013 05:46:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=KjG3WFcgLf6iglblXndtQ+69lX1XnA3mwrkZprEqdE4=; b=C3yhEgc9/dz8+XFnak4U31FoeoIbztZaSk30eKjcz+KdP56O3ebevGTpDQm7K++rp7 OOMsSQs0liMD8gOpINdYuXdIAAUj/PcS0LD4UwF0UXtremT7R4MxIRGpR6QLBLxLSUuS ycZ3jQagcGPndeflChGYPk5NnlFmJP+JiUdN/sOq8nDh4oMbgcyo73LW7jQXR3f2fWCO zVHqLTjjXFhS/FeJIbLwyH+YQxJl+mYWhGnzao2yR+DkRg4SkXOZPhwhInzE+SuNWT4o Dwff3F4XmFv3OX3hKXWlRK7EnDkgnD4hUDcO29Q1qGc7U47DTPgPHytR2uP0jfkPBeZn 8EAg== MIME-Version: 1.0 X-Received: by 10.180.89.243 with SMTP id br19mr3965580wib.5.1365252369525; Sat, 06 Apr 2013 05:46:09 -0700 (PDT) Received: by 10.194.34.97 with HTTP; Sat, 6 Apr 2013 05:46:09 -0700 (PDT) In-Reply-To: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515EDBB8.2020101@deployingradius.com> Date: Sat, 6 Apr 2013 08:46:09 -0400 Message-ID: From: Dave Nelson To: Peter Deacon Content-Type: multipart/alternative; boundary=e89a8f3ba24d83c34c04d9b09649 X-Gm-Message-State: ALoCoQmlO9NBIJBBa8FnR9eScB+hgjnjJCayxDtdDQjd7cK+h68RJZpw0375apzu72jCPssOq+Ym Cc: radext mailing list , radext-chairs@tools.ietf.org, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 06 Apr 2013 12:46:12 -0000 --e89a8f3ba24d83c34c04d9b09649 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Apr 6, 2013 at 3:28 AM, Peter Deacon wrote: At some point the operator would have had to update firmware or software > taking the system offline to obtain RADIUS/DTLS functionality. These kinds > of things are handled normally within a planned maintenance window. > > As draft points out in section 10.3 this automatic scheme causes breakage > while there are multiple clients behind a single IP. When just one of them > upgrades all other clients break causing network outage and potential loss > of revenue. The simple manual server knobs without migration behavior in > this case prevents migration from *causing* an outage. > > Having thought about this a bit more perhaps it would be better simply to > move migration procedure from server to client. This would fix NAT > problems and server "flag" would only be used to declare level of security > it is willing to accept. I was wondering why starting up a replacement RADIUS server offering RADIUS/DTLS on another IP address, and then switching the RADIUS server IP address on each client as it's upgraded -- it has to be upgraded -- wouldn't accomplish the same overlapped, make-before-break transition as a single server that supports two modes of operation? Regards, Dave David B. Nelson Director of Technology Elbrys Networks, Inc. www.elbrys.com +1.603.570.2636 --e89a8f3ba24d83c34c04d9b09649 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Sat, Apr 6, 2013 at 3:28 AM, Peter Deacon <peter= d@iea-software.com> wrote:

At some point the operator would have ha= d to update firmware or software taking the system offline to obtain RADIUS= /DTLS functionality. =A0These kinds of things are handled normally within a= planned maintenance window.

As draft points out in section 10.3 this automatic scheme causes breakage w= hile there are multiple clients behind a single IP. =A0When just one of the= m upgrades all other clients break causing network outage and potential los= s of revenue. =A0The simple manual server knobs without migration behavior = in this case prevents migration from *causing* an outage.

Having thought about this a bit more perhaps it would be better simply to m= ove migration procedure from server to client. =A0This would fix NAT proble= ms and server "flag" would only be used to declare level of secur= ity it is willing to accept.

I was wondering why starting up a replacement RADIUS se= rver offering RADIUS/DTLS on another IP address, and then switching the RAD= IUS server IP address on each client as it's upgraded -- it has to be u= pgraded -- wouldn't accomplish the same overlapped, make-before-break t= ransition as a single server that supports two modes of operation?

Regards,

Dave

David B. Nelson
Director of = Technology
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636
--e89a8f3ba24d83c34c04d9b09649-- From aland@deployingradius.com Sat Apr 6 05:52:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5261921F8E51 for ; Sat, 6 Apr 2013 05:52:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8Nd1Q1Sxv4k for ; Sat, 6 Apr 2013 05:52:56 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D10A921F8E06 for ; Sat, 6 Apr 2013 05:52:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DA3C12240D85; Sat, 6 Apr 2013 14:52:13 +0200 (CEST) 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 M4PgWb1RtlQr; Sat, 6 Apr 2013 14:52:12 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 6A4712240777; Sat, 6 Apr 2013 14:52:11 +0200 (CEST) Message-ID: <51601A79.7020300@deployingradius.com> Date: Sat, 06 Apr 2013 08:52:09 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Dave Nelson References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515EDBB8.2020101@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext mailing list , Peter Deacon , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 06 Apr 2013 12:52:57 -0000 Dave Nelson wrote: > I was wondering why starting up a replacement RADIUS server offering > RADIUS/DTLS on another IP address, and then switching the RADIUS server > IP address on each client as it's upgraded -- it has to be upgraded -- > wouldn't accomplish the same overlapped, make-before-break transition as > a single server that supports two modes of operation? Yes. Switching ports would work, too. Alan DeKok. From aland@deployingradius.com Sat Apr 6 06:38:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63EAC21F8A4F for ; Sat, 6 Apr 2013 06:38:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZ082C3QVoax for ; Sat, 6 Apr 2013 06:38:44 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB421F89B2 for ; Sat, 6 Apr 2013 06:38:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 1149F2240D85; Sat, 6 Apr 2013 15:38:38 +0200 (CEST) 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 qDy2GA67NAd4; Sat, 6 Apr 2013 15:38:37 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 175222240777; Sat, 6 Apr 2013 15:38:36 +0200 (CEST) Message-ID: <5160255B.40409@deployingradius.com> Date: Sat, 06 Apr 2013 09:38:35 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , radext-chairs@tools.ietf.org, radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 06 Apr 2013 13:38:45 -0000 Peter Deacon wrote: >> clients be known by source IP address. RADIUS/DTLS servers MUST treat >> packets from unknown IP addresses as being DTLS. This requirement >> does not mean that the server is required to accept these packets. It >> means that if the server chooses to accept them, they are to be >> treated as being DTLS. > > I don't think this will work for us. This is data that people use to > flag/report possible new clients they should have known about, existing > clients with changed addresses and plain old configuration errors. I don't see how that relates to what I said. The text doesn't *prevent* you from flagging IP addresses, or warning an admin about packets from those IPs. > It can be a configuration option, done conditionally within the context > protocol disambiguation or even a recommendation but not something > unconditionally required. This is how RADIUS works today. Clients are keyed by known IP. Changing that is not an option for RADIUS/UDP. > Suggest reversing this. Have the client maintain the flag. If DTLS > handshake has succeeded then client uses DTLS from then on for any > inquiries without the option of automatically falling back to UDP. The draft already discusses a flag for the client. > Servers would still maintain flag but it would only be a manually turned > knob to indicate security level it is willing to accept. The draft allows it to me administratively configured. > The more I think about it the more I agree with Joe's points on separate > UDP ports. It is definitely simpler. Alan DeKok. From peterd@iea-software.com Sat Apr 6 09:35:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A8221F8E99 for ; Sat, 6 Apr 2013 09:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-DTeDxITSOh for ; Sat, 6 Apr 2013 09:35:15 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id E270C21F8BF0 for ; Sat, 6 Apr 2013 09:35:14 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sat, 6 Apr 2013 09:35:14 -0700 Date: Sat, 6 Apr 2013 09:35:09 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5160255B.40409@deployingradius.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@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: Sam Hartman , radext-chairs@tools.ietf.org, radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 06 Apr 2013 16:35:15 -0000 On Sat, 6 Apr 2013, Alan DeKok wrote: >> I don't think this will work for us. This is data that people use to >> flag/report possible new clients they should have known about, existing >> clients with changed addresses and plain old configuration errors. > I don't see how that relates to what I said. The text doesn't > *prevent* you from flagging IP addresses, or warning an admin about > packets from those IPs. Requests from unknown IPs by itself is not useful. Normally access to the RADIUS request (NAS-ID) often provides relevant clue. >> It can be a configuration option, done conditionally within the context >> protocol disambiguation or even a recommendation but not something >> unconditionally required. > This is how RADIUS works today. Clients are keyed by known IP. > Changing that is not an option for RADIUS/UDP. The comment above was in context of MUST requirement within text quoted. I'm not arguing the policy.. only MUST is too strong. For example changing to SHOULD would be fine. >> Suggest reversing this. Have the client maintain the flag. If DTLS >> handshake has succeeded then client uses DTLS from then on for any >> inquiries without the option of automatically falling back to UDP. > The draft already discusses a flag for the client. I apologize for any misunderstanding. The migration would be in the client rather than server. They would both have flags but the automatic upgrade with memory to prevent downgrade would be handled at the client. >> Servers would still maintain flag but it would only be a manually >> turned knob to indicate security level it is willing to accept. > The draft allows it to me administratively configured. This appears to be restricted by the current text of the draft. See the following from section 3.1. The server MUST maintain the flag and description of "false" value mandates migration using MUST keyword. "RADIUS/DTLS servers MUST maintain a boolean "DTLS Required" flag for each client that indicates if it requires a client to use RADIUS/DTLS. The interpretation of this flag is as follows. If the flag is "true" then the client supports RADIUS/DTLS, and all packets from that client MUST be processed as RADIUS/DTLS. If the flag is "false", then the client supports RADIUS/UDP, but may still support RADIUS/DTLS. " "Once a RADIUS/DTLS server has established a DTLS session with a client that previously had the flag set to "false", the server MUST set the "DTLS Required" flag to "true". This change requires all subsequent traffic from that client to use DTLS, and prevents bidding-down attacks." regards, Peter From aland@deployingradius.com Sat Apr 6 16:49:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5870B21F8B08 for ; Sat, 6 Apr 2013 16:49:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vay1aLb5YWw9 for ; Sat, 6 Apr 2013 16:49:44 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B37821F8B07 for ; Sat, 6 Apr 2013 16:49:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 43F1A2240D85; Sun, 7 Apr 2013 01:49:43 +0200 (CEST) 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 gbKimf0olgML; Sun, 7 Apr 2013 01:49:40 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 03CC722404EF; Sun, 7 Apr 2013 01:49:39 +0200 (CEST) Message-ID: <5160B492.8040604@deployingradius.com> Date: Sat, 06 Apr 2013 19:49:38 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515EDBB8.2020101@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 06 Apr 2013 23:49:45 -0000 Peter Deacon wrote: >> Uh... they declared that RADIUS/UDP packets were acceptable. The DTLS >> flag is for *new* traffic. > > It makes a decision for the operator by assuming past configuration is > still desired or applicable. The point of a specification is to do exactly that: mandate good decisions where the local admin may make bad ones. >> It makes no sense to send RADIUS/UDP packets, and then ignore the >> responses because DTLS is now required. > > When switching to DTLS clients may no longer be capable or willing to > touch RADIUS/UDP. I'm not arguing against the behavior. I just think > the MUST requirement is too strong. You're very concerned about miscommunication for idle timeouts, but you're unconcerned with miscommunication here. I'm not sure why. > At some point the operator would have had to update firmware or software > taking the system offline to obtain RADIUS/DTLS functionality. These > kinds of things are handled normally within a planned maintenance window. There is no requirement to *use* DTLS when you upgrade the firmware. Allowing for a gradual migration path is good, in my opinion. > As draft points out in section 10.3 this automatic scheme causes > breakage while there are multiple clients behind a single IP. Which is not supported by RADIUS/UDP. This document isn't the place to standardize that behavior. > When just > one of them upgrades all other clients break causing network outage and > potential loss of revenue. The simple manual server knobs without > migration behavior in this case prevents migration from *causing* an > outage. If people aren't following the specs, then they're responsible for breaking their own networks. I don't have a lot of sympathy here. > Having thought about this a bit more perhaps it would be better simply > to move migration procedure from server to client. This would fix NAT > problems and server "flag" would only be used to declare level of > security it is willing to accept. That results in down-bidding attacks from the clients, which won't pass a security review. > The main reason I see a need to use heartbeats is to thread the needle > keeping UDP NAT associations from expiring, letting servers know our > session is not forgotten and detecting session termination. None of > these concerns apply to RADIUS/UDP. If you're going to run multiple RADIUS clients behind one NAT, you're not really doing RADIUS. > I would be happy if DTLS heartbeats were able to reset server idle > timeout. Thats all I want. OK. > In my view the only "application layer" thing that works for purpose of > determining useful overall systems availability is still passive > observation of response to client requests in the spirit of RFC 2865. Using Status-Server is a reasonable substitute. Especially when (as you say) the client may not be sending "normal" packets for long periods of time. Alan DeKok. From aland@deployingradius.com Sat Apr 6 17:02:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43E1921F8B96 for ; Sat, 6 Apr 2013 17:02:17 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJZ+xMX39zcm for ; Sat, 6 Apr 2013 17:02:16 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9918F21F8B64 for ; Sat, 6 Apr 2013 17:02:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A9AF02240D85; Sun, 7 Apr 2013 02:02:16 +0200 (CEST) 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 JoMhJHqKHXxU; Sun, 7 Apr 2013 02:02:15 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 1BF812240D25; Sun, 7 Apr 2013 02:02:14 +0200 (CEST) Message-ID: <5160B785.8070703@deployingradius.com> Date: Sat, 06 Apr 2013 20:02:13 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , radext-chairs@tools.ietf.org, radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 07 Apr 2013 00:02:17 -0000 Peter Deacon wrote: > Requests from unknown IPs by itself is not useful. Normally access to > the RADIUS request (NAS-ID) often provides relevant clue. That's not part of standard RADIUS. If you have a proprietary extension, you're responsible for ensuring it works. The IETF isn't. > I apologize for any misunderstanding. The migration would be in the > client rather than server. They would both have flags but the automatic > upgrade with memory to prevent downgrade would be handled at the client. That won't pass security review. Having the server *also* handle client upgrade is a hard requirement. >>> Servers would still maintain flag but it would only be a manually >>> turned knob to indicate security level it is willing to accept. > >> The draft allows it to me administratively configured. > > This appears to be restricted by the current text of the draft. See the > following from section 3.1. The server MUST maintain the flag and > description of "false" value mandates migration using MUST keyword. Quoting the text isn't helpful. I'm sure I've read it. The rest of the draft says: The "DTLS Required" flag MUST be exposed to administrators of the server. As clients are upgraded, administrators can then manually mark them as using RADIUS/DTLS. The "automatic" upgrade path is one which doesn't require administrator intervention. However, it doesn't *prevent* admins from manually forcing a client to do DTLS. Alan DeKok. From tomasz.mrugalski@gmail.com Fri Apr 5 07:16:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B3A21F97C8; Fri, 5 Apr 2013 07:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxdYCeV7FmLb; Fri, 5 Apr 2013 07:16:50 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CBE3A21F97AA; Fri, 5 Apr 2013 07:16:49 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so1426403eaj.21 for ; Fri, 05 Apr 2013 07:16:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=kvcUpe8OcUbg1yBLu9s1lOZPNi1097CCwuuR9Rfsni8=; b=fl3te9NBPUQ+By30DCqMFnNw/MnAimVQUd7SXxPrkW1syNILVHe5+g8/+NbIzdyfgu 5OspbDc2CVdauRCSxLtq/JqheeHwz6wd+JhdXy+bKkD3B7khn9ZC9P49uKpTEwjB+/3O eaHupdKhfX8o+tnfpg2LLBmXRSmm2XlGcsPC7ICbuuxg9pO7rwYhGR3AZyH+gsASx9UW ZqsRJ9R0gmN7uDsjPy9s8gGX2jxPnsjwgBSMAW78dHFqHUdJc64DW7RkAvJMm6eCN2mM JAMEZtrs31pPuLB+LTPVMYr4UQmvSwSEGlkp+jUD/bb9Zly82rm12YJo9f6n/8m2ObbE ioMA== X-Received: by 10.14.179.5 with SMTP id g5mr19998420eem.41.1365171408917; Fri, 05 Apr 2013 07:16:48 -0700 (PDT) Received: from ?IPv6:2001:470:6061:1:887e:68e1:7d5e:1422? ([2001:470:6061:1:887e:68e1:7d5e:1422]) by mx.google.com with ESMTPS id d47sm15705304eem.9.2013.04.05.07.16.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 05 Apr 2013 07:16:44 -0700 (PDT) Message-ID: <515EDCC7.5010708@gmail.com> Date: Fri, 05 Apr 2013 16:16:39 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130405161639166 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 07 Apr 2013 10:11:38 -0700 Cc: "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 05 Apr 2013 14:16:50 -0000 On 05.04.2013 15:12, Ted Lemon wrote: > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen > wrote: >> Blindly dropping an attribute might not work in all cases. For >> example, in some cases the server might not then be able to provide >> all information the relay needs.. > > Well, I did say "silently ignored," not "dropped," but yeah. If the > server doesn't support that attribute, it's not going to have any > effect anyway. It seems like silently ignoring it is better than > dropping the whole message, although I suppose you could argue the > opposite, since a misconfiguration of this sort is probably something > the administrator wants to fix immediately, not discover by accident > years later. Anyway, dropping the whole message is definitely too radical here. We have 3 options when server receives an unknown attribute: a) ignore just the unknown attribute b) ignore the whole radius option c) ignore the whole message I think we have an agreement that a) is the way to go. At least that's what I strongly recommend. Also, depending on server implementation, it is quite likely that the server will parse unknown attributes and handle them in some generic way, e.g. hex string. This is what some implementations do with unknown DHCPv6 options and I imagine similar approach can be taken with RADIUS attributes. Of course, such a behaviour is strictly implementation specific, so there's no need to put anything about it in the spec. So whether the attribute is "unknown" or not may be a bit blurry definition sometimes. "Server MAY ignore received RADIUS attributes that it does not support." seems like a reasonable text here. Some implementors will ignore unknown attribute, some may produce a warning and some my try to handle it in a generic way. Tomek From bingxuere@gmail.com Sun Apr 7 18:12:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4586F21F902B for ; Sun, 7 Apr 2013 18:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.184 X-Spam-Level: X-Spam-Status: No, score=-1.184 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PilLXpClet0z for ; Sun, 7 Apr 2013 18:12:51 -0700 (PDT) Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) by ietfa.amsl.com (Postfix) with ESMTP id 795DB21F9029 for ; Sun, 7 Apr 2013 18:12:51 -0700 (PDT) Received: by mail-vc0-f181.google.com with SMTP id ia10so656995vcb.12 for ; Sun, 07 Apr 2013 18:12:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:from:date:message-id:subject:to :content-type; bh=yODqg/r0qWv+ZhPqvkX1yfv93IDnL1M7e3CY9h4DftA=; b=OQVCO4+Tnd8/LQdj8uAffN+k7VIykmmdnrUaGssNrBFSKUjGoE7AQoIsZs9LpRbC4A UUOONvPpIk5Lw5XxWwogljt/XdgEq7UaBqMMP/7uLPQjkeCJyOIsriGbpWSH78xfP3fH 8wdIQL6Z9HVANoDW2oPt45SnW0uhjSgx0UoKTYMVU7FthYdYA8Z6dzPDs9XdzGlm1aXU DYiG0iMPGe30FbsaQ0zMLyNa5sDJH4gZGsTT9ADjo4GipvlQlCmlW0BYla4cXbF7kFOW 2SFLx8thee1Yk8irAMhwBFI9/Nn5h9ewKLoyLS70SNe7cOeOfoahltqwRU2axLZJRWzh UULQ== X-Received: by 10.58.96.40 with SMTP id dp8mr14376385veb.41.1365383570842; Sun, 07 Apr 2013 18:12:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.224.133 with HTTP; Sun, 7 Apr 2013 18:12:10 -0700 (PDT) From: Qiong Date: Mon, 8 Apr 2013 09:12:10 +0800 Message-ID: To: hartmans@painless-security.com, radext@ietf.org, Xueli Content-Type: multipart/alternative; boundary=089e01229c8ab8f6ce04d9cf22d3 Subject: Re: [radext] FW: New Version Notification for >>draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 01:12:52 -0000 --089e01229c8ab8f6ce04d9cf22d3 Content-Type: text/plain; charset=UTF-8 Hi Sam, We are deploying this use case in our network, where BRAS are doing unified user authentication for both broadband access user and WLAN users. This is for simple user management, authentication, etc. Hope it clarifies. >> >> Xueli> Actually, the issue is when the authenticator is in access >> Xueli> router instead of AC, the PMK should be announced to AC. >> >>What is the use case for putting the authenticator in the access router >>rather than an access point controller? Best wishes Qiong -- ============================================== Qiong Sun China Telecom Beijing Research Institude Open source code: lightweight 4over6: *http://sourceforge.net/projects/laft6/* PCP-natcoord:* http://sourceforge.net/projects/pcpportsetdemo/ * =============================================== --089e01229c8ab8f6ce04d9cf22d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sam,

We= are deploying this use case in our network, where BRAS are doing unified u= ser authentication for both broadband access user and WLAN users. This is f= or simple user management, authentication, etc. Hope it clarifies.
>>
>>=C2=A0=C2=A0=C2=A0=C2=A0Xueli>=C2=A0Actually,=C2=A0the=C2= =A0issue=C2=A0is=C2=A0when=C2=A0the=C2=A0authenticator=C2=A0is=C2=A0in=C2= =A0access
>>=C2=A0=C2=A0=C2=A0=C2=A0Xueli>=C2=A0router=C2=A0instead=C2= =A0of=C2=A0AC,=C2=A0the=C2=A0PMK=C2=A0should=C2=A0be=C2=A0announced=C2=A0to= =C2=A0AC.
>>
>>What=C2=A0is=C2=A0the=C2=A0use=C2=A0case=C2=A0for=C2=A0putting= =C2=A0the=C2=A0authenticator=C2=A0in=C2=A0the=C2=A0access=C2=A0router
>>rather=C2=A0than=C2=A0an=C2=A0access=C2=A0point=C2=A0controlle= r?

Best wishes
Qiong


--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Qiong Sun
China Telecom Beijing Research Institude


Open source code:
li= ghtweight 4over6: http://sourceforge.net/projects/laft6/
PCP-natcoo= rd: http://sourceforge.net/projects/pcpportsetdemo/
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--089e01229c8ab8f6ce04d9cf22d3-- From xueli@huawei.com Sun Apr 7 18:14:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099E521F9029 for ; Sun, 7 Apr 2013 18:14:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGlarpqa71NP for ; Sun, 7 Apr 2013 18:14:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0D5921F9026 for ; Sun, 7 Apr 2013 18:14:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQD68818; Mon, 08 Apr 2013 01:14:21 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 02:13:57 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 02:14:20 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Mon, 8 Apr 2013 09:14:13 +0800 From: Xueli To: Sam Hartman Thread-Topic: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt Thread-Index: AQHOLvr1OTSG7yr9c0iZOcBFFpnzXJjLiWMw Date: Mon, 8 Apr 2013 01:14:13 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B4482A43B5@NKGEML512-MBS.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> <515596D8.1000209@restena.lu> <01FE63842C181246BBE4CF183BD159B4482A1FAE@NKGEML512-MBS.china.huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stefan Winter , sunqiong , "radext@ietf.org" Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 01:14:26 -0000 Hi Sam I apologize for late reply.. Actually, in real network, the location of the authenticator is based on th= e network status and operator's requirement. There are two reasons to deploy authenticator function on AR rather than AC= . 1 AC is simple entity for WTP management. AC isn't intelligent enough to ag= gregated the user/subscriber management in one.=20 Consequently, It is a popular scenario to split the authentication function= from AC to GW, which is the existing authentication gateway for other serv= ice, such as PPP, etc.=20 This enables a better environment that diminishes the software and hardware= upgrade for operator. 2 If GW is the convergence device for all kinds of users charging, it is ea= sy for network operation and service management. =20 Even more, in this scenario, the user address is assigned on GW, it is prop= itious to address management. In this case, the key issue must be considered.=20 BR Li =20 >-----Original Message----- >From: Sam Hartman [mailto:hartmans@painless-security.com] >Sent: Tuesday, April 02, 2013 1:04 AM >To: Xueli >Cc: Stefan Winter; radext@ietf.org >Subject: Re: [radext] FW: New Version Notification for >draft-xue-radext-key-management-00.txt > >>>>>> "Xueli" =3D=3D Xueli writes: > > > Xueli> Actually, the issue is when the authenticator is in access > Xueli> router instead of AC, the PMK should be announced to AC. > >What is the use case for putting the authenticator in the access router >rather than an access point controller? From peterd@iea-software.com Sun Apr 7 21:23:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3F21F8A40 for ; Sun, 7 Apr 2013 21:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.537 X-Spam-Level: X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 42sMH9Lt2vRY for ; Sun, 7 Apr 2013 21:23:52 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id ABF7221F8AA8 for ; Sun, 7 Apr 2013 21:23:52 -0700 (PDT) Received: from littlesmurf (unverified [10.0.1.18]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 7 Apr 2013 21:23:52 -0700 Date: Sun, 7 Apr 2013 21:23:52 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5160B785.8070703@deployingradius.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Sam Hartman , radext-chairs@tools.ietf.org, "radext@ietf.org" Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 04:23:53 -0000 On Sat, 6 Apr 2013, Alan DeKok wrote: > Peter Deacon wrote: >> Requests from unknown IPs by itself is not useful. Normally access to >> the RADIUS request (NAS-ID) often provides relevant clue. > That's not part of standard RADIUS. If you have a proprietary > extension, you're responsible for ensuring it works. The IETF isn't. What "proprietary extension" is required to log incoming requests? >> I apologize for any misunderstanding. The migration would be in the >> client rather than server. They would both have flags but the automatic >> upgrade with memory to prevent downgrade would be handled at the client. > That won't pass security review. Having the server *also* handle > client upgrade is a hard requirement. What is the goal of migration procedure? This is essentially a simplified form of TLS cipher negotiation. TLS clients communicate a list of acceptable ciphers. TLS servers check server list against the client list. If there are no mutually acceptable ciphers TLS handshake fails. If there are multiple acceptable ciphers there is no hysteresis requirement in TLS to further constrain mutually acceptable cipher lists of subsequent sessions between peers. Lets examine the complete matrix of options for RADIUS/UDP vs RADIUS/DTLS clients and servers. Possible client options: Request sent using RADIUS/UDP or RADIUS/DTLS Possible server options: Server accepts RADIUS/UDP only, RADIUS/DTLS only or RADIUS/UDP and RADIUS/DTLS. Client Server Result ---------------- -------------------- ---------------------- RADIUS/UDP UDP only Success - RADIUS/UDP RADIUS/UDP UDP or DTLS Success - RADIUS/UDP RADIUS/UDP DTLS only Fail RADIUS/DTLS UDP only Fail RADIUS/DTLS UDP or DTLS Success - RADIUS/DTLS RADIUS/DTLS DTLS only Success - RADIUS/DTLS If RADIUS server chooses to indicate support for UDP and DTLS the client is able to upgrade to DTLS at any time without server coordination. If the RADIUS server chooses to indicate support for DTLS only then only DTLS connections are accepted. The only necessary reason for migration flag is to enable RADIUS/UDP and RADIUS/DTLS capable clients to automatically probe server to see if it supports RADIUS/DTLS. Section 4 strongly discourages this behavior: "RADIUS/DTLS clients SHOULD NOT probe servers to see if they support DTLS transport. Doing so would cause servers to immediately require that all new packets from the client use DTLS. This requirement may be difficult for a client to satisfy. Instead, clients SHOULD use DTLS as a transport layer only when administratively configured." Further I would argue this must NOT be allowed as RADIUS/DTLS capable clients would then be sending non RADIUS/UDP messages to RFC 2865 compliant servers. I believe the bar should at least be client knob to indicate server supports RADIUS/DTLS to minimize RFC 2865 compliant servers from receiving non-RFC 2865 compliant messages. With regards to the security review claim the migration concept is susceptible to trivial MITM in the network path simply by filtering out the more secure (DTLS) messages. Whether it is the client that does it or the server makes no difference. This scheme is insecure either way. >>>> Servers would still maintain flag but it would only be a manually >>>> turned knob to indicate security level it is willing to accept. >>> The draft allows it to me administratively configured. >> >> This appears to be restricted by the current text of the draft. See the >> following from section 3.1. The server MUST maintain the flag and >> description of "false" value mandates migration using MUST keyword. > Quoting the text isn't helpful. I'm sure I've read it. > The rest of the draft says: > The "DTLS Required" flag MUST be exposed to administrators of the > server. As clients are upgraded, administrators can then manually > mark them as using RADIUS/DTLS. The problem is servers would not have the option of turning off the automatic migration behavior. Side effect of this is that multiple clients behind a single IP can not use a mix of UDP and DTLS concurrently. regards, Peter From hartmans@painless-security.com Sun Apr 7 21:49:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC9821F8DCF for ; Sun, 7 Apr 2013 21:49:26 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76CXVJfbcBIw for ; Sun, 7 Apr 2013 21:49:25 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8B74521F8F06 for ; Sun, 7 Apr 2013 21:49:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 939D52034E; Mon, 8 Apr 2013 00:48:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B140A4499; Mon, 8 Apr 2013 00:49:23 -0400 (EDT) From: Sam Hartman To: Xueli References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> <515596D8.1000209@restena.lu> <01FE63842C181246BBE4CF183BD159B4482A1FAE@NKGEML512-MBS.china.huawei.com> <01FE63842C181246BBE4CF183BD159B4482A43B5@NKGEML512-MBS.china.huawei.com> Date: Mon, 08 Apr 2013 00:49:23 -0400 In-Reply-To: <01FE63842C181246BBE4CF183BD159B4482A43B5@NKGEML512-MBS.china.huawei.com> (xueli@huawei.com's message of "Mon, 8 Apr 2013 01:14:13 +0000") 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: Stefan Winter , sunqiong , "radext@ietf.org" Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 04:49:26 -0000 I'm sorry, but your explanation doesn't make sense to me. So far I haven't seen sufficient support (really any support) for considering your draft. I think that you're going to need to a lot more work in terms of describing your use case before we're even going to be able to understand it. From xueli@huawei.com Sun Apr 7 23:43:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B780421F92E8 for ; Sun, 7 Apr 2013 23:43:39 -0700 (PDT) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lv9ojRyraxB4 for ; Sun, 7 Apr 2013 23:43:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EC91B21F92DC for ; Sun, 7 Apr 2013 23:43:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQD88160; Mon, 08 Apr 2013 06:43:35 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 07:43:08 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 8 Apr 2013 07:43:31 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.01.0323.007; Mon, 8 Apr 2013 14:43:29 +0800 From: Xueli To: Sam Hartman Thread-Topic: [radext] FW: New Version Notification for >>draft-xue-radext-key-management-00.txt Thread-Index: AQHOM/Y2F9bvffHn6E21RqH9PziIeJjL0DQQ Date: Mon, 8 Apr 2013 06:43:27 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B4482A46AD@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.95] Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B4482A46ADNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Stefan Winter , sunqiong , "radext@ietf.org" Subject: [radext] FW: FW: New Version Notification for >>draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2013 06:43:39 -0000 --_000_01FE63842C181246BBE4CF183BD159B4482A46ADNKGEML512MBSchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU2FtDQoNCg0KDQpJbiBtb3N0IGJ1c2luZXNzIHN5c3RlbXMsIEFSKEdXL0JSQVMpIGhhcyBi ZWVuIHNlbGVjdGVkIHRvIHBlcmZvcm0gdGhlIFBvcnRhbC9XZWIgQXV0aGVudGljYXRpb24uDQoN ClNvIGlmIHdlIHdhbnQgdG8gaW50cm9kdWNlIEVBUCBhdXRoZW50aWNhdG9yIGludG8gYSBuZXR3 b3JrIGZvciB0aGUgbW9iaWxlIHVzZXIgYXV0aGVudGljYXRpb24uDQoNCkZvciB1cywgaXQgaXMg ZWFzaWVyIGFuZCBtb3JlIGVmZmljaWVudCB0byBkZXBsb3kgdGhpcyBBdXRoZW50aWNhdG9yIGZ1 bmN0aW9uIG9uIHRoZSBleGlzdGluZyBBUiAoR1cvQlJBUykuDQoNCg0KDQpUaGUgcmVhc29ucyBh cmUgbGlzdGVkIGFzIGZvbGxvd3M6DQoNCg0KDQoxIFRoZSBleGlzdGluZyBBUiBoYXMgZWZmaWNp ZW50IGhhcmR3YXJlIHJlc291cmNlcyB0byBzdXBwb3J0IEVBUCBhdXRoZW50aWNhdGlvbiwgc28g dGhhdCB3ZSBjYW4ganVzdCB1cGRhdGUgdGhlIHNvZnR3YXJlIHN5c3RlbXMuDQoNCg0KDQoyIElu IG1hbnkgbmV0d29ya3MgdGhlIEFDIGlzIHNpbXBsZSBhbmQgY2Fu4oCZdCBzdXBwb3J0IEVBUCBm dW5jdGlvbi4gSWYgd2Ugd2FudCB0byBkZXBsb3kgdGhlIEVBUCBhdXRoZW50aWNhdGlvbiBpbiBB QywNCg0Kd2UgbmVlZCB0byBjaGFuZ2UgdGhlIGRldmljZXMgd2hpY2ggaXMgdW5kZXNpcmVkIHRv IG1hbnkgb3BlcmF0b3JzLg0KDQoNCg0KT2YgY291cnNlLCB3ZSBhbHNvIGJlbGlldmUgaXQgaXMg b25lIG9wdGlvbiB0byBkZXBsb3kgQXV0aGVudGljYXRvciBpbiBBQy4gIEJ1dCB3ZSB3YW50IHRv IGFyZ3VlLCBvdXIgc29sdXRpb24gaGFzIGl0cyBhZHZhbnRhZ2UgaW4gc29tZSBzY2VuYXJpb3Mu DQoNCg0KDQpSZWdhcmRzDQoNCkxpDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQoNCj5Gcm9tOiBTYW0gSGFydG1hbiBbbWFpbHRvOmhhcnRtYW5zQHBh aW5sZXNzLXNlY3VyaXR5LmNvbV0NCg0KPlNlbnQ6IE1vbmRheSwgQXByaWwgMDgsIDIwMTMgMTI6 NDkgUE0NCg0KPlRvOiBYdWVsaQ0KDQo+Q2M6IFN0ZWZhbiBXaW50ZXI7IHN1bnFpb25nOyByYWRl eHRAaWV0Zi5vcmcNCg0KPlN1YmplY3Q6IFJlOiBbcmFkZXh0XSBGVzogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvcg0KDQo+ZHJhZnQteHVlLXJhZGV4dC1rZXktbWFuYWdlbWVudC0wMC50eHQN Cg0KPg0KDQo+SSdtIHNvcnJ5LCBidXQgeW91ciBleHBsYW5hdGlvbiBkb2Vzbid0IG1ha2Ugc2Vu c2UgdG8gbWUuICBTbyBmYXIgSQ0KDQo+aGF2ZW4ndCBzZWVuIHN1ZmZpY2llbnQgc3VwcG9ydCAo cmVhbGx5IGFueSBzdXBwb3J0KSBmb3IgY29uc2lkZXJpbmcNCg0KPnlvdXIgZHJhZnQuICBJIHRo aW5rIHRoYXQgeW91J3JlIGdvaW5nIHRvIG5lZWQgdG8gYSBsb3QgbW9yZSB3b3JrIGluDQoNCj50 ZXJtcyBvZiBkZXNjcmliaW5nIHlvdXIgdXNlIGNhc2UgYmVmb3JlIHdlJ3JlIGV2ZW4gZ29pbmcg dG8gYmUgYWJsZSB0bw0KDQo+dW5kZXJzdGFuZCBpdC4NCg0K --_000_01FE63842C181246BBE4CF183BD159B4482A46ADNKGEML512MBSchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVu dC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0i R2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+ DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250 LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAx O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC41cHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5DaGFyDQoJe21zby1zdHlsZS1uYW1lOiLnuq/m lofmnKwgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOue6 r+aWh+acrDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQg OTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5IaSBTYW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkluIG1vc3QgYnVzaW5l c3Mgc3lzdGVtcywgQVIoR1cvQlJBUykgaGFzIGJlZW4gc2VsZWN0ZWQgdG8gcGVyZm9ybSB0aGUg UG9ydGFsL1dlYiBBdXRoZW50aWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+U28gaWYgd2Ugd2FudCB0byBpbnRy b2R1Y2UgRUFQIGF1dGhlbnRpY2F0b3IgaW50byBhIG5ldHdvcmsgZm9yIHRoZSBtb2JpbGUgdXNl ciBhdXRoZW50aWNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIHVzLCBpdCBpcyBlYXNpZXIgYW5kIG1vcmUg ZWZmaWNpZW50IHRvIGRlcGxveSB0aGlzIEF1dGhlbnRpY2F0b3IgZnVuY3Rpb24gb24gdGhlIGV4 aXN0aW5nIEFSIChHVy9CUkFTKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSByZWFzb25z IGFyZSBsaXN0ZWQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjEgVGhlIGV4 aXN0aW5nIEFSIGhhcyBlZmZpY2llbnQgaGFyZHdhcmUgcmVzb3VyY2VzIHRvIHN1cHBvcnQgRUFQ IGF1dGhlbnRpY2F0aW9uLCBzbyB0aGF0IHdlIGNhbiBqdXN0IHVwZGF0ZSB0aGUgc29mdHdhcmUg c3lzdGVtcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjIgSW4gbWFueSBuZXR3b3JrcyB0aGUg QUMgaXMgc2ltcGxlIGFuZCBjYW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+4oCZPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIj50IHN1cHBvcnQgRUFQIGZ1bmN0aW9uLiBJZiB3ZSB3YW50IHRvIGRlcGxveSB0aGUgRUFQ IGF1dGhlbnRpY2F0aW9uIGluIEFDLA0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPndlIG5lZWQgdG8gY2hhbmdlIHRoZSBk ZXZpY2VzIHdoaWNoIGlzIHVuZGVzaXJlZCB0byBtYW55IG9wZXJhdG9ycy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g bGFuZz0iRU4tVVMiPk9mIGNvdXJzZSwgd2UgYWxzbyBiZWxpZXZlIGl0IGlzIG9uZSBvcHRpb24g dG8gZGVwbG95IEF1dGhlbnRpY2F0b3IgaW4gQUMuICZuYnNwO0J1dCB3ZSB3YW50IHRvIGFyZ3Vl LCBvdXIgc29sdXRpb24gaGFzIGl0cyBhZHZhbnRhZ2UgaW4gc29tZSBzY2VuYXJpb3MuDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+TGk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOnJlZCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpyZWQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0O0Zyb206IFNhbSBIYXJ0bWFu IFttYWlsdG86aGFydG1hbnNAcGFpbmxlc3Mtc2VjdXJpdHkuY29tXTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7U2Vu dDogTW9uZGF5LCBBcHJpbCAwOCwgMjAxMyAxMjo0OSBQTTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7VG86IFh1ZWxp PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZndDtDYzogU3RlZmFuIFdpbnRlcjsgc3VucWlvbmc7IHJhZGV4dEBpZXRmLm9y ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7U3ViamVjdDogUmU6IFtyYWRleHRdIEZXOiBOZXcgVmVyc2lvbiBOb3Rp ZmljYXRpb24gZm9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtkcmFmdC14dWUtcmFkZXh0LWtleS1tYW5hZ2VtZW50 LTAwLnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDtJJ20gc29ycnksIGJ1dCB5 b3VyIGV4cGxhbmF0aW9uIGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBtZS4mbmJzcDsgU28gZmFyIEk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5n PSJFTi1VUyI+Jmd0O2hhdmVuJ3Qgc2VlbiBzdWZmaWNpZW50IHN1cHBvcnQgKHJlYWxseSBhbnkg c3VwcG9ydCkgZm9yIGNvbnNpZGVyaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDt5b3VyIGRyYWZ0LiZuYnNwOyBJ IHRoaW5rIHRoYXQgeW91J3JlIGdvaW5nIHRvIG5lZWQgdG8gYSBsb3QgbW9yZSB3b3JrIGluPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPiZndDt0ZXJtcyBvZiBkZXNjcmliaW5nIHlvdXIgdXNlIGNhc2UgYmVmb3JlIHdlJ3Jl IGV2ZW4gZ29pbmcgdG8gYmUgYWJsZSB0bzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7dW5kZXJzdGFuZCBpdC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_01FE63842C181246BBE4CF183BD159B4482A46ADNKGEML512MBSchi_-- From jouni.nospam@gmail.com Mon Apr 8 00:31:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D4321F854F; Mon, 8 Apr 2013 00:31:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.845 X-Spam-Level: X-Spam-Status: No, score=-1.845 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D+nKkf4aa9hk; Mon, 8 Apr 2013 00:31:54 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 63FEC21F854E; Mon, 8 Apr 2013 00:31:53 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fo12so193396lab.24 for ; Mon, 08 Apr 2013 00:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:message-id:mime-version:subject:date :references:cc:to:x-mailer; bh=REYLf+RVW0n4IVeE5Y10fQF/jLokEVSbRIR02KY5D/8=; b=y52loBgEfe88ygg3xp8JamVlOvBGKCXmsyXyqubMMC5RtzsjQOIDHSRDFa/JBo8zO8 p7QleBbj86XOyjPctjkmIElGYfYC0zQmnHf+g6KSw7sSoIiENyjwkqkaBLoC9uDDyo0C rjyz4UtNvmx0jG9oLOIxaaEUd9op9g38Gw+s1qntiyotiB2Dy8prQQ+jr/9dVtuz9Fas KiTG4Qrk9AcyP+7njedIoGLPlNsutf89yYRCihUJXpBA45gpCczXQf+vojKqJ5nSQiCc 7XeAQV0nd655Bi94GIK8eyRD8Orriy2TooaEG4zwjnphCwvgKv37BC+rw5Zf1DIahwrL JqCA== X-Received: by 10.152.109.112 with SMTP id hr16mr11171361lab.38.1365406312282; Mon, 08 Apr 2013 00:31:52 -0700 (PDT) Received: from [192.168.250.228] ([194.100.71.98]) by mx.google.com with ESMTPS id c7sm10136147lbe.6.2013.04.08.00.31.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 00:31:50 -0700 (PDT) From: Jouni Korhonen Content-Type: multipart/alternative; boundary="Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Date: Mon, 8 Apr 2013 10:31:49 +0300 References: To: "" X-Mailer: Apple Mail (2.1503) Cc: dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 08 Apr 2013 07:31:54 -0000 --Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Seems that I forgot to CC mailing lists. - Jouni Begin forwarded message: > From: jouni korhonen > Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > Date: April 5, 2013 7:37:47 PM GMT+03:00 > To: Tomek Mrugalski >=20 >=20 > 5.4.2013 17.16 "Tomek Mrugalski" = kirjoitti: > > > > On 05.04.2013 15:12, Ted Lemon wrote: > > > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen = > > > wrote: > > >> Blindly dropping an attribute might not work in all cases. For > > >> example, in some cases the server might not then be able to = provide > > >> all information the relay needs.. > > > > > > Well, I did say "silently ignored," not "dropped," but yeah. If = the > > > server doesn't support that attribute, it's not going to have any > > > effect anyway. It seems like silently ignoring it is better than > > > dropping the whole message, although I suppose you could argue the > > > opposite, since a misconfiguration of this sort is probably = something > > > the administrator wants to fix immediately, not discover by = accident > > > years later. > > Anyway, dropping the whole message is definitely too radical here. = We >=20 > I was not suggesting dropping the message. I said "blindly dropping an = attribute".. which is somewhat different. I am fine with a) but my point = was that it is possible in future when new attributes get added to = registry server silently discarding attributes may lead to a situation = where the server fails to provide enough information back to relay. This = needs to be taken into account when defining DHCP extensions relying on = this I-D and the established registry. >=20 > Jouni >=20 > > have 3 options when server receives an unknown attribute: > > a) ignore just the unknown attribute > > b) ignore the whole radius option > > c) ignore the whole message > > > > I think we have an agreement that a) is the way to go. At least = that's > > what I strongly recommend. > > > > Also, depending on server implementation, it is quite likely that = the > > server will parse unknown attributes and handle them in some generic > > way, e.g. hex string. This is what some implementations do with = unknown > > DHCPv6 options and I imagine similar approach can be taken with = RADIUS > > attributes. Of course, such a behaviour is strictly implementation > > specific, so there's no need to put anything about it in the spec. > > So whether the attribute is "unknown" or not may be a bit blurry > > definition sometimes. > > > > "Server MAY ignore received RADIUS attributes that it does not = support." > > seems like a reasonable text here. Some implementors will ignore = unknown > > attribute, some may produce a warning and some my try to handle it = in a > > generic way. > > > > Tomek > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www.ietf.org/mailman/listinfo/dhcwg --Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Seems = that I forgot to CC mailing lists.

- = Jouni

Begin forwarded message:

From: jouni korhonen = <jouni.nospam@gmail.com>
<= /span>
Subject: Re: [dhcwg] [radext] = draft-ietf-dhc-dhcpv6-radius-opt-10
Date: April 5, 2013 = 7:37:47 PM GMT+03:00
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com&= gt;


5.4.2013 17.16 "Tomek Mrugalski" <tomasz.mrugalski@gmail.com&= gt; kirjoitti:
>
> On 05.04.2013 15:12, Ted Lemon wrote:
> > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <jouni.nospam@gmail.com>
> > wrote:
> >> Blindly dropping an attribute might not work in all cases. = For
> >> example, in some cases the server might not then be able = to provide
> >> all information the relay needs..
> >
> > Well, I did say "silently ignored," not "dropped," but yeah. =   If the
> > server doesn't support that attribute, it's not going to have = any
> > effect anyway.   It seems like silently ignoring it is = better than
> > dropping the whole message, although I suppose you could argue = the
> > opposite, since a misconfiguration of this sort is probably = something
> > the administrator wants to fix immediately, not discover by = accident
> > years later.
> Anyway, dropping the whole message is definitely too radical here. = We

I was not suggesting dropping the message. I said = "blindly dropping an attribute".. which is somewhat different. I am fine = with a) but my point was that it is possible in future when new = attributes get added to registry server silently discarding attributes = may lead to a situation where the server fails to provide enough = information back to relay. This needs to be taken into account when = defining DHCP extensions relying on this I-D and the established = registry.

Jouni

> have 3 options = when server receives an unknown attribute:
> a) ignore just the unknown attribute
> b) ignore the whole radius option
> c) ignore the whole message
>
> I think we have an agreement that a) is the way to go. At least = that's
> what I strongly recommend.
>
> Also, depending on server implementation, it is quite likely that = the
> server will parse unknown attributes and handle them in some = generic
> way, e.g. hex string. This is what some implementations do with = unknown
> DHCPv6 options and I imagine similar approach can be taken with = RADIUS
> attributes. Of course, such a behaviour is strictly = implementation
> specific, so there's no need to put anything about it in the = spec.
> So whether the attribute is "unknown" or not may be a bit = blurry
> definition sometimes.
>
> "Server MAY ignore received RADIUS attributes that it does not = support."
> seems like a reasonable text here. Some implementors will ignore = unknown
> attribute, some may produce a warning and some my try to handle it = in a
> generic way.
>
> Tomek
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/= mailman/listinfo/dhcwg


= --Apple-Mail=_81739F0B-8294-4C23-9DF4-B0A1970E30EA-- From trac+radext@trac.tools.ietf.org Mon Apr 8 01:07:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D50421F9322 for ; Mon, 8 Apr 2013 01:07:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U91YKf9B2gIX for ; Mon, 8 Apr 2013 01:07:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id F013721F9321 for ; Mon, 8 Apr 2013 01:07:35 -0700 (PDT) Received: from localhost ([127.0.0.1]:49875 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1UP76x-0002Df-Ky; Mon, 08 Apr 2013 10:07:32 +0200 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, jouni.nospam@gmail.com X-Trac-Project: radext Date: Mon, 08 Apr 2013 08:07:31 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/149#comment:1 Message-ID: <074.93e0863859c8c0e1a10285da73246afd@trac.tools.ietf.org> References: <059.ad1c3a15fdae56f93fecef9b0fcb1ac6@trac.tools.ietf.org> X-Trac-Ticket-ID: 149 In-Reply-To: <059.ad1c3a15fdae56f93fecef9b0fcb1ac6@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, jouni.nospam@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 Resent-To: aland@freeradius.org Resent-Message-Id: <20130408080735.F013721F9321@ietfa.amsl.com> Resent-Date: Mon, 8 Apr 2013 01:07:35 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #149: Multiplexing secure and insecure on the same port 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, 08 Apr 2013 08:07:36 -0000 #149: Multiplexing secure and insecure on the same port Changes (by jouni.nospam@gmail.com): * owner: => draft-ietf-radext-dtls@tools.ietf.org * component: RDTLS => dtls Comment: Changed the ticket from RDTLS to DTLS so that it is tracked on the correct document. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: dtls | Version: Severity: In WG Last | Resolution: Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From hartmans@painless-security.com Mon Apr 8 06:21:59 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B467621F9412 for ; Mon, 8 Apr 2013 06:21:59 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyg9jzVcd-6k for ; Mon, 8 Apr 2013 06:21:59 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1C35521F9409 for ; Mon, 8 Apr 2013 06:21:59 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id F2ECF2048C; Mon, 8 Apr 2013 09:20:35 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 42F024499; Mon, 8 Apr 2013 09:21:57 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> Date: Mon, 08 Apr 2013 09:21:57 -0400 In-Reply-To: <5160B785.8070703@deployingradius.com> (Alan DeKok's message of "Sat, 06 Apr 2013 20:02:13 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Peter Deacon , radext-chairs@tools.ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 13:21:59 -0000 >>>>> "Alan" == Alan DeKok writes: >> I apologize for any misunderstanding. The migration would be in >> the client rather than server. They would both have flags but >> the automatic upgrade with memory to prevent downgrade would be >> handled at the client. Alan> That won't pass security review. Having the server *also* Alan> handle client upgrade is a hard requirement. Can you point to the documentation of the hard requirement for server-side memory in upgrade? I'd like to understand how we got there and the discussions/arguments leading to that. From aland@deployingradius.com Mon Apr 8 06:28:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06AA21F93DA for ; Mon, 8 Apr 2013 06:28:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQdXQwcjGrLc for ; Mon, 8 Apr 2013 06:28:10 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6057821F9157 for ; Mon, 8 Apr 2013 06:28:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0AD2B22410BC; Mon, 8 Apr 2013 15:28:10 +0200 (CEST) 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 XaQWtzmfqS4k; Mon, 8 Apr 2013 15:28:09 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id E5CF32240860; Mon, 8 Apr 2013 15:28:08 +0200 (CEST) Message-ID: <5162C5E7.2050004@deployingradius.com> Date: Mon, 08 Apr 2013 09:28:07 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "radext@ietf.org" Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 13:28:11 -0000 Peter Deacon wrote: > On Sat, 6 Apr 2013, Alan DeKok wrote: > >> Peter Deacon wrote: >>> Requests from unknown IPs by itself is not useful. Normally access to >>> the RADIUS request (NAS-ID) often provides relevant clue. > >> That's not part of standard RADIUS. If you have a proprietary >> extension, you're responsible for ensuring it works. The IETF isn't. > > What "proprietary extension" is required to log incoming requests? So... your best option is to lie about what I said? > Lets examine the complete matrix of options for RADIUS/UDP vs > RADIUS/DTLS clients and servers. Let's not. Conversations presume that both parties operate in good faith. > With regards to the security review claim the migration concept is > susceptible to trivial MITM in the network path simply by filtering out > the more secure (DTLS) messages. Whether it is the client that does it > or the server makes no difference. This scheme is insecure either way. Nonsense. > The problem is servers would not have the option of turning off the > automatic migration behavior. You've understood that, at least. > Side effect of this is that multiple clients behind a single IP ... is not part of RADIUS. Once again, you're ignoring my messages about that topic. You seem to think that by simply repeating yourself ad nauseum, you can win a logical argument. Logic doesn't work that way. IMHO, hell will freeze over before RADIUS/UDP standardizes multiple clients behind one IP. Alan DeKok. From aland@deployingradius.com Mon Apr 8 06:30:29 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209D621F93DA for ; Mon, 8 Apr 2013 06:30:29 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3k4MU6lGXnYz for ; Mon, 8 Apr 2013 06:30:28 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBEF21F93D8 for ; Mon, 8 Apr 2013 06:30:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5CDF222410BC; Mon, 8 Apr 2013 15:29:55 +0200 (CEST) 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 9YDbQX0JIiNr; Mon, 8 Apr 2013 15:29:55 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id DB4622240860; Mon, 8 Apr 2013 15:29:54 +0200 (CEST) Message-ID: <5162C651.2000200@deployingradius.com> Date: Mon, 08 Apr 2013 09:29:53 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 13:30:29 -0000 Sam Hartman wrote: > Can you point to the documentation of the hard requirement for > server-side memory in upgrade? > I'd like to understand how we got there and the discussions/arguments > leading to that. Down-bidding attacks. Once a client upgrades to DTLS, allowing plain UDP is a down-bidding attack. Alan DeKok. From hartmans@painless-security.com Mon Apr 8 06:55:31 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCD421F944B for ; Mon, 8 Apr 2013 06:55:31 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVkws2R7s7Un for ; Mon, 8 Apr 2013 06:55:31 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7EF21F944A for ; Mon, 8 Apr 2013 06:55:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 650A22054D; Mon, 8 Apr 2013 09:54:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9CAC24499; Mon, 8 Apr 2013 09:55:28 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> Date: Mon, 08 Apr 2013 09:55:28 -0400 In-Reply-To: <5162C651.2000200@deployingradius.com> (Alan DeKok's message of "Mon, 08 Apr 2013 09:29:53 -0400") 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] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 13:55:32 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> Can you point to the documentation of the hard requirement for >> server-side memory in upgrade? I'd like to understand how we got >> there and the discussions/arguments leading to that. Alan> Down-bidding attacks. Alan> Once a client upgrades to DTLS, allowing plain UDP is a Alan> down-bidding attack. I'm aware of that. However, gat least sections of the security area I've been involved in have taken a wide variety of approaches to these types of attacks. Having the sort of mechanism you describe as a SHOULD is almost certainly going to be sufficient. However we can check with Steve and Sean if desired or bring it up on secdir. From leaf.yeh.sdo@gmail.com Mon Apr 8 07:35:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37C9A21F97D9; Mon, 8 Apr 2013 07:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.473 X-Spam-Level: X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AujwTgALxPQQ; Mon, 8 Apr 2013 07:35:23 -0700 (PDT) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 4246621F97D7; Mon, 8 Apr 2013 07:35:23 -0700 (PDT) Received: by mail-pa0-f49.google.com with SMTP id kp14so3235316pab.8 for ; Mon, 08 Apr 2013 07:35:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=qTab5rnx1VsUm9i7fa2TEzINOeSIuW4Qqs8C+ZxrEPQ=; b=MeT+idPtY3ZndsKfTy2tDyzoGijEg1hhPc3Cnto59bFJqJzj9/AFK2lLeSRTamu8gH 9JXauAS2nN+kkRSua7ZuhwkZF0CJze80SNC0OBu9zxvamRDOWYygThD5WAZhHYbeMkkO wE75FIjaVCNHt3IzJi7BASVrWdzYVrPijlm0yfLX9gAW/SFPaK2BmG9Jr+KYuRNAMKr1 K0GZBLxW0BL2rW7Hcl547Qhu1RZbcGzna0ZjzDUDPWBnY0wMTnRd3oLrHn/5GyG5LI5g AP853bvA9cf0mW3CxRF7X3hhS+hWzDxC1GI03iw558G1htVGtmfzXmD3bB2lJaDxKsJn WysQ== X-Received: by 10.66.219.136 with SMTP id po8mr24849398pac.53.1365431722591; Mon, 08 Apr 2013 07:35:22 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id to7sm40250501pab.0.2013.04.08.07.34.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 07:35:22 -0700 (PDT) From: "Leaf Yeh" To: "'Jouni Korhonen'" , References: In-Reply-To: Date: Mon, 8 Apr 2013 22:34:33 +0800 Message-ID: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01CE34A9.43392920" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac40KydsA3cjSiyLRsiJsmwVRvqQGAANtouw Content-Language: zh-cn Cc: 'dhcwg' Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 08 Apr 2013 14:35:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01CE34A9.43392920 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jouni - it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay. Does that sounds a question for the newly introduced attribute? Anyway, the server is supposed to know the meaning of the attributes from the relay before its response; if not, the server will silently ignore it. Right? Best Regards, Leaf From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Monday, April 08, 2013 3:32 PM To: Cc: dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Seems that I forgot to CC mailing lists. - Jouni Begin forwarded message: From: jouni korhonen Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Date: April 5, 2013 7:37:47 PM GMT+03:00 To: Tomek Mrugalski 5.4.2013 17.16 "Tomek Mrugalski" kirjoitti: > > On 05.04.2013 15:12, Ted Lemon wrote: > > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen > > wrote: > >> Blindly dropping an attribute might not work in all cases. For > >> example, in some cases the server might not then be able to provide > >> all information the relay needs.. > > > > Well, I did say "silently ignored," not "dropped," but yeah. If the > > server doesn't support that attribute, it's not going to have any > > effect anyway. It seems like silently ignoring it is better than > > dropping the whole message, although I suppose you could argue the > > opposite, since a misconfiguration of this sort is probably something > > the administrator wants to fix immediately, not discover by accident > > years later. > Anyway, dropping the whole message is definitely too radical here. We I was not suggesting dropping the message. I said "blindly dropping an attribute".. which is somewhat different. I am fine with a) but my point was that it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay. This needs to be taken into account when defining DHCP extensions relying on this I-D and the established registry. Jouni > have 3 options when server receives an unknown attribute: > a) ignore just the unknown attribute > b) ignore the whole radius option > c) ignore the whole message > > I think we have an agreement that a) is the way to go. At least that's > what I strongly recommend. > > Also, depending on server implementation, it is quite likely that the > server will parse unknown attributes and handle them in some generic > way, e.g. hex string. This is what some implementations do with unknown > DHCPv6 options and I imagine similar approach can be taken with RADIUS > attributes. Of course, such a behaviour is strictly implementation > specific, so there's no need to put anything about it in the spec. > So whether the attribute is "unknown" or not may be a bit blurry > definition sometimes. > > "Server MAY ignore received RADIUS attributes that it does not support." > seems like a reasonable text here. Some implementors will ignore unknown > attribute, some may produce a warning and some my try to handle it in a > generic way. > > Tomek > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg ------=_NextPart_000_00C1_01CE34A9.43392920 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jouni - it is possible in future when new attributes get = added to registry server silently discarding attributes may lead to a = situation where the server fails to provide enough information back to = relay.

 

Does that sounds a question for the newly introduced attribute? =

Anyway, the server is supposed to know the meaning of the attributes = from the relay before its response; if not, the server will silently = ignore it. Right?

 

 

Best Regards,

Leaf

 

 

 

From:= = dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Jouni Korhonen
Sent: Monday, April 08, 2013 3:32 = PM
To: <radext@ietf.org>
Cc: = dhcwg
Subject: Re: [dhcwg] [radext] = draft-ietf-dhc-dhcpv6-radius-opt-10

 

Seems that I forgot to CC mailing = lists.

 

- = Jouni

 

Begin forwarded message:



From: = jouni = korhonen <jouni.nospam@gmail.com>

Subject: = Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Date: = April 5, = 2013 7:37:47 PM GMT+03:00

To: = Tomek = Mrugalski <tomasz.mrugalski@gmail.com= >

 


5.4.2013 17.16 "Tomek Mrugalski" <tomasz.mrugalski@gmail.com= > kirjoitti:
>
> On 05.04.2013 15:12, Ted Lemon = wrote:
> > On Apr 5, 2013, at 8:50 AM, Jouni Korhonen <jouni.nospam@gmail.com>
= > > wrote:
> >> Blindly dropping an attribute might = not work in all cases. For
> >> example, in some cases the = server might not then be able to provide
> >> all = information the relay needs..
> >
> > Well, I did say = "silently ignored," not "dropped," but yeah.   = If the
> > server doesn't support that attribute, it's not = going to have any
> > effect anyway.   It seems like = silently ignoring it is better than
> > dropping the whole = message, although I suppose you could argue the
> > opposite, = since a misconfiguration of this sort is probably something
> > = the administrator wants to fix immediately, not discover by = accident
> > years later.
> Anyway, dropping the whole = message is definitely too radical here. We

I was not suggesting dropping the message. I said = "blindly dropping an attribute".. which is somewhat different. = I am fine with a) but my point was that it is possible in future when = new attributes get added to registry server silently discarding = attributes may lead to a situation where the server fails to provide = enough information back to relay. This needs to be taken into account = when defining DHCP extensions relying on this I-D and the established = registry.

Jouni

> have = 3 options when server receives an unknown attribute:
> a) ignore = just the unknown attribute
> b) ignore the whole radius = option
> c) ignore the whole message
>
> I think we = have an agreement that a) is the way to go. At least that's
> what = I strongly recommend.
>
> Also, depending on server = implementation, it is quite likely that the
> server will parse = unknown attributes and handle them in some generic
> way, e.g. hex = string. This is what some implementations do with unknown
> DHCPv6 = options and I imagine similar approach can be taken with RADIUS
> = attributes. Of course, such a behaviour is strictly = implementation
> specific, so there's no need to put anything = about it in the spec.
> So whether the attribute is = "unknown" or not may be a bit blurry
> definition = sometimes.
>
> "Server MAY ignore received RADIUS = attributes that it does not support."
> seems like a = reasonable text here. Some implementors will ignore unknown
> = attribute, some may produce a warning and some my try to handle it in = a
> generic way.
>
> Tomek
> = _______________________________________________
> dhcwg mailing = list
> dhcwg@ietf.org
> https://www.ietf.org= /mailman/listinfo/dhcwg

 

------=_NextPart_000_00C1_01CE34A9.43392920-- From peterd@iea-software.com Mon Apr 8 08:20:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F5EF21F944B for ; Mon, 8 Apr 2013 08:20:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z-EkiXThZKTa for ; Mon, 8 Apr 2013 08:20:53 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6A85B21F9385 for ; Mon, 8 Apr 2013 08:20:53 -0700 (PDT) Received: from littlesmurf (unverified [10.0.1.16]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 8 Apr 2013 08:20:52 -0700 Date: Mon, 8 Apr 2013 08:20:53 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5162C651.2000200@deployingradius.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@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: Sam Hartman , radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 15:20:54 -0000 On Mon, 8 Apr 2013, Alan DeKok wrote: > Sam Hartman wrote: >> Can you point to the documentation of the hard requirement for >> server-side memory in upgrade? >> I'd like to understand how we got there and the discussions/arguments >> leading to that. > Down-bidding attacks. A bidding down attack requires client or server to be tricked into accepting security lower than highest supported by both peers. See the table in my previous message. > Once a client upgrades to DTLS, allowing plain UDP is a down-bidding > attack. To be an attack the attack must be successful. With RADIUS/DTLS draft there is no negotiation protocol to attack. Either the nonnegotiable demands of both sides are met or it fails. A client configured to only emit RADIUS/DTLS requests cannot be tricked into falling back to a less secure RADIUS/UDP. Likewise a server willing to accept RADIUS/UDP and RADIUS/DTLS cannot be tricked into accepting RADIUS/UDP as RADIUS/UDP has been configured to be acceptable to the server. A server willing to accept only RADIUS/DTLS cannot be tricked into accepting RADIUS/UDP. This is a setting on the server rather than negotiation parameter able to be attacked from the protocol. regards, Peter From hartmans@painless-security.com Mon Apr 8 08:35:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5C621F93E4 for ; Mon, 8 Apr 2013 08:35:09 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fUGvG4H8Wt7j for ; Mon, 8 Apr 2013 08:35:03 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9D45B21F93E2 for ; Mon, 8 Apr 2013 08:35:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id ECBD620556; Mon, 8 Apr 2013 11:33:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DFE574499; Mon, 8 Apr 2013 11:35:00 -0400 (EDT) From: Sam Hartman To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> Date: Mon, 08 Apr 2013 11:35:00 -0400 In-Reply-To: (Peter Deacon's message of "Mon, 8 Apr 2013 08:20:53 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 15:35:10 -0000 >>>>> "Peter" == Peter Deacon writes: Peter> On Mon, 8 Apr 2013, Alan DeKok wrote: >> Sam Hartman wrote: >> Can you point to the documentation of the hard requirement for >>> server-side memory in upgrade? I'd like to understand how we >>> got there and the discussions/arguments leading to that. >> Down-bidding attacks. Peter> A bidding down attack requires client or server to be tricked Peter> into accepting security lower than highest supported by both Peter> peers. See the table in my previous message. OK. So, RADIUS/UDP is easier to attack than RADIUS/DTLS. Let's assume a server requires message authenticators for UDP. If the server forbids UDP-after-DTLS, then once DTLS has happened, an attacker can no longer attack that particular UDP secret. However if the client is responsible for enforcing the attack, then an attacker can try and convince the server to accept a request using the UDP secret in question. I don't want to argue about whether it's a bid-down attack or not. It is a real attack. It's almost certainly in our threat model. It's almost certain that a policy control of forbid UDP as the mandatory-to-implementmechanism combined with Alan's proposal for latching on use of DTLS as a SHOULD is sufficient to meet security review. If you turn off the latching behavior then you have a residual risk. That said, I think I've also convinced myself that having the latching behavior be mandatory-to-implement but not mandatory-to-use on the server is also fine. So, here's where I stand on this issue: * we need to do something in this space. * I'm against mandating that clients or proxies support upgrading from UDP to DTLS without a restart/flag day * I am in favor of requiring servers support clients upgrading without a flag day. Alan's latching proposal seems like a fine option to get that either as a SHOULD or MUST. --Sam From Ted.Lemon@nominum.com Mon Apr 8 08:42:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6C021F9421; Mon, 8 Apr 2013 08:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.592 X-Spam-Level: X-Spam-Status: No, score=-106.592 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A06-DN487qa; Mon, 8 Apr 2013 08:42:00 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A183321F9415; Mon, 8 Apr 2013 08:42:00 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUWLlSN/vkFvJzAYM3JbzHv3BiKj1rOGg@postini.com; Mon, 08 Apr 2013 08:42:00 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 49CB3108394; Mon, 8 Apr 2013 08:42:00 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 41C80190061; Mon, 8 Apr 2013 08:42:00 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 08:42:00 -0700 From: Ted Lemon To: Leaf Yeh Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14A= Date: Mon, 8 Apr 2013 15:41:59 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> In-Reply-To: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: multipart/alternative; boundary="_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_" MIME-Version: 1.0 Cc: "" , Jouni Korhonen , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 08 Apr 2013 15:42:01 -0000 --_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Apr 8, 2013, at 10:34 AM, Leaf Yeh > wrote: Jouni - it is possible in future when new attributes get added to registry = server silently discarding attributes may lead to a situation where the ser= ver fails to provide enough information back to relay. Also, having the server reflect the option back is easy; having it make cha= nges to the option is actually a protocol update, and probably not a good i= dea. --_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_ Content-Type: text/html; charset="us-ascii" Content-ID: <0A376C5C2B565942B911568E7B64E6C9@nominum.com> Content-Transfer-Encoding: quoted-printable
On Apr 8, 2013, at 10:34 AM, Leaf Yeh <leaf.yeh.sdo@gmail.com> wrote:
Jouni - it is possible in future when new attributes get added to registry serve= r silently discarding attributes may lead to a situation where the server f= ails to provide enough information back to relay.

Also, having the server reflect the option back is easy; having it mak= e changes to the option is actually a protocol update, and probably not a g= ood idea.

--_000_8D23D4052ABE7A4490E77B1A012B630775138825mbx01winnominum_-- From aland@deployingradius.com Mon Apr 8 10:09:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0AB221F9382 for ; Mon, 8 Apr 2013 10:09:18 -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=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUqGvEqIGDrk for ; Mon, 8 Apr 2013 10:09:18 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4AD21F8CE8 for ; Mon, 8 Apr 2013 10:09:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 583D822410BC; Mon, 8 Apr 2013 19:09:18 +0200 (CEST) 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 A1yNdMhK3nJL; Mon, 8 Apr 2013 19:09:16 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 1B44C2240F50; Mon, 8 Apr 2013 19:09:16 +0200 (CEST) Message-ID: <5162F9BA.7030500@deployingradius.com> Date: Mon, 08 Apr 2013 13:09:14 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 17:09:18 -0000 Sam Hartman wrote: > * we need to do something in this space. Agreed. > * I'm against mandating that clients or proxies support upgrading from > UDP to DTLS without a restart/flag day OK. > * I am in favor of requiring servers support clients upgrading without a > flag day. Alan's latching proposal seems like a fine option to get > that either as a SHOULD or MUST. OK. Or... we can delete all of the text around upgrade paths, and just use a different port. I really don't care either way. The upgrade text is there due to WG consensus on the issue. If the WG now has consensus on using a new port instead, that's fine. I'll have a new draft available tomorrow. Alan DeKok. From aland@deployingradius.com Mon Apr 8 10:10:19 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A79921F93A9 for ; Mon, 8 Apr 2013 10:10:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw14Rd+mo-gY for ; Mon, 8 Apr 2013 10:10:18 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C40C221F8BF4 for ; Mon, 8 Apr 2013 10:10:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C51BF22410BC; Mon, 8 Apr 2013 19:10:18 +0200 (CEST) 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 Qzhde3eU32MJ; Mon, 8 Apr 2013 19:10:18 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 321AB2240F50; Mon, 8 Apr 2013 19:10:18 +0200 (CEST) Message-ID: <5162F9F8.4060104@deployingradius.com> Date: Mon, 08 Apr 2013 13:10:16 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 17:10:19 -0000 Peter Deacon wrote: > Likewise a server willing to accept RADIUS/UDP and RADIUS/DTLS cannot be > tricked into accepting RADIUS/UDP as RADIUS/UDP has been configured to > be acceptable to the server. See my previous 10 messages for why this reasoning is wrong. Alan DeKok. From hartmans@painless-security.com Mon Apr 8 10:21:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B458C21F9777 for ; Mon, 8 Apr 2013 10:21:21 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dFKzhkCls+zR for ; Mon, 8 Apr 2013 10:21:21 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2E66721F9773 for ; Mon, 8 Apr 2013 10:21:20 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 7F5DB20556; Mon, 8 Apr 2013 13:19:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BEC3B4499; Mon, 8 Apr 2013 13:21:17 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9BA.7030500@deployingradius.com> Date: Mon, 08 Apr 2013 13:21:17 -0400 In-Reply-To: <5162F9BA.7030500@deployingradius.com> (Alan DeKok's message of "Mon, 08 Apr 2013 13:09:14 -0400") 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] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 17:21:25 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Or... we can delete all of the text around upgrade paths, Alan> and just use a different port. Well, I'm actually not sure about the security of this. Even if you use a different port, don't you still have all the bid-down issues? I mean what stops an attacker from sending you UDP traffic that's from a client that should be using DTLS. I don't mind using a different port, but I don't think it helps much with this discussion. From leaf.yeh.sdo@gmail.com Mon Apr 8 10:31:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7CD221F95ED; Mon, 8 Apr 2013 10:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.039 X-Spam-Level: X-Spam-Status: No, score=0.039 tagged_above=-999 required=5 tests=[AWL=-2.455, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y41dR3688Uq2; Mon, 8 Apr 2013 10:31:45 -0700 (PDT) Received: from mail-ie0-x22d.google.com (mail-ie0-x22d.google.com [IPv6:2607:f8b0:4001:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE4321F9577; Mon, 8 Apr 2013 10:31:45 -0700 (PDT) Received: by mail-ie0-f173.google.com with SMTP id 9so7324169iec.18 for ; Mon, 08 Apr 2013 10:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=2ERwQXfvVLpbTc1jqFGrOSZnjeuA5epX2M1gM7I384E=; b=0bSZry82BcnegdbFkWHw723nPj2CtF47Nn7qH9aSRax1ATlC0jC5Pftgp7NZj0vu9e UnZWmXSk1wQ5yZRd0Keg88dWIOM38SE10A0YO6DrWo3SG1DDa1f8OdLr7wOMkcFt5qFc 6oPLTFIZFKNKBnha13NJmgMcBp6XbnbkW1jgG6WmtEXrXyb6SQupuv0Dgf/JTdIoiw33 f+G5+qd9YdEI5DDRmuAM0sNS1fdc3Evcyzmu48x3XJNJbmiRymoNGY91X0LiYQkyppFU MFzkW4vHj7E7doy5RHF6dk6EJ/pKTE5GYRJzndzFtkyqJaF1s+q8PV1qzfXilR+kQ+0L WVqA== X-Received: by 10.42.247.8 with SMTP id ma8mr12570815icb.1.1365442304252; Mon, 08 Apr 2013 10:31:44 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id ip2sm18310754igc.5.2013.04.08.10.31.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 10:31:43 -0700 (PDT) From: "Leaf Yeh" To: "'Alan DeKok'" , "'Ted Lemon'" References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> <8D23D4052ABE7A4490E77B1A012B630775132F65@mbx-01.win.nominum.com> <515EDCC7.5010708@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513327A@mbx-01.win.nominum.com> <515EDF8C.90104@deployingradius.com> In-Reply-To: <515EDF8C.90104@deployingradius.com> Date: Tue, 9 Apr 2013 01:31:36 +0800 Message-ID: <5162feff.e2c4320a.4c2e.4d83@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4yCeWxcMGiRw5nTrO1UXPWF7CTRgAEd9hQ Content-Language: zh-cn Cc: 'dhcwg' , radext@ietf.org Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 08 Apr 2013 17:31:45 -0000 Tomek - "Server MAY ignore received RADIUS attributes that it does not support." The draft (ver.-11) will have no further update on this point. OK? Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Alan DeKok Sent: Friday, April 05, 2013 10:28 PM To: Ted Lemon Cc: dhcwg; Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Ted Lemon wrote: > Generally speaking, this sort of language is a recipe for attack. I think the draft should just say that the administrator should be able to update the list of acceptable options. That's probably best. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From leaf.yeh.sdo@gmail.com Mon Apr 8 10:31:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCAE21F97B9; Mon, 8 Apr 2013 10:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.39 X-Spam-Level: X-Spam-Status: No, score=0.39 tagged_above=-999 required=5 tests=[AWL=-2.104, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_LT4=0.442, HELO_OEM=2.195, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ec4c2GRRfa89; Mon, 8 Apr 2013 10:31:48 -0700 (PDT) Received: from mail-ia0-x231.google.com (mail-ia0-x231.google.com [IPv6:2607:f8b0:4001:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 97F5221F97B7; Mon, 8 Apr 2013 10:31:48 -0700 (PDT) Received: by mail-ia0-f177.google.com with SMTP id w33so5309583iag.8 for ; Mon, 08 Apr 2013 10:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=dPbvYLNyJwbN1QF1vmjIg5lPFtDipl+KUOKfqs1f0EU=; b=ujjbSLLVvChTHfXCWrCQ7jorEqZKVO9DMO9elfvB9KTlen2EfZG4GubUge9tTPQ5OE Mb4kAqi1EuioJcH+3qdqIIuoMs462PeuwF0Ku1GatzuJhM6IvSVyuFK/Mwfcprj14Cdl tNoc/I2ls2KkhtUIqYFSwiIQfl3ig6IXF9zJNVCc9UeJbNMbonG7HQVsweBl38c5dfB1 FcKl46H2czmxdytcg7USjG2zj/CYfF26G/JY982FZ9izG9QQh4/VWvDDhf1c3OcZs1Qf TvdQlCdtTgIW2yzarg/Q9uLS4YMAEfwCvFCLYlOSS12j/SeCPkofWg2ABmhpP7hFM+fh TOfw== X-Received: by 10.50.212.74 with SMTP id ni10mr7916340igc.60.1365442307934; Mon, 08 Apr 2013 10:31:47 -0700 (PDT) Received: from PC ([114.248.232.47]) by mx.google.com with ESMTPS id ip2sm18310754igc.5.2013.04.08.10.31.44 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 08 Apr 2013 10:31:47 -0700 (PDT) From: "Leaf Yeh" To: "'Jouni Korhonen'" , "'Ted Lemon'" References: <515D7B4D.7090201@deployingradius.com> <515db052.24fa440a.4c16.ffff93c2@mx.google.com> <515DBD38.2020607@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775131DB4@mbx-01.win.nominum.com> <515DE629.6070706@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132294@mbx-01.win.nominum.com> <515DE957.1060202@deployingradius.com> <8D23D4052ABE7A4490E77B1A012B630775132374@mbx-01.win.nominum.com> <9992DCA7-FFB3-4328-A8FC-266109BDD059@gmail.com> <8D23D4052ABE7A4490E77B1A012B630775132B92@mbx-01.win.nominum.com> In-Reply-To: Date: Tue, 9 Apr 2013 01:31:36 +0800 Message-ID: <5162ff03.e2c4320a.4c2e.4d89@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac4x/DTwlyIftvbWQ5+H5ZTlKErHfQAHyYnw Content-Language: zh-cn Cc: radext@ietf.org, 'Alan DeKok' , 'dhcwg' Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 08 Apr 2013 17:31:49 -0000 Jouni - If that is a concern one can always change the "can only" to "MUST". The draft (ver.-11) will take this point. Best Regards, Leaf -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Jouni Korhonen Sent: Friday, April 05, 2013 8:51 PM To: Ted Lemon Cc: ; dhcwg; Alan DeKok Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 On Apr 5, 2013, at 2:42 PM, Ted Lemon wrote: > On Apr 5, 2013, at 3:19 AM, Jouni Korhonen wrote: >> The option-data of OPTION_RADIUS is a list of one or more RADIUS >> attributes received in the Access-Accept message from the RADIUS >> server. The OPTION_RADIUS can only contain RADIUS attributes listed >> in the IANA Registry of 'RADIUS attributes permitted in >> DHCPv6 RADIUS option'. > > So you took out the normative language, right? Was that intentional? That was intentional. If that is a concern one can always change the "can only" to "MUST". That works too, since the previous sentence already points out that the option contains one or more attributes, not all. >> The next question I have is what happens when a relay includes an >> attribute that the server does not understand or is not listed in the >> registry? There is no versioning thus it is possible that relay and >> server have a different understanding what the IANA registry is. Now >> the text in Section 6 only addresses the case where the server does not understand the DHCP option. > > Good question. I think the right answer is that that RADIUS attribute is silently ignored, because, as you say, the server might not be up to date. Blindly dropping an attribute might not work in all cases. For example, in some cases the server might not then be able to provide all information the relay needs.. That is more of a DHCP specification issue but what I would like to see in this I-D is some text pointing out that the server and the relay may have a different idea of the registry and the protocol design need to take that into account. - Jouni > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg From hartmans@painless-security.com Mon Apr 8 10:32:13 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44C0721F97D8 for ; Mon, 8 Apr 2013 10:32:13 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K3mUhWXhiCiw for ; Mon, 8 Apr 2013 10:32:12 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B68C921F97B2 for ; Mon, 8 Apr 2013 10:32:12 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 3A0E820556; Mon, 8 Apr 2013 13:30:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 825474499; Mon, 8 Apr 2013 13:32:10 -0400 (EDT) From: Sam Hartman To: Arran Cudbard-Bell References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9BA.7030500@deployingradius.com> <0FFFD8DE-5337-4A4F-A844-F8F05297A25E@freeradius.org> Date: Mon, 08 Apr 2013 13:32:10 -0400 In-Reply-To: <0FFFD8DE-5337-4A4F-A844-F8F05297A25E@freeradius.org> (Arran Cudbard-Bell's message of "Mon, 8 Apr 2013 13:26:00 -0400") 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, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 17:32:13 -0000 >>>>> "Arran" == Arran Cudbard-Bell writes: Arran> On 8 Apr 2013, at 13:21, Sam Hartman wrote: >>>>>> "Alan" == Alan DeKok writes: >> Alan> Or... we can delete all of the text around upgrade paths, and Alan> just use a different port. >> >> Well, I'm actually not sure about the security of this. Even if >> you use a different port, don't you still have all the bid-down >> issues? I mean what stops an attacker from sending you UDP >> traffic that's from a client that should be using DTLS. Arran> Presumably you would make this a dedicated DTLS port and Arran> discard non-DTLS traffic. Attackers have been known to choose the port that makes their attack work. The attacker will send you udp on the udp port and dtls on the dtls port. Ports aren't magic. >From a security standpoint, what the upgrade logic does is reduce the number of senders who are permitted to send you UDP. That's most effective if you use a different secret for each UDP sender. Each time you reduce the number of secrets that you accept for UDP traffic you increase security. From a.cudbardb@networkradius.com Mon Apr 8 11:50:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20DFC21F93FE for ; Mon, 8 Apr 2013 11:50:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vqHsWPr1RxN for ; Mon, 8 Apr 2013 11:50:49 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D43DC21F93FB for ; Mon, 8 Apr 2013 11:50:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B5CD722410BC; Mon, 8 Apr 2013 20:50:43 +0200 (CEST) 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 d90I2UmvvJFZ; Mon, 8 Apr 2013 20:50:41 +0200 (CEST) Received: from [192.168.2.22] (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 10E4E2240860; Mon, 8 Apr 2013 20:50:40 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_FFB14215-CA19-4E3D-8D56-B5D5D11BB721"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Arran Cudbard-Bell In-Reply-To: Date: Mon, 8 Apr 2013 14:50:08 -0400 Message-Id: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9BA.7030500@deployingradius.com> <0FFFD8DE-5337-4A4F-A844-F8F05297A25E@freeradius.org> To: Sam Hartman X-Mailer: Apple Mail (2.1503) Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 18:50:50 -0000 --Apple-Mail=_FFB14215-CA19-4E3D-8D56-B5D5D11BB721 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 8 Apr 2013, at 13:32, Sam Hartman = wrote: >>>>>> "Arran" =3D=3D Arran Cudbard-Bell = writes: >=20 > Arran> On 8 Apr 2013, at 13:21, Sam Hartman = wrote: >=20 >>>>>>> "Alan" =3D=3D Alan DeKok writes: >>>=20 > Alan> Or... we can delete all of the text around upgrade paths, and > Alan> just use a different port. >>>=20 >>> Well, I'm actually not sure about the security of this. Even if >>> you use a different port, don't you still have all the bid-down >>> issues? I mean what stops an attacker from sending you UDP >>> traffic that's from a client that should be using DTLS. >=20 > Arran> Presumably you would make this a dedicated DTLS port and > Arran> discard non-DTLS traffic. >=20 > Attackers have been known to choose the port that makes their attack > work. > The attacker will send you udp on the udp port and dtls on the dtls > port. > Ports aren't magic. True. But a atching mechanism feasible eveywhere. I'd suggest that such = a mechanism MUST be implemented, but suggest that it be SHOULD be = configurable with high enough granularity to dictate behaviour for = individual clients. What having a dedicated DTLS port gets you, is the ability to mandate = that between network boundaries only encrypted RADIUS traffic may pass. = This would otherwise be difficult to enforce without DPI.=20 > =46rom a security standpoint, what the upgrade logic does is reduce = the > number of senders who are permitted to send you UDP. It also requires that the RADIUS server be able to persistently store = this latching state for this to be effective. This is a new and = potentially problematic issue for a RADIUS server which up to now had = not had to dynamically modify its own configuration. Allowing a daemon to modify any part of its configuration is generally = considered bad practice, and where systems operate in a 'deep freeze' = state provisions would have to be made for storing this information off = box. Whilst this is an implementation issue it may hinder uptake in some = cases, which is why the latching should be optional. > That's most effective if you use a different secret for each UDP = sender. Indeed. > Each time you reduce the number of secrets that you accept for UDP > traffic you increase security. Agreed. Reducing the number of IP addresses unencrypted traffic is = accepted from reduces the range of IPs that can be used for a brute = force attack, reducing the number of secrets also makes it less likely = that such an attack would be successful.=20 As an aside, were still working under the assumption that it's = non-trivial to recover the shared secret from unecrypted RADIUS packets, = correct? -Arran --Apple-Mail=_FFB14215-CA19-4E3D-8D56-B5D5D11BB721 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMLTCCBbww ggOkoAMCAQICCQDgDuc54nniwjANBgkqhkiG9w0BAQUFADCBrzELMAkGA1UEBhMCRlIxEzARBgNV BAgMClJob25lIEFscHMxETAPBgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElV UzEPMA0GA1UECwwGRnJhbmNlMSQwIgYDVQQDDBtlbXBsb3llZXMubmV0d29ya3JhZGl1cy5jb20x KDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wHhcNMTIxMTA0MTYyNTAy WhcNMjIxMTAyMTYyNTAyWjCBqTELMAkGA1UEBhMCRlIxEzARBgNVBAgMClJob25lIEFscHMxETAP BgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElVUzEPMA0GA1UECwwGRnJhbmNl MRswGQYDVQQDDBJBcnJhbiBDdWRiYXJkLUJlbGwxKzApBgkqhkiG9w0BCQEWHGEuY3VkYmFyZGJA bmV0d29ya3JhZGl1cy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+oyztJu99 hxoGKXeIgLu9s2yZWTefCI6SRePRn8JogcMP+URSSxrmaiTOMFVq6YebDgNwhqcxcX88LaA9gq+y eXTN/xke8XUogibLccuT1gzrHsVTxdfkNSBDZ3Ar0ePzZlfl+1v/TMis/AirhfmZRJ6YiXfwtfHN 3+fR4w/uQZ1a7sM0XeLHZloJ2ltw3LlER+fXlpE3d424jM2ulhQcdgpvARHZnysyj6rkFQaDxOyT Z4Sr4pBQ5QT5NZFlFubXFPDvUVjGvTjyaLn+27PEEjylPX0LAKwNW5/El1DYvNmauBhqm6ZqXB0f 8TL9WvJvwxuZVKxh43FAk/wlh16PAgMBAAGjgd4wgdswCQYDVR0TBAIwADARBglghkgBhvhCAQEE BAMCBaAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0GA1Ud DgQWBBTJo8sR/WO+nHHOaOZdURNAcGbcAzAfBgNVHSMEGDAWgBRie89pUWaGz/uhMgr2Pf/UxBAv sDAnBgNVHREEIDAegRxhLmN1ZGJhcmRiQG5ldHdvcmtyYWRpdXMuY29tMCQGA1UdEgQdMBuBGXN1 cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wDQYJKoZIhvcNAQEFBQADggIBAA8XtsB8MMMYN5p2htV7 dRbIxOuPL4gtemmrsRmYtRUP7pdLP4NahBrnVWEve60q+zdgZO6IcqoYvoeG1/Yr82DABoHFai7H V3UU3nG4SPJk8+VXeeOGbpnCcylhm45MYZvdikbogsbItMtnDRZbV/7mJeNgADGJYaQGC7IzGoQ2 aawHiXVNRFI5JUcN/2Pj8xPApGNDbssA3kncW5+fqlmZXZE8lIE0GXH/qNAvS1rxT1WEAZ6dzI0y UIWIVQugeAQvEGTey4VW0XFPtX/Si6OQNFyXVLgQa17bneH+M/XVNYVK887bDMKjLLmHfSZnH/ra RCl2OCjtHkj850T1dJ8DUE83jyz4qlU1ARZjivJcXv/btIN4DCDyE/2vyar6OCd/ynwvIQyJAprY WJ+7dnOf/owQ9m9OUZnN+iSE/dsEdD3N+VfckD6FPefibUxZrwGdKSmpAkHZplYWCpOHhiXMI+8c dYhJsX43dBlHievq4eAU5qa6LiyazMdg3G4tlJYRcLc91CeQ9dB2M4IHJsnhOoaxVtkRGyVeXugd 7f6N5OXpbUIM7yUzmFd9owZZ6LrRkwKLBQOWoI1B1FlDKc5aaKDHER6wiDPRDUlsQu+5LEUaOdIK gTJncoXWCyVgIKHGmNjodOQp64lsbBxZH/pshb9CGlOGyfkbr2NUfNReMIIGaTCCBFGgAwIBAgIJ ANAO5znieeK+MA0GCSqGSIb3DQEBBQUAMIGSMQswCQYDVQQGEwJGUjETMBEGA1UECAwKUmhvbmUg QWxwczEXMBUGA1UECgwOTmV0d29yayBSQURJVVMxDzANBgNVBAsMBkZyYW5jZTEaMBgGA1UEAwwR bmV0d29ya3JhZGl1cy5jb20xKDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5j b20wHhcNMTIxMTA0MTUzMDM1WhcNMjIxMTAyMTUzMDM1WjCBrzELMAkGA1UEBhMCRlIxEzARBgNV BAgMClJob25lIEFscHMxETAPBgNVBAcMCEdyZW5vYmxlMRcwFQYDVQQKDA5OZXR3b3JrIFJBRElV UzEPMA0GA1UECwwGRnJhbmNlMSQwIgYDVQQDDBtlbXBsb3llZXMubmV0d29ya3JhZGl1cy5jb20x KDAmBgkqhkiG9w0BCQEWGXN1cHBvcnRAbmV0d29ya3JhZGl1cy5jb20wggIiMA0GCSqGSIb3DQEB AQUAA4ICDwAwggIKAoICAQC3aWd6I+mwM+eD8op/lrrZTbOegzFmdk0SsEN2lrok2s7Wzud+bRx7 SlzMx//OoAxj9w0SgwNaWCaixIjnhmyvJ9Fxu6fk3Ql/U6ThhGO7ca+UXDOtFsjg4AMsdN8FdNZz 183rDmMm5oAERyKEevc0iuutiyqfrmeS8IQXOiuqztZoypIoYtlICxtdcF2hVT0z+urpwDiKJ8qH NBLEjxD3VpFVA3DOyZGOtxpwsP9W6GUIhGamAgC+jqgFOqBitzsaKT521R6sdlPYuy6/q/L1M0jX g4xgBrBZCWYOTsFf1F8kXT2dqm1SGA3CARm4Mjn3CtV26QNhU2hbjw/hL8tPIrpOehyxEMJ8Bzbp HzMTjmW5N2OOBRK61DEbH1Y4gKgPtaAjMqKechFdiL/JCG/tbxFjCYZYLRPsz/MiT/rOSoWEOLkM ice+76KpVHqDUzjJxvDO4GnmnRIarqistG7ai51/adyJ1BRcmkAEKrmk5ToFzWTEkJtg+BZblToX q2upHg6AEeHbIXpv7s+u5V9rIlihXMbq4hhrW4DDrAEX/ZIFczaFPA4gIFj5u7QXD6DD0iSiPsdu FcTOsOFf55j93yg7PAQ9GbXSEdIN9lKwuggW+PSxNhcgr7ieYH6C5E8kLse5jgTt9u4NDg/eiLQK agkf+lVdHlzi5tAW9tW1fwIDAQABo4GiMIGfMB0GA1UdDgQWBBRie89pUWaGz/uhMgr2Pf/UxBAv sDAfBgNVHSMEGDAWgBSX4gMQTLLNEQEqik7f9MpkimjmDDAMBgNVHRMEBTADAQH/MAsGA1UdDwQE AwIBBjARBglghkgBhvhCAQEEBAMCAQYwJAYDVR0RBB0wG4EZc3VwcG9ydEBuZXR3b3JrcmFkaXVz LmNvbTAJBgNVHRIEAjAAMA0GCSqGSIb3DQEBBQUAA4ICAQCVSM0a5CgoDsnX2zEMy5Lb9FW9//tr wqCBP1PfgDyJgDoIHzpRGgpNQvir2tjLP26KanNMYAibFl/mKrv3KAfaTaQsu8aOj4aWJOM8FwsK wruN90uLDFYV5hZMHy7QDc5pueIsZdE5/To+ekK7nHJr0WrM3o1fkV3p3EqA17aG7VIpeMgfJvwA +foO+IqGBQIsw4/HYfL5elva+n8Pp2rvHYddIqgKnmEeIsDRmdp0RMYBuPrixvJ7503kyxcIxZ9R 5umJyrLIMUBbGiPyi5IuL3nIjkAnxFyCzLO2HSeDqRhIieVY8a7yiPOhb0XV+KEBfyvJz0fj3qgn BguBEhSQA/F4X7EaBsqrWdxqk1hl5+k1Nu+bO35yWPeATXfW+dRJVh8xrb/lDnlhw6lyjccih3Oo 2Ut6+R/nP/7GZP+WO1Dtq/XsyWfhXnvZVdh6+3QWolXYmY2rBJDd2jAJo8brgwF1IIQohMCoqOj8 8uVQbrLmG/lozjlnO+JuofmDMKjhha2kDUT946qzfajDTR9o1lASP4h9eyKk/7q10V+lz+QbsH4s 6KpgBnrNxRRrgd0/fE3LekBDTouKSvsJT+X2/p9oX5OyoQKNtXSm85T83Ko9PCiDRTIU1V2Bc6er RpOrU4n6Z8y87GJ+giQcmpN5CR2F2YNf3ZW9Wff+UnvXAzGCA+owggPmAgEBMIG9MIGvMQswCQYD VQQGEwJGUjETMBEGA1UECAwKUmhvbmUgQWxwczERMA8GA1UEBwwIR3Jlbm9ibGUxFzAVBgNVBAoM Dk5ldHdvcmsgUkFESVVTMQ8wDQYDVQQLDAZGcmFuY2UxJDAiBgNVBAMMG2VtcGxveWVlcy5uZXR3 b3JrcmFkaXVzLmNvbTEoMCYGCSqGSIb3DQEJARYZc3VwcG9ydEBuZXR3b3JrcmFkaXVzLmNvbQIJ AOAO5znieeLCMAkGBSsOAwIaBQCgggIBMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEzMDQwODE4NTAwOVowIwYJKoZIhvcNAQkEMRYEFApq/T32Ot6rE6PSweX/oOcU e4rQMIHOBgkrBgEEAYI3EAQxgcAwgb0wga8xCzAJBgNVBAYTAkZSMRMwEQYDVQQIDApSaG9uZSBB bHBzMREwDwYDVQQHDAhHcmVub2JsZTEXMBUGA1UECgwOTmV0d29yayBSQURJVVMxDzANBgNVBAsM BkZyYW5jZTEkMCIGA1UEAwwbZW1wbG95ZWVzLm5ldHdvcmtyYWRpdXMuY29tMSgwJgYJKoZIhvcN AQkBFhlzdXBwb3J0QG5ldHdvcmtyYWRpdXMuY29tAgkA4A7nOeJ54sIwgdAGCyqGSIb3DQEJEAIL MYHAoIG9MIGvMQswCQYDVQQGEwJGUjETMBEGA1UECAwKUmhvbmUgQWxwczERMA8GA1UEBwwIR3Jl bm9ibGUxFzAVBgNVBAoMDk5ldHdvcmsgUkFESVVTMQ8wDQYDVQQLDAZGcmFuY2UxJDAiBgNVBAMM G2VtcGxveWVlcy5uZXR3b3JrcmFkaXVzLmNvbTEoMCYGCSqGSIb3DQEJARYZc3VwcG9ydEBuZXR3 b3JrcmFkaXVzLmNvbQIJAOAO5znieeLCMA0GCSqGSIb3DQEBAQUABIIBAC04X/9KobK3cNKDMsVx WMMYmu/6x21jh4dTA8xnmgrLMjxmIK2APdyKYLlInfIEbm10a8Y574MnssGj0mfp/rOaL3e/9IyN BfilsQl1PfSLdRQdQ1Fi/xzvNOsOAvfL3+mANecDog5uAAkcrtKi9GdcX2+kwsmMDWxNRoXCRpz9 2GWNwQJ2p7NHR+ruQuQytYA8T9zwyM2pXTyg8ORNJ1lvHQbdl9zQEGh8gwErcaRPcYOpiS2LfRy+ UdteJcYMRZZlD+k3c/6IlQT7qeJsM5xsUrdSem7gp/LflojNRN7wpdjADIySLGdm3w9+NVBHAkAl RKn+PdxItjYzeP/N+jYAAAAAAAA= --Apple-Mail=_FFB14215-CA19-4E3D-8D56-B5D5D11BB721-- From hartmans@painless-security.com Mon Apr 8 12:11:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E0521F8EE1 for ; Mon, 8 Apr 2013 12:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYDXbwLxovsE for ; Mon, 8 Apr 2013 12:11:19 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CAA8021F89C3 for ; Mon, 8 Apr 2013 12:11:19 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id D4C3320556; Mon, 8 Apr 2013 15:09:55 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0FB674499; Mon, 8 Apr 2013 15:11:17 -0400 (EDT) From: Sam Hartman To: Arran Cudbard-Bell References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9BA.7030500@deployingradius.com> <0FFFD8DE-5337-4A4F-A844-F8F05297A25E@freeradius.org> Date: Mon, 08 Apr 2013 15:11:16 -0400 In-Reply-To: (Arran Cudbard-Bell's message of "Mon, 8 Apr 2013 14:50:08 -0400") 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, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 19:11:22 -0000 >What having a dedicated DTLS port gets you, is the ability to mandate that between network boundaries only encrypted RADIUS traffic may pass. This would otherwise be difficult to enforce without DPI. True. no objection to dedicated dtls port. >As an aside, were still working under the assumption that it's non-trivial to recover the shared secret from unecrypted RADIUS packets, correct? I don't know. Enumerating through I think 96^11 md4s is apparently trivial given reasonably-priced hardware for cracking. So probably $10k investment. See recent discussions of hash cracking on GPUs. However, md5 is a bit slower, and 11 is less than 16. I think I'd say that I would be unsurprised if someone broke RADIUS secrets entirely, and would be entirely unsurprised if brute forcing the secrets anyone is actually using in practice was easy. On the other hand I would not commit to being able to brute force a particular RADIUS secret without more research. From volz@cisco.com Mon Apr 8 09:25:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA9121F9415; Mon, 8 Apr 2013 09:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSkG9IYVZlwU; Mon, 8 Apr 2013 09:25:06 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2421F9410; Mon, 8 Apr 2013 09:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10677; q=dns/txt; s=iport; t=1365438306; x=1366647906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rSbWy5PtlFkWtIXPnP0IpjxpUlWka2brqqj7J6cFBpc=; b=OUfAP3BThx1konH0gy7bGxdGntnWio15F2EqP1nK4QdzFkPhEz7NHHtM nitCXyANZKu4kamGUrVhTblrqH1+5dpBkZt2oSWqSMy/xC9H8eJrvVLuB 8UjKwjrq8FBNb/y3SEq2lt2mxc6vGCpaxVWeIV5hi20QMxY0YZZ1HScqk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAIruYlGtJXG8/2dsb2JhbABRgkJENsEsgQoWdIIfAQEBAwEtTAULAgEIEQQBAQsdByERFAkIAgQBDQUIh3oDCQazMQ2JXYkLg0WCIjEGAYJgYQOVE41UhRuDC4Io X-IronPort-AV: E=Sophos;i="4.87,432,1363132800"; d="scan'208,217";a="196286228" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 08 Apr 2013 16:25:05 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r38GP5TL025192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 16:25:05 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 11:25:05 -0500 From: "Bernie Volz (volz)" To: Ted Lemon , Leaf Yeh Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wA== Date: Mon, 8 Apr 2013 16:25:04 +0000 Message-ID: <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.252.121] Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 08 Apr 2013 12:20:07 -0700 Cc: "" , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 08 Apr 2013 16:25:07 -0000 --_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (This is with chair hat off! I have to remember to indicate that.) > having the server reflect the option back is easy The ERO option can be specified to cause the server to send back the option= to the relay. I don't think we want to server to "change" the data in the = option. I wonder whether Jouni's concern is that the server may not send the client= the correct response? But in that case you need to assure your server is u= pdated accordingly (to use the new Radius attribute) and I don't see that t= his is really a concern for this document? We can't assume servers would know how to do something for something that i= s not yet defined. The "old" server ignoring the attribute in the option is= the correct action until it is updated. - Bernie From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of T= ed Lemon Sent: Monday, April 08, 2013 11:42 AM To: Leaf Yeh Cc: ; dhcwg Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 On Apr 8, 2013, at 10:34 AM, Leaf Yeh > wrote: Jouni - it is possible in future when new attributes get added to registry = server silently discarding attributes may lead to a situation where the ser= ver fails to provide enough information back to relay. Also, having the server reflect the option back is easy; having it make cha= nges to the option is actually a protocol update, and probably not a good i= dea. --_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

(This is with chair hat o= ff! I have to remember to indicate that.)

 <= /p>

> having the se= rver reflect the option back is easy<= /span>

 <= /p>

The ERO option can be spe= cified to cause the server to send back the option to the relay. I don̵= 7;t think we want to server to “change” the data in the option.=

 <= /p>

I wonder whether Jouni= 217;s concern is that the server may not send the client the correct respon= se? But in that case you need to assure your server is updated accordingly (to use the new Radius attribute) and I don’t see that t= his is really a concern for this document?

 <= /p>

We can’t assume ser= vers would know how to do something for something that is not yet defined. = The “old” server ignoring the attribute in the option is the co= rrect action until it is updated.

 <= /p>

- =          Bernie=

 <= /p>

From: dhcwg-bo= unces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
Sent: Monday, April 08, 2013 11:42 AM
To: Leaf Yeh
Cc: <radext@ietf.org>; dhcwg
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

 

On Apr 8, 2013, at 10:34 AM, Leaf Yeh <leaf.yeh.sdo@gmail.com> wrote:<= /o:p>

Jouni - it is possible in future when new attributes= get added to registry server silently discarding attributes may lead to a = situation where the server fails to provide enough information back to rela= y.

 

Also, having the server reflect the option back is e= asy; having it make changes to the option is actually a protocol update, an= d probably not a good idea.

 

--_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_-- From a.cudbardb@freeradius.org Mon Apr 8 10:26:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F0C21F9771 for ; Mon, 8 Apr 2013 10:26:39 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSp76jlWU1MT for ; Mon, 8 Apr 2013 10:26:38 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19221F9132 for ; Mon, 8 Apr 2013 10:26:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0BBFF22410BC; Mon, 8 Apr 2013 19:26:35 +0200 (CEST) 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 pRQo9LBNlOou; Mon, 8 Apr 2013 19:26:32 +0200 (CEST) Received: from [192.168.2.22] (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 7A96B2240742; Mon, 8 Apr 2013 19:26:32 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Arran Cudbard-Bell In-Reply-To: Date: Mon, 8 Apr 2013 13:26:00 -0400 Content-Transfer-Encoding: 7bit Message-Id: <0FFFD8DE-5337-4A4F-A844-F8F05297A25E@freeradius.org> References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9BA.7030500@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.1503) X-Mailman-Approved-At: Mon, 08 Apr 2013 12:20:07 -0700 Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 17:26:39 -0000 On 8 Apr 2013, at 13:21, Sam Hartman wrote: >>>>>> "Alan" == Alan DeKok writes: > > Alan> Or... we can delete all of the text around upgrade paths, > Alan> and just use a different port. > > Well, I'm actually not sure about the security of this. > Even if you use a different port, don't you still have all the bid-down > issues? > I mean what stops an attacker from sending you UDP traffic that's from a > client that should be using DTLS. Presumably you would make this a dedicated DTLS port and discard non-DTLS traffic. -Arran From aland@deployingradius.com Mon Apr 8 12:44:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A2721F8887 for ; Mon, 8 Apr 2013 12:44:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCYUKSPsx+WQ for ; Mon, 8 Apr 2013 12:43:59 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 868EE21F8842 for ; Mon, 8 Apr 2013 12:43:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 787AE22410BC; Mon, 8 Apr 2013 21:43:58 +0200 (CEST) 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 cjiI1RZgBPZo; Mon, 8 Apr 2013 21:43:56 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id AEC902240742; Mon, 8 Apr 2013 21:43:55 +0200 (CEST) Message-ID: <51631DF9.1080307@deployingradius.com> Date: Mon, 08 Apr 2013 15:43:53 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9BA.7030500@deployingradius.com> <0FFFD8DE-5337-4A4F-A844-F8F05297A25E@freeradius.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Arran Cudbard-Bell , radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 08 Apr 2013 19:44:00 -0000 Sam Hartman wrote: > I don't know. Enumerating through I think 96^11 md4s is apparently > trivial given reasonably-priced hardware for cracking. So probably $10k > investment. See recent discussions of hash cracking on GPUs. However, > md5 is a bit slower, and 11 is less than 16. http://www.insidepro.com/eng/egb.shtml Says that they can do about 500M hashes/s. Let's assume that's true, and is the best case. This is even though other sites claim 100x that cracking power. These numbers are for *password* cracking, which is a bit different from cracking RADIUS packets. So maybe RADIUS will be slower. > I think I'd say that I > would be unsurprised if someone broke RADIUS secrets entirely, and would > be entirely unsurprised if brute forcing the secrets anyone is actually > using in practice was easy. I agree. Let's say the MD5 cracking of RADIUS packets was 1% of the above password cracking speed. Even with that, brute-forcing all alphanumerical passwords would take less than a year for one person. I have 94 individual characters available on my keyboard. Let's say I use them all for shared secrets, and that the cracking speed is 5M attempts per second. We have the following crack times, for each length of shared secret: 4 16 seconds 5 25 minutes 6 38 hours 7 150 days 8 37 years If you assume that the attacker can do 500M attempts per second, then all shared secrets less than 8 characters long can be trivially broken. And it gets MUCH worse than that if people are less rigorous about using a wide range of ASCII characters. Alan DeKok. From peterd@iea-software.com Mon Apr 8 21:14:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB1821F8FFA for ; Mon, 8 Apr 2013 21:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHghFiNyP-Lq for ; Mon, 8 Apr 2013 21:14:57 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 1AA6321F8FF3 for ; Mon, 8 Apr 2013 21:14:56 -0700 (PDT) Received: from littlesmurf.peterd.ws (unverified [10.0.3.39]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 8 Apr 2013 21:14:56 -0700 Date: Mon, 8 Apr 2013 21:14:59 -0700 (Pacific Daylight Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 09 Apr 2013 04:14:57 -0000 On Mon, 8 Apr 2013, Sam Hartman wrote: > That said, I think I've also convinced myself that having the latching > behavior be mandatory-to-implement but not mandatory-to-use on the > server is also fine. This sounds good to me. regards, Peter From peterd@iea-software.com Tue Apr 9 00:41:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34F3F21F9156 for ; Tue, 9 Apr 2013 00:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piM+RKMpW6+V for ; Tue, 9 Apr 2013 00:41:38 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id B7E6C21F8FFA for ; Tue, 9 Apr 2013 00:41:38 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 9 Apr 2013 00:41:38 -0700 Date: Tue, 9 Apr 2013 00:41:35 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5162F9F8.4060104@deployingradius.com> Message-ID: References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9F8.4060104@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] WGLC #2 for draft-ietf-radext-dtls-04 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, 09 Apr 2013 07:41:44 -0000 On Mon, 8 Apr 2013, Alan DeKok wrote: > Peter Deacon wrote: >> Likewise a server willing to accept RADIUS/UDP and RADIUS/DTLS cannot be >> tricked into accepting RADIUS/UDP as RADIUS/UDP has been configured to >> be acceptable to the server. > See my previous 10 messages for why this reasoning is wrong. To help understand my perspective on this issue here is an example of hypothetical bidding down attack against TLS. TLS Client allows ciphers BAD1,SEC1 TLS Server allows ciphers BAD1,SEC1,SEC2. Normally this leads to negotiation of the best common cipher (SEC1). A bidding down attack occurs when a third party is able to trick peers into using a lower security cipher (BAD1) than necessary. If instead a malicious client connects to TLS server directly using BAD1 cipher this is no longer a bidding down attack. Neither is it the fault of TLS server. The server operator has elected to make a poor choice in allowing BAD1 cipher. (It's the operators fault) Switching to RADIUS the same is applicable. If operator elects to enable RADIUS/UDP and RADIUS/DTLS concurrently the operator has made an explicit decision to accept the implication of this choice. (It's the operators fault) I support attempts to provide recommendations and give operators more options to improve security of their systems such as the migration flag however I don't think the bar for mandating protection of operators from themselves has been met in this instance. regards, Peter From jouni.nospam@gmail.com Tue Apr 9 02:59:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047B621F8E7B; Tue, 9 Apr 2013 02:59:52 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znFejwvlgUwc; Tue, 9 Apr 2013 02:59:51 -0700 (PDT) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id E71A221F9123; Tue, 9 Apr 2013 02:59:50 -0700 (PDT) Received: by mail-ee0-f54.google.com with SMTP id e51so2852301eek.13 for ; Tue, 09 Apr 2013 02:59:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=UctFiYFhFkf420aVPuD7z9Ywc0RckOWP0YwOtSpdUAs=; b=x0+haXdgxbMjSnezNNmAthUD7nWXHssMkFVcmk5iM/dnvHULeA6Gyk0ZYNRzonRh0w bzxIbHtjQ8iq+yZGOObLLxMlt7A/rTUb0jCt9GB6Up6QSK7DcOFBYQEBqWKxD73ruEz9 uw/G/VW4XxnIw9WaY/MbA+sPS0A6IhScF9LdVmyOubBB6+KPXsipoDCAFxUo+bKm2dT1 vnObuhk6NOfAVL8QqbDIbrl4317InbRypg7dyWoHFzcM5X2ei4CINUCSYWxr/xYbbVnZ xqGGNuACuR29iilJHdQvuibiW0Zd8FvyhrT+Z8+Es0iFA6i+uE5s5IC+aGYQSbiAB4LI FkCQ== X-Received: by 10.14.216.2 with SMTP id f2mr58460601eep.44.1365501589930; Tue, 09 Apr 2013 02:59:49 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:39c5:a766:d0ea:341d? ([2001:1bc8:101:f101:39c5:a766:d0ea:341d]) by mx.google.com with ESMTPS id cd3sm27182663eeb.6.2013.04.09.02.59.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 02:59:49 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> Date: Tue, 9 Apr 2013 12:59:46 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> To: Bernie Volz (volz) X-Mailer: Apple Mail (2.1503) Cc: "" , Leaf Yeh , Ted Lemon , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 09:59:52 -0000 On Apr 8, 2013, at 7:25 PM, Bernie Volz (volz) wrote: > (This is with chair hat off! I have to remember to indicate that.) > =20 > > having the server reflect the option back is easy > =20 > The ERO option can be specified to cause the server to send back the = option to the relay. I don=92t think we want to server to =93change=94 = the data in the option. > =20 > I wonder whether Jouni=92s concern is that the server may not send the = client the correct response? But in that case This is my concern and yes, it is not a concern of this document but the = future documents using the OPTION_RADIUS. > you need to assure your server is updated accordingly (to use the new = Radius attribute) and I don=92t see that this is really a concern for = this document? >=20 > We can=92t assume servers would know how to do something for something = that is not yet defined. The =93old=94 server ignoring the attribute in = the option is the correct action until it is updated. Sure. What I am after is a note stating that a _client_ must be prepared for a = reply from a server that does not provide adequate response/information = for all the RADIUS attributes the client included in the request. This = is solely meant for the future specifications using the OPTION_RADIUS. - JOuni > =20 > - Bernie > =20 > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf = Of Ted Lemon > Sent: Monday, April 08, 2013 11:42 AM > To: Leaf Yeh > Cc: ; dhcwg > Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 > =20 > On Apr 8, 2013, at 10:34 AM, Leaf Yeh wrote: > Jouni - it is possible in future when new attributes get added to = registry server silently discarding attributes may lead to a situation = where the server fails to provide enough information back to relay. > =20 > Also, having the server reflect the option back is easy; having it = make changes to the option is actually a protocol update, and probably = not a good idea. > =20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From hartmans@painless-security.com Tue Apr 9 03:27:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B87621F930A for ; Tue, 9 Apr 2013 03:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2PEzaVHE4fo for ; Tue, 9 Apr 2013 03:27:30 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A28AE21F9323 for ; Tue, 9 Apr 2013 03:27:30 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id E32762003E; Tue, 9 Apr 2013 06:26:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id AEF834499; Tue, 9 Apr 2013 06:27:25 -0400 (EDT) From: Sam Hartman To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9F8.4060104@deployingradius.com> Date: Tue, 09 Apr 2013 06:27:25 -0400 In-Reply-To: (Peter Deacon's message of "Tue, 9 Apr 2013 00:41:35 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Alan DeKok Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 09 Apr 2013 10:27:32 -0000 >>>>> "Peter" == Peter Deacon writes: Peter> Normally this leads to negotiation of the best common cipher Peter> (SEC1). Peter> A bidding down attack occurs when a third party is able to Peter> trick peers into using a lower security cipher (BAD1) than Peter> necessary. Peter> If instead a malicious client connects to TLS server directly Peter> using BAD1 cipher this is no longer a bidding down attack. Peter> Neither is it the fault of TLS server. The server operator Peter> has elected to make a poor choice in allowing BAD1 cipher. Peter> (It's the operators fault) Hi. I said I was not going to argue about whether it's a bidding down attack mostly because we could get into arguments like the above. The way to propose looking at this issue is one of the ways that it's often looked at. What Alan proposes is another. However, with your message agreeing to MTI but not mandatory to use, I think we've found a consensus around here so let's not destroy it with semantics. From aland@deployingradius.com Tue Apr 9 05:29:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05CB21F89CF for ; Tue, 9 Apr 2013 05:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fin99-8Tj4Yq for ; Tue, 9 Apr 2013 05:29:01 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDA521F85F5 for ; Tue, 9 Apr 2013 05:29:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E1F712240EBD; Tue, 9 Apr 2013 14:28:24 +0200 (CEST) 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 zXFwp1utGstc; Tue, 9 Apr 2013 14:28:24 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176224750.dsl.bell.ca [70.27.195.238]) by power.freeradius.org (Postfix) with ESMTPSA id 3D3852240E7B; Tue, 9 Apr 2013 14:28:24 +0200 (CEST) Message-ID: <51640966.6060904@deployingradius.com> Date: Tue, 09 Apr 2013 08:28:22 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <1A5FDF7C-9E93-447E-A103-9700349CB2F5@gmail.com> <515C3604.3040406@deployingradius.com> <515ED047.3040200@deployingradius.com> <5160255B.40409@deployingradius.com> <5160B785.8070703@deployingradius.com> <5162C651.2000200@deployingradius.com> <5162F9F8.4060104@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04 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, 09 Apr 2013 12:29:01 -0000 Peter Deacon wrote: > Switching to RADIUS the same is applicable. Only if you ignore the migration mechanism which protects against this. The draft talks about it in detail. I know you're aware of the mechanism. You mention it below, and you've previously claimed it would destroy client-server communication. Because you were ignoring the watchdog method for keeping connections active. I know you're aware of the watchdog mechanism. You've previously claimed that not using it would destroy client-server communication because of idle timeouts. Your solution there was to suggest idle timeouts which wouldn't fix the problem. > I support attempts to provide recommendations and give operators more > options to improve security of their systems such as the migration flag > however I don't think the bar for mandating protection of operators from > themselves has been met in this instance. You haven't said what the "bar" requirements are. That which can be asserted without evidence can be dismissed without evidence. Alan DeKok. From jouni.nospam@gmail.com Tue Apr 9 05:32:09 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6568421F8EEB; Tue, 9 Apr 2013 05:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWeTe-c6sxyE; Tue, 9 Apr 2013 05:32:09 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8615C21F8F1E; Tue, 9 Apr 2013 05:32:08 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so2745679eaj.7 for ; Tue, 09 Apr 2013 05:32:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject:date :message-id:cc:to:mime-version:x-mailer; bh=uDDVf0HHlBnlsGdIU2lTagIwLHH5LvvKf/Ao+8RKHmI=; b=KDy5uzTpUDfrzQ2WemmG2g4NqeyIvr7E807nHCREbQafgYP5of7WNHFvkcRy2JDCs4 En14F48hKWDiSPdEBui2yNa/sSibXyeyG3C9+yc+JR0TVMKHDrtethNakellLVLOtaI0 IU1zwZ+VOAHbMIH6/P2ql7uXu+Dyrd0ixxMomCZY9hlvzroIOzSHMteCnTKMH8APevrp /bUS0lqxK3Zngb1kwZ0+V7Dy71OzJovHxBvMi1O3mYQa4rb2eVJ5Tzr25MA6Jm2Y5ZUH bt9dwJ/rY0g866JXHbSxbCEtm3bv5ZpzZ81qWDV26+Z6e7tRKvLns7xC3zQ0CcH2gozG 8ycg== X-Received: by 10.14.218.66 with SMTP id j42mr13572784eep.46.1365510726433; Tue, 09 Apr 2013 05:32:06 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:39c5:a766:d0ea:341d? ([2001:1bc8:101:f101:39c5:a766:d0ea:341d]) by mx.google.com with ESMTPS id b5sm6017191eew.16.2013.04.09.05.32.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 05:32:05 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 9 Apr 2013 15:32:03 +0300 Message-Id: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com> To: netmod@ietf.org Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) X-Mailer: Apple Mail (2.1503) Cc: "" Subject: [radext] Comment on draft-ietf-netmod-system-mgmt-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 12:32:09 -0000 Folks, AAA-Doctors track on all documents that specify something that relates to AAA protocols (RADIUS/Diameter). In that light we also occasionally provide some early comments before the I-Ds from other WGs enter IETF LC. Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data model for the configuration of the RADIUS client. Has the WG considered additional transports for RADIUS than the original UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is about to complete DTLS (draft-ietf-radext-dtls-04). There are implementations already out in the field. I would envision different transports would have an impact to the data model (transport type, possible TLS cipher details and credentials, etc). Or is there a particular reason for not taking alternative transports into account? - Jouni (RADEXT co-chair) From Ted.Lemon@nominum.com Tue Apr 9 06:53:19 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB31421F8A91; Tue, 9 Apr 2013 06:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.548 X-Spam-Level: X-Spam-Status: No, score=-106.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2m3YDbOnbpgI; Tue, 9 Apr 2013 06:53:17 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD4021F8F33; Tue, 9 Apr 2013 06:53:06 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUWQdQdC7yHKPlMbY/0M1Rb6FZ/Kb3Wvj@postini.com; Tue, 09 Apr 2013 06:53:15 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 86DCC1B89FF; Tue, 9 Apr 2013 06:53:05 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 7B936190061; Tue, 9 Apr 2013 06:53:05 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 06:53:05 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABBMQA= Date: Tue, 9 Apr 2013 13:53:04 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513A36C@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <536E2DDED7E1AF499082A21B5D21FCF2@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Leaf Yeh , Bernie Volz , dhcwg Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 13:53:19 -0000 On Apr 9, 2013, at 5:59 AM, Jouni Korhonen wrote: > What I am after is a note stating that a _client_ must be prepared for a = reply from a server that does not provide adequate response/information for= all the RADIUS attributes the client included in the request. This is sole= ly meant for the future specifications using the OPTION_RADIUS. Yes, I think this would improve the document. From Ted.Lemon@nominum.com Tue Apr 9 07:35:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982EB21F9357; Tue, 9 Apr 2013 07:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.55 X-Spam-Level: X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSOzZevwmguN; Tue, 9 Apr 2013 07:35:48 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2121F9351; Tue, 9 Apr 2013 07:35:47 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUWQnQtaR+E9czanszywpIslpm4ntl344@postini.com; Tue, 09 Apr 2013 07:35:48 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C28AF1B84E5; Tue, 9 Apr 2013 07:35:46 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BAD5A190061; Tue, 9 Apr 2013 07:35:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 07:35:46 -0700 From: Ted Lemon To: Tomek Mrugalski Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAAE1gA== Date: Tue, 9 Apr 2013 14:35:45 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> In-Reply-To: <5164263E.50402@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BA4DDBD5FC67D419AD2C9532C274349@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 14:35:49 -0000 On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski wrote: > On 09.04.2013 11:59, Jouni Korhonen wrote: >> What I am after is a note stating that a _client_ must be prepared >> for a reply from a server that does not provide adequate >> response/information for all the RADIUS attributes the client >> included in the request. This is solely meant for the future >> specifications using the OPTION_RADIUS. > When clarifying that, we must remember to be explicit about which client > or server (radius or dhcpv6) we are talking about here. >=20 > Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 > client. DHCPv6 client will never send it either. DHCPv6 Server will > never send this option back, just receive it from the DHCPv6 relay. Oops, right. So it's the relay that may need to deal with an inappropriat= e response from the DHCP server? From tomasz.mrugalski@gmail.com Tue Apr 9 07:31:32 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD47B21F913E; Tue, 9 Apr 2013 07:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.995 X-Spam-Level: X-Spam-Status: No, score=-2.995 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEScPioFCWNm; Tue, 9 Apr 2013 07:31:32 -0700 (PDT) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id E477421F8F39; Tue, 9 Apr 2013 07:31:31 -0700 (PDT) Received: by mail-ee0-f50.google.com with SMTP id e53so3005951eek.9 for ; Tue, 09 Apr 2013 07:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=Bapb3zlhrTfTh3VOs/vR8+dLWwaAJisVLMNKORPeUN8=; b=p8wBjIslg+mZzAh8xS2S4l41iA0JuZk80tYmcRS9Yf/TWXj9J3Gx3dj56NdN956fNx Lq5iTeyVarfBJervWjcw+BZj9TjXyN5jdmNEcl3HyYkEPOXMT+G//RtQh0RbSUuwd27M 2WfpLBtSpy6ZMp6+De5TtMdsfrikE20gbUad69XodqESXANwDWpQ/ltRLLJLxUsAizrl GquLi25hPOUfWL3zhpMmqohmXvp88EG0IkcpULyJJIUgjYHc+C1yTBkTdgqWx5SsNtJV yceKW+vnumuqVqcotdsFquOJHQz6BJaohA4eUd9MjtV1igj9KAyx8Ox0A9cY9kLliC8C oDJQ== X-Received: by 10.15.21.1 with SMTP id c1mr60104763eeu.36.1365517890650; Tue, 09 Apr 2013 07:31:30 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id d47sm38332200eem.9.2013.04.09.07.31.28 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 07:31:29 -0700 (PDT) Message-ID: <5164263E.50402@gmail.com> Date: Tue, 09 Apr 2013 16:31:26 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: dhcwg@ietf.org, "" References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> In-Reply-To: X-TagToolbar-Keys: D20130409163126087 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 09 Apr 2013 07:54:31 -0700 Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 14:31:33 -0000 On 09.04.2013 11:59, Jouni Korhonen wrote: > What I am after is a note stating that a _client_ must be prepared > for a reply from a server that does not provide adequate > response/information for all the RADIUS attributes the client > included in the request. This is solely meant for the future > specifications using the OPTION_RADIUS. When clarifying that, we must remember to be explicit about which client or server (radius or dhcpv6) we are talking about here. Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 client. DHCPv6 client will never send it either. DHCPv6 Server will never send this option back, just receive it from the DHCPv6 relay. From leaf.yeh.sdo@gmail.com Tue Apr 9 08:10:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A544F21F942C; Tue, 9 Apr 2013 08:10:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWeZRljsLhve; Tue, 9 Apr 2013 08:10:08 -0700 (PDT) Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com [209.85.192.177]) by ietfa.amsl.com (Postfix) with ESMTP id D3EAD21F9397; Tue, 9 Apr 2013 08:10:07 -0700 (PDT) Received: by mail-pd0-f177.google.com with SMTP id u11so3847352pdi.36 for ; Tue, 09 Apr 2013 08:09:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=YMFBVt6RlEMYqMAE/eTpk4ZQeTrxY4dyfPaGI5aCZ1k=; b=tjke9XLIPhnDsXMNVow9xSNn/5ld3GGnKO6Fs7VWt/AO6c4Fh+yUT3Ym++I0iML9tJ QlIfUexe2LDjt4sRChGJotdByTeTCSbNCMkUT4ZOm4+pgH8DacamLO0ItceffAC78n5m X6Nsgd/rhKSZZ22vFYRgKSf6kaUgjnHTaHuXIQ8G5R+JE+9M9E0JKsZcugYBv4j3KvYZ h3Kkt4N9pjGCssPmjjTPe9fXwE1EWd/seznauc+r4cGqGzl/VSxhNAQn/xDz/4US2Ywf 2W+7SjEcmS+iEAC4O//H28jb7nW4qBJV3wbTIWZRRjlFBDVVKYOsfh0dmbkvqrOn7lBg 67rw== X-Received: by 10.68.12.7 with SMTP id u7mr2822264pbb.210.1365520199892; Tue, 09 Apr 2013 08:09:59 -0700 (PDT) Received: from PC ([221.219.107.201]) by mx.google.com with ESMTPS id yi5sm2546282pbb.25.2013.04.09.08.09.56 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Apr 2013 08:09:59 -0700 (PDT) From: "Leaf Yeh" To: "'Ted Lemon'" , "'Tomek Mrugalski'" References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> Date: Tue, 9 Apr 2013 23:09:47 +0800 Message-ID: <51642f47.85a3440a.0bb3.ffffd0ac@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAAE1gP//kLwQ Content-Language: zh-cn Cc: dhcwg@ietf.org, radext@ietf.org Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 15:10:09 -0000 Jouni - ...for all the RADIUS attributes the client included in the request. The DHCPv6 client never include the RADIUS attribute in this draft, the DHCPv6 relay include the RADIUS attribute from the RADIUS client. Ted - So it's the relay that may need to deal with an inappropriate response from the DHCP server? Tomek - DHCPv6 Server will never send this option back,... Tomek's words sounds right in most cases, including those cases described in Fig.1 & 2 of the draft. Best Regards, Leaf -----Original Message----- From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of Ted Lemon Sent: Tuesday, April 09, 2013 10:36 PM To: Tomek Mrugalski Cc: ; Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski wrote: > On 09.04.2013 11:59, Jouni Korhonen wrote: >> What I am after is a note stating that a _client_ must be prepared >> for a reply from a server that does not provide adequate >> response/information for all the RADIUS attributes the client >> included in the request. This is solely meant for the future >> specifications using the OPTION_RADIUS. > When clarifying that, we must remember to be explicit about which > client or server (radius or dhcpv6) we are talking about here. > > Here's DHCPv6 point of view: This DHCPv6 option will never reach > DHCPv6 client. DHCPv6 client will never send it either. DHCPv6 Server > will never send this option back, just receive it from the DHCPv6 relay. Oops, right. So it's the relay that may need to deal with an inappropriate response from the DHCP server? _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Tue Apr 9 08:26:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A463521F9497; Tue, 9 Apr 2013 08:26:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Il5LR9JaCKP8; Tue, 9 Apr 2013 08:26:11 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 52FD421F9733; Tue, 9 Apr 2013 08:26:10 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id h10so2962365eaj.35 for ; Tue, 09 Apr 2013 08:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=XlF+8zH0lY8pU4ObFfs4dBp316HCZHVbtdln9/G7MA8=; b=MZI2C92KCYQcC8CUBbCicnSqeKaXSYpV43RX9rYon0QVk2onOK3tXftoXKLounVJYK /BUZaIp/sQSnicekuVbGkba9VR+E1/93JJReumOoHEcq/ZcO6fG4knQPGVY6c/7QR5vb P6TG0OUw4NfG/0Vcc9+k9Ia76YHXmwv9iLojg1ERxYvixi+cYsgei9+lijUnfuG93FR0 Zvz+qyzIiaOIXApE2Bf/F5fnvVReNpcyhUhmGZ4/fKC+dJuqiCYS9AQwSbZ9oF/MUr+1 6bHSVbRiLTVFvXj99O8m8Nt4ir6YXG8BUla97I/Y7yDC2TVZ+XzuC42KQU+k1mkG5kA7 JyhQ== X-Received: by 10.15.99.201 with SMTP id bl49mr47250811eeb.43.1365521164284; Tue, 09 Apr 2013 08:26:04 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:52b:794d:ebdc:df24? ([2001:1bc8:101:f101:52b:794d:ebdc:df24]) by mx.google.com with ESMTPS id a41sm4397012eei.4.2013.04.09.08.26.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 08:26:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <5164263E.50402@gmail.com> Date: Tue, 9 Apr 2013 18:26:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1503) Cc: dhcwg@ietf.org, "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 15:26:11 -0000 On Apr 9, 2013, at 5:31 PM, Tomek Mrugalski = wrote: > On 09.04.2013 11:59, Jouni Korhonen wrote: >> What I am after is a note stating that a _client_ must be prepared >> for a reply from a server that does not provide adequate >> response/information for all the RADIUS attributes the client >> included in the request. This is solely meant for the future >> specifications using the OPTION_RADIUS. > When clarifying that, we must remember to be explicit about which = client > or server (radius or dhcpv6) we are talking about here. Ops. Good catch. Meant actually relay, not client, but wrote something = else :-)=20 > Here's DHCPv6 point of view: This DHCPv6 option will never reach = DHCPv6 > client. DHCPv6 client will never send it either. DHCPv6 Server will > never send this option back, just receive it from the DHCPv6 relay. I never said server sending the OPTION_RADIUS back. Still confirming = what I meant & asked to be clarified for future use of OPTION_RADIUS (and = whether my concern is valid to begin with): 0) Magic happens.. 1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS including attributes X,Y,Z. 2) DHCP Server does not understand Z and thus responses to the Relay with DHCP options/values based on X & Y only. 3) DHCP Relay receives the response but for it to send a meaningful reply to DHCP Client it would need some DHCP option/value in the reply that reflects the content of the RADIUS attribute Z (that was included into the request sent to Server). 4) what does DHCP Relay do now? - Jouni > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www.ietf.org/mailman/listinfo/dhcwg From tomasz.mrugalski@gmail.com Tue Apr 9 08:08:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B104D21F936C; Tue, 9 Apr 2013 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.865 X-Spam-Level: X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 tests=[FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK6PWleFuAQY; Tue, 9 Apr 2013 08:08:01 -0700 (PDT) Received: from mail-ea0-x22e.google.com (mail-ea0-x22e.google.com [IPv6:2a00:1450:4013:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D1BC821F93A6; Tue, 9 Apr 2013 08:07:57 -0700 (PDT) Received: by mail-ea0-f174.google.com with SMTP id m14so2858685eaj.19 for ; Tue, 09 Apr 2013 08:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=k6O9KQrqqr31/qVj2T06lzy4gLhPYv15vycBG4nSBBY=; b=sypW6d7s4BYFzF2jmtw2WxNxz0H7AXEc74P9DuyvdPoKHWpIJC7H8FyES4eik04W2W GmsNSKKB4c/+ce9jai+C2I/Xp4mDV+RwwbU9TGHcgsogTB9+Efajh+KpGV6b1EBfHFRy uIUMh4hhVYuYebNLqvSPQZMCKjyoi2Dqz0lIFNPAE7CxUOVHmQc+2f7JTETptRrkrpAw 9S8SrzNDRHBTfpn59VVazdNzsZJVq7EY2CKLgOzsT1KTXZe+JYHqUsFx/RMvZRzg66sE rT+htAwrIcTGLYHa8EwyR4ZKW2z+M/051QPOj0VS39kkV9CG24tXKA0n1wvrhNyxEjae Q9+A== X-Received: by 10.15.83.73 with SMTP id b49mr17533416eez.25.1365520076927; Tue, 09 Apr 2013 08:07:56 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id bk42sm20283919eeb.3.2013.04.09.08.07.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 08:07:56 -0700 (PDT) Message-ID: <51642EC7.1010101@gmail.com> Date: Tue, 09 Apr 2013 17:07:51 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Ted Lemon References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> In-Reply-To: <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com> X-TagToolbar-Keys: D20130409170751209 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 09 Apr 2013 08:26:53 -0700 Cc: "" , "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 15:08:01 -0000 On 09.04.2013 16:35, Ted Lemon wrote: > On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski > wrote: >> On 09.04.2013 11:59, Jouni Korhonen wrote: >>> What I am after is a note stating that a _client_ must be prepared >>> for a reply from a server that does not provide adequate >>> response/information for all the RADIUS attributes the client >>> included in the request. This is solely meant for the future >>> specifications using the OPTION_RADIUS. >> When clarifying that, we must remember to be explicit about which client >> or server (radius or dhcpv6) we are talking about here. >> >> Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 >> client. DHCPv6 client will never send it either. DHCPv6 Server will >> never send this option back, just receive it from the DHCPv6 relay. > > Oops, right. So it's the relay that may need to deal with an inappropriate response from the DHCP server? No. Is is the DHCP server. Relay/radius client get some attributes from radius server and then sends it along with the relayed message to the DHCP server. The DHCP server will use that information to select configuration parameters for the dhcp client. If the relay includes some Radius attributes the DHCP server does not recognize, the DHCP server should ignore that particular RADIUS attribute and use those it understands. Server will send response back to the DHCP client via DHCP relay, but that response will not include any RADIUS attributes. From Ted.Lemon@nominum.com Tue Apr 9 09:24:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21C621F8554; Tue, 9 Apr 2013 09:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jIWdDm9Ba3i; Tue, 9 Apr 2013 09:24:50 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by ietfa.amsl.com (Postfix) with ESMTP id 55F5321F8546; Tue, 9 Apr 2013 09:24:50 -0700 (PDT) Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKUWRA0iiHQdBD+snbVOf4x7qi6MGftaCC@postini.com; Tue, 09 Apr 2013 09:24:50 PDT Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 0ED211B889A; Tue, 9 Apr 2013 09:24:50 -0700 (PDT) Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 04819190061; Tue, 9 Apr 2013 09:24:50 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com) Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 09:24:50 -0700 From: Ted Lemon To: Jouni Korhonen Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10 Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAA9AgIAAEG6A Date: Tue, 9 Apr 2013 16:24:49 +0000 Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513AAEA@mbx-01.win.nominum.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> In-Reply-To: <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.1.10] Content-Type: text/plain; charset="Windows-1252" Content-ID: <45CF9C5A6925F7429FEC29232C136A05@nominum.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Tomek Mrugalski , "" , "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 16:24:52 -0000 On Apr 9, 2013, at 11:26 AM, Jouni Korhonen wrote: > 2) DHCP Server does not understand Z and thus responses to the Relay > with DHCP options/values based on X & Y only. This is an administrative error. > 3) DHCP Relay receives the response but for it to send a meaningful > reply to DHCP Client it would need some DHCP option/value in > the reply that reflects the content of the RADIUS attribute Z > (that was included into the request sent to Server). The relay agent _never_ makes any decisions about what to send the client: = that decision is made on the server. Relay agent options can affect how t= he relay gets the response to the client, but do not affect the content of = the response. As a practical matter, it seems unlikely that a future RADIUS option would = affect _how_ the relay agent gets the response back to the client. So I t= hink this particular scenario is not a problem. Going back to the administrative error, it's an error because the administr= ation has configured the RADIUS server and relay to support something but n= eglected to update the DHCP server to support it. I think this failure mo= de is worth documenting, but ultimately it's not something that can be addr= essed in the spec other than as advice to administrators to make sure their= DHCP server supports the added functionality they are hoping to get out of= RADIUS. Sorry for my earlier slightly off-base remarks=97I have quite a few plates = spinning at the moment. From tomasz.mrugalski@gmail.com Tue Apr 9 09:38:35 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038B921F9183; Tue, 9 Apr 2013 09:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.434 X-Spam-Level: X-Spam-Status: No, score=-0.434 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eKTNkwFyVqw; Tue, 9 Apr 2013 09:38:34 -0700 (PDT) Received: from mail-ea0-x236.google.com (mail-ea0-x236.google.com [IPv6:2a00:1450:4013:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD0121F9157; Tue, 9 Apr 2013 09:38:33 -0700 (PDT) Received: by mail-ea0-f182.google.com with SMTP id q15so3017885ead.41 for ; Tue, 09 Apr 2013 09:38:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:x-tagtoolbar-keys:content-type :content-transfer-encoding; bh=cYHGYi5rE+krljM4WYCTcndyTz/+xn/SUCBQD4597Ks=; b=IebUx3+PcLUGKfEgeQxCdDqIarft9lZ5rk+ucqUY9ndUszVtPRjAEuAgcJMRd7jYGa Kv8p7knNNng4MD2utUExAqJNIAGPOWUiLHGuNpraBEPqOy+LmCGOWOukYj26LpiwkVM5 GD7SN3sMTt3jmh8naGVquQS09YD0VH0KiwxS7S0tQiK9fYCsYiqOvtoKZSjfXVO9IKYS BDRBA4vVMgqxtunOu4GzC/JtZyB00GNUhINopYWq3/qcWO1tqwVjVo57n0fRV8rhF7mc d6NC2eIVcrMRSExrDztbrboTzf5DNbazS8gHEsgVvzzlhpXX0Re5fEG773//ZIyxqykL w5lg== X-Received: by 10.14.5.137 with SMTP id 9mr61239229eel.30.1365525513212; Tue, 09 Apr 2013 09:38:33 -0700 (PDT) Received: from [10.0.0.100] (host-109-107-11-157.ip.jarsat.pl. [109.107.11.157]) by mx.google.com with ESMTPS id b5sm7262444eew.16.2013.04.09.09.38.31 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 09:38:32 -0700 (PDT) Message-ID: <51644403.9080206@gmail.com> Date: Tue, 09 Apr 2013 18:38:27 +0200 From: Tomek Mrugalski User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jouni Korhonen References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> In-Reply-To: <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> X-TagToolbar-Keys: D20130409183827957 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 09 Apr 2013 16:38:35 -0000 On 09.04.2013 17:26, Jouni Korhonen wrote: >> Here's DHCPv6 point of view: This DHCPv6 option will never reach DHCPv6 >> client. DHCPv6 client will never send it either. DHCPv6 Server will >> never send this option back, just receive it from the DHCPv6 relay. > > I never said server sending the OPTION_RADIUS back. You didn't, but someone in this thread mentioned something about sending the option back to the client. > Still confirming what I > meant & asked to be clarified for future use of OPTION_RADIUS (and whether > my concern is valid to begin with): > > 0) Magic happens.. > 1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS > including attributes X,Y,Z. > 2) DHCP Server does not understand Z and thus responses to the Relay > with DHCP options/values based on X & Y only. > 3) DHCP Relay receives the response but for it to send a meaningful > reply to DHCP Client it would need some DHCP option/value in > the reply that reflects the content of the RADIUS attribute Z > (that was included into the request sent to Server). > 4) what does DHCP Relay do now? Send the response back to the client, as usual. This is defined in RFC3315, section 20.2, which is a very simple section. Here's the relevant part: The relay agent extracts the message from the Relay Message option and relays it to the address contained in the peer-address field of the Relay-reply message. As simple as that: decapsulate and send to the client. Relay is not supposed to inspect the responses coming back from the server or act as judge of any sort (that response is good and the other is bad, because some DHCP option related to RADIUS attribute is not there). Some relays do deep packet inspection for various reasons (snooping addresses or prefixes for example), but that's an additional thing that do not affect the basic operation - send the response towards the client (or next relay closer to the client if there are more relays). Relays may produce warnings or send some alerts if certain option is missing, but they need to send the resonse back to the client anyway. Otherwise they violate RFC3315 and are not really DHCPv6 relays, but something that acts similar to DHCPv6 relay. Tomek From andy@yumaworks.com Tue Apr 9 08:42:12 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D61E21F976C for ; Tue, 9 Apr 2013 08:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.428 X-Spam-Level: X-Spam-Status: No, score=-0.428 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6QLI5rXhvWx for ; Tue, 9 Apr 2013 08:42:11 -0700 (PDT) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id CC9A021F9771 for ; Tue, 9 Apr 2013 08:42:11 -0700 (PDT) Received: by mail-ie0-f181.google.com with SMTP id 17so8689867iea.12 for ; Tue, 09 Apr 2013 08:42:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=w4fblGZKLnmrs1yXynHQZ2YEcfU4wRj1bJnF26ENqu4=; b=NYEgCrR0TxIhHLiW6+yhmURFnyD0tEVntJb6koX1htlEob2xSsYLNpq36s+60OFJFf I4QWB9rjXpt0bfrEkCKCScRTyzKWDWLEICU2G1rnqvjrCVKZ9pT34ImBCSURTpAe/Nt+ fkdhQGs/jRgZM/gSLs8R5Vj7lAF7jV3s5txtTF1PFwe0qdn1uCjWfapA5UQQTzW12sdK aQJVNK671HGTfHd9b0FETNPMpy70SGc1pGdBAoMS0kxcOpZTMuvA1wuRUVSocFfaj8Yr eRigJXjnv8JK0llDKjuSeA5nWkgzoQYaxBr3dIcJWGlwuiAaNvhiEh5rdQUxDzOm9QkJ pjHQ== MIME-Version: 1.0 X-Received: by 10.42.58.201 with SMTP id j9mr15069025ich.20.1365522131444; Tue, 09 Apr 2013 08:42:11 -0700 (PDT) Received: by 10.231.11.2 with HTTP; Tue, 9 Apr 2013 08:42:11 -0700 (PDT) In-Reply-To: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com> References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com> Date: Tue, 9 Apr 2013 08:42:11 -0700 Message-ID: From: Andy Bierman To: Jouni Korhonen Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlCsB/tFZs5KnZ9CBlJ0wZO2GEwvxqZkldua230QTkc9zUK69G4FId6kn1DBneDJhG92xv/ X-Mailman-Approved-At: Tue, 09 Apr 2013 23:23:06 -0700 Cc: "" , netmod@ietf.org Subject: Re: [radext] [netmod] Comment on draft-ietf-netmod-system-mgmt-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 15:42:12 -0000 On Tue, Apr 9, 2013 at 5:32 AM, Jouni Korhonen wrote: > Folks, > > AAA-Doctors track on all documents that specify something that > relates to AAA protocols (RADIUS/Diameter). In that light we > also occasionally provide some early comments before the I-Ds > from other WGs enter IETF LC. > > Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data > model for the configuration of the RADIUS client. Has the WG > considered additional transports for RADIUS than the original > UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is > about to complete DTLS (draft-ietf-radext-dtls-04). There are > implementations already out in the field. I would envision > different transports would have an impact to the data model > (transport type, possible TLS cipher details and credentials, > etc). Or is there a particular reason for not taking alternative > transports into account? > thanks for the review. How would you suggest adding this support? The radius feature (page 12) references RFC 2865. If the transport is something the server developer picks, then perhaps updating the description and reference statements for this feature is sufficient. If the transport is something the operator picks, then it gets more complicated. E.g., - add a config=false leaf or leaf-list identifying the transports supported by the server - add a config=true leaf to the radius/server list (page 21) specifying the transport for the server to use - add new identity statements for the standard transports > - Jouni (RADEXT co-chair) Andy From mbj@tail-f.com Tue Apr 9 12:25:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE7321F989A; Tue, 9 Apr 2013 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.846 X-Spam-Level: X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhZ7fb+pjupH; Tue, 9 Apr 2013 12:25:15 -0700 (PDT) Received: from mail.tail-f.com (de-2007.d.ipeer.se [213.180.74.102]) by ietfa.amsl.com (Postfix) with ESMTP id 97BB021F98C2; Tue, 9 Apr 2013 12:25:14 -0700 (PDT) Received: from localhost (c213-100-166-57.cust.tele2.se [213.100.166.57]) by mail.tail-f.com (Postfix) with ESMTPSA id 6372F1200A35; Tue, 9 Apr 2013 21:25:13 +0200 (CEST) Date: Tue, 09 Apr 2013 21:25:12 +0200 (CEST) Message-Id: <20130409.212512.301591899.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com> X-Mailer: Mew version 6.5rc2 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 09 Apr 2013 23:23:06 -0700 Cc: radext@ietf.org, jouni.nospam@gmail.com, netmod@ietf.org Subject: Re: [radext] [netmod] Comment on draft-ietf-netmod-system-mgmt-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 19:25:16 -0000 Andy Bierman wrote: > On Tue, Apr 9, 2013 at 5:32 AM, Jouni Korhonen wrote: > > Folks, > > > > AAA-Doctors track on all documents that specify something that > > relates to AAA protocols (RADIUS/Diameter). In that light we > > also occasionally provide some early comments before the I-Ds > > from other WGs enter IETF LC. > > > > Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data > > model for the configuration of the RADIUS client. Has the WG > > considered additional transports for RADIUS than the original > > UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is > > about to complete DTLS (draft-ietf-radext-dtls-04). There are > > implementations already out in the field. I would envision > > different transports would have an impact to the data model > > (transport type, possible TLS cipher details and credentials, > > etc). Or is there a particular reason for not taking alternative > > transports into account? > > > > thanks for the review. > How would you suggest adding this support? > The radius feature (page 12) references RFC 2865. > > If the transport is something the server developer picks, > then perhaps updating the description and reference > statements for this feature is sufficient. > > If the transport is something the operator picks, > then it gets more complicated. E.g., > - add a config=false leaf or leaf-list identifying the transports > supported by the server > - add a config=true leaf to the radius/server list (page 21) > specifying the transport for the server to use > - add new identity statements for the standard transports I think what is needed is more flexibility in the radius server list (note that we only provide client-side configuration; so in the client config we list the servers the client can talk to). Something like this: container radius { list server { key name; ordered-by user; leaf name { type string; // arbitrary name } leaf address { type inet:host; mandatory true; } choice transport { case udp { container udp { leaf authentication-port { ... } leaf shared-secret { ... } } case tcp { container tcp { leaf authentication-port { ... } // RFC 6613 section 2.6.7 talks about config parameters // maybe include them here? } } case tls { leaf port { ... } // what else...? } } } ... } Note that this is an extensible model; other transports can be added or augmented into this structure. One option could be to restructure like this but only actually define the udp case above, and leave the rest (tcp, tls, dtls) for future work. /martin From jouni.nospam@gmail.com Tue Apr 9 23:47:34 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3593421F8C3C; Tue, 9 Apr 2013 23:47:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[AWL=1.799, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DShLm7-mf6GE; Tue, 9 Apr 2013 23:47:33 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1650D21F8E36; Tue, 9 Apr 2013 23:47:32 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id r10so188936lbi.36 for ; Tue, 09 Apr 2013 23:47:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=53Fc3f5BzeRoLkY8f4eU4O4mFE6vzx6srBhIxGjA43I=; b=lt/ZTD8OqevkWC2UuSHM21Gmj33ISzihZZ4G3l58UxNVl+j/UcsKBf6HLE/iyeIqeu Rkxd+1vDUrgPlDahYAqmK5/Vca/Lk8kvGQ6wJz7Yjf7Mux7xYh3vKL6QVDpEzXxa7hk0 7VxSuymupYjUW8VrpI0YJTDRfhGaTar9W3jWSP1LyjLTyuZed0LKvlRBSnMDAoCSx9HU +zUerNvHy+wPmEj5BKnd9luSvRWXEaa20hwv/4Y5c/xcclmzjQsaLQxFUMk5S7BrEhZj bnnpVfCmpNhGZkEbMjF/5DFns3eXwn3JNaXt0eyVrPrOv8eK5Eyv74IxTjzLsKG7cArd Pr0Q== X-Received: by 10.152.87.212 with SMTP id ba20mr405127lab.0.1365576452054; Tue, 09 Apr 2013 23:47:32 -0700 (PDT) Received: from [192.168.250.151] ([194.100.71.98]) by mx.google.com with ESMTPS id 10sm3328323laq.8.2013.04.09.23.47.30 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 23:47:30 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <51644403.9080206@gmail.com> Date: Wed, 10 Apr 2013 09:47:31 +0300 Content-Transfer-Encoding: 7bit Message-Id: <46E1E39C-4256-4AB3-B1B8-AA2701426F3A@gmail.com> References: <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <5164263E.50402@gmail.com> <450791A9-F1A5-41F5-8EE7-8A69C823CE7A@gmail.com> <51644403.9080206@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.1503) Cc: dhcwg@ietf.org, Jouni Korhonen , "" Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10 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, 10 Apr 2013 06:47:34 -0000 > >> Still confirming what I >> meant & asked to be clarified for future use of OPTION_RADIUS (and whether >> my concern is valid to begin with): >> >> 0) Magic happens.. >> 1) DHCP Relay sends a relay-forward to DHCP Server with OPTION_RADIUS >> including attributes X,Y,Z. >> 2) DHCP Server does not understand Z and thus responses to the Relay >> with DHCP options/values based on X & Y only. >> 3) DHCP Relay receives the response but for it to send a meaningful >> reply to DHCP Client it would need some DHCP option/value in >> the reply that reflects the content of the RADIUS attribute Z >> (that was included into the request sent to Server). >> 4) what does DHCP Relay do now? > Send the response back to the client, as usual. This is defined in > RFC3315, section 20.2, which is a very simple section. Here's the > relevant part: > > The relay agent extracts the message from the Relay Message option > and relays it to the address contained in the peer-address field of > the Relay-reply message. > > As simple as that: decapsulate and send to the client. Ok. So this clears my concerns. Thanks for the patience convincing me ;-) - Jouni > > Relay is not supposed to inspect the responses coming back from the > server or act as judge of any sort (that response is good and the other > is bad, because some DHCP option related to RADIUS attribute is not > there). Some relays do deep packet inspection for various reasons > (snooping addresses or prefixes for example), but that's an additional > thing that do not affect the basic operation - send the response towards > the client (or next relay closer to the client if there are more > relays). Relays may produce warnings or send some alerts if certain > option is missing, but they need to send the resonse back to the client > anyway. Otherwise they violate RFC3315 and are not really DHCPv6 relays, > but something that acts similar to DHCPv6 relay. > > Tomek From jouni.nospam@gmail.com Wed Apr 10 23:33:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C59321F8D7A; Wed, 10 Apr 2013 23:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AWL=-0.851, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ykJ5mOqIGFf; Wed, 10 Apr 2013 23:33:00 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id 7AC4821F8D31; Wed, 10 Apr 2013 23:32:59 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ec20so1155893lab.27 for ; Wed, 10 Apr 2013 23:32:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=J7IUzWWov/0EscTT1ADBwkOtjZldJKjb9G8blSTfBc8=; b=gTBRh37cPSj4VNu6cW+sk62o74vpofcVgDvB0wMRnGoMOH7KDhWIMoqASbDyy2PwKq b3MUTHdi3+fS5igZSHb0QanVrHINa7Is2iK3k4qCuPkYCdq10qeMP5fuZ1iwEGQ8bN4+ 7K4SfemO/RsIchtYeDT+6gLEAPuU0PKU7kPh8yTRw4cdiGoARr0m0tWDfannazO7ArQt 6h9de7xooDL69y9FUrQ7Vde+O8pP2NyuED/GzgFDCAf40mO55QFBpSU8fVXl51VpTP78 p02WVzcEzqwJIo+X/0iLXlPEyJzWmStuAj/F1/BY59/mmY3x1k/WaNc18UO/O7OnANM4 w2Zw== X-Received: by 10.112.132.134 with SMTP id ou6mr2568065lbb.45.1365661978398; Wed, 10 Apr 2013 23:32:58 -0700 (PDT) Received: from [192.168.250.235] ([194.100.71.98]) by mx.google.com with ESMTPS id t20sm1202617lbi.5.2013.04.10.23.32.55 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Apr 2013 23:32:56 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <20130409.212512.301591899.mbj@tail-f.com> Date: Thu, 11 Apr 2013 09:32:56 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8F9CE41F-422C-4143-9261-BAF6F71848E8@gmail.com> References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com> <20130409.212512.301591899.mbj@tail-f.com> To: Martin Bjorklund X-Mailer: Apple Mail (2.1503) Cc: radext@ietf.org, jouni.nospam@gmail.com, andy@yumaworks.com, netmod@ietf.org Subject: Re: [radext] [netmod] Comment on draft-ietf-netmod-system-mgmt-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 06:33:00 -0000 Martin, On Apr 9, 2013, at 10:25 PM, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Apr 9, 2013 at 5:32 AM, Jouni Korhonen = wrote: >>> Folks, >>>=20 >>> AAA-Doctors track on all documents that specify something that >>> relates to AAA protocols (RADIUS/Diameter). In that light we >>> also occasionally provide some early comments before the I-Ds >>> from other WGs enter IETF LC. >>>=20 >>> Section 3.4 of draft-ietf-netmod-system-mgmt-05 defines a data >>> model for the configuration of the RADIUS client. Has the WG >>> considered additional transports for RADIUS than the original >>> UDP? RADEXT has defined TCP (RFC6613), TLS (RFC6614) and is >>> about to complete DTLS (draft-ietf-radext-dtls-04). There are >>> implementations already out in the field. I would envision >>> different transports would have an impact to the data model >>> (transport type, possible TLS cipher details and credentials, >>> etc). Or is there a particular reason for not taking alternative >>> transports into account? >>>=20 >>=20 >> thanks for the review. >> How would you suggest adding this support? >> The radius feature (page 12) references RFC 2865. >>=20 >> If the transport is something the server developer picks, >> then perhaps updating the description and reference >> statements for this feature is sufficient. >>=20 >> If the transport is something the operator picks, >> then it gets more complicated. E.g., >> - add a config=3Dfalse leaf or leaf-list identifying the transports >> supported by the server >> - add a config=3Dtrue leaf to the radius/server list (page 21) >> specifying the transport for the server to use >> - add new identity statements for the standard transports >=20 > I think what is needed is more flexibility in the radius server list > (note that we only provide client-side configuration; so in the client > config we list the servers the client can talk to). Something like > this: Something like below would be fine. Of course, it is up to Netmod to decide what goes in and what does not. We just wanted to point out that RADIUS has moved on and there are more tools in the box. I would assume that TLS transport should be interesting for the management folks. - Jouni >=20 > container radius { > list server { > key name; > ordered-by user; >=20 > leaf name { > type string; // arbitrary name > } > leaf address { > type inet:host; > mandatory true; > } > choice transport { > case udp { > container udp { > leaf authentication-port { ... } > leaf shared-secret { ... } > } > case tcp { > container tcp { > leaf authentication-port { ... } > // RFC 6613 section 2.6.7 talks about config parameters > // maybe include them here? > } > } > case tls { > leaf port { ... } > // what else...? > } > } > } > ... > } >=20 > Note that this is an extensible model; other transports can be added > or augmented into this structure. >=20 > One option could be to restructure like this but only actually define > the udp case above, and leave the rest (tcp, tls, dtls) for future > work. >=20 >=20 > /martin >=20 >=20 From jouni.nospam@gmail.com Fri Apr 12 00:02:56 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B6721F8A74 for ; Fri, 12 Apr 2013 00:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.362 X-Spam-Level: X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=1.238, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7I7Cx+eRGgX for ; Fri, 12 Apr 2013 00:02:55 -0700 (PDT) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA2921F84E9 for ; Fri, 12 Apr 2013 00:02:55 -0700 (PDT) Received: by mail-lb0-f181.google.com with SMTP id r11so2363215lbv.12 for ; Fri, 12 Apr 2013 00:02:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=IvcY55fdH56RQY9ra6HHPXgIT0JRTFaACWtNEGnhCUI=; b=VFPYOXS1L+XWmPJ0lvSe3vFbMt5KaSczrDJ1/iXyc/ReMur+fABwp18Sx5Elw94bnj cfzhcQ/ILO4sn01vxIDh2n8NEqo0ASHEfgJ4zAs/JzwwWDjGfPRmkxH5kafv6CltD7jf +OQ4Pq84K0O5jCmWMgljB3TvjO/fE29A1GOY2rGDhydNLk1FqKMbX6k7ns4tRjCfF0wx 09ZVU68HZdfeluhLmjWgKWeiUryv3piZ4+VFJYsWhyblUyUFiccb24vhzpTLO9lldaVz WQqCzu/bOwh+EmUSnU+Mna9+3PCfpklLokw9hcFDwyyz1vplxoGFBswgth0Zh9/G7KHl Psmg== X-Received: by 10.112.147.99 with SMTP id tj3mr4792969lbb.94.1365750174277; Fri, 12 Apr 2013 00:02:54 -0700 (PDT) Received: from [192.168.250.43] ([194.100.71.98]) by mx.google.com with ESMTPS id iq6sm2744043lab.10.2013.04.12.00.02.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Apr 2013 00:02:53 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com> Date: Fri, 12 Apr 2013 10:02:54 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <5C315239-A002-4AC5-8209-D0262E58880E@gmail.com> References: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1503) Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 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, 12 Apr 2013 07:02:56 -0000 Folks, The WGLC has completed successfully for this I-D. The next step will be the Proto Write-Up within approximately one week.=20 - Jouni & Mauricio On Apr 3, 2013, at 10:41 AM, Jouni Korhonen = wrote: > Folks, >=20 > This email starts a quick one week WGLC #2 for "RADIUS Attributes for = IEEE 802 Networks" > I-D (draft-ietf-radext-ieee802ext-04). The WGLC ends 10-Apr-2013. Send = your comments to > the mailer and please also use the IssueTracker. No comments would = this time also imply > that everybody agrees with the content. >=20 > - Jouni & Mauricio From andy@yumaworks.com Fri Apr 12 07:38:34 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8031B21F89DB for ; Fri, 12 Apr 2013 07:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y3RBaLthbJo for ; Fri, 12 Apr 2013 07:38:34 -0700 (PDT) Received: from mail-ia0-x22f.google.com (mail-ia0-x22f.google.com [IPv6:2607:f8b0:4001:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 1400821F884A for ; Fri, 12 Apr 2013 07:38:34 -0700 (PDT) Received: by mail-ia0-f175.google.com with SMTP id e16so2419351iaa.6 for ; Fri, 12 Apr 2013 07:38:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=1A3UdyOjeOMlymiJ1xBKZ0NAdds/GaBtYStuBcc0eyw=; b=MpTyrqHm/2dcqMp67zRK9mUHSQ3Yhz5M4UIf5GoaeEkxYkcoLm/WBJMbuzXZ4K1APe 3aM5rS6yNkrZ00VRxSrlyi5jJDot4OLdyzsbC0YFRz22eQR+GwRScUHUenFMMw0YMLYx zdQtSkkxElskf8G1TI7rkJYqV0O8siT+f1/2qTywzf5d1qISIKt3YBe5lmOWECRrCq4T Ia1j/vJFRky7M4ggrD5k3g/gRAprPGl5yh7BTyiE391C/38mfwGV4nCIiC+h9/wVf2hW eD+l/anZ9WKhUWqE4WgJ0AxZnU/RIJUi2IJARLRfmNjblBMkhZHcsdpcJi3KLIer2h8y L7Ug== MIME-Version: 1.0 X-Received: by 10.50.236.100 with SMTP id ut4mr1821257igc.86.1365777513588; Fri, 12 Apr 2013 07:38:33 -0700 (PDT) Received: by 10.231.125.202 with HTTP; Fri, 12 Apr 2013 07:38:33 -0700 (PDT) In-Reply-To: <20130409.212512.301591899.mbj@tail-f.com> References: <97FEA158-451F-4F48-85B3-5763A6026A8F@gmail.com> <20130409.212512.301591899.mbj@tail-f.com> Date: Fri, 12 Apr 2013 07:38:33 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmGVnYwZ8/mBX5FoTEDIj6O6C5qhz6mYPfhQirZzvrF7ueG/HyMXgiSzrjtGAVC0oAqStw4 X-Mailman-Approved-At: Fri, 12 Apr 2013 07:40:49 -0700 Cc: radext@ietf.org, jouni.nospam@gmail.com, netmod@ietf.org Subject: Re: [radext] [netmod] Comment on draft-ietf-netmod-system-mgmt-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 14:38:34 -0000 .... > container radius { > list server { > key name; > ordered-by user; > > leaf name { > type string; // arbitrary name > } > leaf address { > type inet:host; > mandatory true; > } > choice transport { > case udp { > container udp { > leaf authentication-port { ... } > leaf shared-secret { ... } > } > case tcp { if-feature radius-over-tcp; > container tcp { > leaf authentication-port { ... } > // RFC 6613 section 2.6.7 talks about config parameters > // maybe include them here? > } > } > case tls { if-feature radius-over-tls; > leaf port { ... } > // what else...? > } > } > } > ... > } > > Note that this is an extensible model; other transports can be added > or augmented into this structure. > Re: features: Doesn't the NETCONF server decide what transports it can use, not the client? So new cases need to be optional. > One option could be to restructure like this but only actually define > the udp case above, and leave the rest (tcp, tls, dtls) for future > work. > Or just define the leafs you have here and leave the rest for future work. > > /martin > > Andy From internet-drafts@ietf.org Wed Apr 17 06:43:06 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D121F86F2; Wed, 17 Apr 2013 06:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU0T5-6r5jbF; Wed, 17 Apr 2013 06:43:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7821F8480; Wed, 17 Apr 2013 06:43:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130417134305.1271.64089.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 06:43:05 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 13:43:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : DTLS as a Transport Layer for RADIUS Author(s) : Alan DeKok Filename : draft-ietf-radext-dtls-05.txt Pages : 26 Date : 2013-04-17 Abstract: The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dtls-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-dtls-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From trac+radext@trac.tools.ietf.org Wed Apr 17 06:45:37 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35AFC21E8047 for ; Wed, 17 Apr 2013 06:45:37 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWsBxjot+V1G for ; Wed, 17 Apr 2013 06:45:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 8A89B21E8045 for ; Wed, 17 Apr 2013 06:45:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:55654 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1USSfz-0003hP-B4; Wed, 17 Apr 2013 15:45:31 +0200 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, jouni.nospam@gmail.com, aland@deployingradius.com X-Trac-Project: radext Date: Wed, 17 Apr 2013 13:45:31 -0000 X-URL: http://tools.ietf.org/radext/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/149#comment:2 Message-ID: <074.6ec7abef750b18b89b5ab90d09282212@trac.tools.ietf.org> References: <059.ad1c3a15fdae56f93fecef9b0fcb1ac6@trac.tools.ietf.org> X-Trac-Ticket-ID: 149 In-Reply-To: <059.ad1c3a15fdae56f93fecef9b0fcb1ac6@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, jouni.nospam@gmail.com, 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: <20130417134536.8A89B21E8045@ietfa.amsl.com> Resent-Date: Wed, 17 Apr 2013 06:45:36 -0700 (PDT) Resent-From: trac+radext@trac.tools.ietf.org Cc: radext@ietf.org Subject: Re: [radext] #149: Multiplexing secure and insecure on the same port 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, 17 Apr 2013 13:45:37 -0000 #149: Multiplexing secure and insecure on the same port Changes (by aland@deployingradius.com): * status: new => closed * resolution: => fixed Comment: Version -05 has been updated to allocate a port dedicated to RADIUS/DTLS, with supporting text. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-radext- jsalowey@cisco.com | dtls@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: dtls | Version: Severity: In WG Last | Resolution: fixed Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: radext From aland@deployingradius.com Wed Apr 17 06:54:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7C821F8AA8 for ; Wed, 17 Apr 2013 06:54:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DB517RLnkyB3 for ; Wed, 17 Apr 2013 06:54:09 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0863221F8A85 for ; Wed, 17 Apr 2013 06:54:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A72622240C73 for ; Wed, 17 Apr 2013 15:54:08 +0200 (CEST) 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 jOCOeDH5leSX for ; Wed, 17 Apr 2013 15:54:08 +0200 (CEST) Received: from Thor-2.local (unknown [70.50.217.239]) by power.freeradius.org (Postfix) with ESMTPSA id 1DC042240B9C for ; Wed, 17 Apr 2013 15:54:08 +0200 (CEST) Message-ID: <516EA97E.2000005@deployingradius.com> Date: Wed, 17 Apr 2013 09:54:06 -0400 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] New DTLS document 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, 17 Apr 2013 13:54:16 -0000 http://tools.ietf.org/html/draft-ietf-radext-dtls-05 Which addresses all of the open concerns. Alan DeKok. From jouni.nospam@gmail.com Wed Apr 17 07:04:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B61921F8B13 for ; Wed, 17 Apr 2013 07:04:57 -0700 (PDT) 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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C538mzf8e-bO for ; Wed, 17 Apr 2013 07:04:56 -0700 (PDT) Received: from mail-ia0-x22b.google.com (mail-ia0-x22b.google.com [IPv6:2607:f8b0:4001:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 7A10D21F871C for ; Wed, 17 Apr 2013 07:04:56 -0700 (PDT) Received: by mail-ia0-f171.google.com with SMTP id f27so1475687iae.30 for ; Wed, 17 Apr 2013 07:04:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=E9VEC1OoYHJxe2ypb37SSOfaF0xLE5ycBphDnY4QTuU=; b=KGAAe8gQwIR75ujQ8mSEuc/fux0yQ5NHNZzQechHLnqv/Hyiy6Mx63bpj9xiqUg70U 1qNBIzClHyGldYUIRw5g+htGidLAsvKuX4gydUf1/5kirPydLXqRjofdraY+ivRRCe7S 4brVvp1CstkaZsV4zPpkkG5HflKjGVf7z+kaaaNoLDhbiQyKz03LuX//kSASnWkbzcoZ LgbOO5VsOsoo7IfleTgXmJ2mZJS60KkwBFvQR0f5QKENUrR9Rewc4TlNTF1wiQmCFQDb +qVArwoWjmHahTAv/b/C86sXIJq3MAUYJ1wSHz3rimsDlY1ZKywZE06jTkO1FHPuQ3up lFvQ== MIME-Version: 1.0 X-Received: by 10.50.65.9 with SMTP id t9mr3903231igs.63.1366207496108; Wed, 17 Apr 2013 07:04:56 -0700 (PDT) Received: by 10.231.4.69 with HTTP; Wed, 17 Apr 2013 07:04:55 -0700 (PDT) Received: by 10.231.4.69 with HTTP; Wed, 17 Apr 2013 07:04:55 -0700 (PDT) In-Reply-To: <516EA97E.2000005@deployingradius.com> References: <516EA97E.2000005@deployingradius.com> Date: Wed, 17 Apr 2013 16:04:55 +0200 Message-ID: From: jouni korhonen To: Alan DeKok Content-Type: multipart/alternative; boundary=047d7b3a983a7ec14504da8ef8f2 Cc: radext@ietf.org Subject: Re: [radext] New DTLS document 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, 17 Apr 2013 14:04:57 -0000 --047d7b3a983a7ec14504da8ef8f2 Content-Type: text/plain; charset=ISO-8859-1 Thanks Alan. - Jouni 17.4.2013 16.54 "Alan DeKok" kirjoitti: > http://tools.ietf.org/html/draft-ietf-radext-dtls-05 > > Which addresses all of the open concerns. > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > --047d7b3a983a7ec14504da8ef8f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thanks Alan.

- Jouni

17.4.2013 16.54 "Alan DeKok" <aland@deployingradius.com> k= irjoitti:
http://tools.ietf.org/html/draft-ietf-radext-dtls-05

=A0 Which addresses all of the open concerns.

=A0 Alan DeKok.
_______________________________________________
radext mailing list
radext@ietf.org
= https://www.ietf.org/mailman/listinfo/radext
--047d7b3a983a7ec14504da8ef8f2-- From internet-drafts@ietf.org Wed Apr 17 08:51:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DE521F8E4C; Wed, 17 Apr 2013 08:51:02 -0700 (PDT) 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.083, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjX00nupkwb0; Wed, 17 Apr 2013 08:51:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E1D21F8D46; Wed, 17 Apr 2013 08:51:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130417155101.5964.46381.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 08:51:01 -0700 Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-ieee802ext-05.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 15:51:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the RADIUS EXTensions Working Group of the IE= TF. Title : RADIUS Attributes for IEEE 802 Networks Author(s) : Bernard Aboba Jouni Malinen Paul Congdon Joseph Salowey Mark Jones Filename : draft-ietf-radext-ieee802ext-05.txt Pages : 28 Date : 2013-04-17 Abstract: RFC 3580 provides guidelines for the use of the Remote Authentication Dialin User Service (RADIUS) within IEEE 802 local area networks (LANs). This document proposes additional attributes for use within IEEE 802 networks, as well as clarifications on the usage of the EAP- Key-Name attribute, updating RFC 4072. The attributes defined in this document are usable both within RADIUS and Diameter. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-ieee802ext-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-ieee802ext-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From bernard_aboba@hotmail.com Wed Apr 17 09:01:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFA21F86D5 for ; Wed, 17 Apr 2013 09:01:55 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o40HoBjP6u-x for ; Wed, 17 Apr 2013 09:01:54 -0700 (PDT) Received: from blu0-omc1-s20.blu0.hotmail.com (blu0-omc1-s20.blu0.hotmail.com [65.55.116.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0284E21F86D2 for ; Wed, 17 Apr 2013 09:01:53 -0700 (PDT) Received: from BLU169-W116 ([65.55.116.9]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 17 Apr 2013 09:01:53 -0700 X-EIP: [mGg56KS6QPBg8Glk1CZEeCToBXxQx/4b] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_a7c66948-7424-4bc2-b6da-f8fc2e2747d7_" From: Bernard Aboba To: "Riegel, Maximilian (NSN - DEMunich)" , ext Jouni Korhonen , "radext@ietf.org" Date: Wed, 17 Apr 2013 09:01:53 -0700 Importance: Normal In-Reply-To: References: <4923E335-442A-4369-AF98-CB5059A1DB34@gmail.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 17 Apr 2013 16:01:53.0671 (UTC) FILETIME=[E0FCD170:01CE3B84] Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 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, 17 Apr 2013 16:01:55 -0000 --_a7c66948-7424-4bc2-b6da-f8fc2e2747d7_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you=2C Max for this thorough review. I have submitted an -05 which (= partially) addresses these comments.=20 However=2C given that the draft now references IEEE 802.11 for allocation o= f a number of the attribute values=2C the IANA considerations section will = need to be rewritten. This will be addressed in an -06 revision.=20 > From: maximilian.riegel@nsn.com > To: jouni.nospam@gmail.com=3B radext@ietf.org > Date: Thu=2C 4 Apr 2013 19:55:13 +0000 > CC: radext-chairs@tools.ietf.org > Subject: Re: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 >=20 > There may be a couple of minor=2C mostly editorial issues in draft-ietf-r= adext-ieee802ext-04: >=20 >=20 > - 2.9. WLAN-SSID > The usage statement is missing. > >> add 'A single WLAN-SSID Attribute is permitted within an Access-Accept= or Accounting-Request packet.' >=20 > - 2.10. WLAN-HESSID > The usage statement is missing. > >> add 'A single WLAN-HESSID Attribute is permitted within an Access-Acce= pt or Accounting-Request packet.' > In line 763 the term 'subscription service provider network (SSPN)' is us= ed without any indication=2C that the term has special meaning in IEEE 802.= 11 > >> adding 'as described in [IEEE-802.11].' may provide more clarity.=20 >=20 > - 2.11. WLAN-Venue-Info > WLAN Venue Group and Venue Type is defined without binding dashes in IEEE= 802.11=2C however shown as Venue-Group and Venue-Type in the radext-ieee80= 2ext specification. Furthermore the Length of this attribute is 6 bytes ins= tead of 4 as written. > >> correct Length to '6' > >> use 'Venue Group' and 'Venue Type' instead of 'Venue-Group' and 'Venue= -Type'=2C respectively. > >> probably it would be better to make direct reference to clause 8.4.1.3= 4 of [IEEE-802.11] instead of re-specifying the attribute elements in radex= t-ieee802ext >=20 > - 2.12. WLAN-Venue-Language > The attribute may appear in Accounting-Request messages as well > >>add 'or Accounting-Request' >=20 > - 2.13. WLAN-Venue-Name > The attribute may appear in Accounting-Request messages as well > >>add 'or Accounting-Request' >=20 > - 2.14. WLAN-Reason-Code > The length of this attribute is 6 bytes instead of 4 bytes as written > The usage statement is missing. > >> add 'A single WLAN-Reason-Code Attribute is permitted within a RADIUS = Access-Reject or Accounting-Request packet.' > >> correct Length to '6' >=20 > - 2.15. WLAN-Pairwise-Cipher > The length of this attribute is 6 bytes instead of 4 bytes as written > >> correct Length to '6' >=20 > - 2.16. WLAN-Group-Cipher > The length of this attribute is 6 bytes instead of 4 bytes as written > >> correct Length to '6' >=20 > - 2.17. WLAN-AKM-Suite > The length of this attribute is 6 bytes instead of 4 bytes as written > >> correct Length to '6' >=20 > - 2.18. WLAN-Group-Mgmt-Cipher > The length of this attribute is 6 bytes instead of 4 bytes as written > >> correct Length to '6' >=20 > - 2.19. WLAN-RF-Band > IEEE 802.11ad-2012 is meanwhile available. Therefore the note in lines 11= 85-1191 can be removed with insertion of the proper reference to IEEE 802.1= 1ad-2012. > Furthermore the value field should be directly adopted from Table 8-53a o= f IEEE 802.11ad-2012 instead of defining specific values in the radext-ieee= 802ext specification. Please take into account that the Table 8-53a defines= single octet values=2C while a 4 octets field is defined for this attribut= e. > How are access points handled supporting multiple bands? Shouldn't the at= tribute be allowed multiple times within an Access Request message? >=20 > - 3. Table of attributes > The definition of WLAN-Venue-Language and WLAN-Venue-Name allows multiple= entries within an Access-Request or Accounting-Request message. The table = states that zero or one are present is the Access-Request or Accounting-Req= uest message >=20 >=20 > Bye > Max >=20 >=20 >=20 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf = Of ext Jouni Korhonen > Sent: Wednesday=2C April 03=2C 2013 09:42 > To: radext@ietf.org > Cc: radext-chairs@tools.ietf.org > Subject: [radext] WGLC #2 for draft-ietf-radext-ieee802ext-04 >=20 > Folks=2C >=20 > This email starts a quick one week WGLC #2 for "RADIUS Attributes for IEE= E 802 Networks" > I-D (draft-ietf-radext-ieee802ext-04). The WGLC ends 10-Apr-2013. Send yo= ur comments to > the mailer and please also use the IssueTracker. No comments would this t= ime also imply > that everybody agrees with the content. >=20 > - Jouni & Mauricio > _______________________________________________ > 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 = --_a7c66948-7424-4bc2-b6da-f8fc2e2747d7_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you=2C Max for this thorou= gh review.  =3BI have submitted an -05 which (partially) addresses thes= e comments. =3B

However=2C given that the draft now = references IEEE 802.11 for allocation of a number of the attribute values= =2C the IANA considerations section will need to be rewritten.  =3BThis= will be addressed in an -06 revision. =3B

>=3B From: maximilian.riegel@= nsn.com
>=3B To: jouni.nospam@gmail.com=3B radext@ietf.org
>=3B D= ate: Thu=2C 4 Apr 2013 19:55:13 +0000
>=3B CC: radext-chairs@tools.iet= f.org
>=3B Subject: Re: [radext] WGLC #2 for draft-ietf-radext-ieee802= ext-04
>=3B
>=3B There may be a couple of minor=2C mostly editor= ial issues in draft-ietf-radext-ieee802ext-04:
>=3B
>=3B
>= =3B - 2.9. WLAN-SSID
>=3B The usage statement is missing.
>=3B &g= t=3B>=3B add 'A single WLAN-SSID Attribute is permitted within an Access-= Accept or Accounting-Request packet.'
>=3B
>=3B - 2.10. WLAN-HES= SID
>=3B The usage statement is missing.
>=3B >=3B>=3B add 'A= single WLAN-HESSID Attribute is permitted within an Access-Accept or Accou= nting-Request packet.'
>=3B In line 763 the term 'subscription service= provider network (SSPN)' is used without any indication=2C that the term h= as special meaning in IEEE 802.11
>=3B >=3B>=3B adding 'as describ= ed in [IEEE-802.11].' may provide more clarity.
>=3B
>=3B - 2.1= 1. WLAN-Venue-Info
>=3B WLAN Venue Group and Venue Type is defined wit= hout binding dashes in IEEE 802.11=2C however shown as Venue-Group and Venu= e-Type in the radext-ieee802ext specification. Furthermore the Length of th= is attribute is 6 bytes instead of 4 as written.
>=3B >=3B>=3B cor= rect Length to '6'
>=3B >=3B>=3B use 'Venue Group' and 'Venue Type= ' instead of 'Venue-Group' and 'Venue-Type'=2C respectively.
>=3B >= =3B>=3B probably it would be better to make direct reference to clause 8.= 4.1.34 of [IEEE-802.11] instead of re-specifying the attribute elements in = radext-ieee802ext
>=3B
>=3B - 2.12. WLAN-Venue-Language
>= =3B The attribute may appear in Accounting-Request messages as well
>= =3B >=3B>=3Badd 'or Accounting-Request'
>=3B
>=3B - 2.13. WL= AN-Venue-Name
>=3B The attribute may appear in Accounting-Request mess= ages as well
>=3B >=3B>=3Badd 'or Accounting-Request'
>=3B >=3B - 2.14. WLAN-Reason-Code
>=3B The length of this attribute is= 6 bytes instead of 4 bytes as written
>=3B The usage statement is mis= sing.
>=3B >=3B>=3B add 'A single WLAN-Reason-Code Attribute is pe= rmitted within a RADIUS Access-Reject or Accounting-Request packet.'
>= =3B >=3B>=3B correct Length to '6'
>=3B
>=3B - 2.15. WLAN-Pa= irwise-Cipher
>=3B The length of this attribute is 6 bytes instead of = 4 bytes as written
>=3B >=3B>=3B correct Length to '6'
>=3B <= br>>=3B - 2.16. WLAN-Group-Cipher
>=3B The length of this attribute = is 6 bytes instead of 4 bytes as written
>=3B >=3B>=3B correct Len= gth to '6'
>=3B
>=3B - 2.17. WLAN-AKM-Suite
>=3B The length= of this attribute is 6 bytes instead of 4 bytes as written
>=3B >= =3B>=3B correct Length to '6'
>=3B
>=3B - 2.18. WLAN-Group-Mgm= t-Cipher
>=3B The length of this attribute is 6 bytes instead of 4 byt= es as written
>=3B >=3B>=3B correct Length to '6'
>=3B
&g= t=3B - 2.19. WLAN-RF-Band
>=3B IEEE 802.11ad-2012 is meanwhile availab= le. Therefore the note in lines 1185-1191 can be removed with insertion of = the proper reference to IEEE 802.11ad-2012.
>=3B Furthermore the value= field should be directly adopted from Table 8-53a of IEEE 802.11ad-2012 in= stead of defining specific values in the radext-ieee802ext specification. P= lease take into account that the Table 8-53a defines single octet values=2C= while a 4 octets field is defined for this attribute.
>=3B How are ac= cess points handled supporting multiple bands? Shouldn't the attribute be a= llowed multiple times within an Access Request message?
>=3B
>= =3B - 3. Table of attributes
>=3B The definition of WLAN-Venue-Languag= e and WLAN-Venue-Name allows multiple entries within an Access-Request or A= ccounting-Request message. The table states that zero or one are present is= the Access-Request or Accounting-Request message
>=3B
>=3B
= >=3B Bye
>=3B Max
>=3B
>=3B
>=3B
>=3B -----Or= iginal Message-----
>=3B From: radext-bounces@ietf.org [mailto:radext-= bounces@ietf.org] On Behalf Of ext Jouni Korhonen
>=3B Sent: Wednesday= =2C April 03=2C 2013 09:42
>=3B To: radext@ietf.org
>=3B Cc: rade= xt-chairs@tools.ietf.org
>=3B Subject: [radext] WGLC #2 for draft-ietf= -radext-ieee802ext-04
>=3B
>=3B Folks=2C
>=3B
>=3B Th= is email starts a quick one week WGLC #2 for "RADIUS Attributes for IEEE 80= 2 Networks"
>=3B I-D (draft-ietf-radext-ieee802ext-04). The WGLC ends = 10-Apr-2013. Send your comments to
>=3B the mailer and please also use= the IssueTracker. No comments would this time also imply
>=3B that ev= erybody agrees with the content.
>=3B
>=3B - Jouni &=3B Mauri= cio
>=3B _______________________________________________
>=3B rad= ext mailing list
>=3B radext@ietf.org
>=3B https://www.ietf.org/m= ailman/listinfo/radext
>=3B __________________________________________= _____
>=3B radext mailing list
>=3B radext@ietf.org
>=3B htt= ps://www.ietf.org/mailman/listinfo/radext
= = --_a7c66948-7424-4bc2-b6da-f8fc2e2747d7_-- From jouni.nospam@gmail.com Thu Apr 18 00:26:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B24521F8EBE for ; Thu, 18 Apr 2013 00:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-1.276, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAyJqVb8TpUc for ; Thu, 18 Apr 2013 00:26:18 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A225F21F8E8E for ; Thu, 18 Apr 2013 00:26:17 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id fk20so2014736lab.34 for ; Thu, 18 Apr 2013 00:26:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=hx3GTy3IBgnTd9qFo8F9uOQpvPjeDTrt41zEPCKP8aQ=; b=frQXmVHUk035xSUKXBEvVIupzSElcqTb0NDlasjdsiFoXDyfaYax/BjOSZuSQRaIrS Lw3CbkVc1b3n7KRmFtjDl1z9P1joNqYriC9nHk3H7XIOsolkSMVznifCpFFcb6I1v+nz XBPkeax7ttfPpmLSiMhPgUQpv48m7tXfwE3sEOTDdQ88AwtJeoBR1fZ0FcUvCkGT2Tq7 KYA7Y3Pft1AGFRb0uZralcVNe9w4/33rg1b65lNaUVl91FQVrZ2WPmfKhLYKKqwCm048 sDWfPj1nUaAqEhcNmLhk1LLcMFnjQzSKqYRPA0Kyht/h94wvO6bQJGfiuB5ongx+JBWp Bvfw== X-Received: by 10.152.3.4 with SMTP id 4mr5172504lay.29.1366269976565; Thu, 18 Apr 2013 00:26:16 -0700 (PDT) Received: from [192.168.250.209] ([194.100.71.98]) by mx.google.com with ESMTPS id t6sm3847495lae.3.2013.04.18.00.26.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 18 Apr 2013 00:26:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <516EA97E.2000005@deployingradius.com> Date: Thu, 18 Apr 2013 10:26:15 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <516EA97E.2000005@deployingradius.com> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1503) Cc: Alan DeKok Subject: Re: [radext] New DTLS document 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, 18 Apr 2013 07:26:18 -0000 Folks, Everybody happy with -05 ? If I here no immediate voices of disagreement, we can conclude the WG has reached consensus and the document can move forward. I'll wait till next Monday. - Jouni On Apr 17, 2013, at 4:54 PM, Alan DeKok wrote: > http://tools.ietf.org/html/draft-ietf-radext-dtls-05 > > Which addresses all of the open concerns. > > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From internet-drafts@ietf.org Sun Apr 21 00:43:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F20D21F8F0D; Sun, 21 Apr 2013 00:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.321 X-Spam-Level: X-Spam-Status: No, score=-99.321 tagged_above=-999 required=5 tests=[AWL=-3.004, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iOKc6SLzuufj; Sun, 21 Apr 2013 00:43:54 -0700 (PDT) Received: from jlonline.com (pip46.ptt.js.cn [61.155.13.222]) by ietfa.amsl.com (Postfix) with SMTP id A5AEB21F8ECA; Sun, 21 Apr 2013 00:43:53 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm95173a7f8; Sun, 21 Apr 2013 15:49:41 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm1f7516eb120; Wed, 17 Apr 2013 21:49:27 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Wed, 17 Apr 2013 21:49:27 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6244221F8480; Wed, 17 Apr 2013 06:43:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1366206199; bh=yCOjarWyceurkNIRvP1D43Gr3ZKOI2RLeWkztT/ww7Q=; h=MIME-Version:From:To:Subject:Message-ID:Date:Cc:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=E2E2J4DcxDbbYAunWekW0F49UeASywYTJQ3zgYxgv0xDU4yV0pex5E3+Ly9xGtIuU sjx1FgbKrnH/9slgNJT6kJWsPeStU4ITxXwYXGG9JIBGcfNAdROH+2IOYQZRSMuDyq eiJJkkNpsTP92+xALrENcLqYLzG/ex9AAsZjvP6Y= X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0D121F86F2; Wed, 17 Apr 2013 06:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pU0T5-6r5jbF; Wed, 17 Apr 2013 06:43:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF7821F8480; Wed, 17 Apr 2013 06:43:05 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130417134305.1271.64089.idtracker@ietfa.amsl.com> Date: Wed, 17 Apr 2013 06:43:05 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: BAnj224B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dtls-05.txt X-BeenThere: radext@ietf.org Reply-To: internet-drafts@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 07:43:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : DTLS as a Transport Layer for RADIUS Author(s) : Alan DeKok Filename : draft-ietf-radext-dtls-05.txt Pages : 26 Date : 2013-04-17 Abstract: The RADIUS protocol [RFC2865] has limited support for authentication and encryption of RADIUS packets. The protocol transports data "in the clear", although some parts of the packets can have "obfuscated" content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can co-exist with current RADIUS systems. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dtls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dtls-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dtls-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From peterd@iea-software.com Sun Apr 21 11:43:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDE321F9335 for ; Sun, 21 Apr 2013 11:43:40 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXgNMAg7iiIE for ; Sun, 21 Apr 2013 11:43:40 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 985C521F851C for ; Sun, 21 Apr 2013 11:43:38 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 21 Apr 2013 11:43:34 -0700 Date: Sun, 21 Apr 2013 11:43:33 -0700 (Pacific Daylight Time) From: Peter Deacon To: Jouni Korhonen In-Reply-To: Message-ID: References: <516EA97E.2000005@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] New DTLS document 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, 21 Apr 2013 18:43:40 -0000 On Thu, 18 Apr 2013, Jouni Korhonen wrote: > Folks, > > Everybody happy with -05 ? If I here no immediate Yep, thank you. regards, Peter From jsalowey@cisco.com Sun Apr 21 22:32:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D35A221F8B04 for ; Sun, 21 Apr 2013 22:32:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFyCSkXTjSE8 for ; Sun, 21 Apr 2013 22:32:49 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 0F50021F8AE8 for ; Sun, 21 Apr 2013 22:32:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2923; q=dns/txt; s=iport; t=1366608769; x=1367818369; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2VWojGw/VDb7zseFDWYybeE5fo+A4GLz6lJEZt9+uHE=; b=YUS99yT+CSv4zCnM/T4eAx0ln2SO4w1GSCTbdQVTT29PPR+zUMXUD2tv UpJrO5V2V775p8Veup0pmb13GNIpbCLdQflUZhAKJBDCyQZsna9H2845e +PKQhRwanh7h7JNVCCVmDMzAgUGt+9qcbvYbmKm4JdQtn0xEf5mOX1sF9 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFADDKdFGtJV2Y/2dsb2JhbABPgwY2wQCBAxZ0gh8BAQEDAQEBATc0CxACAQgYChQQIQYLJQIEDgUIh3oDCQYMsTINiV2MaIIkAjEHgmZhA5UxgweKWYUegwyCKA X-IronPort-AV: E=Sophos;i="4.87,524,1363132800"; d="scan'208";a="201441129" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 22 Apr 2013 05:32:48 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3M5WmWg004137 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 05:32:48 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 00:32:48 -0500 From: "Joseph Salowey (jsalowey)" To: Jouni Korhonen Thread-Topic: [radext] New DTLS document Thread-Index: AQHOPxrSUMYvYTIR/ESEOHVAZTrrOg== Date: Mon, 22 Apr 2013 05:32:46 +0000 Message-ID: References: <516EA97E.2000005@deployingradius.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <04CE3E5A5A15EB4B98131D6EA3334946@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] New DTLS document 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, 22 Apr 2013 05:32:49 -0000 I think there are a few inconsistencies that need cleaning-up: - Section 2.2.1 Section 2.5 of RFC 6614 should apply to RADIUS over DTLS since a single por= t is used for all types of RADIUS codes. ( I think the last bullet point i= n section 2.1 should be removed as well.) - Section 5.1.1 This section references a requirement to receive RADIUS/UDP and RADIUS/DTLS= on the same port, this is no longer a requirement. Suggest cleaning up th= e text along the lines of: " ... Implementations that accept RADIUS/DTLS on the RADIUS/UDP port may f= ind this recommendation difficult to implement in practice. ... " - Section 5.1.2 I still have a concern about the disambiguation recommendation since it rel= ies upon a protocol field which is not in control of RADIUS, but it is rath= er in control of DTLS. Its possible that int he future DTLS may choose to = define a new extended handshake type that would use a different type code o= f 22. This would introduce ambiguity and prevent this version of DTLS from= being used with this mechanism. It would be a better, more reliable desig= n to have the disambiguation rely upon something that RADIUS had control ov= er. For example, define a RADIUS code type that encapsulates a RADIUS DTL= S message. =20 Additionally section 5.1.2 should clarify that it only applies to implement= ations that accept RADIUS/DTLS on the RADIUS/UDP port=20 - Section 5.1.3=20 Most of this section applies to implementations that accept RADIUS/DTLS on = the RADIUS/UDP port. THis section should clarify this. I think the last 3= paragraphs are generic and can be moved to a a different section, such as = 5.1.1. - Section 9 We could request the same port as RADSEC. Something like: IANA is requested to assign a registered UDP port number for RADIUS over D= TLS. The same values as for RADIUS over TLS (RFC6614) are requested. That= is, update the registry as follows: radius-dtls 2083/udp RADIUS over DTLS [RFCTBD] On Apr 18, 2013, at 12:26 AM, Jouni Korhonen wrote= : >=20 > Folks, >=20 > >=20 > Everybody happy with -05 ? If I here no immediate=20 > voices of disagreement, we can conclude the WG > has reached consensus and the document can move > forward. I'll wait till next Monday. >=20 > - Jouni >=20 >=20 >=20 > On Apr 17, 2013, at 4:54 PM, Alan DeKok wrote= : >=20 >> http://tools.ietf.org/html/draft-ietf-radext-dtls-05 >>=20 >> Which addresses all of the open concerns. >>=20 >> Alan DeKok. >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From johnsonhammond1@hushmail.com Sat Apr 27 10:26:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90A7D21F9821 for ; Sat, 27 Apr 2013 10:26:50 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm-0jKD4UsFx for ; Sat, 27 Apr 2013 10:26:50 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 6338721F96CD for ; Sat, 27 Apr 2013 10:26:50 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 2A2363053D for ; Sat, 27 Apr 2013 17:26:50 +0000 (UTC) Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:26:49 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id E2321E6736; Sat, 27 Apr 2013 17:26:49 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:26:49 -0400 To: radext@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427172649.E2321E6736@smtp.hushmail.com> Subject: [radext] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 18:32:36 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From jouni.nospam@gmail.com Mon Apr 29 01:32:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A63521F9763 for ; Mon, 29 Apr 2013 01:32:24 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvgBD6vVCfiJ for ; Mon, 29 Apr 2013 01:32:24 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id A2B0E21F9497 for ; Mon, 29 Apr 2013 01:32:20 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id em20so1911453lab.6 for ; Mon, 29 Apr 2013 01:32:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=zz7PqHekF2+19KVWdVcKw1scOTqCFP1P/ArX5sPecTA=; b=FNIkPhLRRVqoGPpvOiIWOCB8YRIlkdTKpV8uwlG86dPqQQJmOyKAGLIM8tss9E/bVI +oKV8Sl+MX9H9jo9gd9L5D7NsGSJ3mPDIgzRmKHhYDhiUZb9WX3H3ZWZuQJ6xN507P1S ZU1uo81z98/LWWrhpfeNQ1NhEc0i735JYYn5qif31zGMadhcxZCDy8OM1Im2q+ar4GBH wnJcafbtuYVvJfsYwoyFyD4noxI5sKOXXe9J9Bz/6YNV3mr+E6JUBTW9a7mrcs+H0IKS MRDDIfb4JrtPK4+Ai6LtU9M7EO403VeHVjYr/lrCuqK7J2IzI0xUDdcP/O2yYFuL5srp kroQ== X-Received: by 10.112.161.97 with SMTP id xr1mr26838869lbb.15.1367224339556; Mon, 29 Apr 2013 01:32:19 -0700 (PDT) Received: from [192.168.250.191] ([194.100.71.98]) by mx.google.com with ESMTPSA id u2sm9389988lag.7.2013.04.29.01.32.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 01:32:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: Date: Mon, 29 Apr 2013 11:32:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> References: <516EA97E.2000005@deployingradius.com> To: "Joseph Salowey (jsalowey)" , Alan DeKok X-Mailer: Apple Mail (2.1503) Cc: radext@ietf.org, Jouni Korhonen Subject: Re: [radext] New DTLS document 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, 29 Apr 2013 08:32:24 -0000 Thanks Joe for detailed comments. Just few generic questions to the WG. 1) Do you agree with Joe's suggestion to use the same port as RADSEC: radius-dtls 2083/udp RADIUS over DTLS [RFCTBD] 2) Do you think Joe's concern on Section 5.1.2 "disambiguation = recommendation" is something that need to be reconsidered..=20 - Jouni On Apr 22, 2013, at 8:32 AM, Joseph Salowey (jsalowey) = wrote: > I think there are a few inconsistencies that need cleaning-up: >=20 > - Section 2.2.1 >=20 > Section 2.5 of RFC 6614 should apply to RADIUS over DTLS since a = single port is used for all types of RADIUS codes. ( I think the last = bullet point in section 2.1 should be removed as well.) >=20 > - Section 5.1.1 >=20 > This section references a requirement to receive RADIUS/UDP and = RADIUS/DTLS on the same port, this is no longer a requirement. Suggest = cleaning up the text along the lines of: >=20 > " ... Implementations that accept RADIUS/DTLS on the RADIUS/UDP port = may find this recommendation difficult to implement in > practice. ... " >=20 > - Section 5.1.2 >=20 > I still have a concern about the disambiguation recommendation since = it relies upon a protocol field which is not in control of RADIUS, but = it is rather in control of DTLS. Its possible that int he future DTLS = may choose to define a new extended handshake type that would use a = different type code of 22. This would introduce ambiguity and prevent = this version of DTLS from being used with this mechanism. It would be a = better, more reliable design to have the disambiguation rely upon = something that RADIUS had control over. For example, define a RADIUS = code type that encapsulates a RADIUS DTLS message. =20 >=20 > Additionally section 5.1.2 should clarify that it only applies to = implementations that accept RADIUS/DTLS on the RADIUS/UDP port=20 >=20 > - Section 5.1.3=20 >=20 > Most of this section applies to implementations that accept = RADIUS/DTLS on the RADIUS/UDP port. THis section should clarify this. = I think the last 3 paragraphs are generic and can be moved to a a = different section, such as 5.1.1. >=20 >=20 > - Section 9 >=20 > We could request the same port as RADSEC. Something like: >=20 > IANA is requested to assign a registered UDP port number for RADIUS = over DTLS. The same values as for RADIUS over TLS (RFC6614) are = requested. That is, update the registry as follows: >=20 > radius-dtls 2083/udp RADIUS over DTLS [RFCTBD] >=20 >=20 >=20 >=20 >=20 >=20 > On Apr 18, 2013, at 12:26 AM, Jouni Korhonen = wrote: >=20 >>=20 >> Folks, >>=20 >> >>=20 >> Everybody happy with -05 ? If I here no immediate=20 >> voices of disagreement, we can conclude the WG >> has reached consensus and the document can move >> forward. I'll wait till next Monday. >>=20 >> - Jouni >>=20 >>=20 >>=20 >> On Apr 17, 2013, at 4:54 PM, Alan DeKok = wrote: >>=20 >>> http://tools.ietf.org/html/draft-ietf-radext-dtls-05 >>>=20 >>> Which addresses all of the open concerns. >>>=20 >>> Alan DeKok. >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >>=20 >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 From stefan.winter@restena.lu Mon Apr 29 07:13:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E067121F9402; Mon, 29 Apr 2013 07:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.916 X-Spam-Level: X-Spam-Status: No, score=0.916 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_45=0.6, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6Qb3lcZ-oiz; Mon, 29 Apr 2013 07:13:10 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1112F21F99FB; Mon, 29 Apr 2013 07:13:10 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 977621057F; Mon, 29 Apr 2013 16:13:08 +0200 (CEST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 87B5D1057D; Mon, 29 Apr 2013 16:13:08 +0200 (CEST) Message-ID: <517E7FF4.1050009@restena.lu> Date: Mon, 29 Apr 2013 16:13:08 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130329 Thunderbird/17.0.5 MIME-Version: 1.0 To: "" , "radext@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CQMXGCKNDSRLOOIDTTDG" X-Virus-Scanned: ClamAV Subject: [radext] Improving EAP usability and deployment security: call for participants 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, 29 Apr 2013 14:13:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CQMXGCKNDSRLOOIDTTDG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, (and sorry for being slightly off-topic) I'm writing this mail as someone who is heavily involved with deploying Enterprise WiFi to millions of end users, belonging to thousands of independent administrative domains, all of which have their own EAP deployment and associated supplicant configuration needs - the eduroam roaming consortium (you may want to look at http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-00 for a description of the consortium and its inner workings). Over the ten years of operation of eduroam, we have seen the good, the bad, and the ugly of supplicants, and realised that even if there are excellent technical specifications (IEEE 802.11i, IEEE 802.1X, EAP, various EAP types, RADIUS, ...), the real world deployments of these specifications aren't always as perfect as they should be. One of the biggest complaints we hear from end users is the effort of initial supplicant setup, and sometimes the sad fact that users are either DoSed because their device doesn't support any EAP type which matches their organisation's deployment; or that the supplicant setup is only possible with leaving gaping security holes open (e.g. not possible to specify which CA issued the EAP server certificate!). We believe that there is a lot of potential in the implementation space to take EAP peers - 802.1X supplicants - to a new level of a) implementation completeness b) user-friendly interactive configuration c) automated configuration deployment (a.k.a. "profiles") There is currently a call for participants in a European project where one of the topics on call is "IEEE 802.1X and EAP - Improving Implementation Completeness and User-Friendliness". It's call #16 of the list on this page: http://www.geant.net/opencalls -> "Call Text" My employer and other organisations are in the process of forming a consortium to reply to this call and we are looking for further partners - in particular industry partners who implement supplicants and ship them in their products; the main goals of the consortium-to-be is to develop guidelines for UI design, cornerstones for implementation of EAP in supplicants, and a standard interface for conveying EAP configuration data ("EAP metadata") to the supplicants for automatic configuration provisioning - and of course to have partners who are willing to implement these guidelines! Why should you join? The benefit for you as a supplicant implementor to join the project is that you'll get valuable input and suggestions for improving your product - which will ultimately give you an advantage on the market compared to other implementations which don't participate. The time your workforce spends in this project will be partially compensated for according to normal European Commission project rules (I'm not a finance guy, so just as a non-authoritative indication: with exceptions, only European entities can be compensated; up to a maximum of 50%-75% of the workforce expenditure plus overhead (subject to several conditions)). The slide deck of the "Information Day" regarding this call which was held on 19 April may give you more specific detail; slide 54 f. are about this particular objective. Also check out the FAQ! http://www.geant.net/opencalls -> "Information Day" http://www.geant.net/opencalls -> "FAQ" If you or your company are interested in joining this consortium, please get in touch with me (off-list; stefan.winter@restena.lu ). Note that while I'm recruiting for this project-to-be, my company will very likely not take the consortium leadership role but be a mere member of the consortium. Thanks for your attention! For those who care, a number of real-life imperfections is below. Greetings, Stefan Winter There are numerous examples of imperfection; I do not believe that a single perfect supplicant exists. So, when I give a few examples below please understand them as random specimen of the world out there, not as a particular name&shame for the company names in these examples. It just goes to show that there is work in this for everyone :-) Example 1: EAP identity has a 1:1 mapping with an SSID =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D Apple, Inc. has a very powerful tool for deployment of WiFi configuration profiles to recent Mac devices and i* mobile devices using their "mobileconfig" file format. Unfortunately, the file format assumes that the SSID is the primary discriminator of networks, and that an EAP identity is a property of an SSID. As a consequence, if an Enterprise WiFi deployment uses multiple SSIDs, all to be used with the same EAP identity, these need to be configured independently. This is not just a question of deployer's convenience when crafting the config files: it transpires down to the end user, who has to enter his username and password "n" times while installing the profile, once for each SSID in the set - even if the account information is identical. This approach also makes uses in the new Hotspot 2.0 / IEEE 802.11 Interworking difficult. An automated configuration file format should have the richness to define an EAP identity, and in a 1:n mapping any number and form of applicable uses for this EAP identity; sth like "This EAP identity is good for the SSIDs 'ietf-1x', 'ietf-1x-11n', all networks of the consortium "ca:fe:ba:be", the wired 802.1X network with the network ID 'foo' and for all ABFAB uses". Devices consuming this configuration should only ask for and store the user credentials /once/ and use them for all defined use cases automatically. Example 2: Mutual Authentication doesn't verify exact server identity =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Google, Inc.'s Android operating system supplicant allows a user to specify the CA which the EAP server's server certificate has to be issued from. It does not allow to specify the Subject of the expected incoming certificate. If the EAP server has a certificate which is issued from a large ("commercial") CA, an attacker can request an unrelated certificate from the same CA, set up a fake EAP server and trick the user to connect to the associated network. The supplicant will not be able to detect that the server is not his proper EAP server, and will release the user credentials to that unauthorised server. Example 3: Mutual Authentication not possible =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Microsoft, Inc. has various implementations of EAP for various platforms. One of those is Windows Phone 7, which supports EAP (at least EAP type PEAP). Technically, an EAP conversation with mutual authentication is carried out (i.e. the supplicant requires the server to send a server certificate prior to releasing the client credentials); but the device does not allow to specify which server certificate from which CA to expect. As a consequence, arbitrary third parties can craft their own CA and server certificate and present this; or have a commercial CA issue a unrelated certificate for them - and the client credentials are released to these third parties. Windows Phone 8 has become better (as bad as Example 2) by adding the possibility to add the CA certificate validation but as in the case of Example 2, there is no place for server identity verification. Example 4: Suboptimal User Interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The K Desktop Environment's user interface for WiFi configuration, KNetworkManager, mixes user authentication details and server-side authentication details into one single dialog with no clear distinction. E.g. when selecting using EAP-TLS, there is one single list of visual elements for user(U) and server-side(S) details like (U) Identity (U) User Certificate (S) Server Certificate (S) Use System CA certificates (S) Connect to these Servers (U) Private Key (U) Private Key Password The "System CA" checkbox for server-side credential checks is also dangerous by making the connection insecure - more than the exact one CA to be trusted would be permitted then. Offering such an option is counter-productive. Supplicants should give a clear indication that mutual authentication is taking place, and should separate user authentication from server authentication UI elements for clarity when configuring interactively. Example 5: Unhelpful advice on failed authentications =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D In case of an unsuccessful authentication, many supplicants disregard the exact state of the EAP state machine and simply convey a simplistic error message to the user: "Probably your password was wrong." An ideal EAP implementation would examine the state machine, and depending on the moment the failure occured give accurate advice to the user. E.g.: If the the initial EAP-Response/Identity was sent, but no reply ever came back, then the error is unrelated to the user's password; no EAP conversation was established with the other end even. A useful error message in this case would be "Unable to contact the authentication server. Please try again later, or check your username." Example 6: no EAP support on WiFi interface =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D There are also end-user computing devices which allow to connect to WiFi, but do not support EAP authentication / 802.11i Enterprise at all. One recent example is FirefoxOS, which does not currently allow users to log into enterprise WiFi networks. --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2CQMXGCKNDSRLOOIDTTDG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlF+f/QACgkQ+jm90f8eFWY/XQCgi+UhPzF8L2cfl61x3Pm4xEzo 2doAnjyaJBe77iGUOXn280VHt3hrMZUE =VWVd -----END PGP SIGNATURE----- ------enig2CQMXGCKNDSRLOOIDTTDG-- From hartmans@painless-security.com Mon Apr 29 08:24:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E74C21F9D98 for ; Mon, 29 Apr 2013 08:24:54 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ctv5g2clZ0lr for ; Mon, 29 Apr 2013 08:24:53 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9245B21F9D42 for ; Mon, 29 Apr 2013 08:24:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6A62C20248; Mon, 29 Apr 2013 11:22:46 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XxDxd61oNIn; Mon, 29 Apr 2013 11:22:44 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 29 Apr 2013 11:22:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 014FD4499; Mon, 29 Apr 2013 11:24:41 -0400 (EDT) From: Sam Hartman To: Jouni Korhonen References: <516EA97E.2000005@deployingradius.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> Date: Mon, 29 Apr 2013 11:24:41 -0400 In-Reply-To: <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> (Jouni Korhonen's message of "Mon, 29 Apr 2013 11:32:28 +0300") 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, "Joseph Salowey \(jsalowey\)" , Alan DeKok Subject: Re: [radext] New DTLS document 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, 29 Apr 2013 15:24:54 -0000 Question: is the text Joe is concerned about still intended to be in the draft? That is, do we still want to specify running both over the same port as an option? From aland@deployingradius.com Mon Apr 29 11:16:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 288BE21F8480 for ; Mon, 29 Apr 2013 11:16:40 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id clG+OrHAki35 for ; Mon, 29 Apr 2013 11:16:34 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3147B21F8206 for ; Mon, 29 Apr 2013 11:16:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CAE792241035; Mon, 29 Apr 2013 20:15:43 +0200 (CEST) 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 0VzCFcqsYHWZ; Mon, 29 Apr 2013 20:15:43 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121151.dsl.bell.ca [70.26.47.63]) by power.freeradius.org (Postfix) with ESMTPSA id E8FFE2240FF8; Mon, 29 Apr 2013 20:15:42 +0200 (CEST) Message-ID: <517EB8CE.3020805@deployingradius.com> Date: Mon, 29 Apr 2013 14:15:42 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <516EA97E.2000005@deployingradius.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Jouni Korhonen , "Joseph Salowey \(jsalowey\)" Subject: Re: [radext] New DTLS document 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, 29 Apr 2013 18:16:40 -0000 Sam Hartman wrote: > Question: is the text Joe is concerned about still intended to be in the > draft? > That is, do we still want to specify running both over the same port as > an option? It's still in the draft, as a migration step. The text in the draft says that implementations should migrate to either using a dedicated port, or to only allowing DTLS over the traditional ports. Alan DeKok. From hartmans@painless-security.com Mon Apr 29 11:24:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AB321F9AEA for ; Mon, 29 Apr 2013 11:24:37 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUokNqiKcD9j for ; Mon, 29 Apr 2013 11:24:31 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D9C5321F9AD1 for ; Mon, 29 Apr 2013 11:24:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 9382F202AE; Mon, 29 Apr 2013 14:22:19 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_9dQh7l8Hue; Mon, 29 Apr 2013 14:22:19 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 29 Apr 2013 14:22:19 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2719F4499; Mon, 29 Apr 2013 14:24:17 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <516EA97E.2000005@deployingradius.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> <517EB8CE.3020805@deployingradius.com> Date: Mon, 29 Apr 2013 14:24:17 -0400 In-Reply-To: <517EB8CE.3020805@deployingradius.com> (Alan DeKok's message of "Mon, 29 Apr 2013 14:15:42 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Jouni Korhonen , "Joseph Salowey \(jsalowey\)" Subject: Re: [radext] New DTLS document 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, 29 Apr 2013 18:24:38 -0000 Ok. I have no comments on Joe's issues. I just wanted to make sure that it was not an editing artifact. --Sam From wwwrun@rfc-editor.org Mon Apr 29 11:50:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51A221F9AC5; Mon, 29 Apr 2013 11:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+dgFHRMiyHR; Mon, 29 Apr 2013 11:50:38 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id B2B0F21F9B06; Mon, 29 Apr 2013 11:50:21 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EBA71B1E008; Mon, 29 Apr 2013 11:49:52 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130429184952.EBA71B1E008@rfc-editor.org> Date: Mon, 29 Apr 2013 11:49:52 -0700 (PDT) Cc: radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 6911 on RADIUS Attributes for IPv6 Access Networks 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, 29 Apr 2013 18:50:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6911 Title: RADIUS Attributes for IPv6 Access Networks Author: W. Dec, Ed., B. Sarikaya, G. Zorn, Ed., D. Miles, B. Lourdelet Status: Standards Track Stream: IETF Date: April 2013 Mailbox: wdec@cisco.com, sarikaya@ieee.org, glenzorn@gmail.com, davidmiles@google.com, blourdel@juniper.net Pages: 15 Characters: 28123 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-radext-ipv6-access-16.txt URL: http://www.rfc-editor.org/rfc/rfc6911.txt This document specifies additional IPv6 RADIUS Attributes useful in residential broadband network deployments. The Attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and an IPv6 DNS server address via DHCPv6, assignment of an IPv6 route announced via router advertisement, assignment of a named IPv6 delegated prefix pool, and assignment of a named IPv6 pool for host DHCPv6 addressing. This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From peterd@iea-software.com Mon Apr 29 14:39:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0651221F9B64 for ; Mon, 29 Apr 2013 14:39:45 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0mpMYxHWdK2e for ; Mon, 29 Apr 2013 14:39:39 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id A777721F9B3C for ; Mon, 29 Apr 2013 14:39:39 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 29 Apr 2013 14:39:38 -0700 Date: Mon, 29 Apr 2013 14:39:35 -0700 (Pacific Daylight Time) From: Peter Deacon To: Jouni Korhonen In-Reply-To: <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> Message-ID: References: <516EA97E.2000005@deployingradius.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org, "Joseph Salowey \(jsalowey\)" , Alan DeKok Subject: Re: [radext] New DTLS document 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, 29 Apr 2013 21:39:45 -0000 On Mon, 29 Apr 2013, Jouni Korhonen wrote: > Thanks Joe for detailed comments. Just few generic questions to the WG. > 1) Do you agree with Joe's suggestion to use the same port as RADSEC: > radius-dtls 2083/udp RADIUS over DTLS [RFCTBD] Yep > 2) Do you think Joe's concern on Section 5.1.2 "disambiguation recommendation" > is something that need to be reconsidered.. This does not seem to be difficult to mitigate against. I think any of the following would be an improvement: Either 4-byte or single byte header. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Session ID (Issue #64) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DTLS ... or +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | DTLS ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ or Removal of disambiguation. DTLS implementations expected to use DTLS port. Would prefer any of the above changes with a preference for removal of disambiguation however also willing to live with draft as-is. regards, Peter From jouni.nospam@gmail.com Mon Apr 29 23:54:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC6921F9BE3 for ; Mon, 29 Apr 2013 23:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OdZdAGcs2UNY for ; Mon, 29 Apr 2013 23:54:50 -0700 (PDT) Received: from mail-lb0-f170.google.com (mail-lb0-f170.google.com [209.85.217.170]) by ietfa.amsl.com (Postfix) with ESMTP id 6522421F9BB9 for ; Mon, 29 Apr 2013 23:54:50 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id r10so232118lbi.1 for ; Mon, 29 Apr 2013 23:54:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=VDsQUXhS91Gc4khiQbddvnoJ2xREEYcA/nFtAQmW++c=; b=iOrX3aD0+9uQN2O2Yfp5wJtg8ZNAsqDh3SaFep4cn302rsomPXaC5krqqxHPxfXzTQ +1PJLcG1b1BLsw9CD0i0eUtxDbUm8uBfOZfxMoMAZ2rQReL4XRqINfuVKTOPAS6iMHIv Wx+QwlByyocHHUeZ+rPZOFzVfkyulvNu20UOMqzZjgeq7hF5jq1gtslw6N7wmZva90e9 uTLvBCw2n6BppvNK6skEDOQ919Hiyd6ewTasFsBLsaX4OIuBM7PRn7X1qwlCS0gyXQ8c vPmlRRnOrR97XkoyfnSwVRp6DaJg1GQPnwNssQC5K5U8qe65rW8K2uNDmBmC3RPTK/09 r1PQ== X-Received: by 10.112.147.170 with SMTP id tl10mr27843434lbb.100.1367304881889; Mon, 29 Apr 2013 23:54:41 -0700 (PDT) Received: from [192.168.250.203] ([194.100.71.98]) by mx.google.com with ESMTPSA id m9sm3262414lag.10.2013.04.29.23.54.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Apr 2013 23:54:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Jouni Korhonen In-Reply-To: <20130429184952.EBA71B1E008@rfc-editor.org> Date: Tue, 30 Apr 2013 09:54:53 +0300 Content-Transfer-Encoding: 7bit Message-Id: <63AAB07F-3BED-4BD5-9AD3-2FB9B4454A38@gmail.com> References: <20130429184952.EBA71B1E008@rfc-editor.org> To: "radext@ietf.org" X-Mailer: Apple Mail (2.1503) Subject: [radext] New RFC 6911 on RADIUS Attributes for IPv6 Access Networks 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, 30 Apr 2013 06:54:55 -0000 Congratulations to the authors and thanks for the hard work. - Jouni & Mauricio On Apr 29, 2013, at 9:49 PM, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. > > > RFC 6911 > > Title: RADIUS Attributes for IPv6 Access > Networks > Author: W. Dec, Ed., > B. Sarikaya, > G. Zorn, Ed., > D. Miles, > B. Lourdelet > Status: Standards Track > Stream: IETF > Date: April 2013 > Mailbox: wdec@cisco.com, > sarikaya@ieee.org, > glenzorn@gmail.com, > davidmiles@google.com, > blourdel@juniper.net > Pages: 15 > Characters: 28123 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-radext-ipv6-access-16.txt > > URL: http://www.rfc-editor.org/rfc/rfc6911.txt > From aland@deployingradius.com Tue Apr 30 05:46:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A09921F98C9 for ; Tue, 30 Apr 2013 05:46:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvVo+f2CRDF6 for ; Tue, 30 Apr 2013 05:46:40 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8613421F91A3 for ; Tue, 30 Apr 2013 05:46:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 36E942240EBD; Tue, 30 Apr 2013 14:45:58 +0200 (CEST) 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 GzCp1zhO1Y0w; Tue, 30 Apr 2013 14:45:57 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121151.dsl.bell.ca [70.26.47.63]) by power.freeradius.org (Postfix) with ESMTPSA id 57F922240842; Tue, 30 Apr 2013 14:45:57 +0200 (CEST) Message-ID: <517FBD04.1050009@deployingradius.com> Date: Tue, 30 Apr 2013 08:45:56 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <516EA97E.2000005@deployingradius.com> <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> In-Reply-To: <0E1BBA4B-1985-43C3-800A-AF336CABEF30@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, "Joseph Salowey \(jsalowey\)" Subject: Re: [radext] New DTLS document 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, 30 Apr 2013 12:46:46 -0000 Jouni Korhonen wrote: > Thanks Joe for detailed comments. Just few generic questions to the WG. > > 1) Do you agree with Joe's suggestion to use the same port as RADSEC: > > radius-dtls 2083/udp RADIUS over DTLS [RFCTBD] I'm OK with it. > 2) Do you think Joe's concern on Section 5.1.2 "disambiguation recommendation" > is something that need to be reconsidered.. I would prefer to avoid that. The document makes it clear that this is a temporary measure which should not be used long-term If the WG says the disambiguation is bad, then the preferred approach would be to remove it entirely from the document. There is precedent for protocol disambiguation, but most protocols simply allocate a new port. The suggestion to encapsulate RADIUS inside of RADIUS opens the document up *completely*. It means we'd have to spend another 3 years discussing the details. And a better alternative exists: use a new port. I'm very opposed to RADIUS encapsulation. I see nothing good coming from it. I'm similarly opposed to a "new" header for RADIUS over DTLS over port 1812. The resulting packet isn't RADIUS, and won't pass RADIUS sanity checks for application-layer firewalls. If you're going to design a new protocol, the only reasonable thing to do is to use a new port. Alan DeKok. From aland@deployingradius.com Tue Apr 30 06:27:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E27421F9ABE; Tue, 30 Apr 2013 06:27:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e93rnX2v4mDT; Tue, 30 Apr 2013 06:27:17 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 49A6721F9B07; Tue, 30 Apr 2013 06:27:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D4BC52240EBD; Tue, 30 Apr 2013 15:26:22 +0200 (CEST) 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 nzaE4kiLaDEv; Tue, 30 Apr 2013 15:26:22 +0200 (CEST) Received: from Thor-2.local (bas1-ottawa11-1176121151.dsl.bell.ca [70.26.47.63]) by power.freeradius.org (Postfix) with ESMTPSA id 40D172240842; Tue, 30 Apr 2013 15:26:21 +0200 (CEST) Message-ID: <517FC67C.1070502@deployingradius.com> Date: Tue, 30 Apr 2013 09:26:20 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <50F5316E.905@cisco.com>, <50F53205.2020209@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "aaa-doctors@ietf.org" , Ralph Droms , draft-ietf-softwire-6rd-radius-attrib@ietf.org, Benoit Claise , 'RFC Editor' Subject: Re: [radext] Ready to go? New Version Notification - draft-ietf-softwire-6rd-radius-attrib-10.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2013 13:27:22 -0000 Bernard Aboba wrote: > While Section 3 now does describe how authentication/authorization > functions in a way that is compliant with RFC 2865 and 5080, there is no > normative language and the requirements (e.g. for User-Name and > User-Password attributes, Message-Authenticator attribute) are not > included in Section 4.2. Also, it would be helpful to be explicit about > the value of the Service-Type attribute in Access-Requests (I am > assuming that this is no longer "Call-Check", since the User-Password > attribute is included in the Access-Request). http://datatracker.ietf.org/doc/draft-ietf-softwire-6rd-radius-attrib/?include_text=1 The Table of Attributes in Section 4.2 lists User-Password as 0-1 for Accounting-Request. It should be just "0". RFC 2866 does not allow User-Password to be in Accounting-Request packets. Alan DeKok. From wwwrun@rfc-editor.org Tue Apr 30 22:31:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447E521F89FD; Tue, 30 Apr 2013 22:31:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.257 X-Spam-Level: X-Spam-Status: No, score=-102.257 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjxdmkEktpjK; Tue, 30 Apr 2013 22:31:12 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id A1E0D21F89AF; Tue, 30 Apr 2013 22:31:12 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6510062114; Tue, 30 Apr 2013 22:30:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130501053042.6510062114@rfc-editor.org> Date: Tue, 30 Apr 2013 22:30:42 -0700 (PDT) Cc: radext@ietf.org, rfc-editor@rfc-editor.org Subject: [radext] RFC 6929 on Remote Authentication Dial In User Service (RADIUS) Protocol Extensions 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, 01 May 2013 05:31:15 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6929 Title: Remote Authentication Dial In User Service (RADIUS) Protocol Extensions Author: A. DeKok, A. Lior Status: Standards Track Stream: IETF Date: April 2013 Mailbox: aland@networkradius.com, avi.ietf@lior.org Pages: 68 Characters: 133099 Updates: RFC 2865, RFC 3575, RFC 6158 I-D Tag: draft-ietf-radext-radius-extensions-13.txt URL: http://www.rfc-editor.org/rfc/rfc6929.txt The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. This document is a product of the RADIUS EXTensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC