From owner-radiusext@ops.ietf.org Wed Mar 2 05:11:44 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF6F3A67F4 for ; Wed, 2 Mar 2011 05:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fhg462hud1Qs for ; Wed, 2 Mar 2011 05:11:43 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B34A73A67F0 for ; Wed, 2 Mar 2011 05:11:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Puln6-000I7j-WD for radiusext-data0@psg.com; Wed, 02 Mar 2011 13:08:33 +0000 Received: from ss2.mm-com.ru ([194.149.90.8]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Puln4-000I6z-32 for radiusext@ops.ietf.org; Wed, 02 Mar 2011 13:08:30 +0000 Received: from host-93-182-8-148.real.kvidex.net ([93.182.8.148]:61757 "EHLO [192.168.100.10]" rhost-flags-OK-OK-OK-FAIL) by mail.euro-comm.net with ESMTPSA id S17129045Ab1CBNIZ (ORCPT ); Wed, 2 Mar 2011 16:08:25 +0300 Message-ID: <4D6E4146.2040806@euro-comm.net> Date: Wed, 02 Mar 2011 16:08:22 +0300 From: Victor Gamov Organization: Eurocomm.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-radius-extensions-00.txt References: <20110227090002.7026.40042.idtracker@localhost> In-Reply-To: <20110227090002.7026.40042.idtracker@localhost> Content-Type: multipart/mixed; boundary="------------050005050407040405020306" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------050005050407040405020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All ! To extend Type space and allow large values I propose following format with new unassigned Type: 0 1 2 3 +---------------------------------------------------------------+ |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+-------------------------------+ | Type | Length=0 | Actual Length | +---------------+---------------+-------------------------------+ | New Type (up to 65535 types) |Long Value (up to 65529 bytes).. +---------------+---------------+---------------+---------------+ Incompatible implementations will generate reject or discard such attributes due Length=0. To allow VSA with extended types (more than 255) and values (Type is new unassigned type): 0 1 2 3 +---------------------------------------------------------------+ |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+-------------------------------+ | Type | Length=0 | Actual Length | +---------------+---------------+-------------------------------+ | Vendor ID | +---------------+---------------+---------------+---------------+ | VSA Type |Long Value (up to 65525 bytes).. +---------------+---------------+---------------+---------------+ In more general, second format may be used to extend RADIUS-standard attributes when 'Vendor ID' = 0 -- CU, Victor Gamov --------------050005050407040405020306 Content-Type: text/x-vcard; charset=utf-8; name="vit.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vit.vcf" begin:vcard fn:Victor Gamov n:Gamov;Victor email;internet:vit@euro-comm.net tel;work:sip:04800112@euro-comm.net x-mozilla-html:FALSE version:2.1 end:vcard --------------050005050407040405020306-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 13:17:40 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2084B3A6893 for ; Thu, 3 Mar 2011 13:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.890, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4mJ5Bse+lXU for ; Thu, 3 Mar 2011 13:17:39 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 16AEE3A6811 for ; Thu, 3 Mar 2011 13:17:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvFsd-000Oei-KN for radiusext-data0@psg.com; Thu, 03 Mar 2011 21:16:15 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvFsa-000OeX-8h for radiusext@ops.ietf.org; Thu, 03 Mar 2011 21:16:12 +0000 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8AFE3A6A20 for ; Thu, 3 Mar 2011 13:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEwtfsd8-ZQn; Thu, 3 Mar 2011 13:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1699F3A6823; Thu, 3 Mar 2011 13:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-02.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110303211502.21331.20082.idtracker@localhost> Date: Thu, 03 Mar 2011 13:15:02 -0800 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart 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 : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-02.txt Pages : 8 Date : 2011-03-03 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03130525.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 13:45:07 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2343A6A3F for ; Thu, 3 Mar 2011 13:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AnPlUBUKBmlH for ; Thu, 3 Mar 2011 13:44:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62D893A6835 for ; Thu, 3 Mar 2011 13:44:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGJK-000Pyt-5J for radiusext-data0@psg.com; Thu, 03 Mar 2011 21:43:50 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGJH-000PyT-40 for radiusext@ops.ietf.org; Thu, 03 Mar 2011 21:43:47 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvGJE-0004oW-55; Thu, 03 Mar 2011 13:43:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: d.b.nelson@comcast.net, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 03 Mar 2011 21:43:44 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #78: Pre-November 2008 Copyright Notice X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/78 Message-ID: <066.786840e236484a02f68d05bcae225353@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: d.b.nelson@comcast.net, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #78: Pre-November 2008 Copyright Notice The current -02 document does not utilize the pre-November 2008 copyright notice. This issue is filed in case the authors wish to change the notice. Otherwise, this issue can be resolved "won't fix". Here is what the pre-November 2008 notice looks like; Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: d.b.nelson@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 13:47:36 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F00393A6A3F for ; Thu, 3 Mar 2011 13:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKLv0cZ6Kgdr for ; Thu, 3 Mar 2011 13:47:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B19D33A68CE for ; Thu, 3 Mar 2011 13:47:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGLr-0000AO-HX for radiusext-data0@psg.com; Thu, 03 Mar 2011 21:46:27 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGLo-00009g-Ck for radiusext@ops.ietf.org; Thu, 03 Mar 2011 21:46:24 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvGLm-0005Qi-JB; Thu, 03 Mar 2011 13:46:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 03 Mar 2011 21:46:22 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #79: Reference issues X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/79 Message-ID: <066.c1f016202b867220eee064feef80ea2b@trac.tools.ietf.org> X-Trac-Ticket-ID: 79 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #79: Reference issues idnits currently finds the following NITs relating to references in the -02 document: Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2865' is defined on line 293, but no explicit reference was found in the text '[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Rem...' == Unused Reference: 'RFC3162' is defined on line 297, but no explicit reference was found in the text '[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RF...' == Unused Reference: 'RFC3579' is defined on line 300, but no explicit reference was found in the text '[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication...' == Unused Reference: 'RFC4962' is defined on line 307, but no explicit reference was found in the text '[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, A...' Looking through the document, each of the "unused" references are actually included, but not in the referenced form (e.g. RFC 2865 instead of [RFC2865]). This should be cleaned up. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 13:48:58 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AEF283A68CE for ; Thu, 3 Mar 2011 13:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5bB3Rl4+dvW for ; Thu, 3 Mar 2011 13:48:57 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A71D83A68B0 for ; Thu, 3 Mar 2011 13:48:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGNv-0000Hx-Gd for radiusext-data0@psg.com; Thu, 03 Mar 2011 21:48:35 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGNs-0000Hm-MO for radiusext@ops.ietf.org; Thu, 03 Mar 2011 21:48:32 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvGNq-0001bt-TR; Thu, 03 Mar 2011 13:48:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 03 Mar 2011 21:48:30 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #80: Section 3 X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/80 Message-ID: <066.bf885c840855f6d7ca0e423b2fc28ee7@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #80: Section 3 This section isn't just about encryption, but the state of RADIUS security in general. Suggest the following re-write: 3. The Current State of RADIUS Security RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. Various RADIUS attributes support hidden values, including: User-Password, Tunnel-Password, and various Vendor- Specific Attributes. Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Recent work on MD5 collisions does not immediately compromise any of these methods, absent knowledge of the RADIUS shared secret. However, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 13:57:24 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCA343A6A3F for ; Thu, 3 Mar 2011 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wb9UTYYXD7cM for ; Thu, 3 Mar 2011 13:57:23 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 927A73A68B0 for ; Thu, 3 Mar 2011 13:57:23 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGVa-0000iX-Gi for radiusext-data0@psg.com; Thu, 03 Mar 2011 21:56:30 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGVX-0000iE-NS for radiusext@ops.ietf.org; Thu, 03 Mar 2011 21:56:27 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvGVV-0004yq-MM; Thu, 03 Mar 2011 13:56:25 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 03 Mar 2011 21:56:25 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #81: Location Privacy X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/81 Message-ID: <066.451f184eae2eab18c2c871e3f0339e04@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #81: Location Privacy Section 4.2 states: If possible, it is desirable for proposals to provide for the encryption of existing attributes. This includes existing "hidden" attributes as well as attributes (such as location attributes) that require confidentiality. [BA] GEOPRIV requirements are described in RFC 3693; this should probably be referenced here. Also, "desirable" appears to be used as a synonym for RECOMMENDED here. Should this be changed? -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 13:59:22 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACC283A68B0 for ; Thu, 3 Mar 2011 13:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J5ctt7WV2Rx for ; Thu, 3 Mar 2011 13:59:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C8C9E3A6A46 for ; Thu, 3 Mar 2011 13:59:21 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGY6-0000r7-8N for radiusext-data0@psg.com; Thu, 03 Mar 2011 21:59:06 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGY3-0000qj-Lv for radiusext@ops.ietf.org; Thu, 03 Mar 2011 21:59:03 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvGY1-0005Uq-St; Thu, 03 Mar 2011 13:59:01 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 03 Mar 2011 21:59:01 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #82: Diameter compatibliity X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/82 Message-ID: <066.64aab0948023e23ae56821583f5fe72a@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #82: Diameter compatibliity Section 4.5 states: Proposals MUST include a Diameter compatibility section, although it is expected that the work will occur purely within RADIUS or in the transport, and therefore does not affect message data that is exchanged with Diameter. [BA] Since a Diameter compatibility section is no longer required, I recommend that this be changed to the following: Since it is expected that the work will occur purely within RADIUS or in the transport, message data exchanged with Diameter SHOULD NOT be affected. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 14:02:23 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C65FC3A68C9 for ; Thu, 3 Mar 2011 14:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HGmM3ydUHzC for ; Thu, 3 Mar 2011 14:02:22 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A6EC53A68B0 for ; Thu, 3 Mar 2011 14:02:22 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGaN-00010U-Sd for radiusext-data0@psg.com; Thu, 03 Mar 2011 22:01:27 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGaL-0000zy-16 for radiusext@ops.ietf.org; Thu, 03 Mar 2011 22:01:25 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvGaJ-00051R-80; Thu, 03 Mar 2011 14:01:23 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 03 Mar 2011 22:01:23 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #83: AKM Requirements X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/83 Message-ID: <066.2f9c0aa847c1f8f9bed3b42e8b6f39ab@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #83: AKM Requirements Section 4.6 states: Automated key management is required for RADIUS crypto agility solutions that use cryptographic modes of operation that require frequent key changes. Shouldn't "required" be capitalized here? -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 14:05:43 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 089333A68C9 for ; Thu, 3 Mar 2011 14:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKzcsoYOTilL for ; Thu, 3 Mar 2011 14:05:41 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 61B903A68B0 for ; Thu, 3 Mar 2011 14:05:41 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGeR-0001G5-Hh for radiusext-data0@psg.com; Thu, 03 Mar 2011 22:05:39 +0000 Received: from blu0-omc1-s9.blu0.hotmail.com ([65.55.116.20]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvGeO-0001FN-AJ for radiusext@ops.ietf.org; Thu, 03 Mar 2011 22:05:36 +0000 Received: from BLU152-W30 ([65.55.116.9]) by blu0-omc1-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 14:05:35 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_4e65e252-c223-4839-9942-87e6258b2db4_" X-Originating-IP: [72.11.66.126] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Request for Review: Crypto-Agility Requirements for RADIUS Date: Thu, 3 Mar 2011 14:05:34 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 03 Mar 2011 22:05:35.0027 (UTC) FILETIME=[1EF98030:01CBD9EF] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_4e65e252-c223-4839-9942-87e6258b2db4_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a request for review of "Crypto-Agility Requirements for RADIUS". = The document may be found here: http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements The "Request for Review" will last until March 17=2C 2011. RADEXT WG Participants are encouraged to read the document and post issues in=20 the TRAC database (see below for details on how to do this) or on the=20 RADEXT WG mailing list.=20 When all the open issues on this document are addressed=2C the document wil= l go to WG last call.=20 =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 1. To submit an issue in TRAC=2C you first need to login to the RADEX= T WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login= =20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_4e65e252-c223-4839-9942-87e6258b2db4_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a request for review of "Crypto-Agility Requirements for RADIUS".&n= bsp=3B The document may be found here:
http://tools.ietf.org/html/draft-= ietf-radext-crypto-agility-requirements

The "Request for Review" wil= l last until March 17=2C 2011.

RADEXT WG Participants are encouraged to read the document and post issues in=20 the TRAC database (see below for details on how to do this) or on the=20 RADEXT WG mailing list.

When all the open issues on this document a= re addressed=2C the document will go to WG last call.

=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

1. =3B =3B&nbs= p=3B =3B =3B =3B To submit an issue in TRAC=2C you first need t= o login to the RADEXT WG site on the tools server: =3B http://tools.ietf.o= rg/wg/radext/trac/login

2. =3B =3B =3B =3B = =3B =3B If you don=92t already have a login ID=2C you can obtain one by= navigating to this site: =3B =3B http://trac.tools.ietf.org/newlogin
=
3. =3B =3B =3B =3B =3B =3B Once you have obtain= ed an account=2C and have logged in=2C you can file an issue by navigating = to the =3B ticket entry form: http://trac.tools.ietf.org/wg/radex= t/trac/newticket

4. =3B =3B =3B =3B =3B = =3B When opening an issue:

a. =3B =3B =3B =3B = =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tool= s.ietf.org/wg/radext/trac/report/1 =3B Click on the ticket # you wa= nt to update=2C and then modify the ticket fields as required

 =3B

= = --_4e65e252-c223-4839-9942-87e6258b2db4_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 15:54:21 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8467C3A68CB for ; Thu, 3 Mar 2011 15:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O48jif5MRvKX for ; Thu, 3 Mar 2011 15:54:19 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 736153A6816 for ; Thu, 3 Mar 2011 15:54:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvIJ4-0006EW-I9 for radiusext-data0@psg.com; Thu, 03 Mar 2011 23:51:42 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvIIx-0006E9-7o for radiusext@ops.ietf.org; Thu, 03 Mar 2011 23:51:36 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvIIu-0005r0-Is; Thu, 03 Mar 2011 15:51:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Thu, 03 Mar 2011 23:51:32 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #21: Crypto-Agility thoughts X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/21#comment:1 Message-ID: <071.f88ed8874372d9c084da8c153d719368@trac.tools.ietf.org> References: <062.38cc4697693044037d4e777879846ba9@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <062.38cc4697693044037d4e777879846ba9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #21: Crypto-Agility thoughts Changes (by bernard_aboba@…): * status: new => assigned Comment: Here is a proposed resolution to this issue: Hop-by-hop/end-to-end: Much of RFC 4962 is open to multiple interpretations, and some parts of it can be read as requiring more than hop-by-hop security. IMHO exactly the same parts can also be read as saying hop-by-hop can be sufficient (when done properly), and I think this document should explicitly say it's interpreting 4962 the latter way. [BA] The document already incorporates most of the security advice in RFC 4962 relevant to AAA protocols. However, there appear to be a few requirements that are not included. To clarify their interpretation, it is recommended that we add the following text to Section 4.2: In addition to the above goals, [RFC4962] Section 2 describes the following additional security requirements for AAA protocols: 1. Strong, fresh session keys. RFC 4962 Section 2 states: "The AAA protocol MUST ensure that the keying material supplied as an input to session key derivation is fresh... The mechanism used to generate session keys MUST ensure that the disclosure of one session key does not aid the attacker in discovering any other session keys."` RADIUS crypto-agility solutions are REQUIRED to generate fresh session keys for use between the RADIUS client and server. In order to prevent the disclosure of one session key from aiding an attacker in discovering other session keys, RADIUS crypto-agility solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to session keys negotiated between the RADIUS client and server. 2. Limit key scope. RFC 4962 Section 2 states: "Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role." In order to enable a NAS and RADIUS server to transmit keying material directly between each other, it is RECOMMENDED that a RADIUS crypto-agility solution be compatible with NAI-based Dynamic Peer Discovery [RADYN] as well as that it support the use of public key credentials for authentication between the NAS and RADIUS server. For compatibility with existing operations, RADIUS crypto-agility solutions SHOULD also support pre-shared key credentials. 3. Prevent the Domino effect. RFC 4962 Section 2 states: "Likewise, compromise of a single authenticator MUST NOT compromise keying material held by any other authenticator within the system." In order to prevent the domino effect, RADIUS crypto-agility solutions MUST enable each RADIUS client and server pair to authenticate utilizing unique credentials. Forward secrecy: Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be used (perhaps indirectly via additional key derivation steps) to encrypt information that may be valuable for a long time. Given this, the document needs some discussion about "forward secrecy" (whether revealing the long-term credential allows decrypting all past communications), and if the conclusion is that crypto-agility solutions don't need to support forward secrecy (even as optional-to-use feature), explain the rationale behind this conclusion. [BA] The need to support PFS derives from the RFC 4962 requirements, so it is proposed that this be added to the Section 4.2 requirements as a recommendation. Authentication/long-term credentials: Authenticating the RADIUS client and server will require (manual) configuration of some kinds of credentials (currently, the RADIUS shared secret). The document should say something about what kinds of long-term authentication credentials (for RADIUS entities) the crypto-agility solutions are expected to support. Presumably, they MUST support pair-wise shared secrets. Other possibilities for long-term credentials could include e.g. X.509 certificates with PKI, public keys without certification infrastructure (generate keypair + configure fingerprint of peer's key), or Kerberos. Even if the conclusion is that nothing else than pairwise shared secrets is needed, that should be said in the document (with rationale explaining why). [BA] The need to support public-key credentials derives from the requirement for direct transport of keys and the need for pair-wise shared secrets derives from current operational practice. So it is proposed that recommendations relating to support for these credential types be added to Section 4.2. Replay protection: Section 4.2 says "Proposals MUST support replay protection. The existing mechanisms for replay protection are considered adequate and should be maintained." I think the latter sentence needs some clarification. If the intent is to say replay protection provided by the current mechanisms (i.e., basically none for Access-Request messages) is good enough, I would disagree with that (or at least would expect to see an explanation why that's the case for Access-Requests). If the intent is something else, the text needs to be clearer. [BA] The proposal is that the following text within Section 4.2: Proposals MUST support replay protection. The existing mechanisms for replay protection are considered adequate and should be maintained. be changed to the following: Proposals MUST support per-packet replay protection for all RADIUS message types. Meaning of negotiation: The document says proposals MUST support negotiation of cryptographic algorithms. Does "negotiation" here mean picking which algorithm to use in the protocol (RADIUS client and server figure out an algorithm supported by both of them), or would negotiation between system administrators meet this requirement? I assume the WG has rough consensus about what this means, and ordinarily, I would have automatically assumed it's the former. But some earlier proposals in this space have supported only the latter kind (which does provide some kind of algorithm agility -- it's better than hardcoding MD5 -- but could mean synchronized manual work for every transition)... [BA] The proposal is that the following text in Section 2: "of RADIUS implementations to negotiate cryptographic algorithms" be changed to: "of RADIUS implementations to automatically negotiate cryptographic algorithms" Automated Key Management: Well... RADIUS certainly requires only O(n) keys, but on the other hand, the amount of data encrypted with a single key is not necessarily small (when considering the "value of the data" and time aspects -- in terms of gigabytes, it's probably small compared to what decent algorithms can handle). And if you anyway support negotiating the algorithms (in the protocol), generating a fresh session key may not be that much extra effort, and may be needed anyway since the key can depend on the selected algorithm (if you negotiate 256-bit AES, you need a 256-bit key; if it's 3DES, 168 bits, etc.). And the solutions should avoid using the same cryptographic key with multiple algorithms (and the easiest way to ensure this would probably be fresh session keys). Generating a fresh session key probably also simplifies replay protection (it's the obvious time to e.g. reset counters to zero), but other approaches to replays are certainly feasible. And obviously, forward secrecy and supporting any other types of long-term credentials than shared secrets requires automated key management of some kind. So, I think the conclusion here needs at the very least some qualification and additional explanation. *If* a solution not supporting forward secrecy and not supporting other types of credentials is acceptable, *and* replay protection is solved in certain way, *and* the solution can ensure that the negotiated algorithms get keys appropriate for them, *and* the solution can ensure that two algorithms don't use the same key, then you might get away with no AKM. But even then, AKM might be less work. [BA] The requirement for a fresh session key derives from RFC 4962, Since a fresh session key can be derived from a pre-shared key via the exchange of nonces, this doesn't necessarily imply AKM. However, the requirement for PFS as well as for direct key transport between a NAS and RADIUS server do effectively imply AKM. The proposal is to change Section 4.6 to the following: 4.6. Applicability of Automated Key Management Requirements [RFC4107] provides guidelines for when automated key management is necessary. At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG debated whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). The working group determined that AKM was not inherently required for RADIUS based on the following points: o RFC 4107 requires AKM for protocols that involve O(n^2) keys. This does not apply to RADIUS deployments, which require O(n) keys. o Requirements for session key freshness can be met without AKM, for example, by utilizing a pre-shared key along with an exchange of nonces. o RADIUS does not require the encryption of large amounts of data in a short time. o Organizations already have operational practices to manage existing RADIUS shared secrets to address key changes required through personnel changes. o The crypto-agility solution can avoid use cryptographic modes of operation such as a counter mode cipher that require frequent key changes. However, the same time, it is recognized that features recommended in Section 4.2 such as support for PFS and direct transport of keys between a NAS and RADIUS server, can only be provided by a solution supporting AKM. As a result, support for Automated Key Management is RECOMMENDED within a RADIUS crypto-agility solution. Compromise of legacy shared secret: Section 4.2 says "Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks." If interpreted literally, this requirement could be very difficult to meet (perhaps impossible). It seems to assume that for this particular peer, the administrator has configured two different shared secrets (one for the current security mechanisms, another for the new ones), but has not configured whether to use the old or new mechanisms (with this particular peer), and instead, that is negotiated somehow. If the attacker knows the legacy shared secret, and has complete control over the communication channel (and in particular, can drop messages going from A to B), then it seems the attacker will be indistinguishable from a valid peer that supports only the legacy mechanisms (and does not know the new shared secret), and detecting bidding down will not be possible. Preventing bidding down in less extreme cases of compromise is of course both possible and desirable (e.g. if the algorithms are just weak but not breakable in real time, or if the attacker doesn't have complete control over the communications). And the administrator could always configure just the "new shared secret", if he/she knows that the peer supports it. [BA] Propose that the following text in Section 4.2: Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks. be changed to: Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks. In analyzing the resilience of a crypto-agility solution, it can be assumed that the RADIUS server can be configured to require the use of new secure algorithms in the event of a compromise of existing cryptographic algorithms or the legacy RADIUS shared secret. Backward compatibility/negotiation: Section 4.3 says "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, a crypto-agility solution needs to be able to send packets that a legacy RADIUS client or server will receive and process successfully. Similarly, a crypto-agility solution needs to be capable of receiving and processing packets from a legacy RADIUS client or server." The intent of this paragraph is probably right, but currently, it's somewhat open to multiple interpretations. Would something like this capture the intent? "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration." Note that *not* meeting this requirement would actually be quite difficult... if the intent of this paragraph was to require some kind of negotiation (interpreted loosely -- anything more automatic than manual configuration), the text should say so. [BA] Recommend that the following text in Section 4.3: "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, a crypto-agility solution needs to be able to send packets that a legacy RADIUS client or server will receive and process successfully. Similarly, a crypto-agility solution needs to be capable of receiving and processing packets from a legacy RADIUS client or server." be changed to: "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration." "Operational model"? Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model, such as the introduction of new commands or maintenance of [additional] state on the RADIUS server." I'm not sure what "operational" means here -- at first I thought it might mean "operations and management" (so the requirement would be basically "SHOULD not complicate life for administrators"), but the two examples given don't seem to fit that very well. And it seems any solution that e.g. derives fresh session keys will involve some small (but greater than zero) amount of additional state on clients and servers. If the intent was really operations and management, perhaps the should be rephased something like "When using long-term shared secrets for authentication, crypto-agility solutions SHOULD NOT require more operations and management work than the current solutions." "RADIUS service?" Section 4.3 says "For example, proposals SHOULD NOT .. include definition of new RADIUS services." What's a RADIUS service -- i.e. what types of proposals this definition would disqualify? (In RFC 2865, "service" is defined as the service provided by the NAS to the user, but that definition doesn't seem applicable here.) [BA] Proposal is to change the following text in Section 4.3: Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model, such as the introduction of new commands or maintenance of [additional] state on the RADIUS server. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats or include definition of new RADIUS services. to the following: "Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC 6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC 6158] Section 2.3." -- -----------------------------------+---------------------------------------- Reporter: Pasi.Eronen@… | Owner: bernard_aboba@… Type: defect | Status: assigned Priority: blocker | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 21:03:14 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E364B3A6938 for ; Thu, 3 Mar 2011 21:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.883, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlzK9oINwLUd for ; Thu, 3 Mar 2011 21:03:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 06BB23A692B for ; Thu, 3 Mar 2011 21:03:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvN8f-000KHl-MQ for radiusext-data0@psg.com; Fri, 04 Mar 2011 05:01:17 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvN8b-000KHO-Nv for radiusext@ops.ietf.org; Fri, 04 Mar 2011 05:01:13 +0000 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D28E3A693A for ; Thu, 3 Mar 2011 21:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6HjmfPElsGC; Thu, 3 Mar 2011 21:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FAFE3A684D; Thu, 3 Mar 2011 21:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-03.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110304050002.27885.97768.idtracker@localhost> Date: Thu, 03 Mar 2011 21:00:02 -0800 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart 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 : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-03.txt Pages : 9 Date : 2011-03-03 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03205856.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:12:07 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC3B3A6965 for ; Thu, 3 Mar 2011 22:12:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EJcs1SsmIsDY for ; Thu, 3 Mar 2011 22:12:06 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D4CFE3A693A for ; Thu, 3 Mar 2011 22:12:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOEA-000O4D-SM for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:11:02 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOE8-000O3y-Ax for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:11:00 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvOE6-0005Y2-1S; Thu, 03 Mar 2011 22:10:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:10:58 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #80: Section 3 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/80#comment:1 Message-ID: <075.98c38d8bdebeff353476a9d5a8fb0618@trac.tools.ietf.org> References: <066.bf885c840855f6d7ca0e423b2fc28ee7@trac.tools.ietf.org> X-Trac-Ticket-ID: 80 In-Reply-To: <066.bf885c840855f6d7ca0e423b2fc28ee7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #80: Section 3 Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:12:15 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597363A6965 for ; Thu, 3 Mar 2011 22:12:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xnw4PUSfmYjv for ; Thu, 3 Mar 2011 22:12:14 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 38DE93A6967 for ; Thu, 3 Mar 2011 22:12:14 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOFI-000OA6-R4 for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:12:12 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOFG-000O9j-9G for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:12:10 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvOFE-0007Uw-Fi; Thu, 03 Mar 2011 22:12:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:12:08 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #83: AKM Requirements X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/83#comment:1 Message-ID: <075.0492cbf511073c68c01238768a169dc2@trac.tools.ietf.org> References: <066.2f9c0aa847c1f8f9bed3b42e8b6f39ab@trac.tools.ietf.org> X-Trac-Ticket-ID: 83 In-Reply-To: <066.2f9c0aa847c1f8f9bed3b42e8b6f39ab@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #83: AKM Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:12:31 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9733A6965 for ; Thu, 3 Mar 2011 22:12:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtG+zs1bP1Eb for ; Thu, 3 Mar 2011 22:12:30 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B62F3A693A for ; Thu, 3 Mar 2011 22:12:30 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvODl-000O3P-9I for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:10:37 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvODi-000O37-Hm for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:10:34 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvODe-0003LR-Mq; Thu, 03 Mar 2011 22:10:30 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:10:30 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #82: Diameter compatibliity X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/82#comment:1 Message-ID: <075.3d469df7b744a9d15a3b87dcbc38345e@trac.tools.ietf.org> References: <066.64aab0948023e23ae56821583f5fe72a@trac.tools.ietf.org> X-Trac-Ticket-ID: 82 In-Reply-To: <066.64aab0948023e23ae56821583f5fe72a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #82: Diameter compatibliity Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:12:34 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A88A3A6965 for ; Thu, 3 Mar 2011 22:12:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E7x8Y5OUog5h for ; Thu, 3 Mar 2011 22:12:33 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5ECA63A693A for ; Thu, 3 Mar 2011 22:12:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOEo-000O7e-EF for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:11:42 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOEl-000O7E-VN for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:11:40 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvOEj-0003Bq-Ab; Thu, 03 Mar 2011 22:11:37 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: d.b.nelson@comcast.net, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:11:37 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #78: Pre-November 2008 Copyright Notice X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/78#comment:1 Message-ID: <075.c530d2c202c6ff6f94a23f4058de3bd6@trac.tools.ietf.org> References: <066.786840e236484a02f68d05bcae225353@trac.tools.ietf.org> X-Trac-Ticket-ID: 78 In-Reply-To: <066.786840e236484a02f68d05bcae225353@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: d.b.nelson@comcast.net, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #78: Pre-November 2008 Copyright Notice Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: d.b.nelson@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:13:10 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4A33A6970 for ; Thu, 3 Mar 2011 22:13:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.6 X-Spam-Level: X-Spam-Status: No, score=-104.6 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i9XcPHAMtNw for ; Thu, 3 Mar 2011 22:12:55 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id 1CB9B3A68D3 for ; Thu, 3 Mar 2011 22:12:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOEY-000O5q-Ds for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:11:26 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOEV-000O5P-Vr for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:11:24 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvOEU-0000fa-6p; Thu, 03 Mar 2011 22:11:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:11:22 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #79: Reference issues X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/79#comment:1 Message-ID: <075.249fa599469059e20f65a39929fb2745@trac.tools.ietf.org> References: <066.c1f016202b867220eee064feef80ea2b@trac.tools.ietf.org> X-Trac-Ticket-ID: 79 In-Reply-To: <066.c1f016202b867220eee064feef80ea2b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #79: Reference issues Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:16:19 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAB6C3A68D3 for ; Thu, 3 Mar 2011 22:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.695 X-Spam-Level: X-Spam-Status: No, score=-104.695 tagged_above=-999 required=5 tests=[AWL=1.904, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcnP6cVtkGno for ; Thu, 3 Mar 2011 22:16:19 -0800 (PST) Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id F3EFD3A689F for ; Thu, 3 Mar 2011 22:16:18 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOIN-000OZp-Q6 for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:15:23 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOIL-000OZc-25 for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:15:21 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvOIJ-0003HN-0J; Thu, 03 Mar 2011 22:15:19 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:15:18 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #21: Crypto-Agility thoughts X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/21#comment:2 Message-ID: <071.360187d1874240e364a18fbedd074ec1@trac.tools.ietf.org> References: <062.38cc4697693044037d4e777879846ba9@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <062.38cc4697693044037d4e777879846ba9@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #21: Crypto-Agility thoughts Changes (by bernard_aboba@…): * status: assigned => closed * resolution: => fixed -- -----------------------------------+---------------------------------------- Reporter: Pasi.Eronen@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:26:39 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A4CB3A68D3 for ; Thu, 3 Mar 2011 22:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-nCKqi885ga for ; Thu, 3 Mar 2011 22:26:26 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 3C10B3A6800 for ; Thu, 3 Mar 2011 22:26:25 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvORt-000OwI-0x for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:25:13 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvORq-000Ovn-9C for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:25:10 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvORo-00039C-BO; Thu, 03 Mar 2011 22:25:08 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:25:08 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #84: Requirements Language X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/84 Message-ID: <066.93e77ab00ad6de675f313084b5a53300@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #84: Requirements Language Add the following text to the Requirements Language text on page 1: A RADIUS crypto-agility solution is not compliant with this specification if it fails to satisfy one or more of the MUST or MUST NOT statements. A solution that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT statements but not all the SHOULD or SHOULD NOT requirements is said to be "conditionally compliant". -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:31:59 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1400A3A692D for ; Thu, 3 Mar 2011 22:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HxXMVul6xMm for ; Thu, 3 Mar 2011 22:31:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 26BE13A696C for ; Thu, 3 Mar 2011 22:31:51 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOUi-000P3j-LF for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:28:08 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOUg-000P3T-0K for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:28:06 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvOUe-0001tH-70; Thu, 03 Mar 2011 22:28:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 06:28:04 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #81: Location Privacy X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/81#comment:1 Message-ID: <075.e04624c050a9d76d5df995554a087adc@trac.tools.ietf.org> References: <066.451f184eae2eab18c2c871e3f0339e04@trac.tools.ietf.org> X-Trac-Ticket-ID: 81 In-Reply-To: <066.451f184eae2eab18c2c871e3f0339e04@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #81: Location Privacy Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Recommendation is to change the text to: It is RECOMMENDED for proposals to provide for the encryption of existing attributes. This includes existing "hidden" attributes as well as attributes (such as location attributes) that require confidentiality. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 3 22:55:18 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C14D13A6969 for ; Thu, 3 Mar 2011 22:55:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kbgq4SkYNazV for ; Thu, 3 Mar 2011 22:55:16 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5E1383A692D for ; Thu, 3 Mar 2011 22:55:16 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOu3-000PzW-GJ for radiusext-data0@psg.com; Fri, 04 Mar 2011 06:54:19 +0000 Received: from blu0-omc1-s16.blu0.hotmail.com ([65.55.116.27]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvOu0-000PzK-4W for radiusext@ops.ietf.org; Fri, 04 Mar 2011 06:54:16 +0000 Received: from BLU152-W43 ([65.55.116.7]) by blu0-omc1-s16.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 22:54:14 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_b7802388-12e8-4e75-bc91-b116697b581b_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Call for Agenda Items Date: Thu, 3 Mar 2011 22:54:14 -0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 04 Mar 2011 06:54:14.0365 (UTC) FILETIME=[F92C60D0:01CBDA38] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_b7802388-12e8-4e75-bc91-b116697b581b_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a call for agenda items at the RADEXT WG session at IETF 80 in Prag= ue=2C CZ. The WG is scheduled to meet on Wednesday morning from 9 AM to 11= :30 AM. Remote presentation can be arranged=2C so feel free to suggest an= agenda item even if you cannot be physically present.=20 Here is a strawman agenda: =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=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 RADEXT WG IETF 80 Agenda=20 =20 Chairs: Bernard Aboba Mauricio Sanchez =20 Jabber room: radext at jabber.ietf.org (Please join) =20 Wednesday=2C March 30=2C 2011 =20 0900 - 1130 =20 Karlin II and III =20 09:00 - 09:20=2C Preliminaries =20 Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Documented completing WG Last Call (20 minutes) 9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access WG Work Items (60 minutes) 9:40 - 10:00 AM Crypto-Agility Requirements for RADIUS (20 minutes)http://= tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:00 AM - 10:10 AM RADIUS over TLS=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec =20 10:10 AM - 10:20 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery =20 10:20 AM - 10:40 AM RADIUS over DTLS=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls =20 10:40 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Discussion and Wrap-up (30 minutes) =20 11:00 =96 11:15 AM Discussion (15 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) = --_b7802388-12e8-4e75-bc91-b116697b581b_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a call for agenda items at the RADEXT WG session at IETF 80 in Prag= ue=2C CZ. =3B The WG is scheduled to meet on Wednesday morning from 9 A= M to 11:30 AM.  =3B Remote presentation can be arranged=2C so feel free= to suggest an agenda item even if you cannot be physically present.
Here is a strawman agenda:

=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=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

RADEXT WG IETF 80= Agenda

 =3B

Chairs:

Bernard Aboba <=3Bbernard_aboba at hotmail.com>= =3B

Mauricio Sanchez <=3Bmauricio.sanchez at hp.com>= =3B

 =3B

Jabber room: =3B radext at jabber.ietf.org (Plea= se join)

 =3B

Wednesday=2C March 30=2C 2011

 =3B

0900 - 1130

 =3B

Karlin II and III

 =3B

09:00 - 09:20=2C Preliminaries

 =3B

 =3B =3B =3B =3B Debugging

 =3B =3B =3B =3B Note Well

 =3B =3B =3B =3B Note Takers

 =3B =3B =3B =3B Jabber scribe

 =3B =3B =3B =3B Agenda bash

 =3B =3B =3B =3B Document Status

=
Documented completing WG Last Call (20 minutes)

<= br>

9:20 - 9:40 AM RADIUS Attributes for IPv6 Acc= ess Networks (20 minutes)

http://tools.ietf.o= rg/html/draft-ietf-radext-ipv6-access


WG Work Items (60 minutes)

 =3B

9:40 - 10:00 AM C= rypto-Agility Requirements for RADIUS (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements<= /p>


10:00 AM - 10:10 AM RADIUS over TLS=2C Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec<= /p>

 =3B

10:10 AM - 10:20 AM Dynamic Peer Discovery=2C Stefan= Winter (10 minutes)

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

 =3B

10:20 AM - 10:40 AM RADIUS over DTLS=2C Alan DeKok (= 20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls

 =3B

10:40 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (20 minutes)
h= ttp://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (30 minutes)

 =3B

11:00 =96 11:15 AM Discussion (15 minutes)

11:15 - 11:30 =3B AM Next Steps: =3B WG Chairs &=3B ADs (15 minu= tes)
= --_b7802388-12e8-4e75-bc91-b116697b581b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 4 00:59:54 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73BA23A68B6 for ; Fri, 4 Mar 2011 00:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.129 X-Spam-Level: X-Spam-Status: No, score=-1.129 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kahFZWcfie4K for ; Fri, 4 Mar 2011 00:59:53 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 85C3D3A6892 for ; Fri, 4 Mar 2011 00:59:53 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvQpM-0005lo-Ml for radiusext-data0@psg.com; Fri, 04 Mar 2011 08:57:36 +0000 Received: from ss2.mm-com.ru ([194.149.90.8]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvQpJ-0005ji-Ne for radiusext@ops.ietf.org; Fri, 04 Mar 2011 08:57:34 +0000 Received: from host-93-182-8-148.real.kvidex.net ([93.182.8.148]:60391 "EHLO [192.168.100.10]" rhost-flags-OK-OK-OK-FAIL) by mail.euro-comm.net with ESMTPSA id S17135515Ab1CDI52 (ORCPT ); Fri, 4 Mar 2011 11:57:28 +0300 Message-ID: <4D70A97A.70405@euro-comm.net> Date: Fri, 04 Mar 2011 11:57:30 +0300 From: Victor Gamov Organization: Eurocomm.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-radius-extensions-00.txt References: <20110227090002.7026.40042.idtracker@localhost> <4D6E4146.2040806@euro-comm.net> In-Reply-To: <4D6E4146.2040806@euro-comm.net> Content-Type: multipart/mixed; boundary="------------010001090701010201070304" Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is a multi-part message in MIME format. --------------010001090701010201070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02.03.2011 16:08, Victor Gamov wrote: > Hi All ! > > To extend Type space and allow large values I propose following > format with new unassigned Type: > > 0 1 2 3 > +---------------------------------------------------------------+ |0 > 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| > +---------------+---------------+-------------------------------+ | > Type | Length=0 | Actual Length | > +---------------+---------------+-------------------------------+ | > New Type (up to 65535 types) |Long Value (up to 65529 bytes).. > +---------------+---------------+---------------+---------------+ > > Incompatible implementations will generate reject or discard such > attributes due Length=0. Some explanations If RADIUS-client wants to deliver long-value attribute to RADIUS-server, then this server and client needs to realize some mechanism to allow such values. Any splitting or other -- its need to be realized into both server and clinet. If client wants to deliver any important info by new (compatible) mechanism but server does not know anything about this mechanism, so this important info will be not processed by server. And client does not know about it! If server drop or reject packets with Length=0 then client know about it. If RADIUS-server send replies with important long-value attributes with Length=0 then client drops such packets and session never started. Client may send Acct-Stop by failure and server clear info about session early started (from the point of view of RADIUS-server) -- CU, Victor Gamov --------------010001090701010201070304 Content-Type: text/x-vcard; charset=utf-8; name="vit.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vit.vcf" begin:vcard fn:Victor Gamov n:Gamov;Victor email;internet:vit@euro-comm.net tel;work:sip:04800112@euro-comm.net x-mozilla-html:FALSE version:2.1 end:vcard --------------010001090701010201070304-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 4 01:35:05 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5A43A68CE for ; Fri, 4 Mar 2011 01:35:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t338XOqiBgRr for ; Fri, 4 Mar 2011 01:35:02 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 1093D3A68B3 for ; Fri, 4 Mar 2011 01:35:02 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvRNd-0007i2-KI for radiusext-data0@psg.com; Fri, 04 Mar 2011 09:33:01 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvRNa-0007hk-T5 for radiusext@ops.ietf.org; Fri, 04 Mar 2011 09:32:59 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvRNV-0002nd-Qg; Fri, 04 Mar 2011 01:32:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: stefan.winter@restena.lu, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 09:32:53 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #56: Review X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/56#comment:2 Message-ID: <075.d7fb2a8c448e78c1f35446cc5eef2308@trac.tools.ietf.org> References: <066.f891b898ab1e1624c0f0d57983825f1d@trac.tools.ietf.org> X-Trac-Ticket-ID: 56 In-Reply-To: <066.f891b898ab1e1624c0f0d57983825f1d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stefan.winter@restena.lu, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #56: Review Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: All editorial changes in the review are addressed in the upcoming -08 version. Regarding connection backoff, the following text is in -08: 2.3. Connection Setup RADIUS/TLS nodes 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. Failure to connect leads to continuous retries, with exponentially growing intervals between every try. If multiple servers are defined, the node MAY attempt to establish a connection to these other servers in parallel, in order to implement quick failover. I hope that this closes the issue. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 4 01:39:56 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B01BC3A6889 for ; Fri, 4 Mar 2011 01:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kd1cJFp1Jekk for ; Fri, 4 Mar 2011 01:39:55 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 607E73A695D for ; Fri, 4 Mar 2011 01:39:55 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvRTN-0007zO-C3 for radiusext-data0@psg.com; Fri, 04 Mar 2011 09:38:57 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvRTJ-0007z4-Aj for radiusext@ops.ietf.org; Fri, 04 Mar 2011 09:38:53 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvRTH-00079i-1M; Fri, 04 Mar 2011 01:38:51 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: stefan.winter@restena.lu, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Fri, 04 Mar 2011 09:38:51 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #60: Behavior in response to CoA-Request X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/60#comment:2 Message-ID: <075.e4e7d0854239478ca3b63c83e0ed77d8@trac.tools.ietf.org> References: <066.213c85ddfb8f0769b494d5bb71c885dd@trac.tools.ietf.org> X-Trac-Ticket-ID: 60 In-Reply-To: <066.213c85ddfb8f0769b494d5bb71c885dd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stefan.winter@restena.lu, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #60: Behavior in response to CoA-Request Changes (by stefan.winter@…): * status: new => closed * resolution: => worksforme Comment: A poll was held on the WG mailing list to determine whether Auth/Acct/CoA should be on separte connections (separate ports). The poll favoured to stay on one port for all traffic. This requires a RADIUS/TLS enabled DAS to implement a CoA-NAK as an indication of unwillingness to process CoA requests. This is in line with the text of the -07 draft and remains unchanged for -08. -08 will include further text regarding RADIUS Accounting. For reference, the text for both packet types in -08 is below: (4) RADIUS [RFC2865] used negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. (5) RADIUS [RFC2865] used negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of RADIUS Accounting packets. There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured; no negative ICMP response will reveal this. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Resolution: worksforme Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 13:01:21 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 558CE28C0CF for ; Sat, 5 Mar 2011 13:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+HLfDrDX7Aa for ; Sat, 5 Mar 2011 13:01:20 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id DD6063A6AC4 for ; Sat, 5 Mar 2011 13:01:19 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvyYb-000Kb1-Sa for radiusext-data0@psg.com; Sat, 05 Mar 2011 20:58:33 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvyYY-000Kal-Mr for radiusext@ops.ietf.org; Sat, 05 Mar 2011 20:58:30 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvyYU-0003KN-HL; Sat, 05 Mar 2011 12:58:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 05 Mar 2011 20:58:26 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #22: Review X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/22#comment:1 Message-ID: <068.fc5b1a2a8dcb6367d20fabb20fda2770@trac.tools.ietf.org> References: <059.f8c9a1d54a86dc5166344bc76ea5306d@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <059.f8c9a1d54a86dc5166344bc76ea5306d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #22: Review Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: The proposed resolution is as follows: Within Section 4.3, change the following text: Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. Included in such negotiation techniques are "hint and accept" and "hint and reject" mechanisms, where the NAS (RADIUS client) provides a list of supported algorithms and the RADIUS server selects one. to: Proposals MUST NOT introduce new capabilities negotiation features into the RADIUS protocol, but rather MUST use existing mechanisms. Negotiation techniques include "hint and accept" and "hint and reject" mechanisms, where the RADIUS request provides a list of supported algorithms and one is selected in the response. Since it is necessary to integrity protect the list of algorithms, at least one ciphersuite needs to be used to protect the request and response. -- --------------------------------+------------------------------------------- Reporter: jsalowey@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 14:16:43 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D7F3A6A2F for ; Sat, 5 Mar 2011 14:16:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id erxKki1BMiQR for ; Sat, 5 Mar 2011 14:16:42 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 52F503A687E for ; Sat, 5 Mar 2011 14:16:42 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvzlG-000ODV-5I for radiusext-data0@psg.com; Sat, 05 Mar 2011 22:15:42 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvzlC-000OD6-SA for radiusext@ops.ietf.org; Sat, 05 Mar 2011 22:15:39 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pvzl8-0000xj-M3; Sat, 05 Mar 2011 14:15:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 05 Mar 2011 22:15:34 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #85: Confidentiality Requirements X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/85 Message-ID: <066.e17ec0e3f0e25c275ff005745ef92abc@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #85: Confidentiality Requirements Section 4.3 states: Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. Support for confidentiality of entire RADIUS packets is OPTIONAL. However, proposals MUST support the negotiation of algorithms for encryption (sometimes referred to as "hiding") of RADIUS attributes. It is RECOMMENDED for proposals to provide for the encryption of existing attributes. This includes existing "hidden" attributes as well as attributes (such as location attributes) that require confidentiality. This paragraph is confusing along multiple dimensions. Since RADIUS is a transactional protocol, it is not possible to "negotiate" algorithms for use in a RADIUS request; algorithm(s) must be chosen. Also, it is not clear whether negotiation as referred to here would refer to encryption of entire RADIUS packets or just individual attributes. Also does "encryption of existing attributes" imply that attributes can be doubly encrypted? -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 14:25:19 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78ABB3A6A32 for ; Sat, 5 Mar 2011 14:25:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nELG79b5oskL for ; Sat, 5 Mar 2011 14:25:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A95303A6A31 for ; Sat, 5 Mar 2011 14:25:17 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvzuN-000OVy-3s for radiusext-data0@psg.com; Sat, 05 Mar 2011 22:25:07 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PvzuJ-000OVj-Qz for radiusext@ops.ietf.org; Sat, 05 Mar 2011 22:25:04 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PvzuI-000533-1p; Sat, 05 Mar 2011 14:25:02 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 05 Mar 2011 22:25:02 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #86: MD5 Stream Cipher Weaknesses X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/86 Message-ID: <066.62285455ad08292c0ca0af89a211ff48@trac.tools.ietf.org> X-Trac-Ticket-ID: 86 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #86: MD5 Stream Cipher Weaknesses Section 3 states: RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. Various RADIUS attributes support encrypted (also known as "hidden") values, including: User-Password, Tunnel-Password, and various Vendor- Specific Attributes. Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Recent work on MD5 collisions does not immediately compromise any of these methods, absent knowledge of the RADIUS shared secret. However, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. The weaknesses of MD5 stream ciphers is independent of MD5 collision issues and therefore it is not accurate to state that there is no compromise absent knowledge of the shared secret. For example, were the RADIUS authenticator to repeat, a known plaintext attack on hidden attributes such as User-Password is possible. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 18:52:09 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A6E33A6A32 for ; Sat, 5 Mar 2011 18:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+gLIOdtB2Rq for ; Sat, 5 Mar 2011 18:52:08 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 48D6B3A69FB for ; Sat, 5 Mar 2011 18:52:08 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw434-0008tL-Sa for radiusext-data0@psg.com; Sun, 06 Mar 2011 02:50:22 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw432-0008tB-7j for radiusext@ops.ietf.org; Sun, 06 Mar 2011 02:50:20 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pw42y-0005iz-Ah; Sat, 05 Mar 2011 18:50:16 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 06 Mar 2011 02:50:16 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #87: Guidance on mandatory-to-implement algorithms X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/87 Message-ID: <066.91fb381c465ec50f28acab7326ef36f7@trac.tools.ietf.org> X-Trac-Ticket-ID: 87 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #87: Guidance on mandatory-to-implement algorithms Section 4.2 does not provide any guidance as to what cryptographic algorithms are acceptable for designation as mandatory-to-implement, nor does it reference any such guidance. My recommendation is that the following paragraph be added to Section 4.2: Guidance on acceptable algorithms can be found in [NIST-SP800-131A]. It is RECOMMENDED that mandatory-to-implement cryptographic algorithms be chosen from among those classified as "Acceptable" with no known deprecation date within [NIST-SP800-131A]. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 19:01:13 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0D53A6A41 for ; Sat, 5 Mar 2011 19:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfat044BJ39b for ; Sat, 5 Mar 2011 19:01:09 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AF6703A6A32 for ; Sat, 5 Mar 2011 19:01:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw4Cy-0009I5-Uq for radiusext-data0@psg.com; Sun, 06 Mar 2011 03:00:36 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw4Cw-0009Ht-AG for radiusext@ops.ietf.org; Sun, 06 Mar 2011 03:00:34 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pw4Cu-0003t3-5o; Sat, 05 Mar 2011 19:00:32 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 06 Mar 2011 03:00:32 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #84: Requirements Language X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/84#comment:1 Message-ID: <075.78f0fc68ff663589419dfe31269a2cb1@trac.tools.ietf.org> References: <066.93e77ab00ad6de675f313084b5a53300@trac.tools.ietf.org> X-Trac-Ticket-ID: 84 In-Reply-To: <066.93e77ab00ad6de675f313084b5a53300@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #84: Requirements Language Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 19:12:46 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C503A6ACC for ; Sat, 5 Mar 2011 19:12:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgwYAqRdYfJg for ; Sat, 5 Mar 2011 19:12:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 44BDA3A69FA for ; Sat, 5 Mar 2011 19:12:45 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw4Nx-0009cR-Ib for radiusext-data0@psg.com; Sun, 06 Mar 2011 03:11:57 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw4Nu-0009cG-Px for radiusext@ops.ietf.org; Sun, 06 Mar 2011 03:11:55 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pw4Ns-00044K-Jz; Sat, 05 Mar 2011 19:11:52 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 06 Mar 2011 03:11:52 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #85: Confidentiality Requirements X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/85#comment:1 Message-ID: <075.a26e302efa8f3d630a7e34772e82b4e4@trac.tools.ietf.org> References: <066.e17ec0e3f0e25c275ff005745ef92abc@trac.tools.ietf.org> X-Trac-Ticket-ID: 85 In-Reply-To: <066.e17ec0e3f0e25c275ff005745ef92abc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #85: Confidentiality Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposal is to change the existing text to the following: Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. This includes providing support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 20:57:35 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0C803A6A13 for ; Sat, 5 Mar 2011 20:57:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRHZcGBEP5r8 for ; Sat, 5 Mar 2011 20:57:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D1E73A6929 for ; Sat, 5 Mar 2011 20:57:34 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw60D-000DFR-VT for radiusext-data0@psg.com; Sun, 06 Mar 2011 04:55:33 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw60A-000DEi-Sk for radiusext@ops.ietf.org; Sun, 06 Mar 2011 04:55:31 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pw607-0003yq-Pn; Sat, 05 Mar 2011 20:55:27 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 06 Mar 2011 04:55:27 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #23: Comments X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/23#comment:1 Message-ID: <070.da63666a956c5b12bbf105148ebffee5@trac.tools.ietf.org> References: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #23: Comments Comment(by bernard_aboba@…): It is proposed that we change the following text in Section 4.3: Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. Included in such negotiation techniques are "hint and accept" and "hint and reject" mechanisms, where the NAS (RADIUS client) provides a list of supported algorithms and the RADIUS server selects one. To: Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within RADIUS is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be pre-configured. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms, in the absence of knowledge about the capabilities of the recipient, requests will need to be protected by legacy algorithms. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 23:00:00 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C97413A6925 for ; Sat, 5 Mar 2011 23:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LglTgw6O08cd for ; Sat, 5 Mar 2011 22:59:59 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 5BBB13A6923 for ; Sat, 5 Mar 2011 22:59:59 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw7vW-000Iay-3t for radiusext-data0@psg.com; Sun, 06 Mar 2011 06:58:50 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw7vT-000Iam-Iy for radiusext@ops.ietf.org; Sun, 06 Mar 2011 06:58:47 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pw7vR-0000kd-Q8; Sat, 05 Mar 2011 22:58:45 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 06 Mar 2011 06:58:45 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #87: Guidance on mandatory-to-implement algorithms X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/87#comment:1 Message-ID: <075.81bcdf5dc9ef15715db9f5402725319e@trac.tools.ietf.org> References: <066.91fb381c465ec50f28acab7326ef36f7@trac.tools.ietf.org> X-Trac-Ticket-ID: 87 In-Reply-To: <066.91fb381c465ec50f28acab7326ef36f7@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #87: Guidance on mandatory-to-implement algorithms Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 5 23:00:12 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C41F028C0F5 for ; Sat, 5 Mar 2011 23:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtqTupOax+qr for ; Sat, 5 Mar 2011 23:00:12 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 930A228C0E8 for ; Sat, 5 Mar 2011 23:00:11 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw7uv-000IYt-4s for radiusext-data0@psg.com; Sun, 06 Mar 2011 06:58:13 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pw7ur-000IYj-Kf for radiusext@ops.ietf.org; Sun, 06 Mar 2011 06:58:09 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Pw7un-0000jb-Mw; Sat, 05 Mar 2011 22:58:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 06 Mar 2011 06:58:05 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #23: Comments X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/23#comment:2 Message-ID: <070.6295347d267497183a0f348451db8eab@trac.tools.ietf.org> References: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #23: Comments Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Updated proposal. Add the following text to the end of Section 2: Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within RADIUS is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be pre- configured. Since legacy implementations not supporting crypto- agility will silently discard requests not protected by legacy algorithms, in the absence of knowledge about the capabilities of the recipient, requests will need to be protected by legacy algorithms. Within Section 4.3 delete: Included in such negotiation techniques are "hint and accept" and "hint and reject" mechanisms, where the NAS (RADIUS client) provides a list of supported algorithms and the RADIUS server selects one. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 7 14:24:12 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 210633A68BD for ; Mon, 7 Mar 2011 14:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HS_INDEX_PARAM=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id omIZiwn6s9Fi for ; Mon, 7 Mar 2011 14:24:10 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 9E2603A694D for ; Mon, 7 Mar 2011 14:24:07 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pwioy-0007LG-P4 for radiusext-data0@psg.com; Mon, 07 Mar 2011 22:22:32 +0000 Received: from usaga02-in.huawei.com ([206.16.17.70]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pwiov-0007Kc-Tb for radiusext@ops.ietf.org; Mon, 07 Mar 2011 22:22:29 +0000 Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LHP00KB8KTGPO@usaga02-in.huawei.com> for radiusext@ops.ietf.org; Mon, 07 Mar 2011 14:22:28 -0800 (PST) Received: from TingZousc1 ([10.193.34.192]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LHP00GJ1KTFY4@usaga02-in.huawei.com> for radiusext@ops.ietf.org; Mon, 07 Mar 2011 14:22:28 -0800 (PST) Date: Mon, 07 Mar 2011 14:22:27 -0800 From: Tina Tsou Subject: RADIUS Attributes for Dual Stack Access To: radiusext@ops.ietf.org Message-id: <003601cbdd16$24995a40$6dcc0ec0$@com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvdFTgSmao58O9zTVegcpnCQoQ2+QAAC9bwAAArp4A= x-cr-hashedpuzzle: AvVk BElT B3G7 CvQT Dtrw FUJC FlQD GAQq GXbB GXmw GYFe H/cS IRwu IpgR JAw4 Jvoq;1;cgBhAGQAaQB1AHMAZQB4AHQAQABvAHAAcwAuAGkAZQB0AGYALgBvAHIAZwA=;Sosha1_v1;7;{1E608120-8130-47D9-A2A5-8B4BDEF6DA0F};dABlAG4AYQBAAGgAdQBhAHcAZQBpAC4AYwBvAG0A;Mon, 07 Mar 2011 22:22:25 GMT;UgBBAEQASQBVAFMAIABBAHQAdAByAGkAYgB1AHQAZQBzACAAZgBvAHIAIABEAHUAYQBsACAAUwB0AGEAYwBrACAAQQBjAGMAZQBzAHMA x-cr-puzzleid: {1E608120-8130-47D9-A2A5-8B4BDEF6DA0F} Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi all, https://datatracker.ietf.org/doc/draft-yeh-radext-dual-stack-access/?include _text=1 submitted. Filename: draft-yeh-radext-dual-stack-access Revision: 00 Title: RADIUS Attributes for Dual Stack Access Creation_date: 2011-03-07 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document specifies the RADIUS attributes for IPv4 and IPv6 dual stack access, which are intended to be used in the AAA processes for the transfer of user's configuration from AAA server to NAS and traffic statistics reporting from NAS to AAA server. The new attributes cover a specified user type for NAS to allocate the proper resource and employ the right mechanism for the users; and a batch of IPv4 and IPv6 traffic statistics for the differentiated accounting policies on the AAA server. I would like to say something about this draft-yeh-radext-dual-stack-access-00. 1. draft-ietf-radext-ipv6-access is valid. 2. draft-yeh-radext-dual-stack-access-00 talks about 13 attributes. The following 6 attributes in draft-yeh-radext-dual-stack-access-00 are similar to draft-maglione-radext-ipv6-acct-extensions, which expired. o Acct-Input-IPv6-Octets o Acct-Output-IPv6-Octets o Acct-Input-IPv6-Packets o Acct-Output-IPv6-Packets o Acct-Input-IPv6-Gigawords o Acct-Output-IPv6-Gigawords 3. There is one work item of IPv6-only in WG RADEXT, would the WG tell me whether we would like to have a new work item for dual-stack? Thanks. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 11 06:05:06 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4E1E3A6BE6 for ; Fri, 11 Mar 2011 06:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbrD2+xUz0t5 for ; Fri, 11 Mar 2011 06:04:58 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0479C3A6C0F for ; Fri, 11 Mar 2011 06:04:57 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Py2vm-000Fzr-L8 for radiusext-data0@psg.com; Fri, 11 Mar 2011 14:03:02 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Py2vj-000Fzc-9d for radiusext@ops.ietf.org; Fri, 11 Mar 2011 14:02:59 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Py2ve-0000Ms-Py; Fri, 11 Mar 2011 06:02:54 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: stefan.winter@restena.lu X-Trac-Project: radext Date: Fri, 11 Mar 2011 14:02:54 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #3: Review of RTLS document (part 1, Technical) X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/3#comment:1 Message-ID: <075.e42375a209b3eff2afe0b869c38de64e@trac.tools.ietf.org> References: <066.2d399c2db02b2377eb32a2e4ed0b6a18@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <066.2d399c2db02b2377eb32a2e4ed0b6a18@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: stefan.winter@restena.lu, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #3: Review of RTLS document (part 1, Technical) Comment(by stefan.winter@…): - TLS negotiation text rewritten as suggested - certificate validation from trusted sources: removed; this will be dealt with in the dynamic discovery draft. Only a note in the non-normative section remains. - Client Identity: still needs some discussion, will be up on the slide deck at IETF 80 - DAC: as discussed on the ML, all traffic should go through the same port. A client does not have to be a DAC; if it's not, it is required to NAK the DA traffic though. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 11 18:17:19 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB8313A6CA3 for ; Fri, 11 Mar 2011 18:17:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.425 X-Spam-Level: X-Spam-Status: No, score=-102.425 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCyrjxpSEdyh for ; Fri, 11 Mar 2011 18:17:17 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C35583A67A8 for ; Fri, 11 Mar 2011 18:17:06 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyEKZ-0003dY-A3 for radiusext-data0@psg.com; Sat, 12 Mar 2011 02:13:23 +0000 Received: from rfc-editor.org ([2001:1890:1112:1::2f]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyEKW-0003dL-36 for radiusext@ops.ietf.org; Sat, 12 Mar 2011 02:13:20 +0000 Received: by rfc-editor.org (Postfix, from userid 30) id 5E006E075A; Fri, 11 Mar 2011 18:13:15 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: BCP 158, RFC 6158 on RADIUS Design Guidelines From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org Message-Id: <20110312021315.5E006E075A@rfc-editor.org> Date: Fri, 11 Mar 2011 18:13:15 -0800 (PST) Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: A new Request for Comments is now available in online RFC libraries. BCP 158 RFC 6158 Title: RADIUS Design Guidelines Author: A. DeKok, Ed., G. Weber Status: Best Current Practice Stream: IETF Date: March 2011 Mailbox: aland@freeradius.org, gdweber@gmail.com Pages: 38 Characters: 89319 See Also: BCP0158 I-D Tag: draft-ietf-radext-design-19.txt URL: http://www.rfc-editor.org/rfc/rfc6158.txt This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice. This document is a product of the RADIUS EXTensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 14:25:09 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2716A3A68F3 for ; Sat, 12 Mar 2011 14:25:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WuYDmY4NHhv for ; Sat, 12 Mar 2011 14:25:00 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7B14F3A690A for ; Sat, 12 Mar 2011 14:25:00 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyXBx-0006Na-75 for radiusext-data0@psg.com; Sat, 12 Mar 2011 22:21:45 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyXBt-0006NI-G0 for radiusext@ops.ietf.org; Sat, 12 Mar 2011 22:21:41 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyXBo-0008GY-2P; Sat, 12 Mar 2011 14:21:36 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 12 Mar 2011 22:21:36 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #86: MD5 Stream Cipher Weaknesses X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/86#comment:1 Message-ID: <075.b7696d14718211b99253c6b6fcbd5940@trac.tools.ietf.org> References: <066.62285455ad08292c0ca0af89a211ff48@trac.tools.ietf.org> X-Trac-Ticket-ID: 86 In-Reply-To: <066.62285455ad08292c0ca0af89a211ff48@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #86: MD5 Stream Cipher Weaknesses Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Note that the Access-Request isn't the only RADIUS packet not protected by a MIC in the Authenticator field; Status-Server also isn't protected that way. The proposed resolution is to change Section 3 to the following: 3. The Current State of RADIUS Security RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request [RFC2865] and Status-Server [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. While RADIUS does not support confidentiality of entire packets, various RADIUS attributes support encrypted (also known as "hidden") values, including: User-Password [RFC2865, section 5.2], Tunnel- Password [RFC2868, section 3.5], and various Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes defined in [RFC2548, section 2.4]. Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Attacks against this mechanism are described in [RFC3579] Section 4.3.4. Recent work on MD5 collisions does not immediately compromise these functions absent knowledge of the RADIUS shared secret. However, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. Add the following references to Section 8: [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dialin User Service (RADIUS) Protocol", RFC 5997, August 2011. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 14:56:35 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDBA3A6A34 for ; Sat, 12 Mar 2011 14:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvJtDRHqeVz5 for ; Sat, 12 Mar 2011 14:56:34 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8DF9C3A6A15 for ; Sat, 12 Mar 2011 14:56:33 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyXha-0007od-O1 for radiusext-data0@psg.com; Sat, 12 Mar 2011 22:54:26 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyXhW-0007oP-3S for radiusext@ops.ietf.org; Sat, 12 Mar 2011 22:54:23 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyXhR-0002iJ-Sq; Sat, 12 Mar 2011 14:54:17 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 12 Mar 2011 22:54:17 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #23: Comments X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/23#comment:3 Message-ID: <070.9c0a66bf65ec86e15d9bd13d736db30a@trac.tools.ietf.org> References: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #23: Comments Comment(by bernard_aboba@…): This still isn't quite right. While negotiation within a single RADIUS request/response is limited, there are potential techniques that could be utilized over multiple exchanges. Currently, the text doesn't describe the limitations or lay out some of the possibilities, nor does it discuss the implications for backwards compatibility for security or performance. Suggested resolution is as follows: Change Section 2 to the following: 2. A Working Definition of Crypto-Agility A generalized definition of crypto-agility was offered up at the RADEXT WG session during IETF-68. Crypto-Agility is the ability of a protocol to adapt to evolving cryptography and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to fielded implementations. It may provide for the dynamic negotiation and installation of cryptographic algorithms within protocol implementations (think of Dynamic-Link Libraries (DLL)). In the specific context of the RADIUS protocol and RADIUS implementations, crypto-agility may be better defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS Attributes. This capability covers all RADIUS message types: Access-Request/Response, Accounting-Request/Response, CoA/Disconnect- Request/Response, and Status-Server. Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be determined a-priori. Techniques that can be used for negotiation over multiple request/response exchanges are described in Section 4.3. Change the third paragraph of Section 4.2 to the following: Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks. In analyzing the resilience of a crypto-agility solution, it can be assumed that RADIUS requesters and responders can be configured to require the use of new secure algorithms in the event of a compromise of existing cryptographic algorithms or the legacy RADIUS shared secret. Change Section 4.3 to the following: 4.3. Backwards Compatibility Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy algorithms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms as well as more secure algorithms. While this approach permits the initial use of legacy algorithms between crypto-agile implementations, if the responder indicates support for crypto-agility, future requests can omit use of legacy algorithms. This approach minimizes the response delay from both legacy and crypto-agile implementations. However, it is viable only where legacy hidden attributes (e.g. User-Password) are not included within requests, and where compromise of the legacy algorithm and RADIUS shared secret does not compromise secure algorithms. Probing techniques can be used to avoid the use of legacy algorithms between crypto-agile implementations. An initial request can omit use of legacy algorithms, and if a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure algorithms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy algorithms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy algorithms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests may be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. As a result, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158] Section 2.3. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 15:09:40 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 832673A6A5B for ; Sat, 12 Mar 2011 15:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbZXUoeu9Cg1 for ; Sat, 12 Mar 2011 15:09:39 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 91A1F3A6A48 for ; Sat, 12 Mar 2011 15:09:38 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyXvO-0008Uo-4p for radiusext-data0@psg.com; Sat, 12 Mar 2011 23:08:42 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyXvJ-0008UZ-RX for radiusext@ops.ietf.org; Sat, 12 Mar 2011 23:08:38 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyXvG-0002KX-La; Sat, 12 Mar 2011 15:08:34 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 12 Mar 2011 23:08:34 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #22: Review X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/22#comment:2 Message-ID: <068.bc36bd28b83c9370b70ca5f0b380f02c@trac.tools.ietf.org> References: <059.f8c9a1d54a86dc5166344bc76ea5306d@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <059.f8c9a1d54a86dc5166344bc76ea5306d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #22: Review Comment(by bernard_aboba@…): It isn't clear to me how "Hint and Reject" techniques apply, since legacy implementations will silently discard crypto-agile requests that don't utilize legacy mechanisms, without sending an error-message. So the reality is more like "Choose and Silent Discard". This can make it hard for a requester to distinguish lack of support for crypto-agility from packet loss or some other failure. Unless a request utilizing "Hint and Accept" is protected by legacy methods, a legacy implementation will silently discard it, this approach is only possible if the responder is crypto-agile, and even then, it only applies to the response, not the request, which needs to be protected by mechanisms that are chosen apriori. Yet the document talks about the need to protect all RADIUS messages, not just responses. The reality is that in the absence of information about the capabilities of the responder, the requester will need to make a decision on what algorithms to use to protect the request. If legacy mechanisms are included, then there will be potential consequences, regardless of what other algorithms are used. So it is desirable to avoid use of legacy algorithms between crypto-agile implementations. Also, information from previous responses could be used to determine what mechanisms to use to protect subsequent requests. Since Section 4.3 is about backward compatibility, it needs to talk about some of these issues, and put forward some potential approaches to solving the problem that can address security issues in both requests and responses. The suggested resolution is to change Section 4.3 to the following: 4.3. Backwards Compatibility Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy algorithms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms as well as more secure algorithms. While this approach permits the initial use of legacy algorithms between crypto-agile implementations, if the responder indicates support for crypto-agility, future requests can omit use of legacy algorithms. This approach minimizes the response delay from both legacy and crypto-agile implementations. However, it is viable only where legacy hidden attributes (e.g. User-Password) are not included within requests, and where compromise of the legacy algorithm and RADIUS shared secret does not compromise secure algorithms. Probing techniques can be used to avoid the use of legacy algorithms between crypto-agile implementations. An initial request can omit use of legacy algorithms, and if a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure algorithms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy algorithms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy algorithms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests may be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. As a result, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158] Section 2.3. -- --------------------------------+------------------------------------------- Reporter: jsalowey@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 15:18:37 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 411893A6A6A for ; Sat, 12 Mar 2011 15:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqRTcuo8vWqk for ; Sat, 12 Mar 2011 15:18:36 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 077563A6A48 for ; Sat, 12 Mar 2011 15:18:36 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyY3S-00097N-BI for radiusext-data0@psg.com; Sat, 12 Mar 2011 23:17:02 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyY3O-00096O-Sw for radiusext@ops.ietf.org; Sat, 12 Mar 2011 23:16:59 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyY3M-0006EW-I1; Sat, 12 Mar 2011 15:16:56 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 12 Mar 2011 23:16:56 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #88: NITs X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/88 Message-ID: <066.f39d692b398a10183ca011590471e345@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #88: NITs In Section 4.5, Status-Server is left out of the list of RADIUS message to which crypto-agility should apply. Several mispellings should be fixed: "biding" -> bidding "negotation" -> negotiation -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 15:18:45 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1C4F3A6A6A for ; Sat, 12 Mar 2011 15:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7BSDjNTkKLB for ; Sat, 12 Mar 2011 15:18:45 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id B41B23A6A48 for ; Sat, 12 Mar 2011 15:18:44 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyY44-00098m-CI for radiusext-data0@psg.com; Sat, 12 Mar 2011 23:17:40 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyY41-00098Z-M0 for radiusext@ops.ietf.org; Sat, 12 Mar 2011 23:17:37 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyY3z-0007OS-By; Sat, 12 Mar 2011 15:17:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 12 Mar 2011 23:17:35 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #88: NITs X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/88#comment:1 Message-ID: <075.129345626faf9ede31c8a1d8e43c33f4@trac.tools.ietf.org> References: <066.f39d692b398a10183ca011590471e345@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <066.f39d692b398a10183ca011590471e345@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #88: NITs Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 15:36:12 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35093A69DA for ; Sat, 12 Mar 2011 15:36:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQiUXDxzTZff for ; Sat, 12 Mar 2011 15:36:10 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C09013A6939 for ; Sat, 12 Mar 2011 15:36:09 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyYJr-0009pw-DF for radiusext-data0@psg.com; Sat, 12 Mar 2011 23:33:59 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyYJo-0009pm-7E for radiusext@ops.ietf.org; Sat, 12 Mar 2011 23:33:56 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyYJl-0007Of-66; Sat, 12 Mar 2011 15:33:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 12 Mar 2011 23:33:53 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #89: Key Wrap and Password Hiding Requirements X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/89 Message-ID: <066.cff106be913743859c8f78dbb4aeb58d@trac.tools.ietf.org> X-Trac-Ticket-ID: 89 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #89: Key Wrap and Password Hiding Requirements The properties of a key and a password are different. Yet in several places, the document seems unclear about whether requirements for negotiation of Key-Wrap algorithms are distinct from requirements relating to hiding of passwords. For example, Section 1.3 states the following: The RADEXT WG will propose one or more specifications to remediate any identified deficiencies in the crypto-agility properties of the RADIUS protocol. The known deficiencies include the issue of negotiation of substitute algorithms for the message digest functions, the key-wrap functions, and the password-hiding function. Additionally, at least one mandatory to implement cryptographic algorithm will be defined in each of these areas, as required. This would seem to imply that negotiation of algorithms for key-wrap is distinct from algorithms for "password hiding". Section 2 says this: Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. While confidentiality can be provided in the transport layer, is it possible to provide keywrap functionality in this layer? Section 4.2 says: Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. This includes providing support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. This text appears to treat all encrypted attributes the same. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 15:55:05 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47DB63A695B for ; Sat, 12 Mar 2011 15:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuYTUQbrZt9h for ; Sat, 12 Mar 2011 15:55:03 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 806BA3A6778 for ; Sat, 12 Mar 2011 15:55:03 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyYcH-000AhL-1j for radiusext-data0@psg.com; Sat, 12 Mar 2011 23:53:01 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyYcD-000AgN-BL for radiusext@ops.ietf.org; Sat, 12 Mar 2011 23:52:57 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyYc9-00042j-Ic; Sat, 12 Mar 2011 15:52:53 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 12 Mar 2011 23:52:53 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #90: Process for publication and selection X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/90 Message-ID: <066.e58b887196f2be1f6847935efa1523d1@trac.tools.ietf.org> X-Trac-Ticket-ID: 90 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #90: Process for publication and selection Nowhere in the document is the approach to publication of crypto-agility solutions described, nor does the document describe how standards track crypto-agility mechanisms will be selected. Previously the RADEXT WG has utilized WG consensus to determine whether to adopt a crypto-agility proposal as a WG work item. Initial proposals are to be published as EXPERIMENTAL, and multiple implementations of WG work items are now in progress. One potential approach to evaluating standards track submissions is as follows: 1. Require documents submitted for consideration on the standards track to include an evaluation against the Crypto-agility requirements, stating whether they are compliant, conditionally compliant, or non-compliant. Documents published as EXPERIMENTAL could also include such an evaluation (though it wouldn't be required). 2. Determine the success of the experiments based on implementation experience. Factors that may be relevant include performance, required footprint, and demonstrated interoperability between multiple independent implementations. 3. Based on requirements evaluation and experiment writeups, the RADEXT WG can make the decision of whether to promote a crypto-agility proposal to the standards track. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 16:11:18 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36CC63A6A7D for ; Sat, 12 Mar 2011 16:11:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RqoZIaO3QmQ for ; Sat, 12 Mar 2011 16:11:11 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id A14A93A6A63 for ; Sat, 12 Mar 2011 16:11:05 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyYrv-000BZg-S6 for radiusext-data0@psg.com; Sun, 13 Mar 2011 00:09:11 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyYrr-000BZO-7g for radiusext@ops.ietf.org; Sun, 13 Mar 2011 00:09:08 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyYrn-0004AN-3A; Sat, 12 Mar 2011 16:09:03 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 13 Mar 2011 00:09:03 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: [radext] #91: Citation for MD5 security Issues X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/91 Message-ID: <066.a2513676ea4112890b2e940868240806@trac.tools.ietf.org> X-Trac-Ticket-ID: 91 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #91: Citation for MD5 security Issues The document currently does not provide any citations relating to MD5 or HMAC-MD5 security considerations. At a minimum, I'd suggested citing "MD5 and HMAC-MD5 Security Considerations " RFC 6151. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 16:30:35 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 317CD3A6A4D for ; Sat, 12 Mar 2011 16:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOyJvBv5Gh3g for ; Sat, 12 Mar 2011 16:30:32 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AADBC3A69F1 for ; Sat, 12 Mar 2011 16:30:32 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyZAn-000CdC-TO for radiusext-data0@psg.com; Sun, 13 Mar 2011 00:28:41 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyZAj-000Cd3-Ju for radiusext@ops.ietf.org; Sun, 13 Mar 2011 00:28:37 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyZAh-00053B-4h; Sat, 12 Mar 2011 16:28:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 13 Mar 2011 00:28:35 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #91: Citation for MD5 security Issues X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/91#comment:1 Message-ID: <075.265de9a02e42603014cb250b04dd3ee9@trac.tools.ietf.org> References: <066.a2513676ea4112890b2e940868240806@trac.tools.ietf.org> X-Trac-Ticket-ID: 91 In-Reply-To: <066.a2513676ea4112890b2e940868240806@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #91: Citation for MD5 security Issues Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is to change Section 3 to the following: 3. The Current State of RADIUS Security RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request [RFC2865] and Status-Server [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. While RADIUS does not support confidentiality of entire packets, various RADIUS attributes support encrypted (also known as "hidden") values, including: User-Password (defined in [RFC2865] Section 5.2), Tunnel-Password (defined in [RFC2868] Section 3.5), and various Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE- Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Attacks against this mechanism are described in [RFC3579] Section 4.3.4. "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 collisions do not immediately compromise the use of MD5 or HMAC-MD5 for the purposes used within RADIUS absent knowledge of the RADIUS shared secret, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. As noted in [RFC6151] Section 2: MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5; however, since MD5 must not be used for digital signatures, new protocol designs should not employ HMAC-MD5. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 12 17:41:03 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F0723A6AC4 for ; Sat, 12 Mar 2011 17:41:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9sLHkQWCdVs5 for ; Sat, 12 Mar 2011 17:40:58 -0800 (PST) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0410A3A6AC3 for ; Sat, 12 Mar 2011 17:40:58 -0800 (PST) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyaGi-000GE6-89 for radiusext-data0@psg.com; Sun, 13 Mar 2011 01:38:52 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PyaGd-000GDq-Ja for radiusext@ops.ietf.org; Sun, 13 Mar 2011 01:38:48 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PyaGa-0002RY-0O; Sat, 12 Mar 2011 17:38:44 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sun, 13 Mar 2011 01:38:43 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #23: Comments X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/23#comment:4 Message-ID: <070.4e1b1ca42d5e31e07a174868bd1fa0ed@trac.tools.ietf.org> References: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <061.3d489134c104de79506ce2674a89454d@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #23: Comments Comment(by bernard_aboba@…): It is not clear to me what is meant by "MUST use the existing mechanisms". RADIUS does not include a version field, nor is any negotiation mechanism defined in any of the existing RADIUS RFCs. Recommend that this phrase be deleted. Also, there is a simple workaround to the issue of probing delays: upgrade the responder (e.g. RADIUS server) first, so that a crypto-agile request will always receive a response. The proposed revision to Section 2 is as follows: 2. A Working Definition of Crypto-Agility A generalized definition of crypto-agility was offered up at the RADEXT WG session during IETF-68. Crypto-Agility is the ability of a protocol to adapt to evolving cryptography and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to fielded implementations. It may provide for the dynamic negotiation and installation of cryptographic algorithms within protocol implementations (think of Dynamic-Link Libraries (DLL)). In the specific context of the RADIUS protocol and RADIUS implementations, crypto-agility may be better defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS Attributes. This capability covers all RADIUS message types: Access-Request/Response, Accounting-Request/Response, CoA/Disconnect- Request/Response, and Status-Server. Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be determined a-priori. Proposals MUST NOT introduce new capabilities negotiation features into the RADIUS protocol and crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158] Section 2.3. Acceptable solutions for determining the mechanisms to be used within a request include manual configuration as well as backward compatible negotiation techniques such as those described in Section 4.3. Solutions for determining the mechanisms to be used in a response include manual configuration and "advertise and select" mechanisms (e.g. selection within the response from mechanisms advertised in a request). The proposed revision to Section 4.3 is as follows: 4.3. Backwards Compatibility Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms as well as more secure algorithms. While this approach permits the initial use of legacy algorithms between crypto-agile implementations, if the responder indicates support for crypto- agility, future requests can omit use of legacy algorithms, instead utilizing mechanisms indicated in the response. This approach minimizes the response delay from both legacy and crypto-agile implementations. However, it is viable only where legacy hidden attributes (e.g. User-Password) are not included within requests. Probing techniques can avoid the use of legacy algorithms between crypto-agile implementations. An initial request can omit use of legacy mechanisms, and if a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests may be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. As a result, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g. RADIUS servers) first. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sun Mar 13 06:32:48 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F7A3A68CB for ; Sun, 13 Mar 2011 06:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.509 X-Spam-Level: X-Spam-Status: No, score=-103.509 tagged_above=-999 required=5 tests=[AWL=0.928, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdellQKAGYs1 for ; Sun, 13 Mar 2011 06:32:47 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 394403A681A for ; Sun, 13 Mar 2011 06:32:47 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PylOM-000OI8-IA for radiusext-data0@psg.com; Sun, 13 Mar 2011 13:31:30 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PylOJ-000OHp-1t for radiusext@ops.ietf.org; Sun, 13 Mar 2011 13:31:27 +0000 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2453F3A68E9 for ; Sun, 13 Mar 2011 06:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnNy0vgObqJo; Sun, 13 Mar 2011 06:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BE763A68B5; Sun, 13 Mar 2011 06:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313133001.19061.33533.idtracker@localhost> Date: Sun, 13 Mar 2011 06:30:01 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart 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 : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-04.txt Pages : 11 Date : 2011-03-12 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13062046.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 00:17:28 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7330F3A69D0 for ; Mon, 14 Mar 2011 00:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nwUIaCyvfvAk for ; Mon, 14 Mar 2011 00:17:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C38E53A6A41 for ; Mon, 14 Mar 2011 00:17:26 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz1zI-0006ox-8B for radiusext-data0@psg.com; Mon, 14 Mar 2011 07:14:44 +0000 Received: from blu0-omc1-s13.blu0.hotmail.com ([65.55.116.24]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz1zF-0006om-A9 for radiusext@ops.ietf.org; Mon, 14 Mar 2011 07:14:41 +0000 Received: from BLU152-W43 ([65.55.116.7]) by blu0-omc1-s13.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 00:14:39 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c1e356c3-d7e5-4884-9fbb-1c82064e628f_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Agenda for IETF 80 - Take Two Date: Mon, 14 Mar 2011 00:14:39 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Mar 2011 07:14:39.0796 (UTC) FILETIME=[7BB7CF40:01CBE217] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_c1e356c3-d7e5-4884-9fbb-1c82064e628f_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RADEXT WG IETF 80 Agenda=20 =20 Chairs: Bernard Aboba Mauricio Sanchez =20 Jabber room: radext at jabber.ietf.org (Please join) =20 Wednesday=2C March 30=2C 2011 =20 0900 - 1130 =20 Karlin II and III =20 09:00 - 09:20=2C Preliminaries =20 Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 Items (40 minutes) 9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:40 AM - 9:50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (10 mi= nutes)http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access 9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite=2C R. Magliione (1= 0 minutes) http://tools.ietf.org/html/draft-ietf-softwire-dslite-radius-ext Security Work Items (60 minutes) 10:00 - 10:20 AM Crypto-Agility Requirements for RADIUS (20 minutes)http:/= /tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:20 AM - 10:30 AM RADIUS over TLS=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec =20 10:30 AM - 10:40 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery =20 10:40 AM - 10:50 AM RADIUS over DTLS=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls =20 10:50 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Discussion and Wrap-up (30 minutes) =20 11:00 =96 11:15 AM Discussion (15 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) = --_c1e356c3-d7e5-4884-9fbb-1c82064e628f_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 80 Agenda

 =3B

Chairs:

Bernard Aboba <=3Bbernard_aboba at hotmail.com>= =3B

Mauricio Sanchez <=3Bmauricio.sanchez at hp.com>= =3B

 =3B

Jabber room: =3B radext at jabber.ietf.org (Plea= se join)

 =3B

Wednesday=2C March 30=2C 2011

 =3B

0900 - 1130

 =3B

Karlin II and III

 =3B

09:00 - 09:20=2C Preliminaries

 =3B

 =3B =3B =3B =3B Debugging

 =3B =3B =3B =3B Note Well

 =3B =3B =3B =3B Note Takers

 =3B =3B =3B =3B Jabber scribe

 =3B =3B =3B =3B Agenda bash

 =3B =3B =3B =3B Document Status

=
IPv6 Items (40 minutes)


9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 min= utes)

http://tools.ietf.org/html/draft-ietf-r= adext-ipv6-access


= 9:40 AM - 9:50 AM =3B RADIUS Attributes for Dual Stack Access=2C L. Yeh= (10 minutes)

http://tools.ietf.org/html/draft-ye= h-radext-dual-stack-access


9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite=2C R. Mag= liione (10 minutes)

http://tools.ietf.org/htm= l/draft-ietf-softwire-dslite-radius-ext


<= /p>

Security Work Items (60 minutes)

 =3B

10:00 - 10:20 AM = Crypto-Agility Requirements for RADIUS (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements=


10:20 AM - 10:30 AM R= ADIUS over TLS=2C Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec<= /p>

 =3B

10:30 AM - 10:40 AM Dynamic Peer Discovery=2C Stefan= Winter (10 minutes)

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

 =3B

10:40 AM - 10:50 AM RADIUS over DTLS=2C Alan DeKok (= 10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls

 =3B

10:50 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes)
h= ttp://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (30 minutes)

 =3B

11:00 =96 11:15 AM Discussion (15 minutes)

11:15 - 11:30 =3B AM Next Steps: =3B WG Chairs &=3B ADs (15 minu= tes) = --_c1e356c3-d7e5-4884-9fbb-1c82064e628f_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 01:32:25 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D26543A6AF4 for ; Mon, 14 Mar 2011 01:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.515 X-Spam-Level: X-Spam-Status: No, score=-103.515 tagged_above=-999 required=5 tests=[AWL=0.922, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paEdZWiuJ8vE for ; Mon, 14 Mar 2011 01:32:25 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5C793A6ADD for ; Mon, 14 Mar 2011 01:32:24 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz3Bd-000Aqa-1v for radiusext-data0@psg.com; Mon, 14 Mar 2011 08:31:33 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz3BX-000AqP-DK for radiusext@ops.ietf.org; Mon, 14 Mar 2011 08:31:27 +0000 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F2BC3A6BF0 for ; Mon, 14 Mar 2011 01:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+kiG8PILT+D; Mon, 14 Mar 2011 01:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07283A6AD2; Mon, 14 Mar 2011 01:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-radsec-08.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314083001.9053.38957.idtracker@localhost> Date: Mon, 14 Mar 2011 01:30:01 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart 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 : TLS encryption for RADIUS Author(s) : S. Winter, et al. Filename : draft-ietf-radext-radsec-08.txt Pages : 19 Date : 2011-03-14 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-radsec-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14011505.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 06:01:42 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 143983A6D30 for ; Mon, 14 Mar 2011 06:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iuqNhrwwdwzE for ; Mon, 14 Mar 2011 06:01:40 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E63F73A6D2F for ; Mon, 14 Mar 2011 06:01:33 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7Lg-000Of9-7I for radiusext-data0@psg.com; Mon, 14 Mar 2011 12:58:12 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7Ld-000Oep-ND for radiusext@ops.ietf.org; Mon, 14 Mar 2011 12:58:10 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pz7LZ-0004vD-5I; Mon, 14 Mar 2011 05:58:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 12:58:05 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #73: Section 3.1 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/73#comment:1 Message-ID: <075.5959046c724c60b9451f7480c685fed5@trac.tools.ietf.org> References: <066.d29b2827497df6ae63aaa3fa296a3c3a@trac.tools.ietf.org> X-Trac-Ticket-ID: 73 In-Reply-To: <066.d29b2827497df6ae63aaa3fa296a3c3a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #73: Section 3.1 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 06:02:29 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACF203A6D14 for ; Mon, 14 Mar 2011 06:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbCklWDnNHOb for ; Mon, 14 Mar 2011 06:02:29 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96D4B3A6D13 for ; Mon, 14 Mar 2011 06:02:28 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7O2-000OoZ-08 for radiusext-data0@psg.com; Mon, 14 Mar 2011 13:00:38 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7Ny-000OoK-N9 for radiusext@ops.ietf.org; Mon, 14 Mar 2011 13:00:35 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pz7Nw-0002lh-84; Mon, 14 Mar 2011 06:00:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 13:00:32 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #72: Section 2.4 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/72#comment:1 Message-ID: <075.e3a1f6d0bc70a6447e20a229f4bc7aee@trac.tools.ietf.org> References: <066.66dcecd97615ebe1eb6e2b23188aa329@trac.tools.ietf.org> X-Trac-Ticket-ID: 72 In-Reply-To: <066.66dcecd97615ebe1eb6e2b23188aa329@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #72: Section 2.4 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 06:22:52 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFB93A6D49 for ; Mon, 14 Mar 2011 06:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SH8Uu4wKhzKV for ; Mon, 14 Mar 2011 06:22:50 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 810213A6D53 for ; Mon, 14 Mar 2011 06:22:49 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7id-00006v-Sl for radiusext-data0@psg.com; Mon, 14 Mar 2011 13:21:55 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7ia-00006c-SX for radiusext@ops.ietf.org; Mon, 14 Mar 2011 13:21:53 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pz7iU-0004vQ-PL; Mon, 14 Mar 2011 06:21:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 13:21:46 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #71: Section 2.3 and 3.3 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/71#comment:1 Message-ID: <075.8648bd0627dfacc3c98965724b69794e@trac.tools.ietf.org> References: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #71: Section 2.3 and 3.3 Changes (by wdec@…): * status: new => assigned Comment: New description reads: An IPv6 Route Information option, defined in [RFC4191] is intended to be used to inform a host connected to the NAS that a specific route is reachable via the NAS. This is particularly desirable in cases where the RG or host are multi-homed to different NASes as shown in Figure 1. This document specifies the RADIUS attribute that allows the AAA system to provision the announcement by the NAS of a specific Route Information Option to an accessing host. The NAS may advertise this route using the method defined in [RFC4191] or using other equivalent methods. The distinction and separation between this attribute and the Framed- IPv6-Route attribute defined in [RFC3633] is needed due to the need to have the information carried by this attribute advertised to an attaching client. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 06:37:16 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06E7D3A6958 for ; Mon, 14 Mar 2011 06:37:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94cAwYFLK9ac for ; Mon, 14 Mar 2011 06:37:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AE2803A6D35 for ; Mon, 14 Mar 2011 06:37:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7wZ-0000yF-1s for radiusext-data0@psg.com; Mon, 14 Mar 2011 13:36:19 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7wT-0000xt-3n for radiusext@ops.ietf.org; Mon, 14 Mar 2011 13:36:13 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pz7wO-00053G-SB; Mon, 14 Mar 2011 06:36:08 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 13:36:08 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #69: Section 1 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/69#comment:2 Message-ID: <075.c39087ffd2141d3fbd15d81d724c2897@trac.tools.ietf.org> References: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #69: Section 1 Changes (by wdec@…): * status: new => assigned Comment: Agreed with one caveat. I'm not sure that the framed-ipv6-route was intended for use with RIPng. It seems more like being intended to be intended for the NAS to install the specified route towards the client, which then may be redistributed into some IGP. This is different than advertising a route to a client by means of ICMPv6 or DHCPv6. Awaiting a response. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 06:37:57 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE2413A6D18 for ; Mon, 14 Mar 2011 06:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jPphfTEpBS0 for ; Mon, 14 Mar 2011 06:37:57 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C1B1C3A6958 for ; Mon, 14 Mar 2011 06:37:56 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7xe-00014T-E7 for radiusext-data0@psg.com; Mon, 14 Mar 2011 13:37:26 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Pz7xY-00012b-TF for radiusext@ops.ietf.org; Mon, 14 Mar 2011 13:37:21 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Pz7xW-0007bL-I6; Mon, 14 Mar 2011 06:37:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 13:37:18 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #75: Section 3.6 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/75#comment:1 Message-ID: <075.e57d998d951748e2e45de7031dec6532@trac.tools.ietf.org> References: <066.2e7de2241798d5f24e1170f6704fcbd5@trac.tools.ietf.org> X-Trac-Ticket-ID: 75 In-Reply-To: <066.2e7de2241798d5f24e1170f6704fcbd5@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #75: Section 3.6 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 09:45:12 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6173A6E2B for ; Mon, 14 Mar 2011 09:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN4Nuu+7f9a4 for ; Mon, 14 Mar 2011 09:45:11 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 93C663A6DFB for ; Mon, 14 Mar 2011 09:45:10 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzArX-000C6B-0N for radiusext-data0@psg.com; Mon, 14 Mar 2011 16:43:19 +0000 Received: from blu0-omc1-s22.blu0.hotmail.com ([65.55.116.33]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzArU-000C60-4H for radiusext@ops.ietf.org; Mon, 14 Mar 2011 16:43:16 +0000 Received: from BLU152-DS6 ([65.55.116.7]) by blu0-omc1-s22.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 09:43:15 -0700 X-Originating-IP: [98.203.198.61] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: "'radext mailing list'" Subject: Remote Presentation at IETF 80 Date: Mon, 14 Mar 2011 09:44:52 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CBE22C.782F3830" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcviZyRIHRMiwu9HSH6/DR9D31Ns6Q== Content-Language: en-us X-OriginalArrivalTime: 14 Mar 2011 16:43:15.0334 (UTC) FILETIME=[EA29CA60:01CBE266] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: ------=_NextPart_000_0031_01CBE22C.782F3830 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit If you are on the IETF 80 agenda and are interested in presenting remotely, let me know. The IETF has not had good experiences with remote presentation based on PSTN gateways, but newer technologies are available that permit the use of HD audio, so perhaps this will work better. ------=_NextPart_000_0031_01CBE22C.782F3830 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

If you are = on the IETF 80 agenda and are interested in presenting remotely, let me = know.

 

The IETF has not had good experiences with remote = presentation based on PSTN gateways,

but newer technologies are available that permit the = use of HD audio, so perhaps this will work better. =

------=_NextPart_000_0031_01CBE22C.782F3830-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 11:00:10 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 696F33A6E63 for ; Mon, 14 Mar 2011 11:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnE6qoBF1+HO for ; Mon, 14 Mar 2011 11:00:09 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D5ABB3A6E3F for ; Mon, 14 Mar 2011 11:00:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzC34-000HU3-Ge for radiusext-data0@psg.com; Mon, 14 Mar 2011 17:59:18 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzC31-000HTq-S8 for radiusext@ops.ietf.org; Mon, 14 Mar 2011 17:59:16 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzC2y-0004lk-3z; Mon, 14 Mar 2011 10:59:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 17:59:12 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #70: Section 2.1 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/70#comment:1 Message-ID: <075.d88f716e55369008b6468fd116922b4e@trac.tools.ietf.org> References: <066.c7731b5e6c1566122816ff2375fdacf3@trac.tools.ietf.org> X-Trac-Ticket-ID: 70 In-Reply-To: <066.c7731b5e6c1566122816ff2375fdacf3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #70: Section 2.1 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 11:02:24 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984613A6D5E for ; Mon, 14 Mar 2011 11:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64qEuL4Pnd34 for ; Mon, 14 Mar 2011 11:02:23 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 8C9883A69BC for ; Mon, 14 Mar 2011 11:02:23 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzC5x-000Hyp-JA for radiusext-data0@psg.com; Mon, 14 Mar 2011 18:02:17 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzC5u-000HyN-RA for radiusext@ops.ietf.org; Mon, 14 Mar 2011 18:02:15 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzC5s-0003D3-Hc; Mon, 14 Mar 2011 11:02:12 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 18:02:12 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #76: Section 6 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/76#comment:1 Message-ID: <075.7a00433cb27caae2c3202b2493bcdee5@trac.tools.ietf.org> References: <066.2b073272645f39932eb8e4824d4ecbff@trac.tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <066.2b073272645f39932eb8e4824d4ecbff@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #76: Section 6 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 11:28:36 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EB633A6A72 for ; Mon, 14 Mar 2011 11:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8lv2O3FHv1XB for ; Mon, 14 Mar 2011 11:28:34 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 089973A68C3 for ; Mon, 14 Mar 2011 11:28:29 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCTW-000JmP-QS for radiusext-data0@psg.com; Mon, 14 Mar 2011 18:26:38 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCTU-000Jm9-6L for radiusext@ops.ietf.org; Mon, 14 Mar 2011 18:26:36 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzCTR-0006oE-J2; Mon, 14 Mar 2011 11:26:33 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 18:26:33 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #77: Section 2 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/77#comment:1 Message-ID: <075.84f96fc91b915f57ff87c90e755db255@trac.tools.ietf.org> References: <066.240d180f65d3cd15f7155459b259b621@trac.tools.ietf.org> X-Trac-Ticket-ID: 77 In-Reply-To: <066.240d180f65d3cd15f7155459b259b621@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #77: Section 2 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 11:40:20 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4123A6A26 for ; Mon, 14 Mar 2011 11:40:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Omb6UQj4V6uc for ; Mon, 14 Mar 2011 11:40:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id D09423A6A03 for ; Mon, 14 Mar 2011 11:40:18 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCfK-000KUK-8v for radiusext-data0@psg.com; Mon, 14 Mar 2011 18:38:50 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCfH-000KUA-DD for radiusext@ops.ietf.org; Mon, 14 Mar 2011 18:38:47 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzCfE-0005vb-DM; Mon, 14 Mar 2011 11:38:44 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 18:38:44 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #61: DNS attribute for IPv4? X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/61#comment:3 Message-ID: <075.27e0e097ed48892f86193ab65f689ce0@trac.tools.ietf.org> References: <066.cc2411f6b119d81f73eec60b018d6670@trac.tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <066.cc2411f6b119d81f73eec60b018d6670@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #61: DNS attribute for IPv4? Changes (by wdec@…): * status: new => assigned Comment: IETF spec, no, existing implementations however do things like http://freeradius.org/rfc/rfc2548.html#MS-Primary-DNS-Server. Let me know how you'd like to see this represented. We didn't want to provide links to specific implementations, but also not hide from the fact that limited VSAs are being used. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 11:43:54 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 524943A6A31 for ; Mon, 14 Mar 2011 11:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zy8aF78ka2zb for ; Mon, 14 Mar 2011 11:43:53 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9BB73A6A2D for ; Mon, 14 Mar 2011 11:43:52 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzChc-000Kcu-QH for radiusext-data0@psg.com; Mon, 14 Mar 2011 18:41:12 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCha-000Kcc-7W for radiusext@ops.ietf.org; Mon, 14 Mar 2011 18:41:10 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzChX-0002EO-Qg; Mon, 14 Mar 2011 11:41:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 18:41:07 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #62: Use of "Address" X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/62#comment:2 Message-ID: <075.e93d09b625265f5b415b62e02c99c5d3@trac.tools.ietf.org> References: <066.17eef1017064d45f1c34a9e0e44ff3f1@trac.tools.ietf.org> X-Trac-Ticket-ID: 62 In-Reply-To: <066.17eef1017064d45f1c34a9e0e44ff3f1@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #62: Use of "Address" Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as suggested. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 11:44:28 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1BF93A6979 for ; Mon, 14 Mar 2011 11:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9yKjssX9Iiy for ; Mon, 14 Mar 2011 11:44:27 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 96D753A68C3 for ; Mon, 14 Mar 2011 11:44:27 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCk8-000Kpu-P8 for radiusext-data0@psg.com; Mon, 14 Mar 2011 18:43:48 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCk5-000Kpi-RP for radiusext@ops.ietf.org; Mon, 14 Mar 2011 18:43:46 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzCk3-0004e9-FD; Mon, 14 Mar 2011 11:43:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 18:43:43 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #74: Section 3.2 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/74#comment:1 Message-ID: <075.c5489a2ca9b7fce0ac6e53ce4917ec3c@trac.tools.ietf.org> References: <066.74b35e8d828c4c9a7d45a91f8991e364@trac.tools.ietf.org> X-Trac-Ticket-ID: 74 In-Reply-To: <066.74b35e8d828c4c9a7d45a91f8991e364@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #74: Section 3.2 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Will clarify that order of attributes is supposed to be reflected in the client advertisement. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 11:45:21 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87FE93A6E63 for ; Mon, 14 Mar 2011 11:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-oPgY00yr2w for ; Mon, 14 Mar 2011 11:45:20 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 634073A6E15 for ; Mon, 14 Mar 2011 11:45:15 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCiQ-000KhF-TK for radiusext-data0@psg.com; Mon, 14 Mar 2011 18:42:03 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzCiO-000KgT-3d for radiusext@ops.ietf.org; Mon, 14 Mar 2011 18:42:00 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1PzCiL-0004WN-Js; Mon, 14 Mar 2011 11:41:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 14 Mar 2011 18:41:57 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #68: Abstract X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/68#comment:2 Message-ID: <075.b346fb2494f8e94fe1bccb0a79e89aef@trac.tools.ietf.org> References: <066.8a6e2f0a86c5f4506a6394a1e6cbb2d2@trac.tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <066.8a6e2f0a86c5f4506a6394a1e6cbb2d2@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #68: Abstract Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 12:18:32 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83083A6B49 for ; Mon, 14 Mar 2011 12:18:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.75 X-Spam-Level: X-Spam-Status: No, score=-103.75 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq0LXKENkClV for ; Mon, 14 Mar 2011 12:18:32 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id F2E453A6B50 for ; Mon, 14 Mar 2011 12:18:30 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzDG9-000NK0-2y for radiusext-data0@psg.com; Mon, 14 Mar 2011 19:16:53 +0000 Received: from mail.ietf.org ([2001:1890:1112:1::20]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzDG6-000NJj-CL for radiusext@ops.ietf.org; Mon, 14 Mar 2011 19:16:50 +0000 Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CF43A6979 for ; Mon, 14 Mar 2011 12:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UWxJHHZJvMI; Mon, 14 Mar 2011 12:15:03 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6FD03A6B57; Mon, 14 Mar 2011 12:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-ipv6-access-04.txt X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314191502.23501.21922.idtracker@localhost> Date: Mon, 14 Mar 2011 12:15:02 -0700 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --NextPart 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 : RADIUS attributes for IPv6 Access Networks Author(s) : B. Lourdelet, et al. Filename : draft-ietf-radext-ipv6-access-04.txt Pages : 13 Date : 2011-03-14 This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement, and assignment of a named IPv6 delegated prefix pool. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-ipv6-access-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14120837.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 19:40:03 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281AF3A6B1E for ; Mon, 14 Mar 2011 19:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.259 X-Spam-Level: X-Spam-Status: No, score=-1.259 tagged_above=-999 required=5 tests=[AWL=1.340, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZc4Bg9Sz+-8 for ; Mon, 14 Mar 2011 19:40:01 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 4D20E3A6A3A for ; Mon, 14 Mar 2011 19:40:01 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzK7t-000MES-BK for radiusext-data0@psg.com; Tue, 15 Mar 2011 02:36:49 +0000 Received: from szxga01-in.huawei.com ([119.145.14.64]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzK7q-000MEJ-J0 for radiusext@ops.ietf.org; Tue, 15 Mar 2011 02:36:46 +0000 Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI200FJ5V8YUV@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Tue, 15 Mar 2011 10:36:34 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI2009M5V8YUK@szxga05-in.huawei.com> for radiusext@ops.ietf.org; Tue, 15 Mar 2011 10:36:34 +0800 (CST) Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 15 Mar 2011 10:36:32 +0800 Received: from SZXEML504-MBX.china.huawei.com ([169.254.8.52]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Tue, 15 Mar 2011 10:36:34 +0800 Date: Tue, 15 Mar 2011 02:36:32 +0000 From: Jiangsheng Subject: RE: RADEXT WG Agenda for IETF 80 - Take Two In-reply-to: <5D36713D8A4E7348A7E10DF7437A4B927FCF8E@SZXEML504-MBX.china.huawei.com> X-Originating-IP: [172.24.2.40] To: Bernard Aboba , "radiusext@ops.ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B927FD43E@SZXEML504-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-GB Content-transfer-encoding: quoted-printable Accept-Language: en-GB, zh-CN, en-US Thread-topic: RADEXT WG Agenda for IETF 80 - Take Two Thread-index: AQHL4hgoO9t7qHZW2EO8m89vqaF/25QsezhBgAE0C8E= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <5D36713D8A4E7348A7E10DF7437A4B927FCF8E@SZXEML504-MBX.china.huawei.com> Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Dear RADEXT chairs, We did send a request for presentation as early as March 4th. It is an soft= wire WG draft, which is IPv6 relevant. "RADIUS Attribute for 6rd" draft-ietf-softwire-6rd-radius-attrib update for radext WG review. The presentation should be less than 5 mins, 10 mins slot should be enough = including discussion. Thanks and regards, Sheng From: owner-radiusext@ops.ietf.org [owner-radiusext@ops.ietf.org] on behalf= of Bernard Aboba [bernard_aboba@hotmail.com] Sent: 14 March 2011 15:14 To: radiusext@ops.ietf.org Subject: RADEXT WG Agenda for IETF 80 - Take Two RADEXT WG IETF 80 Agenda=20 Chairs: Bernard Aboba Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Wednesday, March 30, 2011 0900 - 1130 Karlin II and III 09:00 - 09:20, Preliminaries Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 Items (40 minutes) 9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:40 AM - 9:50 AM RADIUS Attributes for Dual Stack Access, L. Yeh (10 minu= tes) http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access 9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite, R. Magliione (10 = minutes) http://tools.ietf.org/html/draft-ietf-softwire-dslite-radius-ext Security Work Items (60 minutes) 10:00 - 10:20 AM Crypto-Agility Requirements for RADIUS (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:20 AM - 10:30 AM RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec 10:30 AM - 10:40 AM Dynamic Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:40 AM - 10:50 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls 10:50 - 11:00 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Discussion and Wrap-up (30 minutes) 11:00 =96 11:15 AM Discussion (15 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) = -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 14 23:11:39 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B0323A6B80 for ; Mon, 14 Mar 2011 23:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.455 X-Spam-Level: X-Spam-Status: No, score=-102.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mx34hymEDe8d for ; Mon, 14 Mar 2011 23:11:28 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 220053A697C for ; Mon, 14 Mar 2011 23:10:51 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzNRJ-0007FB-HM for radiusext-data0@psg.com; Tue, 15 Mar 2011 06:09:05 +0000 Received: from blu0-omc1-s27.blu0.hotmail.com ([65.55.116.38]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzNRG-0007Ew-Fc for radiusext@ops.ietf.org; Tue, 15 Mar 2011 06:09:02 +0000 Received: from BLU152-W60 ([65.55.116.8]) by blu0-omc1-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 23:09:01 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_439a6b67-6c2a-4271-8933-8640607a6667_" X-Originating-IP: [98.203.198.61] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT Agenda for IETF 80 - Take 3 Date: Mon, 14 Mar 2011 23:09:01 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 15 Mar 2011 06:09:01.0671 (UTC) FILETIME=[7AD35F70:01CBE2D7] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_439a6b67-6c2a-4271-8933-8640607a6667_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry for the confusion relating to the IPv6 presentations. Here is a revi= sed agenda.=20 =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 RADEXT WG IETF 80 Agenda Chairs: Bernard Aboba
Sorry for the confusion relating to the IPv6 presentations. =3B Her= e is a revised agenda.

=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
RADEXT WG IETF 80 Agenda

Chairs:
Bernard Aboba <=3Bberna= rd_aboba at hotmail.com
Mauricio Sanchez <=3Bmauricio.sanchez at hp.co= m

Jabber room: radext at jabber.ietf.org (Please join)

Wednes= day=2C March 30=2C 2011

0900 - 1130

Karlin II and III

= 09:00 - 09:20=2C Preliminaries (20 minutes)

Audio/Video &=3B Remo= te Presentation Debugging
Note Well
Note Takers
Jabber scribe
A= genda bash
Document Status

IPv6 Items (45 minutes)

9:20 - = 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)
http://t= ools.ietf.org/html/draft-ietf-radext-ipv6-access

9:35 AM - 9:50 AM R= ADIUS Attributes for Dual Stack Access=2C L. Yeh (15 minutes)
http://too= ls.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM - 10:05 = AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)
http://tools.ie= tf.org/html/draft-ietf-softwire-6rd-radius-attrib

Security Work Item= s (60 minutes)

10:05 - 10:25 AM Crypto-Agility Requirements for RADI= US (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agil= ity-requirements

10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winte= r (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec
10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)<= br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

10= :45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://too= ls.ietf.org/html/draft-ietf-radext-dtls

10:55 - 11:05 AM RADIUS Prot= ocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/dr= aft-ietf-radext-radius-extensions

Discussion and Wrap-up (25 minutes= )

11:05 =96 11:20 AM Discussion (15 minutes)
11:20 - 11:30 AM Nex= t Steps: WG Chairs &=3B ADs (10 minutes)

= --_439a6b67-6c2a-4271-8933-8640607a6667_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Mar 15 10:41:36 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E9D3A6DBA for ; Tue, 15 Mar 2011 10:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeJRSABUKJOR for ; Tue, 15 Mar 2011 10:41:35 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id AC85C3A6971 for ; Tue, 15 Mar 2011 10:41:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzYDf-000KC6-4L for radiusext-data0@psg.com; Tue, 15 Mar 2011 17:39:43 +0000 Received: from mail200.messagelabs.com ([216.82.254.195]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1PzYDc-000KBn-6V for radiusext@ops.ietf.org; Tue, 15 Mar 2011 17:39:40 +0000 X-VirusChecked: Checked X-Env-Sender: avi@bridgewatersystems.com X-Msg-Ref: server-5.tower-200.messagelabs.com!1300210776!92153259!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [72.35.6.119] Received: (qmail 27728 invoked from network); 15 Mar 2011 17:39:37 -0000 Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-5.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 15 Mar 2011 17:39:37 -0000 Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Tue, 15 Mar 2011 13:39:36 -0400 From: Avi Lior To: "bernard_aboba@hotmail.com" CC: "radiusext@ops.ietf.org" , Alper Yegin Date: Tue, 15 Mar 2011 13:39:35 -0400 Subject: [IANA #409959] Genreral Request for Assignements Thread-Topic: [IANA #409959] Genreral Request for Assignements Thread-Index: AcvjN/PfETWqJsnhRbCJ3Q5584NJVA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3 Content-Type: multipart/alternative; boundary="_000_C9A51C9711D20avibridgewatersystemscom_" MIME-Version: 1.0 Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_000_C9A51C9711D20avibridgewatersystemscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard, Thank you for the review of the NAS-Port-Type IANA request for assignment. = In a previous email you were seeking answers to the following questions: Bernard wrote: Can someone answer the following questions? 1. What is different between WiMAX WiFi and normal IEEE 802.11? We already= have a number of IEEE 802.11 NAS-Port-types allocated and have proposed ad= ditional data for this. 2. Why do DHCP and a location service need NAS-Port-Type values? 3. Why should we just allocate a generic WiMAX NAS-Port and let additional = data be included in a WiMAX Forum VSA? The general answer to your question is as follows: For a given session, the WIMAX AAA Server interacts with many different WiM= AX network elements and also non-WiMAX network elements. The approach take= n by WiMAX is to have an explicit indication from the NAS as to the context= of the RADIUS access-request. The NAS-Port-Type is viewed as the attribut= e to provide that information. WRT 1) the WiMAX AAA needs to be able to differentiate between a normal WiF= i Access and a WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additio= nal behaviours over and above the "normal" wifi AP. T WRT 2) Again, WiMAX AAA needs to differentiate between the request from bot= h these entities because the AAA behaviour is different when request comes = from a DHCP server vs., a Location Based Server. WRT 3) WiMAX would just be inventing our own NAS-Port-Type attribute. We = thought the idea is that we reuse attributes when we can. Since there doesn= 't seem to be a lack of number space associated with NAS-Port-Type there do= esn't seem to be a reason to invent our own attribute. -- Avi Lior --Bridgewater Systems --_000_C9A51C9711D20avibridgewatersystemscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Hi Berna= rd,

Thank you for the review of the NAS-Port-Type = IANA request for assignment.  In a previous email you were seeking ans= wers to the following questions:

Bernard wrote:

Can someone answer the following questions?

1. What is diff= erent between WiMAX WiFi and normal IEEE 802.11?  We already have a nu= mber of IEEE 802.11 NAS-Port-types allocated and have proposed additional d= ata for this.

2. Why do DHCP and a location service need NAS-Port-Type values?&nbs= p;

3. W= hy should we just allocate a generic WiMAX NAS-Port and let additional data= be included in a WiMAX Forum VSA?

The general answer to your question is as follows:

For a given session, the WIMAX AAA= Server interacts with many different WiMAX network elements and also non-W= iMAX network elements.  The approach taken by WiMAX is to have an expl= icit indication from the NAS as to the context of the RADIUS access-request= .  The NAS-Port-Type is viewed as the attribute to provide that inform= ation.

= WRT 1) the WiMA= X AAA needs to be able to differentiate between a normal WiFi Access and a = WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additional behaviours = over and above the "normal" wifi AP.  T


WRT 2) Again, WiMAX AAA needs to differentiate between the request = from both these entities because the AAA behaviour is different when reques= t comes from  a DHCP server vs., a Location Based Server.

WRT 3)  WiMAX would just be i= nventing our own NAS-Port-Type attribute.  We thought the idea is that= we reuse attributes when we can. Since there doesn't seem to be a lack of = number space associated with NAS-Port-Type there doesn't seem to be a reaso= n to invent our own attribute.


-- Avi Lior
--Bridgewater Systems

--_000_C9A51C9711D20avibridgewatersystemscom_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 18 16:35:03 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 432003A6A6A for ; Fri, 18 Mar 2011 16:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fLA03vbrQhnO for ; Fri, 18 Mar 2011 16:35:00 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id EBA9D3A6A83 for ; Fri, 18 Mar 2011 16:34:59 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q0j9j-000P65-VH for radiusext-data0@psg.com; Fri, 18 Mar 2011 23:32:31 +0000 Received: from blu0-omc2-s1.blu0.hotmail.com ([65.55.111.76]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q0j9e-000P5l-Kz for radiusext@ops.ietf.org; Fri, 18 Mar 2011 23:32:26 +0000 Received: from BLU152-DS15 ([65.55.111.73]) by blu0-omc2-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 16:32:25 -0700 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: Bernard Aboba To: CC: References: In-Reply-To: Subject: RE: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575 Date: Fri, 18 Mar 2011 16:32:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIez56AUaxI2URk3tiewLiApVCSbQIrFVhsAppot3OTZ7xa8A== Content-Language: en-us X-OriginalArrivalTime: 18 Mar 2011 23:32:25.0358 (UTC) FILETIME=[BCC52AE0:01CBE5C4] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: RFC 3575 Section 2.1 states the following: Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC. Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not = called out as an exception, only Service-Type.=20 If the intent was to exempt RFC 2868, those attributes would have been = included as exceptions but they are not.=20 Therefore, it looks to me like the omission of RFC 2868 in the Updates: = header is an errata. =20 What do other WG participants think? -----Original Message----- From: Amanda Baber via RT [mailto:iana-questions@iana.org]=20 Sent: Friday, March 18, 2011 2:59 PM To: bernard_aboba@hotmail.com Subject: [IANA #278793] Registration of RADIUS Attribute Values and RFC = 3575=20 Hi, I'm afraid I lost track of this message about fixing IANA's descriptions = of RADIUS registration procedures.=20 Given RFC 3575, all of the RADIUS attribute values but 6 (Service-Type), 64 (Tunnel-Type), and 65 (Tunnel-Medium-Type) are now listed as Expert = Review registries. Those remaining three are listed as IETF Consensus. Please see http://www.iana.org/assignments/radius-types The issue with Tunnel-Type and Tunnel-Medium-Type, which has come up = before, is that RFC2868 specifically calls them IETF Consensus = registries, and RFC3575 doesn't update RFC2868. Is this reading correct, = or does RFC3575 supersede 2868 anyway? Since we're not sure what to do about Tunnel-Type and = Tunnel-Medium-Type, the directory at http://www.iana.org/protocols/ = currently says, "Registration procedure varies by attribute." Do we need to make any changes? thanks, Amanda On Tue Nov 10 01:45:42 2009, bernard_aboba@hotmail.com wrote: > Recently on the RADEXT WG mailing list, an issue has been raised about = > the IANA allocation procedures for RADIUS attribute values: >=20 > http://ops.ietf.org/lists/radiusext/2009/msg00625.html >=20 > =20 >=20 > As noted in RFC 3575, Section 2.1: >=20 > =20 >=20 > Certain attributes (for example, NAS-Port-Type) in RADIUS define a >=20 > list of values to correspond with various meanings. There can be 4 >=20 > billion (2^32) values for each attribute. Additional values can be >=20 > allocated by the Designated Expert. The exception to this policy=20 > is >=20 > the Service-Type attribute (6), whose values define new modes of >=20 > operation for RADIUS. Values 1-16 of the Service-Type attribute=20 > have >=20 > been allocated. Allocation of new Service-Type values are by IETF >=20 > Consensus. The intention is that any allocation will be=20 > accompanied >=20 > by a published RFC. >=20 > =20 >=20 > Given the above text, it is my understanding that according to RFC=20 > 3575, additional values for RADIUS attributes (with the exception of=20 > the Service-Type attribute (6)) are to be allocated by Designated = Expert. >=20 > =20 >=20 > However, within the IANA RADIUS registry=20 > (http://www.iana.org/protocols/) RADIUS attribute values are listed as = requiring Standards Action. >=20 > =20 >=20 > We have already had one instance in which the insistence on Standards Action > has resulted in a large delay in value allocation with the resulting use of > Vendor-Specific Values as described in RFC 2822. Given that RFC 3575=20 > specifically indicates that standards action is not required for allocation > of values for any RADIUS attribute other than Service-Type, there is=20 > not much room for interpretation here and I would like to make sure=20 > that this problem is corrected as soon as possible. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Sat Mar 19 00:09:08 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99F543A69BE for ; Sat, 19 Mar 2011 00:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnGP4Lajp-Jg for ; Sat, 19 Mar 2011 00:09:07 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 10B5E3A69ED for ; Sat, 19 Mar 2011 00:09:06 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q0qGs-000Ket-Rl for radiusext-data0@psg.com; Sat, 19 Mar 2011 07:08:22 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q0qGq-000Keh-AP for radiusext@ops.ietf.org; Sat, 19 Mar 2011 07:08:20 +0000 Message-ID: <4D845660.6050502@deployingradius.com> Date: Sat, 19 Mar 2011 08:08:16 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org, iana-questions@iana.org Subject: Re: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575 References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Bernard Aboba wrote: > Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not called out as an exception, only Service-Type. > If the intent was to exempt RFC 2868, those attributes would have been included as exceptions but they are not. > > Therefore, it looks to me like the omission of RFC 2868 in the Updates: header is an errata. I agree. IIRC, there are a number of other inconsistencies in the IANA registry. I ran into that a while ago when doing some research, but never made a specific note of the problem. I'll see if I can track that down. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 24 17:40:13 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA36528C11A for ; Thu, 24 Mar 2011 17:40:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2MRkeEFskBB for ; Thu, 24 Mar 2011 17:40:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 737FB28C113 for ; Thu, 24 Mar 2011 17:40:08 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q2v27-0000Dn-D9 for radiusext-data0@psg.com; Fri, 25 Mar 2011 00:37:43 +0000 Received: from blu0-omc1-s30.blu0.hotmail.com ([65.55.116.41]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q2v1y-0000Dd-IF for radiusext@ops.ietf.org; Fri, 25 Mar 2011 00:37:34 +0000 Received: from BLU152-W51 ([65.55.116.7]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Mar 2011 17:37:33 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9ac3b4a7-ceec-46a7-a851-85a7455545b2_" X-Originating-IP: [62.168.35.7] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Presentations Date: Thu, 24 Mar 2011 17:37:32 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Mar 2011 00:37:33.0197 (UTC) FILETIME=[D48093D0:01CBEA84] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_9ac3b4a7-ceec-46a7-a851-85a7455545b2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are presenting at IETF 80=2C please get your slides in ASAP. Agend= a is given below.=20 =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 RADEXT WG IETF 80 Agenda Chairs: Bernard Aboba If you are presenting at IETF 80=2C please get your slides in ASAP. =3B=  =3B Agenda is given below.

=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
RADEXT WG IETF 80 Agenda

Chairs:
Bernard Ab= oba <=3Bbernard_aboba at hotmail.com
Mauricio Sanchez <=3Bmauricio.s= anchez at hp.com

Jabber room: radext at jabber.ietf.org (Please join= )

Wednesday=2C March 30=2C 2011
0900 - 1130
Karlin II and III<= br>
09:00 - 09:20=2C Preliminaries (20 minutes)

Audio/Video &= =3B Remote Presentation Debugging
Note Well
Note Takers
Jabber scr= ibe
Agenda bash
Document Status

IPv6 Items (45 minutes)
9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)
= http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

9:35 AM - 9= :50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (15 minutes)
ht= tp://tools.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM = - 10:05 AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)
http://= tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib

Security W= ork Items (60 minutes)

10:05 - 10:25 AM Crypto-Agility Requirements = for RADIUS (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-cry= pto-agility-requirements

10:25 AM - 10:35 AM RADIUS over TLS=2C Stef= an Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-rads= ec

10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 m= inutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery
10:45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
ht= tp://tools.ietf.org/html/draft-ietf-radext-dtls

10:55 - 11:05 AM RAD= IUS Protocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org= /html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (25= minutes)
= --_9ac3b4a7-ceec-46a7-a851-85a7455545b2_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 25 23:14:16 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A1E3A68DE for ; Fri, 25 Mar 2011 23:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bticFCcYt8Ho for ; Fri, 25 Mar 2011 23:14:15 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BD1723A6823 for ; Fri, 25 Mar 2011 23:14:14 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q3MjO-0002i1-9n for radiusext-data0@psg.com; Sat, 26 Mar 2011 06:12:14 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q3MjK-0002ho-Rb for radiusext@ops.ietf.org; Sat, 26 Mar 2011 06:12:11 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q3MjH-0007Wa-44; Fri, 25 Mar 2011 23:12:07 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 26 Mar 2011 06:12:07 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #69: Section 1 X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/radext/trac/ticket/69#comment:3 Message-ID: <075.4226a94b879e162027dd17b7c0f4e5c0@trac.tools.ietf.org> References: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-Trac-Ticket-ID: 69 In-Reply-To: <066.2bae7a4d167a08e0f441859ab7024657@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #69: Section 1 Comment(by bernard_aboba@…): The RFC 3162 text on Framed-IPv6-Route is included below. The text is analagous to that used to define Framed-Route in RFC 2865, Section 5.22. Note that RFC 2865 also defines Framed-Routing (Section 5.10), which determines how or if an IGP is used. If Framed-Routing = None or Listen, then I wouldn't expect routes to be redistributed into an IGP. The question is what existing implementations do with Framed-IPv6-Route and whether this is influenced by the value of Framed-Routing. 2.5. Framed-IPv6-Route Description This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times. A summary of the Framed-IPv6-Route Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 99 for Framed-IPv6-Route Length >=3 Text The Text field is one or more octets, and its contents are implementation dependent. The field is not NUL (hex 00) terminated. It is intended to be human readable and MUST NOT affect operation of the protocol. For IPv6 routes, it SHOULD contain a destination prefix optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address, a space, and one or more metrics (encoded in decimal) separated by spaces. Prefixes and addresses are formatted as described in [16]. For example, "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". Whenever the gateway address is the IPv6 unspecified address the IP address of the user SHOULD be used as the gateway address. The unspecified address can be expressed in any of the acceptable formats described in [16]. For example, "2000:0:0:106::/64 :: 1". -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 25 23:24:04 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 648C43A6889 for ; Fri, 25 Mar 2011 23:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTX-deV44Fz1 for ; Fri, 25 Mar 2011 23:24:03 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14A843A6805 for ; Fri, 25 Mar 2011 23:24:03 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q3MuJ-0003HP-N1 for radiusext-data0@psg.com; Sat, 26 Mar 2011 06:23:31 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q3MuF-0003HE-Uv for radiusext@ops.ietf.org; Sat, 26 Mar 2011 06:23:28 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q3MuD-0007ii-JM; Fri, 25 Mar 2011 23:23:25 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Sat, 26 Mar 2011 06:23:25 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #71: Section 2.3 and 3.3 X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/71#comment:2 Message-ID: <075.9bd488c0f66fb10c88f3ff612e054d22@trac.tools.ietf.org> References: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #71: Section 2.3 and 3.3 Comment(by bernard_aboba@…): It seems to me that we want to enable use of routes in advertisements as well as in routing protocols, and possibly both at once. RFC 3162 defines Framed-IPv6-Route, and the intent there was to enable inclusion in router advertisements, as well as potential redistribution in IGPs, depending on the value of Framed-Routing. The question is how it was implemented. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Fri Mar 25 23:30:32 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CF513A68DC for ; Fri, 25 Mar 2011 23:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.487 X-Spam-Level: X-Spam-Status: No, score=-102.487 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UHgYHxyXgdCG for ; Fri, 25 Mar 2011 23:30:31 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 217AB3A688C for ; Fri, 25 Mar 2011 23:30:31 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q3N0k-0003Y8-9u for radiusext-data0@psg.com; Sat, 26 Mar 2011 06:30:10 +0000 Received: from blu0-omc1-s20.blu0.hotmail.com ([65.55.116.31]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q3N0h-0003Xy-N3 for radiusext@ops.ietf.org; Sat, 26 Mar 2011 06:30:07 +0000 Received: from BLU152-W6 ([65.55.116.9]) by blu0-omc1-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Mar 2011 23:30:04 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_d196902c-a730-478d-8b74-b80b2aafac21_" X-Originating-IP: [62.168.35.7] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Question to implementers of Framed-IPv6-Route Date: Fri, 25 Mar 2011 23:30:03 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2011 06:30:04.0164 (UTC) FILETIME=[3DDFC440:01CBEB7F] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_d196902c-a730-478d-8b74-b80b2aafac21_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The question has arisen as to what NAS implementers of Framed-IPv6-Route do= with the attribute.=20 The attribute (defined in RFC 3162) is defined using language similar to th= at of Framed-Route in RFC 2865=2C so one might assume a similar use. However=2C RFC 3162 did not= define a Framed-IPv6-Routing attribute to parallel the Framed-Routing attribute defined in RFC 2865=2C s= o that it is possible that implementers did not use Framed-Ipv6-Route in a similar way to the Framed-R= oute/Framed-Routing attributes defined in RFC 2865.=20 If you have implemented Framed-Ipv6-Route on a NAS=2C please tell us what y= ou do with the information: 1. Do you announce the routes via RA? 2. Do you look at Framed-Routing to determine if the routes are redistribut= ed into an IGP? = --_d196902c-a730-478d-8b74-b80b2aafac21_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The question has arisen as to what NAS implementers of Framed-IPv6-Route do= with the attribute.

The attribute (defined in RFC 3162) is defined= using language similar to that of Framed-Route in
RFC 2865=2C so one mi= ght assume a similar use. =3B However=2C RFC 3162 did not define a Fram= ed-IPv6-Routing
attribute to parallel the Framed-Routing attribute defin= ed in RFC 2865=2C so that it is possible that
implementers did not use F= ramed-Ipv6-Route in a similar way to the Framed-Route/Framed-Routing
att= ributes defined in RFC 2865.

If you have implemented Framed-Ipv6-Ro= ute on a NAS=2C please tell us what you do with the information:

1. = Do you announce the routes via RA?
2. Do you look at Framed-Routing to d= etermine if the routes are redistributed into an IGP?
= --_d196902c-a730-478d-8b74-b80b2aafac21_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Mon Mar 28 09:05:14 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 03AE428C0D7 for ; Mon, 28 Mar 2011 09:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T88FlBdz2by8 for ; Mon, 28 Mar 2011 09:05:13 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id C7B443A6A5E for ; Mon, 28 Mar 2011 09:05:12 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4Eur-000BWf-3y for radiusext-data0@psg.com; Mon, 28 Mar 2011 16:03:41 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4Euo-000BWO-7r for radiusext@ops.ietf.org; Mon, 28 Mar 2011 16:03:38 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4Eul-0007V6-AP; Mon, 28 Mar 2011 09:03:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Mon, 28 Mar 2011 16:03:35 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #71: Section 2.3 and 3.3 X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/radext/trac/ticket/71#comment:3 Message-ID: <075.204a3c8c6b6ef713c01869efa5de2d14@trac.tools.ietf.org> References: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-Trac-Ticket-ID: 71 In-Reply-To: <066.72032b396a31a3350ac652b172d83b12@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #71: Section 2.3 and 3.3 Comment(by wdec@…): Well, but it seems that there is a key distintiction between the routes that are advertised *to* the client by the NAS as being reachable via the NAS vs those that are installed to point to the client. Using one attribute, eg Framed-IPv6-Route, for both appears to be more than an implementation question. It's about the intended semantics IMO. How about this as new text? An IPv6 Route Information option, defined in [RFC4191] is intended to be used to inform a host connected to the NAS that a specific route is reachable via the NAS. This is particularly desirable in cases where the RG or host are multi-homed to different NASes as shown in Figure 1. This document specifies the RADIUS attribute that allows the AAA system to provision the announcement by the NAS to an accessing host. The NAS may advertise this route using the method defined in [RFC4191] or using other equivalent methods. The distinction and separation between this attribute and the Framed- IPv6-Route attribute defined in [RFC3633] is needed due to the need to have the information carried by this attribute advertised to an attaching client. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Mar 29 01:55:39 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD1728C0F5 for ; Tue, 29 Mar 2011 01:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.491 X-Spam-Level: X-Spam-Status: No, score=-102.491 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCk-SK5kb7lF for ; Tue, 29 Mar 2011 01:55:38 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 79FD43A683C for ; Tue, 29 Mar 2011 01:55:34 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4Ugr-0003pH-45 for radiusext-data0@psg.com; Tue, 29 Mar 2011 08:54:17 +0000 Received: from blu0-omc1-s25.blu0.hotmail.com ([65.55.116.36]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4Ugn-0003p6-UG for radiusext@ops.ietf.org; Tue, 29 Mar 2011 08:54:14 +0000 Received: from BLU152-W60 ([65.55.116.8]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 29 Mar 2011 01:54:09 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_eaa479c1-57f6-4514-85a0-a01551b166f1_" X-Originating-IP: [130.129.18.21] From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: IETF 80 RADEXT Agenda - Final Date: Tue, 29 Mar 2011 01:54:08 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2011 08:54:09.0415 (UTC) FILETIME=[DE15A170:01CBEDEE] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: --_eaa479c1-57f6-4514-85a0-a01551b166f1_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RADEXT WG IETF 80 Agenda Chairs: Bernard Aboba RADEXT WG IETF 80 Agenda

Chairs:
Bernard Aboba <=3Bbernard_abob= a at hotmail.com
Mauricio Sanchez <=3Bmauricio.sanchez at hp.com
Jabber room: radext at jabber.ietf.org (Please join)

Wednesday=2C = March 30=2C 2011
0900 - 1130
Karlin II and III

09:00 - 09:20= =2C Preliminaries (20 minutes)

Audio/Video &=3B Remote Presentati= on Debugging
Note Well
Note Takers
Jabber scribe
Agenda bashDocument Status

IPv6 Items (45 minutes)

9:20 - 9:35 AM RADIU= S Attributes for IPv6 Access Networks (15 minutes)
http://tools.ietf.org= /html/draft-ietf-radext-ipv6-access

9:35 AM - 9:50 AM RADIUS Attribu= tes for Dual Stack Access=2C L. Yeh (15 minutes)
http://tools.ietf.org/h= tml/draft-yeh-radext-dual-stack-access

9:50 AM - 10:05 AM RADIUS Att= ributes for 6rd=2C Sheng Jiang (15 minutes)
http://tools.ietf.org/html/d= raft-ietf-softwire-6rd-radius-attrib

Security Work Items (60 minutes= )

10:05 - 10:25 AM Crypto-Agility Requirements for RADIUS (20 minute= s)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requireme= nts

10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winter (10 minutes= )
http://tools.ietf.org/html/draft-ietf-radext-radsec

10:35 AM - = 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)
http://too= ls.ietf.org/html/draft-ietf-radext-dynamic-discovery

10:45 AM - 10:5= 5 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/h= tml/draft-ietf-radext-dtls

10:55 - 11:05 AM RADIUS Protocol Extensio= ns=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-rade= xt-radius-extensions

Discussion and Wrap-up (25 minutes)

11:0= 5 =96 11:20 AM Discussion (15 minutes)
11:20 - 11:30 AM Next Steps: WG C= hairs &=3B ADs (10 minutes) = --_eaa479c1-57f6-4514-85a0-a01551b166f1_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Tue Mar 29 06:06:40 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D5993A687C for ; Tue, 29 Mar 2011 06:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXISAoyFn67z for ; Tue, 29 Mar 2011 06:06:39 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 62E143A67C3 for ; Tue, 29 Mar 2011 06:06:39 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4Yae-000ENi-UW for radiusext-data0@psg.com; Tue, 29 Mar 2011 13:04:08 +0000 Received: from zinfandel.tools.ietf.org ([2001:1890:1112:1::2a]) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4Yab-000EN7-Mu for radiusext@ops.ietf.org; Tue, 29 Mar 2011 13:04:05 +0000 Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.74) (envelope-from ) id 1Q4YaX-0006gB-6T; Tue, 29 Mar 2011 06:04:01 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" X-Trac-Version: 0.11.7 Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: wdec@cisco.com, bernard_aboba@hotmail.com X-Trac-Project: radext Date: Tue, 29 Mar 2011 13:04:01 -0000 Reply-To: radiusext@ops.ietf.org X-URL: http://tools.ietf.org/radext/ Subject: Re: [radext] #61: DNS attribute for IPv4? X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/radext/trac/ticket/61#comment:4 Message-ID: <075.c4bc4feb43cc5f93e7a89fa77236f4ec@trac.tools.ietf.org> References: <066.cc2411f6b119d81f73eec60b018d6670@trac.tools.ietf.org> X-Trac-Ticket-ID: 61 In-Reply-To: <066.cc2411f6b119d81f73eec60b018d6670@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: wdec@cisco.com, bernard_aboba@hotmail.com, radiusext@ops.ietf.org X-SA-Exim-Mail-From: trac+radext@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: #61: DNS attribute for IPv4? Comment(by wdec@…): Agreed, with some minor wordsmithing perhaps I'll add the proposed text. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Mar 30 10:26:21 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D928F3A6BA3 for ; Wed, 30 Mar 2011 10:26: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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqbxNzYmHD5a for ; Wed, 30 Mar 2011 10:26:12 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id BDD9B3A6AA0 for ; Wed, 30 Mar 2011 10:26:11 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4z8L-000CT6-99 for radiusext-data0@psg.com; Wed, 30 Mar 2011 17:24:41 +0000 Received: from legolas.restena.lu ([158.64.1.34]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4z8I-000CSS-1B for radiusext@ops.ietf.org; Wed, 30 Mar 2011 17:24:38 +0000 Received: from legolas.restena.lu (localhost [127.0.0.1]) by legolas.restena.lu (Postfix) with ESMTP id 84D8D9DD0B for ; Wed, 30 Mar 2011 19:24:35 +0200 (CEST) Received: from [158.64.15.218] (218-15.vpn.restena.lu [158.64.15.218]) by legolas.restena.lu (Postfix) with ESMTPSA id 6765FA98A2 for ; Wed, 30 Mar 2011 19:24:35 +0200 (CEST) Message-ID: <4D9367E4.9040208@restena.lu> Date: Wed, 30 Mar 2011 19:27:00 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "radiusext@ops.ietf.org" Subject: Accounting for subsets of total traffic X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi, this is what I had in mind today: 245.1 Accounting-Traffic-Group TLV 245.1.1 Accounting-Group-Id ENUM 1 = IPv4 2 = IPv6 245.1.2 Accounting-Group-Name STRING 245.1.3 Acct-Input-Octets 64-Bit-Counter 245.1.4 Acct-Output-Octets 64-Bit-Counter 245.1.5 Acct-Input-Packets 64-Bit-Counter 245.1.6 Acct-Output-Packets 64-Bit-Counter Example Accounting-Traffic-Group Accounting-Group-Id = IPv6 Acct-Input-Octets = 4500 Acct-Output-Octets = 1200 Acct-Input-Packets = 30 Acct-Output-Octets = 10 Accounting-Traffic-Group Accounting-Group-Name = "Traffic on TCP/80 to Google, all IP versions" Acct-Input-Octets = 450 Acct-Output-Octets = 120 Acct-Input-Packets = 3 Acct-Output-Octets = 1 The group is to contain *either* -Id (enums assigned by IETF process) *or* -Name with some string if you want to express some very specialised (read: weird) statistics to report about (and they don't have to bug IETF to get a value). There can be multiple groups in one acct packet (especially IPv4, IPv6 are probably handy). There shouldn't be a requirement that the sum is the total bytes/packets in the session; and that means the "original" Acct-(Input/Output)-(Packets/Bytes) still remain in the accounting packet to report the grand total. I used 245 because the total length can grow beyond 252 - the string can be potentially large. I am aware that I used 64-Bit Counters even though that datatype doesn't exist. That's because -Gigawords is a terrible hack around the 32-Bit limitation of integers; I think it might be about time to change that. If this thinking is in an acceptable general direction, I'm happy to put it into a draft as soon as I'm back home with a shell access to xml2rfc. Greetings, Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Wed Mar 30 10:43:20 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E11B3A6BA9 for ; Wed, 30 Mar 2011 10:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NreyQoRUos20 for ; Wed, 30 Mar 2011 10:43:19 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 0823C3A6BA7 for ; Wed, 30 Mar 2011 10:43:19 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4zON-000DOZ-7m for radiusext-data0@psg.com; Wed, 30 Mar 2011 17:41:15 +0000 Received: from liberty.deployingradius.com ([88.191.76.128]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q4zOJ-000DOF-UR for radiusext@ops.ietf.org; Wed, 30 Mar 2011 17:41:12 +0000 Message-ID: <4D936B33.60200@deployingradius.com> Date: Wed, 30 Mar 2011 19:41:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter CC: "radiusext@ops.ietf.org" Subject: Re: Accounting for subsets of total traffic References: <4D9367E4.9040208@restena.lu> In-Reply-To: <4D9367E4.9040208@restena.lu> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Stefan Winter wrote: > I am aware that I used 64-Bit Counters even though that datatype doesn't > exist. That's because -Gigawords is a terrible hack around the 32-Bit > limitation of integers; I think it might be about time to change that. If there's an expression interest on the list, it might as well be added to the extended attrs draft. > If this thinking is in an acceptable general direction, I'm happy to put > it into a draft as soon as I'm back home with a shell access to xml2rfc. It looks interesting. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 31 03:10:48 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901C03A69B9 for ; Thu, 31 Mar 2011 03:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqDgH9tuAiou for ; Thu, 31 Mar 2011 03:10:44 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 7FB383A6919 for ; Thu, 31 Mar 2011 03:10:43 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5EoN-0006W8-6s for radiusext-data0@psg.com; Thu, 31 Mar 2011 10:09:07 +0000 Received: from smtprelay.restena.lu ([2001:a18:1::62]) by psg.com with esmtp (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5EoK-0006Vn-G2 for radiusext@ops.ietf.org; Thu, 31 Mar 2011 10:09:04 +0000 Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 307DE109FC for ; Thu, 31 Mar 2011 12:09:01 +0200 (CEST) Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1A4E3107B5 for ; Thu, 31 Mar 2011 12:09:01 +0200 (CEST) Message-ID: <4D9452B8.6060409@restena.lu> Date: Thu, 31 Mar 2011 12:08:56 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "radiusext@ops.ietf.org" Subject: Notification: draft-winter-radext-fancyaccounting-00 X-Enigmail-Version: 1.1.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9AE9B3DDF8AFDC7A817372F2" X-Virus-Scanned: ClamAV Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9AE9B3DDF8AFDC7A817372F2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, as discussed, I've written up the idea about fancy accounting in an I-D. URL: https://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting/ Please comment if you find the time - especially those people who need the IPv6 accounting! idnits told me that the Intended Status can't possibly be Standards-track - RADIUS Accounting itself is only informational :-/ Greetings, Stefan Winter -------- Original-Nachricht -------- Betreff: New Version Notification for draft-winter-radext-fancyaccounting-00 Datum: Thu, 31 Mar 2011 03:02:44 -0700 (PDT) Von: IETF I-D Submission Tool An: stefan.winter@restena.lu A new version of I-D, draft-winter-radext-fancyaccounting-00.txt has been= successfully submitted by Stefan Winter and posted to the IETF repositor= y. Filename: draft-winter-radext-fancyaccounting Revision: 00 Title: RADIUS Accounting for traffic classes Creation_date: 2011-03-31 WG ID: Independent Submission Number_of_pages: 7 Abstract: This document specifies new attributes for RADIUS Accounting to enable NAS reporting of subsets of the total traffic in a user session. = =20 The IETF Secretariat. --------------enig9AE9B3DDF8AFDC7A817372F2 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.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2UUr0ACgkQ+jm90f8eFWaOUQCeIDA/ngQCwK/jiBPUkXWS3prl 44gAnj8SY3IXpAEG8/u7mSTGe2hZyo5Y =6Bz+ -----END PGP SIGNATURE----- --------------enig9AE9B3DDF8AFDC7A817372F2-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: From owner-radiusext@ops.ietf.org Thu Mar 31 16:03:43 2011 Return-Path: X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 426DC28C110 for ; Thu, 31 Mar 2011 16:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.901 X-Spam-Level: X-Spam-Status: No, score=-0.901 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FEy13dqq+fR for ; Thu, 31 Mar 2011 16:03:41 -0700 (PDT) Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 80CB328B797 for ; Thu, 31 Mar 2011 16:03:41 -0700 (PDT) Received: from majordom by psg.com with local (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5Qsz-000E4x-8M for radiusext-data0@psg.com; Thu, 31 Mar 2011 23:02:41 +0000 Received: from exchht01-ext.internode.com.au ([203.26.95.185] helo=imail.internode.com.au) by psg.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1Q5Qsw-000E4e-IY for radiusext@ops.ietf.org; Thu, 31 Mar 2011 23:02:38 +0000 Received: from [192.168.99.15] (192.168.99.15) by EXCHHT01.staff.internode.com.au (172.17.2.4) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 1 Apr 2011 09:32:34 +1030 Message-ID: <4D95080A.2090004@internode.com.au> Date: Fri, 1 Apr 2011 09:32:34 +1030 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alan DeKok CC: Stefan Winter , "radiusext@ops.ietf.org" Subject: Re: Accounting for subsets of total traffic References: <4D9367E4.9040208@restena.lu> <4D936B33.60200@deployingradius.com> In-Reply-To: <4D936B33.60200@deployingradius.com> Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.99.15] Sender: owner-radiusext@ops.ietf.org Precedence: bulk List-ID: Hi, On 31/03/2011 4:11 AM, Alan DeKok wrote: > Stefan Winter wrote: >> I am aware that I used 64-Bit Counters even though that datatype doesn't >> exist. That's because -Gigawords is a terrible hack around the 32-Bit >> limitation of integers; I think it might be about time to change that. > > If there's an expression interest on the list, it might as well be > added to the extended attrs draft. > I think there would be a very useful benefit in 64 bit data types. I've recently been having to spend quite a bit of time performing a variety of 4.2Gig uploads/downloads just to verify correct gigawords handling in new RADIUS accounting code. 64 bit counters would mean one less thing to handle in accounting code, and one less thing to have to worry about testing. >> If this thinking is in an acceptable general direction, I'm happy to put >> it into a draft as soon as I'm back home with a shell access to xml2rfc. > > It looks interesting. > > Alan DeKok. > Regards, Mark. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 31 Mar 2011 23:03:41 +0000 Message-ID: <4D95080A.2090004@internode.com.au> Date: Fri, 1 Apr 2011 09:32:34 +1030 From: Mark Smith User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Alan DeKok CC: Stefan Winter , "radiusext@ops.ietf.org" Subject: Re: Accounting for subsets of total traffic Content-Type: text/plain; charset="ISO-8859-15"; format=flowed Content-Transfer-Encoding: 7bit Hi, On 31/03/2011 4:11 AM, Alan DeKok wrote: > Stefan Winter wrote: >> I am aware that I used 64-Bit Counters even though that datatype doesn't >> exist. That's because -Gigawords is a terrible hack around the 32-Bit >> limitation of integers; I think it might be about time to change that. > > If there's an expression interest on the list, it might as well be > added to the extended attrs draft. > I think there would be a very useful benefit in 64 bit data types. I've recently been having to spend quite a bit of time performing a variety of 4.2Gig uploads/downloads just to verify correct gigawords handling in new RADIUS accounting code. 64 bit counters would mean one less thing to handle in accounting code, and one less thing to have to worry about testing. >> If this thinking is in an acceptable general direction, I'm happy to put >> it into a draft as soon as I'm back home with a shell access to xml2rfc. > > It looks interesting. > > Alan DeKok. > Regards, Mark. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 31 Mar 2011 10:10:02 +0000 Message-ID: <4D9452B8.6060409@restena.lu> Date: Thu, 31 Mar 2011 12:08:56 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "radiusext@ops.ietf.org" Subject: Notification: draft-winter-radext-fancyaccounting-00 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9AE9B3DDF8AFDC7A817372F2" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9AE9B3DDF8AFDC7A817372F2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, as discussed, I've written up the idea about fancy accounting in an I-D. URL: https://datatracker.ietf.org/doc/draft-winter-radext-fancyaccounting/ Please comment if you find the time - especially those people who need the IPv6 accounting! idnits told me that the Intended Status can't possibly be Standards-track - RADIUS Accounting itself is only informational :-/ Greetings, Stefan Winter -------- Original-Nachricht -------- Betreff: New Version Notification for draft-winter-radext-fancyaccounting-00 Datum: Thu, 31 Mar 2011 03:02:44 -0700 (PDT) Von: IETF I-D Submission Tool An: stefan.winter@restena.lu A new version of I-D, draft-winter-radext-fancyaccounting-00.txt has been= successfully submitted by Stefan Winter and posted to the IETF repositor= y. Filename: draft-winter-radext-fancyaccounting Revision: 00 Title: RADIUS Accounting for traffic classes Creation_date: 2011-03-31 WG ID: Independent Submission Number_of_pages: 7 Abstract: This document specifies new attributes for RADIUS Accounting to enable NAS reporting of subsets of the total traffic in a user session. = =20 The IETF Secretariat. --------------enig9AE9B3DDF8AFDC7A817372F2 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.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2UUr0ACgkQ+jm90f8eFWaOUQCeIDA/ngQCwK/jiBPUkXWS3prl 44gAnj8SY3IXpAEG8/u7mSTGe2hZyo5Y =6Bz+ -----END PGP SIGNATURE----- --------------enig9AE9B3DDF8AFDC7A817372F2-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 30 Mar 2011 17:41:36 +0000 Message-ID: <4D936B33.60200@deployingradius.com> Date: Wed, 30 Mar 2011 19:41:07 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter CC: "radiusext@ops.ietf.org" Subject: Re: Accounting for subsets of total traffic Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Stefan Winter wrote: > I am aware that I used 64-Bit Counters even though that datatype doesn't > exist. That's because -Gigawords is a terrible hack around the 32-Bit > limitation of integers; I think it might be about time to change that. If there's an expression interest on the list, it might as well be added to the extended attrs draft. > If this thinking is in an acceptable general direction, I'm happy to put > it into a draft as soon as I'm back home with a shell access to xml2rfc. It looks interesting. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 30 Mar 2011 17:25:43 +0000 Message-ID: <4D9367E4.9040208@restena.lu> Date: Wed, 30 Mar 2011 19:27:00 +0200 From: Stefan Winter User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; de; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: "radiusext@ops.ietf.org" Subject: Accounting for subsets of total traffic Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Hi, this is what I had in mind today: 245.1 Accounting-Traffic-Group TLV 245.1.1 Accounting-Group-Id ENUM 1 = IPv4 2 = IPv6 245.1.2 Accounting-Group-Name STRING 245.1.3 Acct-Input-Octets 64-Bit-Counter 245.1.4 Acct-Output-Octets 64-Bit-Counter 245.1.5 Acct-Input-Packets 64-Bit-Counter 245.1.6 Acct-Output-Packets 64-Bit-Counter Example Accounting-Traffic-Group Accounting-Group-Id = IPv6 Acct-Input-Octets = 4500 Acct-Output-Octets = 1200 Acct-Input-Packets = 30 Acct-Output-Octets = 10 Accounting-Traffic-Group Accounting-Group-Name = "Traffic on TCP/80 to Google, all IP versions" Acct-Input-Octets = 450 Acct-Output-Octets = 120 Acct-Input-Packets = 3 Acct-Output-Octets = 1 The group is to contain *either* -Id (enums assigned by IETF process) *or* -Name with some string if you want to express some very specialised (read: weird) statistics to report about (and they don't have to bug IETF to get a value). There can be multiple groups in one acct packet (especially IPv4, IPv6 are probably handy). There shouldn't be a requirement that the sum is the total bytes/packets in the session; and that means the "original" Acct-(Input/Output)-(Packets/Bytes) still remain in the accounting packet to report the grand total. I used 245 because the total length can grow beyond 252 - the string can be potentially large. I am aware that I used 64-Bit Counters even though that datatype doesn't exist. That's because -Gigawords is a terrible hack around the 32-Bit limitation of integers; I think it might be about time to change that. If this thinking is in an acceptable general direction, I'm happy to put it into a draft as soon as I'm back home with a shell access to xml2rfc. Greetings, Stefan Winter -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 29 Mar 2011 13:05:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Tue, 29 Mar 2011 13:04:01 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #61: DNS attribute for IPv4? Message-ID: <075.c4bc4feb43cc5f93e7a89fa77236f4ec@trac.tools.ietf.org> #61: DNS attribute for IPv4? Comment(by wdec@…): Agreed, with some minor wordsmithing perhaps I'll add the proposed text. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 29 Mar 2011 08:55:11 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_eaa479c1-57f6-4514-85a0-a01551b166f1_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: IETF 80 RADEXT Agenda - Final Date: Tue, 29 Mar 2011 01:54:08 -0700 MIME-Version: 1.0 --_eaa479c1-57f6-4514-85a0-a01551b166f1_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RADEXT WG IETF 80 Agenda Chairs: Bernard Aboba RADEXT WG IETF 80 Agenda

Chairs:
Bernard Aboba <=3Bbernard_abob= a at hotmail.com
Mauricio Sanchez <=3Bmauricio.sanchez at hp.com
Jabber room: radext at jabber.ietf.org (Please join)

Wednesday=2C = March 30=2C 2011
0900 - 1130
Karlin II and III

09:00 - 09:20= =2C Preliminaries (20 minutes)

Audio/Video &=3B Remote Presentati= on Debugging
Note Well
Note Takers
Jabber scribe
Agenda bashDocument Status

IPv6 Items (45 minutes)

9:20 - 9:35 AM RADIU= S Attributes for IPv6 Access Networks (15 minutes)
http://tools.ietf.org= /html/draft-ietf-radext-ipv6-access

9:35 AM - 9:50 AM RADIUS Attribu= tes for Dual Stack Access=2C L. Yeh (15 minutes)
http://tools.ietf.org/h= tml/draft-yeh-radext-dual-stack-access

9:50 AM - 10:05 AM RADIUS Att= ributes for 6rd=2C Sheng Jiang (15 minutes)
http://tools.ietf.org/html/d= raft-ietf-softwire-6rd-radius-attrib

Security Work Items (60 minutes= )

10:05 - 10:25 AM Crypto-Agility Requirements for RADIUS (20 minute= s)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requireme= nts

10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winter (10 minutes= )
http://tools.ietf.org/html/draft-ietf-radext-radsec

10:35 AM - = 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)
http://too= ls.ietf.org/html/draft-ietf-radext-dynamic-discovery

10:45 AM - 10:5= 5 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://tools.ietf.org/h= tml/draft-ietf-radext-dtls

10:55 - 11:05 AM RADIUS Protocol Extensio= ns=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/draft-ietf-rade= xt-radius-extensions

Discussion and Wrap-up (25 minutes)

11:0= 5 =96 11:20 AM Discussion (15 minutes)
11:20 - 11:30 AM Next Steps: WG C= hairs &=3B ADs (10 minutes) = --_eaa479c1-57f6-4514-85a0-a01551b166f1_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 28 Mar 2011 16:04:44 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 28 Mar 2011 16:03:35 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #71: Section 2.3 and 3.3 Message-ID: <075.204a3c8c6b6ef713c01869efa5de2d14@trac.tools.ietf.org> #71: Section 2.3 and 3.3 Comment(by wdec@…): Well, but it seems that there is a key distintiction between the routes that are advertised *to* the client by the NAS as being reachable via the NAS vs those that are installed to point to the client. Using one attribute, eg Framed-IPv6-Route, for both appears to be more than an implementation question. It's about the intended semantics IMO. How about this as new text? An IPv6 Route Information option, defined in [RFC4191] is intended to be used to inform a host connected to the NAS that a specific route is reachable via the NAS. This is particularly desirable in cases where the RG or host are multi-homed to different NASes as shown in Figure 1. This document specifies the RADIUS attribute that allows the AAA system to provision the announcement by the NAS to an accessing host. The NAS may advertise this route using the method defined in [RFC4191] or using other equivalent methods. The distinction and separation between this attribute and the Framed- IPv6-Route attribute defined in [RFC3633] is needed due to the need to have the information carried by this attribute advertised to an attaching client. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 26 Mar 2011 06:30:24 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_d196902c-a730-478d-8b74-b80b2aafac21_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Question to implementers of Framed-IPv6-Route Date: Fri, 25 Mar 2011 23:30:03 -0700 MIME-Version: 1.0 --_d196902c-a730-478d-8b74-b80b2aafac21_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The question has arisen as to what NAS implementers of Framed-IPv6-Route do= with the attribute.=20 The attribute (defined in RFC 3162) is defined using language similar to th= at of Framed-Route in RFC 2865=2C so one might assume a similar use. However=2C RFC 3162 did not= define a Framed-IPv6-Routing attribute to parallel the Framed-Routing attribute defined in RFC 2865=2C s= o that it is possible that implementers did not use Framed-Ipv6-Route in a similar way to the Framed-R= oute/Framed-Routing attributes defined in RFC 2865.=20 If you have implemented Framed-Ipv6-Route on a NAS=2C please tell us what y= ou do with the information: 1. Do you announce the routes via RA? 2. Do you look at Framed-Routing to determine if the routes are redistribut= ed into an IGP? = --_d196902c-a730-478d-8b74-b80b2aafac21_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The question has arisen as to what NAS implementers of Framed-IPv6-Route do= with the attribute.

The attribute (defined in RFC 3162) is defined= using language similar to that of Framed-Route in
RFC 2865=2C so one mi= ght assume a similar use. =3B However=2C RFC 3162 did not define a Fram= ed-IPv6-Routing
attribute to parallel the Framed-Routing attribute defin= ed in RFC 2865=2C so that it is possible that
implementers did not use F= ramed-Ipv6-Route in a similar way to the Framed-Route/Framed-Routing
att= ributes defined in RFC 2865.

If you have implemented Framed-Ipv6-Ro= ute on a NAS=2C please tell us what you do with the information:

1. = Do you announce the routes via RA?
2. Do you look at Framed-Routing to d= etermine if the routes are redistributed into an IGP?
= --_d196902c-a730-478d-8b74-b80b2aafac21_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 26 Mar 2011 06:23:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Sat, 26 Mar 2011 06:23:25 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #71: Section 2.3 and 3.3 Message-ID: <075.9bd488c0f66fb10c88f3ff612e054d22@trac.tools.ietf.org> #71: Section 2.3 and 3.3 Comment(by bernard_aboba@…): It seems to me that we want to enable use of routes in advertisements as well as in routing protocols, and possibly both at once. RFC 3162 defines Framed-IPv6-Route, and the intent there was to enable inclusion in router advertisements, as well as potential redistribution in IGPs, depending on the value of Framed-Routing. The question is how it was implemented. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 26 Mar 2011 06:13:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Sat, 26 Mar 2011 06:12:07 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #69: Section 1 Message-ID: <075.4226a94b879e162027dd17b7c0f4e5c0@trac.tools.ietf.org> #69: Section 1 Comment(by bernard_aboba@…): The RFC 3162 text on Framed-IPv6-Route is included below. The text is analagous to that used to define Framed-Route in RFC 2865, Section 5.22. Note that RFC 2865 also defines Framed-Routing (Section 5.10), which determines how or if an IGP is used. If Framed-Routing = None or Listen, then I wouldn't expect routes to be redistributed into an IGP. The question is what existing implementations do with Framed-IPv6-Route and whether this is influenced by the value of Framed-Routing. 2.5. Framed-IPv6-Route Description This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times. A summary of the Framed-IPv6-Route Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 99 for Framed-IPv6-Route Length >=3 Text The Text field is one or more octets, and its contents are implementation dependent. The field is not NUL (hex 00) terminated. It is intended to be human readable and MUST NOT affect operation of the protocol. For IPv6 routes, it SHOULD contain a destination prefix optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address, a space, and one or more metrics (encoded in decimal) separated by spaces. Prefixes and addresses are formatted as described in [16]. For example, "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". Whenever the gateway address is the IPv6 unspecified address the IP address of the user SHOULD be used as the gateway address. The unspecified address can be expressed in any of the acceptable formats described in [16]. For example, "2000:0:0:106::/64 :: 1". -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 25 Mar 2011 00:39:06 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_9ac3b4a7-ceec-46a7-a851-85a7455545b2_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Presentations Date: Thu, 24 Mar 2011 17:37:32 -0700 MIME-Version: 1.0 --_9ac3b4a7-ceec-46a7-a851-85a7455545b2_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you are presenting at IETF 80=2C please get your slides in ASAP. Agend= a is given below.=20 =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 RADEXT WG IETF 80 Agenda Chairs: Bernard Aboba If you are presenting at IETF 80=2C please get your slides in ASAP. =3B=  =3B Agenda is given below.

=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
RADEXT WG IETF 80 Agenda

Chairs:
Bernard Ab= oba <=3Bbernard_aboba at hotmail.com
Mauricio Sanchez <=3Bmauricio.s= anchez at hp.com

Jabber room: radext at jabber.ietf.org (Please join= )

Wednesday=2C March 30=2C 2011
0900 - 1130
Karlin II and III<= br>
09:00 - 09:20=2C Preliminaries (20 minutes)

Audio/Video &= =3B Remote Presentation Debugging
Note Well
Note Takers
Jabber scr= ibe
Agenda bash
Document Status

IPv6 Items (45 minutes)
9:20 - 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)
= http://tools.ietf.org/html/draft-ietf-radext-ipv6-access

9:35 AM - 9= :50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (15 minutes)
ht= tp://tools.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM = - 10:05 AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)
http://= tools.ietf.org/html/draft-ietf-softwire-6rd-radius-attrib

Security W= ork Items (60 minutes)

10:05 - 10:25 AM Crypto-Agility Requirements = for RADIUS (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-cry= pto-agility-requirements

10:25 AM - 10:35 AM RADIUS over TLS=2C Stef= an Winter (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-rads= ec

10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 m= inutes)
http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery
10:45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
ht= tp://tools.ietf.org/html/draft-ietf-radext-dtls

10:55 - 11:05 AM RAD= IUS Protocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org= /html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (25= minutes)
= --_9ac3b4a7-ceec-46a7-a851-85a7455545b2_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 19 Mar 2011 07:09:16 +0000 Message-ID: <4D845660.6050502@deployingradius.com> Date: Sat, 19 Mar 2011 08:08:16 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba CC: radiusext@ops.ietf.org, iana-questions@iana.org Subject: Re: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not called out as an exception, only Service-Type. > If the intent was to exempt RFC 2868, those attributes would have been included as exceptions but they are not. > > Therefore, it looks to me like the omission of RFC 2868 in the Updates: header is an errata. I agree. IIRC, there are a number of other inconsistencies in the IANA registry. I ran into that a while ago when doing some research, but never made a specific note of the problem. I'll see if I can track that down. Alan DeKok. -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 18 Mar 2011 23:33:40 +0000 Message-ID: From: Bernard Aboba To: CC: Subject: RE: [IANA #278793] Registration of RADIUS Attribute Values and RFC 3575 Date: Fri, 18 Mar 2011 16:32:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thread-Index: AQIez56AUaxI2URk3tiewLiApVCSbQIrFVhsAppot3OTZ7xa8A== Content-Language: en-us RFC 3575 Section 2.1 states the following: Certain attributes (for example, NAS-Port-Type) in RADIUS define a list of values to correspond with various meanings. There can be 4 billion (2^32) values for each attribute. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC. Note that the Tunnel-Type and Tunnel-Medium-Type attributes are not = called out as an exception, only Service-Type.=20 If the intent was to exempt RFC 2868, those attributes would have been = included as exceptions but they are not.=20 Therefore, it looks to me like the omission of RFC 2868 in the Updates: = header is an errata. =20 What do other WG participants think? -----Original Message----- From: Amanda Baber via RT [mailto:iana-questions@iana.org]=20 Sent: Friday, March 18, 2011 2:59 PM To: bernard_aboba@hotmail.com Subject: [IANA #278793] Registration of RADIUS Attribute Values and RFC = 3575=20 Hi, I'm afraid I lost track of this message about fixing IANA's descriptions = of RADIUS registration procedures.=20 Given RFC 3575, all of the RADIUS attribute values but 6 (Service-Type), 64 (Tunnel-Type), and 65 (Tunnel-Medium-Type) are now listed as Expert = Review registries. Those remaining three are listed as IETF Consensus. Please see http://www.iana.org/assignments/radius-types The issue with Tunnel-Type and Tunnel-Medium-Type, which has come up = before, is that RFC2868 specifically calls them IETF Consensus = registries, and RFC3575 doesn't update RFC2868. Is this reading correct, = or does RFC3575 supersede 2868 anyway? Since we're not sure what to do about Tunnel-Type and = Tunnel-Medium-Type, the directory at http://www.iana.org/protocols/ = currently says, "Registration procedure varies by attribute." Do we need to make any changes? thanks, Amanda On Tue Nov 10 01:45:42 2009, bernard_aboba@hotmail.com wrote: > Recently on the RADEXT WG mailing list, an issue has been raised about = > the IANA allocation procedures for RADIUS attribute values: >=20 > http://ops.ietf.org/lists/radiusext/2009/msg00625.html >=20 > =20 >=20 > As noted in RFC 3575, Section 2.1: >=20 > =20 >=20 > Certain attributes (for example, NAS-Port-Type) in RADIUS define a >=20 > list of values to correspond with various meanings. There can be 4 >=20 > billion (2^32) values for each attribute. Additional values can be >=20 > allocated by the Designated Expert. The exception to this policy=20 > is >=20 > the Service-Type attribute (6), whose values define new modes of >=20 > operation for RADIUS. Values 1-16 of the Service-Type attribute=20 > have >=20 > been allocated. Allocation of new Service-Type values are by IETF >=20 > Consensus. The intention is that any allocation will be=20 > accompanied >=20 > by a published RFC. >=20 > =20 >=20 > Given the above text, it is my understanding that according to RFC=20 > 3575, additional values for RADIUS attributes (with the exception of=20 > the Service-Type attribute (6)) are to be allocated by Designated = Expert. >=20 > =20 >=20 > However, within the IANA RADIUS registry=20 > (http://www.iana.org/protocols/) RADIUS attribute values are listed as = requiring Standards Action. >=20 > =20 >=20 > We have already had one instance in which the insistence on Standards Action > has resulted in a large delay in value allocation with the resulting use of > Vendor-Specific Values as described in RFC 2822. Given that RFC 3575=20 > specifically indicates that standards action is not required for allocation > of values for any RADIUS attribute other than Service-Type, there is=20 > not much room for interpretation here and I would like to make sure=20 > that this problem is corrected as soon as possible. >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 > =20 >=20 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 15 Mar 2011 17:40:44 +0000 From: Avi Lior To: "bernard_aboba@hotmail.com" CC: "radiusext@ops.ietf.org" , Alper Yegin Date: Tue, 15 Mar 2011 13:39:35 -0400 Subject: [IANA #409959] Genreral Request for Assignements Thread-Topic: [IANA #409959] Genreral Request for Assignements Thread-Index: AcvjN/PfETWqJsnhRbCJ3Q5584NJVA== Message-ID: Accept-Language: en-US Content-Language: en-US user-agent: Microsoft-MacOutlook/14.2.0.101115 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C9A51C9711D20avibridgewatersystemscom_" MIME-Version: 1.0 --_000_C9A51C9711D20avibridgewatersystemscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Bernard, Thank you for the review of the NAS-Port-Type IANA request for assignment. = In a previous email you were seeking answers to the following questions: Bernard wrote: Can someone answer the following questions? 1. What is different between WiMAX WiFi and normal IEEE 802.11? We already= have a number of IEEE 802.11 NAS-Port-types allocated and have proposed ad= ditional data for this. 2. Why do DHCP and a location service need NAS-Port-Type values? 3. Why should we just allocate a generic WiMAX NAS-Port and let additional = data be included in a WiMAX Forum VSA? The general answer to your question is as follows: For a given session, the WIMAX AAA Server interacts with many different WiM= AX network elements and also non-WiMAX network elements. The approach take= n by WiMAX is to have an explicit indication from the NAS as to the context= of the RADIUS access-request. The NAS-Port-Type is viewed as the attribut= e to provide that information. WRT 1) the WiMAX AAA needs to be able to differentiate between a normal WiF= i Access and a WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additio= nal behaviours over and above the "normal" wifi AP. T WRT 2) Again, WiMAX AAA needs to differentiate between the request from bot= h these entities because the AAA behaviour is different when request comes = from a DHCP server vs., a Location Based Server. WRT 3) WiMAX would just be inventing our own NAS-Port-Type attribute. We = thought the idea is that we reuse attributes when we can. Since there doesn= 't seem to be a lack of number space associated with NAS-Port-Type there do= esn't seem to be a reason to invent our own attribute. -- Avi Lior --Bridgewater Systems --_000_C9A51C9711D20avibridgewatersystemscom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 Hi Berna= rd,

Thank you for the review of the NAS-Port-Type = IANA request for assignment.  In a previous email you were seeking ans= wers to the following questions:

Bernard wrote:

Can someone answer the following questions?

1. What is diff= erent between WiMAX WiFi and normal IEEE 802.11?  We already have a nu= mber of IEEE 802.11 NAS-Port-types allocated and have proposed additional d= ata for this.

2. Why do DHCP and a location service need NAS-Port-Type values?&nbs= p;

3. W= hy should we just allocate a generic WiMAX NAS-Port and let additional data= be included in a WiMAX Forum VSA?

The general answer to your question is as follows:

For a given session, the WIMAX AAA= Server interacts with many different WiMAX network elements and also non-W= iMAX network elements.  The approach taken by WiMAX is to have an expl= icit indication from the NAS as to the context of the RADIUS access-request= .  The NAS-Port-Type is viewed as the attribute to provide that inform= ation.

= WRT 1) the WiMA= X AAA needs to be able to differentiate between a normal WiFi Access and a = WiMAX NAS which is an a WiFI-WiMAX IWK NAS which has additional behaviours = over and above the "normal" wifi AP.  T


WRT 2) Again, WiMAX AAA needs to differentiate between the request = from both these entities because the AAA behaviour is different when reques= t comes from  a DHCP server vs., a Location Based Server.

WRT 3)  WiMAX would just be i= nventing our own NAS-Port-Type attribute.  We thought the idea is that= we reuse attributes when we can. Since there doesn't seem to be a lack of = number space associated with NAS-Port-Type there doesn't seem to be a reaso= n to invent our own attribute.


-- Avi Lior
--Bridgewater Systems

--_000_C9A51C9711D20avibridgewatersystemscom_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 15 Mar 2011 06:09:56 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_439a6b67-6c2a-4271-8933-8640607a6667_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT Agenda for IETF 80 - Take 3 Date: Mon, 14 Mar 2011 23:09:01 -0700 MIME-Version: 1.0 --_439a6b67-6c2a-4271-8933-8640607a6667_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sorry for the confusion relating to the IPv6 presentations. Here is a revi= sed agenda.=20 =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 RADEXT WG IETF 80 Agenda Chairs: Bernard Aboba
Sorry for the confusion relating to the IPv6 presentations. =3B Her= e is a revised agenda.

=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
RADEXT WG IETF 80 Agenda

Chairs:
Bernard Aboba <=3Bberna= rd_aboba at hotmail.com
Mauricio Sanchez <=3Bmauricio.sanchez at hp.co= m

Jabber room: radext at jabber.ietf.org (Please join)

Wednes= day=2C March 30=2C 2011

0900 - 1130

Karlin II and III

= 09:00 - 09:20=2C Preliminaries (20 minutes)

Audio/Video &=3B Remo= te Presentation Debugging
Note Well
Note Takers
Jabber scribe
A= genda bash
Document Status

IPv6 Items (45 minutes)

9:20 - = 9:35 AM RADIUS Attributes for IPv6 Access Networks (15 minutes)
http://t= ools.ietf.org/html/draft-ietf-radext-ipv6-access

9:35 AM - 9:50 AM R= ADIUS Attributes for Dual Stack Access=2C L. Yeh (15 minutes)
http://too= ls.ietf.org/html/draft-yeh-radext-dual-stack-access

9:50 AM - 10:05 = AM RADIUS Attributes for 6rd=2C Sheng Jiang (15 minutes)
http://tools.ie= tf.org/html/draft-ietf-softwire-6rd-radius-attrib

Security Work Item= s (60 minutes)

10:05 - 10:25 AM Crypto-Agility Requirements for RADI= US (20 minutes)
http://tools.ietf.org/html/draft-ietf-radext-crypto-agil= ity-requirements

10:25 AM - 10:35 AM RADIUS over TLS=2C Stefan Winte= r (10 minutes)
http://tools.ietf.org/html/draft-ietf-radext-radsec
10:35 AM - 10:45 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes)<= br>http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery

10= :45 AM - 10:55 AM RADIUS over DTLS=2C Alan DeKok (10 minutes)
http://too= ls.ietf.org/html/draft-ietf-radext-dtls

10:55 - 11:05 AM RADIUS Prot= ocol Extensions=2C Alan DeKok (10 minutes)
http://tools.ietf.org/html/dr= aft-ietf-radext-radius-extensions

Discussion and Wrap-up (25 minutes= )

11:05 =96 11:20 AM Discussion (15 minutes)
11:20 - 11:30 AM Nex= t Steps: WG Chairs &=3B ADs (10 minutes)

= --_439a6b67-6c2a-4271-8933-8640607a6667_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Tue, 15 Mar 2011 02:37:37 +0000 Date: Tue, 15 Mar 2011 02:36:32 +0000 From: Jiangsheng Subject: RE: RADEXT WG Agenda for IETF 80 - Take Two To: Bernard Aboba , "radiusext@ops.ietf.org" Message-id: <5D36713D8A4E7348A7E10DF7437A4B927FD43E@SZXEML504-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=Windows-1252 Content-language: en-GB Content-transfer-encoding: quoted-printable Accept-Language: en-GB, zh-CN, en-US Thread-topic: RADEXT WG Agenda for IETF 80 - Take Two Thread-index: AQHL4hgoO9t7qHZW2EO8m89vqaF/25QsezhBgAE0C8E= Dear RADEXT chairs, We did send a request for presentation as early as March 4th. It is an soft= wire WG draft, which is IPv6 relevant. "RADIUS Attribute for 6rd" draft-ietf-softwire-6rd-radius-attrib update for radext WG review. The presentation should be less than 5 mins, 10 mins slot should be enough = including discussion. Thanks and regards, Sheng From: owner-radiusext@ops.ietf.org [owner-radiusext@ops.ietf.org] on behalf= of Bernard Aboba [bernard_aboba@hotmail.com] Sent: 14 March 2011 15:14 To: radiusext@ops.ietf.org Subject: RADEXT WG Agenda for IETF 80 - Take Two RADEXT WG IETF 80 Agenda=20 Chairs: Bernard Aboba Mauricio Sanchez Jabber room: radext at jabber.ietf.org (Please join) Wednesday, March 30, 2011 0900 - 1130 Karlin II and III 09:00 - 09:20, Preliminaries Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 Items (40 minutes) 9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:40 AM - 9:50 AM RADIUS Attributes for Dual Stack Access, L. Yeh (10 minu= tes) http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access 9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite, R. Magliione (10 = minutes) http://tools.ietf.org/html/draft-ietf-softwire-dslite-radius-ext Security Work Items (60 minutes) 10:00 - 10:20 AM Crypto-Agility Requirements for RADIUS (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:20 AM - 10:30 AM RADIUS over TLS, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec 10:30 AM - 10:40 AM Dynamic Peer Discovery, Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery 10:40 AM - 10:50 AM RADIUS over DTLS, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls 10:50 - 11:00 AM RADIUS Protocol Extensions, Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Discussion and Wrap-up (30 minutes) 11:00 =96 11:15 AM Discussion (15 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) = -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 19:17:29 +0000 MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-ipv6-access-04.txt Message-ID: <20110314191502.23501.21922.idtracker@localhost> Date: Mon, 14 Mar 2011 12:15:02 -0700 --NextPart 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 : RADIUS attributes for IPv6 Access Networks Author(s) : B. Lourdelet, et al. Filename : draft-ietf-radext-ipv6-access-04.txt Pages : 13 Date : 2011-03-14 This document specifies additional IPv6 RADIUS attributes useful in residential broadband network deployments. The attributes, which are used for authorization and accounting, enable assignment of a host IPv6 address and IPv6 DNS server address via DHCPv6; assignment of an IPv6 route announced via router advertisement, and assignment of a named IPv6 delegated prefix pool. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-ipv6-access-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-ipv6-access-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14120837.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 18:43:59 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 18:43:43 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #74: Section 3.2 Message-ID: <075.c5489a2ca9b7fce0ac6e53ce4917ec3c@trac.tools.ietf.org> #74: Section 3.2 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Will clarify that order of attributes is supposed to be reflected in the client advertisement. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 18:42:11 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 14 Mar 2011 18:41:57 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #68: Abstract Message-ID: <075.b346fb2494f8e94fe1bccb0a79e89aef@trac.tools.ietf.org> #68: Abstract Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 18:41:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 14 Mar 2011 18:41:07 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #62: Use of "Address" Message-ID: <075.e93d09b625265f5b415b62e02c99c5d3@trac.tools.ietf.org> #62: Use of "Address" Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as suggested. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 18:39:10 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 14 Mar 2011 18:38:44 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #61: DNS attribute for IPv4? Message-ID: <075.27e0e097ed48892f86193ab65f689ce0@trac.tools.ietf.org> #61: DNS attribute for IPv4? Changes (by wdec@…): * status: new => assigned Comment: IETF spec, no, existing implementations however do things like http://freeradius.org/rfc/rfc2548.html#MS-Primary-DNS-Server. Let me know how you'd like to see this represented. We didn't want to provide links to specific implementations, but also not hide from the fact that limited VSAs are being used. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: wdec@… Type: defect | Status: assigned Priority: minor | Milestone: milestone1 Component: ipv6-access | Version: Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 18:26:58 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 18:26:33 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #77: Section 2 Message-ID: <075.84f96fc91b915f57ff87c90e755db255@trac.tools.ietf.org> #77: Section 2 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 18:02:26 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 18:02:12 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #76: Section 6 Message-ID: <075.7a00433cb27caae2c3202b2493bcdee5@trac.tools.ietf.org> #76: Section 6 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 17:59:54 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 17:59:12 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #70: Section 2.1 Message-ID: <075.d88f716e55369008b6468fd116922b4e@trac.tools.ietf.org> #70: Section 2.1 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 16:44:09 +0000 Message-ID: From: Bernard Aboba To: "'radext mailing list'" Subject: Remote Presentation at IETF 80 Date: Mon, 14 Mar 2011 09:44:52 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01CBE22C.782F3830" Thread-Index: AcviZyRIHRMiwu9HSH6/DR9D31Ns6Q== Content-Language: en-us ------=_NextPart_000_0031_01CBE22C.782F3830 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit If you are on the IETF 80 agenda and are interested in presenting remotely, let me know. The IETF has not had good experiences with remote presentation based on PSTN gateways, but newer technologies are available that permit the use of HD audio, so perhaps this will work better. ------=_NextPart_000_0031_01CBE22C.782F3830 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

If you are = on the IETF 80 agenda and are interested in presenting remotely, let me = know.

 

The IETF has not had good experiences with remote = presentation based on PSTN gateways,

but newer technologies are available that permit the = use of HD audio, so perhaps this will work better. =

------=_NextPart_000_0031_01CBE22C.782F3830-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 13:37:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 13:37:18 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #75: Section 3.6 Message-ID: <075.e57d998d951748e2e45de7031dec6532@trac.tools.ietf.org> #75: Section 3.6 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 13:36:39 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com, bernard_aboba@hotmail.com Date: Mon, 14 Mar 2011 13:36:08 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #69: Section 1 Message-ID: <075.c39087ffd2141d3fbd15d81d724c2897@trac.tools.ietf.org> #69: Section 1 Changes (by wdec@…): * status: new => assigned Comment: Agreed with one caveat. I'm not sure that the framed-ipv6-route was intended for use with RIPng. It seems more like being intended to be intended for the NAS to install the specified route towards the client, which then may be redistributed into some IGP. This is different than advertising a route to a client by means of ICMPv6 or DHCPv6. Awaiting a response. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 13:22:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 13:21:46 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #71: Section 2.3 and 3.3 Message-ID: <075.8648bd0627dfacc3c98965724b69794e@trac.tools.ietf.org> #71: Section 2.3 and 3.3 Changes (by wdec@…): * status: new => assigned Comment: New description reads: An IPv6 Route Information option, defined in [RFC4191] is intended to be used to inform a host connected to the NAS that a specific route is reachable via the NAS. This is particularly desirable in cases where the RG or host are multi-homed to different NASes as shown in Figure 1. This document specifies the RADIUS attribute that allows the AAA system to provision the announcement by the NAS of a specific Route Information Option to an accessing host. The NAS may advertise this route using the method defined in [RFC4191] or using other equivalent methods. The distinction and separation between this attribute and the Framed- IPv6-Route attribute defined in [RFC3633] is needed due to the need to have the information carried by this attribute advertised to an attaching client. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: assigned Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 13:00:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 13:00:32 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #72: Section 2.4 Message-ID: <075.e3a1f6d0bc70a6447e20a229f4bc7aee@trac.tools.ietf.org> #72: Section 2.4 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 12:59:04 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: wdec@cisco.com Date: Mon, 14 Mar 2011 12:58:05 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #73: Section 3.1 Message-ID: <075.5959046c724c60b9451f7480c685fed5@trac.tools.ietf.org> #73: Section 3.1 Changes (by wdec@…): * status: new => closed * resolution: => fixed Comment: Resolved as proposed. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: wdec@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: ipv6-access | Version: 1.0 Severity: In WG Last Call | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 08:32:11 +0000 MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-radsec-08.txt Message-ID: <20110314083001.9053.38957.idtracker@localhost> Date: Mon, 14 Mar 2011 01:30:01 -0700 --NextPart 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 : TLS encryption for RADIUS Author(s) : S. Winter, et al. Filename : draft-ietf-radext-radsec-08.txt Pages : 19 Date : 2011-03-14 This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-radsec-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-radsec-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14011505.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 14 Mar 2011 07:15:49 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_c1e356c3-d7e5-4884-9fbb-1c82064e628f_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: RADEXT WG Agenda for IETF 80 - Take Two Date: Mon, 14 Mar 2011 00:14:39 -0700 MIME-Version: 1.0 --_c1e356c3-d7e5-4884-9fbb-1c82064e628f_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RADEXT WG IETF 80 Agenda=20 =20 Chairs: Bernard Aboba Mauricio Sanchez =20 Jabber room: radext at jabber.ietf.org (Please join) =20 Wednesday=2C March 30=2C 2011 =20 0900 - 1130 =20 Karlin II and III =20 09:00 - 09:20=2C Preliminaries =20 Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status IPv6 Items (40 minutes) 9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access 9:40 AM - 9:50 AM RADIUS Attributes for Dual Stack Access=2C L. Yeh (10 mi= nutes)http://tools.ietf.org/html/draft-yeh-radext-dual-stack-access 9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite=2C R. Magliione (1= 0 minutes) http://tools.ietf.org/html/draft-ietf-softwire-dslite-radius-ext Security Work Items (60 minutes) 10:00 - 10:20 AM Crypto-Agility Requirements for RADIUS (20 minutes)http:/= /tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:20 AM - 10:30 AM RADIUS over TLS=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec =20 10:30 AM - 10:40 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery =20 10:40 AM - 10:50 AM RADIUS over DTLS=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls =20 10:50 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Discussion and Wrap-up (30 minutes) =20 11:00 =96 11:15 AM Discussion (15 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) = --_c1e356c3-d7e5-4884-9fbb-1c82064e628f_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

RADEXT WG IETF 80 Agenda

 =3B

Chairs:

Bernard Aboba <=3Bbernard_aboba at hotmail.com>= =3B

Mauricio Sanchez <=3Bmauricio.sanchez at hp.com>= =3B

 =3B

Jabber room: =3B radext at jabber.ietf.org (Plea= se join)

 =3B

Wednesday=2C March 30=2C 2011

 =3B

0900 - 1130

 =3B

Karlin II and III

 =3B

09:00 - 09:20=2C Preliminaries

 =3B

 =3B =3B =3B =3B Debugging

 =3B =3B =3B =3B Note Well

 =3B =3B =3B =3B Note Takers

 =3B =3B =3B =3B Jabber scribe

 =3B =3B =3B =3B Agenda bash

 =3B =3B =3B =3B Document Status

=
IPv6 Items (40 minutes)


9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 min= utes)

http://tools.ietf.org/html/draft-ietf-r= adext-ipv6-access


= 9:40 AM - 9:50 AM =3B RADIUS Attributes for Dual Stack Access=2C L. Yeh= (10 minutes)

http://tools.ietf.org/html/draft-ye= h-radext-dual-stack-access


9:50 AM - 10:00 AM RADIUS Extensions for Dual Stack Lite=2C R. Mag= liione (10 minutes)

http://tools.ietf.org/htm= l/draft-ietf-softwire-dslite-radius-ext


<= /p>

Security Work Items (60 minutes)

 =3B

10:00 - 10:20 AM = Crypto-Agility Requirements for RADIUS (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements=


10:20 AM - 10:30 AM R= ADIUS over TLS=2C Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec<= /p>

 =3B

10:30 AM - 10:40 AM Dynamic Peer Discovery=2C Stefan= Winter (10 minutes)

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

 =3B

10:40 AM - 10:50 AM RADIUS over DTLS=2C Alan DeKok (= 10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls

 =3B

10:50 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (10 minutes)
h= ttp://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (30 minutes)

 =3B

11:00 =96 11:15 AM Discussion (15 minutes)

11:15 - 11:30 =3B AM Next Steps: =3B WG Chairs &=3B ADs (15 minu= tes) = --_c1e356c3-d7e5-4884-9fbb-1c82064e628f_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 13 Mar 2011 13:32:27 +0000 MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-04.txt Message-ID: <20110313133001.19061.33533.idtracker@localhost> Date: Sun, 13 Mar 2011 06:30:01 -0700 --NextPart 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 : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-04.txt Pages : 11 Date : 2011-03-12 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13062046.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 13 Mar 2011 01:40:12 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 13 Mar 2011 01:38:43 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #23: Comments Message-ID: <070.4e1b1ca42d5e31e07a174868bd1fa0ed@trac.tools.ietf.org> #23: Comments Comment(by bernard_aboba@…): It is not clear to me what is meant by "MUST use the existing mechanisms". RADIUS does not include a version field, nor is any negotiation mechanism defined in any of the existing RADIUS RFCs. Recommend that this phrase be deleted. Also, there is a simple workaround to the issue of probing delays: upgrade the responder (e.g. RADIUS server) first, so that a crypto-agile request will always receive a response. The proposed revision to Section 2 is as follows: 2. A Working Definition of Crypto-Agility A generalized definition of crypto-agility was offered up at the RADEXT WG session during IETF-68. Crypto-Agility is the ability of a protocol to adapt to evolving cryptography and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to fielded implementations. It may provide for the dynamic negotiation and installation of cryptographic algorithms within protocol implementations (think of Dynamic-Link Libraries (DLL)). In the specific context of the RADIUS protocol and RADIUS implementations, crypto-agility may be better defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS Attributes. This capability covers all RADIUS message types: Access-Request/Response, Accounting-Request/Response, CoA/Disconnect- Request/Response, and Status-Server. Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be determined a-priori. Proposals MUST NOT introduce new capabilities negotiation features into the RADIUS protocol and crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158] Section 2.3. Acceptable solutions for determining the mechanisms to be used within a request include manual configuration as well as backward compatible negotiation techniques such as those described in Section 4.3. Solutions for determining the mechanisms to be used in a response include manual configuration and "advertise and select" mechanisms (e.g. selection within the response from mechanisms advertised in a request). The proposed revision to Section 4.3 is as follows: 4.3. Backwards Compatibility Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy mechanisms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms as well as more secure algorithms. While this approach permits the initial use of legacy algorithms between crypto-agile implementations, if the responder indicates support for crypto- agility, future requests can omit use of legacy algorithms, instead utilizing mechanisms indicated in the response. This approach minimizes the response delay from both legacy and crypto-agile implementations. However, it is viable only where legacy hidden attributes (e.g. User-Password) are not included within requests. Probing techniques can avoid the use of legacy algorithms between crypto-agile implementations. An initial request can omit use of legacy mechanisms, and if a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure mechanisms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy mechanisms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy mechanisms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests may be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. As a result, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. This can be addressed by upgrading the responders (e.g. RADIUS servers) first. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 13 Mar 2011 00:29:41 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 13 Mar 2011 00:28:35 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #91: Citation for MD5 security Issues Message-ID: <075.265de9a02e42603014cb250b04dd3ee9@trac.tools.ietf.org> #91: Citation for MD5 security Issues Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposed resolution is to change Section 3 to the following: 3. The Current State of RADIUS Security RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request [RFC2865] and Status-Server [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. While RADIUS does not support confidentiality of entire packets, various RADIUS attributes support encrypted (also known as "hidden") values, including: User-Password (defined in [RFC2865] Section 5.2), Tunnel-Password (defined in [RFC2868] Section 3.5), and various Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE- Recv-Key attributes (defined in [RFC2548] Section 2.4). Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Attacks against this mechanism are described in [RFC3579] Section 4.3.4. "Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms" [RFC6151] discusses security considerations for use of the MD5 and HMAC-MD5 algorithms. While the advances in MD5 collisions do not immediately compromise the use of MD5 or HMAC-MD5 for the purposes used within RADIUS absent knowledge of the RADIUS shared secret, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. As noted in [RFC6151] Section 2: MD5 is no longer acceptable where collision resistance is required such as digital signatures. It is not urgent to stop using MD5 in other ways, such as HMAC-MD5; however, since MD5 must not be used for digital signatures, new protocol designs should not employ HMAC-MD5. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 13 Mar 2011 00:10:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 13 Mar 2011 00:09:03 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #91: Citation for MD5 security Issues Message-ID: <066.a2513676ea4112890b2e940868240806@trac.tools.ietf.org> #91: Citation for MD5 security Issues The document currently does not provide any citations relating to MD5 or HMAC-MD5 security considerations. At a minimum, I'd suggested citing "MD5 and HMAC-MD5 Security Considerations " RFC 6151. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 23:54:00 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 12 Mar 2011 23:52:53 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #90: Process for publication and selection Message-ID: <066.e58b887196f2be1f6847935efa1523d1@trac.tools.ietf.org> #90: Process for publication and selection Nowhere in the document is the approach to publication of crypto-agility solutions described, nor does the document describe how standards track crypto-agility mechanisms will be selected. Previously the RADEXT WG has utilized WG consensus to determine whether to adopt a crypto-agility proposal as a WG work item. Initial proposals are to be published as EXPERIMENTAL, and multiple implementations of WG work items are now in progress. One potential approach to evaluating standards track submissions is as follows: 1. Require documents submitted for consideration on the standards track to include an evaluation against the Crypto-agility requirements, stating whether they are compliant, conditionally compliant, or non-compliant. Documents published as EXPERIMENTAL could also include such an evaluation (though it wouldn't be required). 2. Determine the success of the experiments based on implementation experience. Factors that may be relevant include performance, required footprint, and demonstrated interoperability between multiple independent implementations. 3. Based on requirements evaluation and experiment writeups, the RADEXT WG can make the decision of whether to promote a crypto-agility proposal to the standards track. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 23:35:06 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 12 Mar 2011 23:33:53 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #89: Key Wrap and Password Hiding Requirements Message-ID: <066.cff106be913743859c8f78dbb4aeb58d@trac.tools.ietf.org> #89: Key Wrap and Password Hiding Requirements The properties of a key and a password are different. Yet in several places, the document seems unclear about whether requirements for negotiation of Key-Wrap algorithms are distinct from requirements relating to hiding of passwords. For example, Section 1.3 states the following: The RADEXT WG will propose one or more specifications to remediate any identified deficiencies in the crypto-agility properties of the RADIUS protocol. The known deficiencies include the issue of negotiation of substitute algorithms for the message digest functions, the key-wrap functions, and the password-hiding function. Additionally, at least one mandatory to implement cryptographic algorithm will be defined in each of these areas, as required. This would seem to imply that negotiation of algorithms for key-wrap is distinct from algorithms for "password hiding". Section 2 says this: Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. While confidentiality can be provided in the transport layer, is it possible to provide keywrap functionality in this layer? Section 4.2 says: Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. This includes providing support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. This text appears to treat all encrypted attributes the same. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 23:18:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 12 Mar 2011 23:17:35 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #88: NITs Message-ID: <075.129345626faf9ede31c8a1d8e43c33f4@trac.tools.ietf.org> #88: NITs Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 23:17:49 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 12 Mar 2011 23:16:56 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #88: NITs Message-ID: <066.f39d692b398a10183ca011590471e345@trac.tools.ietf.org> #88: NITs In Section 4.5, Status-Server is left out of the list of RADIUS message to which crypto-agility should apply. Several mispellings should be fixed: "biding" -> bidding "negotation" -> negotiation -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 23:09:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 12 Mar 2011 23:08:34 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #22: Review Message-ID: <068.bc36bd28b83c9370b70ca5f0b380f02c@trac.tools.ietf.org> #22: Review Comment(by bernard_aboba@…): It isn't clear to me how "Hint and Reject" techniques apply, since legacy implementations will silently discard crypto-agile requests that don't utilize legacy mechanisms, without sending an error-message. So the reality is more like "Choose and Silent Discard". This can make it hard for a requester to distinguish lack of support for crypto-agility from packet loss or some other failure. Unless a request utilizing "Hint and Accept" is protected by legacy methods, a legacy implementation will silently discard it, this approach is only possible if the responder is crypto-agile, and even then, it only applies to the response, not the request, which needs to be protected by mechanisms that are chosen apriori. Yet the document talks about the need to protect all RADIUS messages, not just responses. The reality is that in the absence of information about the capabilities of the responder, the requester will need to make a decision on what algorithms to use to protect the request. If legacy mechanisms are included, then there will be potential consequences, regardless of what other algorithms are used. So it is desirable to avoid use of legacy algorithms between crypto-agile implementations. Also, information from previous responses could be used to determine what mechanisms to use to protect subsequent requests. Since Section 4.3 is about backward compatibility, it needs to talk about some of these issues, and put forward some potential approaches to solving the problem that can address security issues in both requests and responses. The suggested resolution is to change Section 4.3 to the following: 4.3. Backwards Compatibility Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy algorithms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms as well as more secure algorithms. While this approach permits the initial use of legacy algorithms between crypto-agile implementations, if the responder indicates support for crypto-agility, future requests can omit use of legacy algorithms. This approach minimizes the response delay from both legacy and crypto-agile implementations. However, it is viable only where legacy hidden attributes (e.g. User-Password) are not included within requests, and where compromise of the legacy algorithm and RADIUS shared secret does not compromise secure algorithms. Probing techniques can be used to avoid the use of legacy algorithms between crypto-agile implementations. An initial request can omit use of legacy algorithms, and if a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure algorithms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy algorithms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy algorithms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests may be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. As a result, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158] Section 2.3. -- --------------------------------+------------------------------------------- Reporter: jsalowey@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 22:55:24 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 12 Mar 2011 22:54:17 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #23: Comments Message-ID: <070.9c0a66bf65ec86e15d9bd13d736db30a@trac.tools.ietf.org> #23: Comments Comment(by bernard_aboba@…): This still isn't quite right. While negotiation within a single RADIUS request/response is limited, there are potential techniques that could be utilized over multiple exchanges. Currently, the text doesn't describe the limitations or lay out some of the possibilities, nor does it discuss the implications for backwards compatibility for security or performance. Suggested resolution is as follows: Change Section 2 to the following: 2. A Working Definition of Crypto-Agility A generalized definition of crypto-agility was offered up at the RADEXT WG session during IETF-68. Crypto-Agility is the ability of a protocol to adapt to evolving cryptography and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to fielded implementations. It may provide for the dynamic negotiation and installation of cryptographic algorithms within protocol implementations (think of Dynamic-Link Libraries (DLL)). In the specific context of the RADIUS protocol and RADIUS implementations, crypto-agility may be better defined as the ability of RADIUS implementations to automatically negotiate cryptographic algorithms for use in RADIUS exchanges, including the algorithms used to integrity protect and authenticate RADIUS packets and to hide RADIUS Attributes. This capability covers all RADIUS message types: Access-Request/Response, Accounting-Request/Response, CoA/Disconnect- Request/Response, and Status-Server. Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within a single RADIUS exchange is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be determined a-priori. Techniques that can be used for negotiation over multiple request/response exchanges are described in Section 4.3. Change the third paragraph of Section 4.2 to the following: Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks. In analyzing the resilience of a crypto-agility solution, it can be assumed that RADIUS requesters and responders can be configured to require the use of new secure algorithms in the event of a compromise of existing cryptographic algorithms or the legacy RADIUS shared secret. Change Section 4.3 to the following: 4.3. Backwards Compatibility Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. While backward compatibility is needed to ease the transition between legacy RADIUS and crypto-agile RADIUS, use of legacy mechanisms is only appropriate prior to the compromise of those mechanisms. After legacy algorithms have been compromised, secure algorithms MUST be used, so that backward compatibility is no longer possible. Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration. In order to enable a request to be handled both by legacy as well as crypto-agile implementations, a request can be secured with legacy algorithms as well as more secure algorithms. While this approach permits the initial use of legacy algorithms between crypto-agile implementations, if the responder indicates support for crypto-agility, future requests can omit use of legacy algorithms. This approach minimizes the response delay from both legacy and crypto-agile implementations. However, it is viable only where legacy hidden attributes (e.g. User-Password) are not included within requests, and where compromise of the legacy algorithm and RADIUS shared secret does not compromise secure algorithms. Probing techniques can be used to avoid the use of legacy algorithms between crypto-agile implementations. An initial request can omit use of legacy algorithms, and if a response is received, then the recipient can be assumed to be crypto-agile and future requests to that recipient can utilize secure algorithms. Similarly, the responder can assume that the requester supports crypto-agility and can prohibit use of legacy algorithms in future requests. If a response is not received, in the absence of information indicating responder support for crypto-agility (such as pre- configuration or previous receipt of a crypto-agile response), a new request can be composed utilizing legacy algorithms. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms rather than returning an error, repeated requests may be required to distinguish lack of support for crypto-agility from packet loss or other failure conditions. As a result, probing techniques can delay initial communication between crypto-agile requesters and legacy responders. Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC6158] Section 2.3. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 22:23:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 12 Mar 2011 22:21:36 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #86: MD5 Stream Cipher Weaknesses Message-ID: <075.b7696d14718211b99253c6b6fcbd5940@trac.tools.ietf.org> #86: MD5 Stream Cipher Weaknesses Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Note that the Access-Request isn't the only RADIUS packet not protected by a MIC in the Authenticator field; Status-Server also isn't protected that way. The proposed resolution is to change Section 3 to the following: 3. The Current State of RADIUS Security RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request [RFC2865] and Status-Server [RFC5997]. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. While RADIUS does not support confidentiality of entire packets, various RADIUS attributes support encrypted (also known as "hidden") values, including: User-Password [RFC2865, section 5.2], Tunnel- Password [RFC2868, section 3.5], and various Vendor-Specific Attributes, such as the MS-MPPE-Send-Key and MS-MPPE-Recv-Key attributes defined in [RFC2548, section 2.4]. Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Attacks against this mechanism are described in [RFC3579] Section 4.3.4. Recent work on MD5 collisions does not immediately compromise these functions absent knowledge of the RADIUS shared secret. However, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. Add the following references to Section 8: [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS Attributes", RFC 2548, March 1999. [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000. [RFC5997] DeKok, A., "Use of Status-Server Packets in the Remote Authentication Dialin User Service (RADIUS) Protocol", RFC 5997, August 2011. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 12 Mar 2011 02:14:37 +0000 To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: BCP 158, RFC 6158 on RADIUS Design Guidelines From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, radiusext@ops.ietf.org Message-Id: <20110312021315.5E006E075A@rfc-editor.org> Date: Fri, 11 Mar 2011 18:13:15 -0800 (PST) A new Request for Comments is now available in online RFC libraries. BCP 158 RFC 6158 Title: RADIUS Design Guidelines Author: A. DeKok, Ed., G. Weber Status: Best Current Practice Stream: IETF Date: March 2011 Mailbox: aland@freeradius.org, gdweber@gmail.com Pages: 38 Characters: 89319 See Also: BCP0158 I-D Tag: draft-ietf-radext-design-19.txt URL: http://www.rfc-editor.org/rfc/rfc6158.txt This document provides guidelines for the design of attributes used by the Remote Authentication Dial In User Service (RADIUS) protocol. It is expected that these guidelines will prove useful to authors and reviewers of future RADIUS attribute specifications, within the IETF as well as other Standards Development Organizations (SDOs). This memo documents an Internet Best Current Practice. This document is a product of the RADIUS EXTensions Working Group of the IETF. BCP: This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. 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 -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 11 Mar 2011 14:04:03 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: stefan.winter@restena.lu Date: Fri, 11 Mar 2011 14:02:54 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #3: Review of RTLS document (part 1, Technical) Message-ID: <075.e42375a209b3eff2afe0b869c38de64e@trac.tools.ietf.org> #3: Review of RTLS document (part 1, Technical) Comment(by stefan.winter@…): - TLS negotiation text rewritten as suggested - certificate validation from trusted sources: removed; this will be dealt with in the dynamic discovery draft. Only a note in the non-normative section remains. - Client Identity: still needs some discussion, will be up on the slide deck at IETF 80 - DAC: as discussed on the ML, all traffic should go through the same port. A client does not have to be a DAC; if it's not, it is required to NAK the DA traffic though. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Mon, 07 Mar 2011 22:23:30 +0000 Date: Mon, 07 Mar 2011 14:22:27 -0800 From: Tina Tsou Subject: RADIUS Attributes for Dual Stack Access To: radiusext@ops.ietf.org Message-id: <003601cbdd16$24995a40$6dcc0ec0$@com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: AcvdFTgSmao58O9zTVegcpnCQoQ2+QAAC9bwAAArp4A= Hi all, https://datatracker.ietf.org/doc/draft-yeh-radext-dual-stack-access/?include _text=1 submitted. Filename: draft-yeh-radext-dual-stack-access Revision: 00 Title: RADIUS Attributes for Dual Stack Access Creation_date: 2011-03-07 WG ID: Independent Submission Number_of_pages: 11 Abstract: This document specifies the RADIUS attributes for IPv4 and IPv6 dual stack access, which are intended to be used in the AAA processes for the transfer of user's configuration from AAA server to NAS and traffic statistics reporting from NAS to AAA server. The new attributes cover a specified user type for NAS to allocate the proper resource and employ the right mechanism for the users; and a batch of IPv4 and IPv6 traffic statistics for the differentiated accounting policies on the AAA server. I would like to say something about this draft-yeh-radext-dual-stack-access-00. 1. draft-ietf-radext-ipv6-access is valid. 2. draft-yeh-radext-dual-stack-access-00 talks about 13 attributes. The following 6 attributes in draft-yeh-radext-dual-stack-access-00 are similar to draft-maglione-radext-ipv6-acct-extensions, which expired. o Acct-Input-IPv6-Octets o Acct-Output-IPv6-Octets o Acct-Input-IPv6-Packets o Acct-Output-IPv6-Packets o Acct-Input-IPv6-Gigawords o Acct-Output-IPv6-Gigawords 3. There is one work item of IPv6-only in WG RADEXT, would the WG tell me whether we would like to have a new work item for dual-stack? Thanks. We keep our promises with one another - no matter what! Best Regards, Tina TSOU http://tinatsou.weebly.com/contact.html -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 06 Mar 2011 06:59:09 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 06 Mar 2011 06:58:45 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #87: Guidance on mandatory-to-implement algorithms Message-ID: <075.81bcdf5dc9ef15715db9f5402725319e@trac.tools.ietf.org> #87: Guidance on mandatory-to-implement algorithms Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 06 Mar 2011 06:59:01 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 06 Mar 2011 06:58:05 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #23: Comments Message-ID: <070.6295347d267497183a0f348451db8eab@trac.tools.ietf.org> #23: Comments Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Updated proposal. Add the following text to the end of Section 2: Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within RADIUS is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be pre- configured. Since legacy implementations not supporting crypto- agility will silently discard requests not protected by legacy algorithms, in the absence of knowledge about the capabilities of the recipient, requests will need to be protected by legacy algorithms. Within Section 4.3 delete: Included in such negotiation techniques are "hint and accept" and "hint and reject" mechanisms, where the NAS (RADIUS client) provides a list of supported algorithms and the RADIUS server selects one. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 06 Mar 2011 04:56:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 06 Mar 2011 04:55:27 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #23: Comments Message-ID: <070.da63666a956c5b12bbf105148ebffee5@trac.tools.ietf.org> #23: Comments Comment(by bernard_aboba@…): It is proposed that we change the following text in Section 4.3: Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. Included in such negotiation techniques are "hint and accept" and "hint and reject" mechanisms, where the NAS (RADIUS client) provides a list of supported algorithms and the RADIUS server selects one. To: Negotiation of cryptographic algorithms MAY occur within the RADIUS protocol, or within a lower layer such as the transport layer. Since RADIUS is a request/response protocol, the ability to negotiate cryptographic algorithms within RADIUS is inherently limited. While a RADIUS request can provide a list of supported cryptographic algorithms which can selected for use within a response, prior to the receipt of a response, the cryptographic algorithms utilized to provide security services within the request will need to be pre-configured. Since legacy implementations not supporting crypto-agility will silently discard requests not protected by legacy algorithms, in the absence of knowledge about the capabilities of the recipient, requests will need to be protected by legacy algorithms. -- ----------------------------------+----------------------------------------- Reporter: glenzorn@… | Owner: bernard_aboba@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ----------------------------------+----------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 06 Mar 2011 03:12:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 06 Mar 2011 03:11:52 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #85: Confidentiality Requirements Message-ID: <075.a26e302efa8f3d630a7e34772e82b4e4@trac.tools.ietf.org> #85: Confidentiality Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Proposal is to change the existing text to the following: Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. It is RECOMMENDED that solutions provide support for confidentiality, either by supporting encryption of entire RADIUS packets or by encrypting individual RADIUS attributes. This includes providing support for improving the confidentiality of existing encrypted (sometimes referred to as "hidden") attributes as well as encrypting attributes (such as location attributes) that are currently transmitted in cleartext. Proposals supporting confidentiality MUST support the negotiation of cryptographic algorithms for encryption. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 06 Mar 2011 03:00:50 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 06 Mar 2011 03:00:32 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #84: Requirements Language Message-ID: <075.78f0fc68ff663589419dfe31269a2cb1@trac.tools.ietf.org> #84: Requirements Language Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sun, 06 Mar 2011 02:51:15 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sun, 06 Mar 2011 02:50:16 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #87: Guidance on mandatory-to-implement algorithms Message-ID: <066.91fb381c465ec50f28acab7326ef36f7@trac.tools.ietf.org> #87: Guidance on mandatory-to-implement algorithms Section 4.2 does not provide any guidance as to what cryptographic algorithms are acceptable for designation as mandatory-to-implement, nor does it reference any such guidance. My recommendation is that the following paragraph be added to Section 4.2: Guidance on acceptable algorithms can be found in [NIST-SP800-131A]. It is RECOMMENDED that mandatory-to-implement cryptographic algorithms be chosen from among those classified as "Acceptable" with no known deprecation date within [NIST-SP800-131A]. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: critical | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 05 Mar 2011 22:25:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 05 Mar 2011 22:25:02 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #86: MD5 Stream Cipher Weaknesses Message-ID: <066.62285455ad08292c0ca0af89a211ff48@trac.tools.ietf.org> #86: MD5 Stream Cipher Weaknesses Section 3 states: RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. Various RADIUS attributes support encrypted (also known as "hidden") values, including: User-Password, Tunnel-Password, and various Vendor- Specific Attributes. Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Recent work on MD5 collisions does not immediately compromise any of these methods, absent knowledge of the RADIUS shared secret. However, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. The weaknesses of MD5 stream ciphers is independent of MD5 collision issues and therefore it is not accurate to state that there is no compromise absent knowledge of the shared secret. For example, were the RADIUS authenticator to repeat, a known plaintext attack on hidden attributes such as User-Password is possible. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 05 Mar 2011 22:16:18 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 05 Mar 2011 22:15:34 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #85: Confidentiality Requirements Message-ID: <066.e17ec0e3f0e25c275ff005745ef92abc@trac.tools.ietf.org> #85: Confidentiality Requirements Section 4.3 states: Proposals MUST support the negotiation of cryptographic algorithms for per-packet integrity/authentication protection. Support for confidentiality of entire RADIUS packets is OPTIONAL. However, proposals MUST support the negotiation of algorithms for encryption (sometimes referred to as "hiding") of RADIUS attributes. It is RECOMMENDED for proposals to provide for the encryption of existing attributes. This includes existing "hidden" attributes as well as attributes (such as location attributes) that require confidentiality. This paragraph is confusing along multiple dimensions. Since RADIUS is a transactional protocol, it is not possible to "negotiate" algorithms for use in a RADIUS request; algorithm(s) must be chosen. Also, it is not clear whether negotiation as referred to here would refer to encryption of entire RADIUS packets or just individual attributes. Also does "encryption of existing attributes" imply that attributes can be doubly encrypted? -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Sat, 05 Mar 2011 20:59:40 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Sat, 05 Mar 2011 20:58:26 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #22: Review Message-ID: <068.fc5b1a2a8dcb6367d20fabb20fda2770@trac.tools.ietf.org> #22: Review Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: The proposed resolution is as follows: Within Section 4.3, change the following text: Proposals MUST NOT introduce new capabilities negotation features into the RADIUS protocol, but rather MUST use the existing mechanisms. Included in such negotiation techniques are "hint and accept" and "hint and reject" mechanisms, where the NAS (RADIUS client) provides a list of supported algorithms and the RADIUS server selects one. to: Proposals MUST NOT introduce new capabilities negotiation features into the RADIUS protocol, but rather MUST use existing mechanisms. Negotiation techniques include "hint and accept" and "hint and reject" mechanisms, where the RADIUS request provides a list of supported algorithms and one is selected in the response. Since it is necessary to integrity protect the list of algorithms, at least one ciphersuite needs to be used to protect the request and response. -- --------------------------------+------------------------------------------- Reporter: jsalowey@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 09:39:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: stefan.winter@restena.lu, bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 09:38:51 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #60: Behavior in response to CoA-Request Message-ID: <075.e4e7d0854239478ca3b63c83e0ed77d8@trac.tools.ietf.org> #60: Behavior in response to CoA-Request Changes (by stefan.winter@…): * status: new => closed * resolution: => worksforme Comment: A poll was held on the WG mailing list to determine whether Auth/Acct/CoA should be on separte connections (separate ports). The poll favoured to stay on one port for all traffic. This requires a RADIUS/TLS enabled DAS to implement a CoA-NAK as an indication of unwillingness to process CoA requests. This is in line with the text of the -07 draft and remains unchanged for -08. -08 will include further text regarding RADIUS Accounting. For reference, the text for both packet types in -08 is below: (4) RADIUS [RFC2865] used negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of the packet types in [RFC5176]. These packet types are listed as to be received in RADIUS/TLS implementations. Note well: it is not required for an implementation to actually process these packet types. It is sufficient that upon receiving such a packet, an unconditional NAK is sent back to indicate that the action is not supported. (5) RADIUS [RFC2865] used negative ICMP responses to a newly allocated UDP port to signal that a peer RADIUS server does not support reception and processing of RADIUS Accounting packets. There is no RADIUS datagram to signal an Accounting NAK. Clients may be misconfigured to send Accounting packets to a RADIUS/TLS server which does not wish to process their Accounting packet. The server will need to silently drop the packet. The client will need to deduce from the absence of replies that it is misconfigured; no negative ICMP response will reveal this. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: In WG Last Call | Resolution: worksforme Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 09:33:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: stefan.winter@restena.lu, bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 09:32:53 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #56: Review Message-ID: <075.d7fb2a8c448e78c1f35446cc5eef2308@trac.tools.ietf.org> #56: Review Changes (by stefan.winter@…): * status: new => closed * resolution: => fixed Comment: All editorial changes in the review are addressed in the upcoming -08 version. Regarding connection backoff, the following text is in -08: 2.3. Connection Setup RADIUS/TLS nodes 1. establish TCP connections as per [I-D.ietf-radext-tcp-transport]. Failure to connect leads to continuous retries, with exponentially growing intervals between every try. If multiple servers are defined, the node MAY attempt to establish a connection to these other servers in parallel, in order to implement quick failover. I hope that this closes the issue. -- ---------------------------------------+------------------------------------ Reporter: aland@… | Owner: stefan.winter@… Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: radsec | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 08:58:23 +0000 Message-ID: <4D70A97A.70405@euro-comm.net> Date: Fri, 04 Mar 2011 11:57:30 +0300 From: Victor Gamov Organization: Eurocomm.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-radius-extensions-00.txt Content-Type: multipart/mixed; boundary="------------010001090701010201070304" This is a multi-part message in MIME format. --------------010001090701010201070304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 02.03.2011 16:08, Victor Gamov wrote: > Hi All ! > > To extend Type space and allow large values I propose following > format with new unassigned Type: > > 0 1 2 3 > +---------------------------------------------------------------+ |0 > 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| > +---------------+---------------+-------------------------------+ | > Type | Length=0 | Actual Length | > +---------------+---------------+-------------------------------+ | > New Type (up to 65535 types) |Long Value (up to 65529 bytes).. > +---------------+---------------+---------------+---------------+ > > Incompatible implementations will generate reject or discard such > attributes due Length=0. Some explanations If RADIUS-client wants to deliver long-value attribute to RADIUS-server, then this server and client needs to realize some mechanism to allow such values. Any splitting or other -- its need to be realized into both server and clinet. If client wants to deliver any important info by new (compatible) mechanism but server does not know anything about this mechanism, so this important info will be not processed by server. And client does not know about it! If server drop or reject packets with Length=0 then client know about it. If RADIUS-server send replies with important long-value attributes with Length=0 then client drops such packets and session never started. Client may send Acct-Stop by failure and server clear info about session early started (from the point of view of RADIUS-server) -- CU, Victor Gamov --------------010001090701010201070304 Content-Type: text/x-vcard; charset=utf-8; name="vit.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vit.vcf" begin:vcard fn:Victor Gamov n:Gamov;Victor email;internet:vit@euro-comm.net tel;work:sip:04800112@euro-comm.net x-mozilla-html:FALSE version:2.1 end:vcard --------------010001090701010201070304-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:54:42 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_b7802388-12e8-4e75-bc91-b116697b581b_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Call for Agenda Items Date: Thu, 3 Mar 2011 22:54:14 -0800 MIME-Version: 1.0 --_b7802388-12e8-4e75-bc91-b116697b581b_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a call for agenda items at the RADEXT WG session at IETF 80 in Prag= ue=2C CZ. The WG is scheduled to meet on Wednesday morning from 9 AM to 11= :30 AM. Remote presentation can be arranged=2C so feel free to suggest an= agenda item even if you cannot be physically present.=20 Here is a strawman agenda: =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=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 RADEXT WG IETF 80 Agenda=20 =20 Chairs: Bernard Aboba Mauricio Sanchez =20 Jabber room: radext at jabber.ietf.org (Please join) =20 Wednesday=2C March 30=2C 2011 =20 0900 - 1130 =20 Karlin II and III =20 09:00 - 09:20=2C Preliminaries =20 Debugging Note Well Note Takers Jabber scribe Agenda bash Document Status Documented completing WG Last Call (20 minutes) 9:20 - 9:40 AM RADIUS Attributes for IPv6 Access Networks (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-ipv6-access WG Work Items (60 minutes) 9:40 - 10:00 AM Crypto-Agility Requirements for RADIUS (20 minutes)http://= tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements 10:00 AM - 10:10 AM RADIUS over TLS=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-radsec =20 10:10 AM - 10:20 AM Dynamic Peer Discovery=2C Stefan Winter (10 minutes) http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery =20 10:20 AM - 10:40 AM RADIUS over DTLS=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-dtls =20 10:40 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (20 minutes) http://tools.ietf.org/html/draft-ietf-radext-radius-extensions Discussion and Wrap-up (30 minutes) =20 11:00 =96 11:15 AM Discussion (15 minutes) 11:15 - 11:30 AM Next Steps: WG Chairs & ADs (15 minutes) = --_b7802388-12e8-4e75-bc91-b116697b581b_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a call for agenda items at the RADEXT WG session at IETF 80 in Prag= ue=2C CZ. =3B The WG is scheduled to meet on Wednesday morning from 9 A= M to 11:30 AM.  =3B Remote presentation can be arranged=2C so feel free= to suggest an agenda item even if you cannot be physically present.
Here is a strawman agenda:

=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=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

RADEXT WG IETF 80= Agenda

 =3B

Chairs:

Bernard Aboba <=3Bbernard_aboba at hotmail.com>= =3B

Mauricio Sanchez <=3Bmauricio.sanchez at hp.com>= =3B

 =3B

Jabber room: =3B radext at jabber.ietf.org (Plea= se join)

 =3B

Wednesday=2C March 30=2C 2011

 =3B

0900 - 1130

 =3B

Karlin II and III

 =3B

09:00 - 09:20=2C Preliminaries

 =3B

 =3B =3B =3B =3B Debugging

 =3B =3B =3B =3B Note Well

 =3B =3B =3B =3B Note Takers

 =3B =3B =3B =3B Jabber scribe

 =3B =3B =3B =3B Agenda bash

 =3B =3B =3B =3B Document Status

=
Documented completing WG Last Call (20 minutes)

<= br>

9:20 - 9:40 AM RADIUS Attributes for IPv6 Acc= ess Networks (20 minutes)

http://tools.ietf.o= rg/html/draft-ietf-radext-ipv6-access


WG Work Items (60 minutes)

 =3B

9:40 - 10:00 AM C= rypto-Agility Requirements for RADIUS (20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements<= /p>


10:00 AM - 10:10 AM RADIUS over TLS=2C Stefan Winter (10 minutes)

http://tools.ietf.org/html/draft-ietf-radext-radsec<= /p>

 =3B

10:10 AM - 10:20 AM Dynamic Peer Discovery=2C Stefan= Winter (10 minutes)

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

 =3B

10:20 AM - 10:40 AM RADIUS over DTLS=2C Alan DeKok (= 20 minutes)

http://tools.ietf.org/html/draft-ietf-radext-dtls

 =3B

10:40 - 11:00 AM RADIUS Protocol Extensions=2C Alan DeKok (20 minutes)
h= ttp://tools.ietf.org/html/draft-ietf-radext-radius-extensions

Discussion and Wrap-up (30 minutes)

 =3B

11:00 =96 11:15 AM Discussion (15 minutes)

11:15 - 11:30 =3B AM Next Steps: =3B WG Chairs &=3B ADs (15 minu= tes)
= --_b7802388-12e8-4e75-bc91-b116697b581b_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:28:19 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:28:04 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #81: Location Privacy Message-ID: <075.e04624c050a9d76d5df995554a087adc@trac.tools.ietf.org> #81: Location Privacy Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: Recommendation is to change the text to: It is RECOMMENDED for proposals to provide for the encryption of existing attributes. This includes existing "hidden" attributes as well as attributes (such as location attributes) that require confidentiality. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:25:29 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:25:08 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #84: Requirements Language Message-ID: <066.93e77ab00ad6de675f313084b5a53300@trac.tools.ietf.org> #84: Requirements Language Add the following text to the Requirements Language text on page 1: A RADIUS crypto-agility solution is not compliant with this specification if it fails to satisfy one or more of the MUST or MUST NOT statements. A solution that satisfies all the MUST, MUST NOT, SHOULD, and SHOULD NOT statements is said to be "unconditionally compliant"; one that satisfies all the MUST and MUST NOT statements but not all the SHOULD or SHOULD NOT requirements is said to be "conditionally compliant". -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:15:34 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:15:18 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #21: Crypto-Agility thoughts Message-ID: <071.360187d1874240e364a18fbedd074ec1@trac.tools.ietf.org> #21: Crypto-Agility thoughts Changes (by bernard_aboba@…): * status: assigned => closed * resolution: => fixed -- -----------------------------------+---------------------------------------- Reporter: Pasi.Eronen@… | Owner: bernard_aboba@… Type: defect | Status: closed Priority: blocker | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:12:20 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:12:08 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #83: AKM Requirements Message-ID: <075.0492cbf511073c68c01238768a169dc2@trac.tools.ietf.org> #83: AKM Requirements Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:11:48 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: d.b.nelson@comcast.net, bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:11:37 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #78: Pre-November 2008 Copyright Notice Message-ID: <075.c530d2c202c6ff6f94a23f4058de3bd6@trac.tools.ietf.org> #78: Pre-November 2008 Copyright Notice Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: d.b.nelson@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:11:33 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:11:22 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #79: Reference issues Message-ID: <075.249fa599469059e20f65a39929fb2745@trac.tools.ietf.org> #79: Reference issues Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:11:21 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:10:58 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #80: Section 3 Message-ID: <075.98c38d8bdebeff353476a9d5a8fb0618@trac.tools.ietf.org> #80: Section 3 Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 06:11:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Fri, 04 Mar 2011 06:10:30 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #82: Diameter compatibliity Message-ID: <075.3d469df7b744a9d15a3b87dcbc38345e@trac.tools.ietf.org> #82: Diameter compatibliity Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Fri, 04 Mar 2011 05:02:11 +0000 MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-03.txt Message-ID: <20110304050002.27885.97768.idtracker@localhost> Date: Thu, 03 Mar 2011 21:00:02 -0800 --NextPart 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 : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-03.txt Pages : 9 Date : 2011-03-03 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03205856.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 23:52:26 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Thu, 03 Mar 2011 23:51:32 -0000 Reply-To: radiusext@ops.ietf.org Subject: Re: [radext] #21: Crypto-Agility thoughts Message-ID: <071.f88ed8874372d9c084da8c153d719368@trac.tools.ietf.org> #21: Crypto-Agility thoughts Changes (by bernard_aboba@…): * status: new => assigned Comment: Here is a proposed resolution to this issue: Hop-by-hop/end-to-end: Much of RFC 4962 is open to multiple interpretations, and some parts of it can be read as requiring more than hop-by-hop security. IMHO exactly the same parts can also be read as saying hop-by-hop can be sufficient (when done properly), and I think this document should explicitly say it's interpreting 4962 the latter way. [BA] The document already incorporates most of the security advice in RFC 4962 relevant to AAA protocols. However, there appear to be a few requirements that are not included. To clarify their interpretation, it is recommended that we add the following text to Section 4.2: In addition to the above goals, [RFC4962] Section 2 describes the following additional security requirements for AAA protocols: 1. Strong, fresh session keys. RFC 4962 Section 2 states: "The AAA protocol MUST ensure that the keying material supplied as an input to session key derivation is fresh... The mechanism used to generate session keys MUST ensure that the disclosure of one session key does not aid the attacker in discovering any other session keys."` RADIUS crypto-agility solutions are REQUIRED to generate fresh session keys for use between the RADIUS client and server. In order to prevent the disclosure of one session key from aiding an attacker in discovering other session keys, RADIUS crypto-agility solutions are RECOMMENDED to support Perfect Forward Secrecy (PFS) with respect to session keys negotiated between the RADIUS client and server. 2. Limit key scope. RFC 4962 Section 2 states: "Following the principle of least privilege, parties MUST NOT have access to keying material that is not needed to perform their role." In order to enable a NAS and RADIUS server to transmit keying material directly between each other, it is RECOMMENDED that a RADIUS crypto-agility solution be compatible with NAI-based Dynamic Peer Discovery [RADYN] as well as that it support the use of public key credentials for authentication between the NAS and RADIUS server. For compatibility with existing operations, RADIUS crypto-agility solutions SHOULD also support pre-shared key credentials. 3. Prevent the Domino effect. RFC 4962 Section 2 states: "Likewise, compromise of a single authenticator MUST NOT compromise keying material held by any other authenticator within the system." In order to prevent the domino effect, RADIUS crypto-agility solutions MUST enable each RADIUS client and server pair to authenticate utilizing unique credentials. Forward secrecy: Sometimes RADIUS is used to deliver keys (like EAP MSK) that will be used (perhaps indirectly via additional key derivation steps) to encrypt information that may be valuable for a long time. Given this, the document needs some discussion about "forward secrecy" (whether revealing the long-term credential allows decrypting all past communications), and if the conclusion is that crypto-agility solutions don't need to support forward secrecy (even as optional-to-use feature), explain the rationale behind this conclusion. [BA] The need to support PFS derives from the RFC 4962 requirements, so it is proposed that this be added to the Section 4.2 requirements as a recommendation. Authentication/long-term credentials: Authenticating the RADIUS client and server will require (manual) configuration of some kinds of credentials (currently, the RADIUS shared secret). The document should say something about what kinds of long-term authentication credentials (for RADIUS entities) the crypto-agility solutions are expected to support. Presumably, they MUST support pair-wise shared secrets. Other possibilities for long-term credentials could include e.g. X.509 certificates with PKI, public keys without certification infrastructure (generate keypair + configure fingerprint of peer's key), or Kerberos. Even if the conclusion is that nothing else than pairwise shared secrets is needed, that should be said in the document (with rationale explaining why). [BA] The need to support public-key credentials derives from the requirement for direct transport of keys and the need for pair-wise shared secrets derives from current operational practice. So it is proposed that recommendations relating to support for these credential types be added to Section 4.2. Replay protection: Section 4.2 says "Proposals MUST support replay protection. The existing mechanisms for replay protection are considered adequate and should be maintained." I think the latter sentence needs some clarification. If the intent is to say replay protection provided by the current mechanisms (i.e., basically none for Access-Request messages) is good enough, I would disagree with that (or at least would expect to see an explanation why that's the case for Access-Requests). If the intent is something else, the text needs to be clearer. [BA] The proposal is that the following text within Section 4.2: Proposals MUST support replay protection. The existing mechanisms for replay protection are considered adequate and should be maintained. be changed to the following: Proposals MUST support per-packet replay protection for all RADIUS message types. Meaning of negotiation: The document says proposals MUST support negotiation of cryptographic algorithms. Does "negotiation" here mean picking which algorithm to use in the protocol (RADIUS client and server figure out an algorithm supported by both of them), or would negotiation between system administrators meet this requirement? I assume the WG has rough consensus about what this means, and ordinarily, I would have automatically assumed it's the former. But some earlier proposals in this space have supported only the latter kind (which does provide some kind of algorithm agility -- it's better than hardcoding MD5 -- but could mean synchronized manual work for every transition)... [BA] The proposal is that the following text in Section 2: "of RADIUS implementations to negotiate cryptographic algorithms" be changed to: "of RADIUS implementations to automatically negotiate cryptographic algorithms" Automated Key Management: Well... RADIUS certainly requires only O(n) keys, but on the other hand, the amount of data encrypted with a single key is not necessarily small (when considering the "value of the data" and time aspects -- in terms of gigabytes, it's probably small compared to what decent algorithms can handle). And if you anyway support negotiating the algorithms (in the protocol), generating a fresh session key may not be that much extra effort, and may be needed anyway since the key can depend on the selected algorithm (if you negotiate 256-bit AES, you need a 256-bit key; if it's 3DES, 168 bits, etc.). And the solutions should avoid using the same cryptographic key with multiple algorithms (and the easiest way to ensure this would probably be fresh session keys). Generating a fresh session key probably also simplifies replay protection (it's the obvious time to e.g. reset counters to zero), but other approaches to replays are certainly feasible. And obviously, forward secrecy and supporting any other types of long-term credentials than shared secrets requires automated key management of some kind. So, I think the conclusion here needs at the very least some qualification and additional explanation. *If* a solution not supporting forward secrecy and not supporting other types of credentials is acceptable, *and* replay protection is solved in certain way, *and* the solution can ensure that the negotiated algorithms get keys appropriate for them, *and* the solution can ensure that two algorithms don't use the same key, then you might get away with no AKM. But even then, AKM might be less work. [BA] The requirement for a fresh session key derives from RFC 4962, Since a fresh session key can be derived from a pre-shared key via the exchange of nonces, this doesn't necessarily imply AKM. However, the requirement for PFS as well as for direct key transport between a NAS and RADIUS server do effectively imply AKM. The proposal is to change Section 4.6 to the following: 4.6. Applicability of Automated Key Management Requirements [RFC4107] provides guidelines for when automated key management is necessary. At the IETF-70 meeting, and leading up to that meeting, the RADEXT WG debated whether or not RFC 4107 would require a RADIUS Crypto-Agility solution to feature Automated Key Management (AKM). The working group determined that AKM was not inherently required for RADIUS based on the following points: o RFC 4107 requires AKM for protocols that involve O(n^2) keys. This does not apply to RADIUS deployments, which require O(n) keys. o Requirements for session key freshness can be met without AKM, for example, by utilizing a pre-shared key along with an exchange of nonces. o RADIUS does not require the encryption of large amounts of data in a short time. o Organizations already have operational practices to manage existing RADIUS shared secrets to address key changes required through personnel changes. o The crypto-agility solution can avoid use cryptographic modes of operation such as a counter mode cipher that require frequent key changes. However, the same time, it is recognized that features recommended in Section 4.2 such as support for PFS and direct transport of keys between a NAS and RADIUS server, can only be provided by a solution supporting AKM. As a result, support for Automated Key Management is RECOMMENDED within a RADIUS crypto-agility solution. Compromise of legacy shared secret: Section 4.2 says "Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks." If interpreted literally, this requirement could be very difficult to meet (perhaps impossible). It seems to assume that for this particular peer, the administrator has configured two different shared secrets (one for the current security mechanisms, another for the new ones), but has not configured whether to use the old or new mechanisms (with this particular peer), and instead, that is negotiated somehow. If the attacker knows the legacy shared secret, and has complete control over the communication channel (and in particular, can drop messages going from A to B), then it seems the attacker will be indistinguishable from a valid peer that supports only the legacy mechanisms (and does not know the new shared secret), and detecting bidding down will not be possible. Preventing bidding down in less extreme cases of compromise is of course both possible and desirable (e.g. if the algorithms are just weak but not breakable in real time, or if the attacker doesn't have complete control over the communications). And the administrator could always configure just the "new shared secret", if he/she knows that the peer supports it. [BA] Propose that the following text in Section 4.2: Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks. be changed to: Crypto-agility solutions MUST avoid security compromise, even in situations where the existing cryptographic algorithms utilized by RADIUS implementations are shown to be weak enough to provide little or no security (e.g. in event of compromise of the legacy RADIUS shared secret). Included in this would be protection against bidding down attacks. In analyzing the resilience of a crypto-agility solution, it can be assumed that the RADIUS server can be configured to require the use of new secure algorithms in the event of a compromise of existing cryptographic algorithms or the legacy RADIUS shared secret. Backward compatibility/negotiation: Section 4.3 says "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, a crypto-agility solution needs to be able to send packets that a legacy RADIUS client or server will receive and process successfully. Similarly, a crypto-agility solution needs to be capable of receiving and processing packets from a legacy RADIUS client or server." The intent of this paragraph is probably right, but currently, it's somewhat open to multiple interpretations. Would something like this capture the intent? "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration." Note that *not* meeting this requirement would actually be quite difficult... if the intent of this paragraph was to require some kind of negotiation (interpreted loosely -- anything more automatic than manual configuration), the text should say so. [BA] Recommend that the following text in Section 4.3: "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, a crypto-agility solution needs to be able to send packets that a legacy RADIUS client or server will receive and process successfully. Similarly, a crypto-agility solution needs to be capable of receiving and processing packets from a legacy RADIUS client or server." be changed to: "Solutions to the problem MUST demonstrate backward compatibility with existing RADIUS implementations. That is, an implementation that supports both the crypto-agility solution and legacy mechanisms MUST be able to talk with legacy RADIUS clients and servers (using the legacy mechanisms). Acceptable solutions to determining which set of mechanisms is used (with a particular peer) include some kind of negotiation, and manual configuration." "Operational model"? Section 4.3 says "Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model, such as the introduction of new commands or maintenance of [additional] state on the RADIUS server." I'm not sure what "operational" means here -- at first I thought it might mean "operations and management" (so the requirement would be basically "SHOULD not complicate life for administrators"), but the two examples given don't seem to fit that very well. And it seems any solution that e.g. derives fresh session keys will involve some small (but greater than zero) amount of additional state on clients and servers. If the intent was really operations and management, perhaps the should be rephased something like "When using long-term shared secrets for authentication, crypto-agility solutions SHOULD NOT require more operations and management work than the current solutions." "RADIUS service?" Section 4.3 says "For example, proposals SHOULD NOT .. include definition of new RADIUS services." What's a RADIUS service -- i.e. what types of proposals this definition would disqualify? (In RFC 2865, "service" is defined as the service provided by the NAS to the user, but that definition doesn't seem applicable here.) [BA] Proposal is to change the following text in Section 4.3: Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model, such as the introduction of new commands or maintenance of [additional] state on the RADIUS server. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats or include definition of new RADIUS services. to the following: "Crypto-agility solutions SHOULD NOT require changes to the RADIUS operational model as defined in "RADIUS Design Guidelines" [RFC 6158] Section 3.1 and Appendix A.4. Similarly, a proposal SHOULD focus on the crypto-agility problem and nothing else. For example, proposals SHOULD NOT require new attribute formats and SHOULD be compatible with the guidance provided in [RFC 6158] Section 2.3." -- -----------------------------------+---------------------------------------- Reporter: Pasi.Eronen@… | Owner: bernard_aboba@… Type: defect | Status: assigned Priority: blocker | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: -----------------------------------+---------------------------------------- Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 22:05:52 +0000 Message-ID: Content-Type: multipart/alternative; boundary="_4e65e252-c223-4839-9942-87e6258b2db4_" From: Bernard Aboba To: "radiusext@ops.ietf.org" Subject: Request for Review: Crypto-Agility Requirements for RADIUS Date: Thu, 3 Mar 2011 14:05:34 -0800 MIME-Version: 1.0 --_4e65e252-c223-4839-9942-87e6258b2db4_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a request for review of "Crypto-Agility Requirements for RADIUS". = The document may be found here: http://tools.ietf.org/html/draft-ietf-radext-crypto-agility-requirements The "Request for Review" will last until March 17=2C 2011. RADEXT WG Participants are encouraged to read the document and post issues in=20 the TRAC database (see below for details on how to do this) or on the=20 RADEXT WG mailing list.=20 When all the open issues on this document are addressed=2C the document wil= l go to WG last call.=20 =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 1. To submit an issue in TRAC=2C you first need to login to the RADEX= T WG site on the tools server: http://tools.ietf.org/wg/radext/trac/login= =20 2. If you don=92t already have a login ID=2C you can obtain one by na= vigating to this site: http://trac.tools.ietf.org/newlogin 3. Once you have obtained an account=2C and have logged in=2C you can= file an issue by navigating to the ticket entry form: http://trac.tools.i= etf.org/wg/radext/trac/newticket 4. When opening an issue: a. =20 The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).=20 b. The=20 Priority: field is set based on the severity of the Issue. For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94.=20 c. The Milestone: field should be set to milestone1 (useless=2C I kno= w).=20 d. The Component: field should be set to the document you are filing t= he issue on. =20 e. The Version: field should be set to =931.0=94.=20 f. =20 The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call) g. The Keywords: and CC: fields can be left blank unless inspiration= seizes you.=20 h. The Assign To: field is generally filled in with the email address = of the editor.=20 5. =20 Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.=20 6. =20 If you want to preview your Issue=2C click on the =93Preview=94 button. W= hen you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.=20 7. If you want to update an issue=2C go to the "View Tickets" page: h= ttp://trac.tools.ietf.org/wg/radext/trac/report/1 Click on the ticket # yo= u want to update=2C and then modify the ticket fields as required = = --_4e65e252-c223-4839-9942-87e6258b2db4_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable This is a request for review of "Crypto-Agility Requirements for RADIUS".&n= bsp=3B The document may be found here:
http://tools.ietf.org/html/draft-= ietf-radext-crypto-agility-requirements

The "Request for Review" wil= l last until March 17=2C 2011.

RADEXT WG Participants are encouraged to read the document and post issues in=20 the TRAC database (see below for details on how to do this) or on the=20 RADEXT WG mailing list.

When all the open issues on this document a= re addressed=2C the document will go to WG last call.

=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

1. =3B =3B&nbs= p=3B =3B =3B =3B To submit an issue in TRAC=2C you first need t= o login to the RADEXT WG site on the tools server: =3B http://tools.ietf.o= rg/wg/radext/trac/login

2. =3B =3B =3B =3B = =3B =3B If you don=92t already have a login ID=2C you can obtain one by= navigating to this site: =3B =3B http://trac.tools.ietf.org/newlogin
=
3. =3B =3B =3B =3B =3B =3B Once you have obtain= ed an account=2C and have logged in=2C you can file an issue by navigating = to the =3B ticket entry form: http://trac.tools.ietf.org/wg/radex= t/trac/newticket

4. =3B =3B =3B =3B =3B = =3B When opening an issue:

a. =3B =3B =3B =3B = =3B =3B The Type: field should be set to =93defect=94 for an issue with the curren= t document text=2C or =93enhancement=94 for a proposed addition of=20 functionality (such as an additional requirement).
b. =3B =3B&n= bsp=3B =3B =3B The=20 Priority: field is set based on the severity of the Issue. =3B =3B = For=20 example=2C editorial issues are typically =93minor=94 or =93trivial=94. c. =3B =3B =3B =3B =3B =3B The Milestone: field sh= ould be set to milestone1 (useless=2C I know).
d. =3B =3B = =3B =3B =3B The Component: field should be set to the document you = are filing the issue on. =3B
e. =3B =3B =3B =3B&nbs= p=3B The Version: field should be set to =931.0=94.
f. =3B =3B&= nbsp=3B =3B =3B =3B =3B The Severity: field should be set to based on the status of the=20 document (e.g. =93In WG Last Call=94 for a document in WG last call)
g.&= nbsp=3B =3B =3B =3B =3B =3B =3B The Keywords: and C= C: fields can be left blank unless inspiration seizes you.
h. =3B&n= bsp=3B =3B =3B =3B The Assign To: field is generally filled in = with the email address of the editor.

5. =3B =3B =3B&nb= sp=3B =3B =3B Typically it won=92t be necessary to enclose a file with the ticket=2C but= =20 if you need to=2C select =93I have files to attach to this ticket=94.
<= br>6. =3B =3B =3B =3B =3B =3B If you want to preview your Issue=2C click on the =93Preview=94 button.&nb= sp=3B When you=92re ready to submit the issue=2C click on the =93Create Ticket=94 but= ton.

7. =3B =3B =3B =3B =3B =3B If you want= to update an issue=2C go to the "View Tickets" page: http://trac.tool= s.ietf.org/wg/radext/trac/report/1 =3B Click on the ticket # you wa= nt to update=2C and then modify the ticket fields as required

 =3B

= = --_4e65e252-c223-4839-9942-87e6258b2db4_-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 22:01:35 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Thu, 03 Mar 2011 22:01:23 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #83: AKM Requirements Message-ID: <066.2f9c0aa847c1f8f9bed3b42e8b6f39ab@trac.tools.ietf.org> #83: AKM Requirements Section 4.6 states: Automated key management is required for RADIUS crypto agility solutions that use cryptographic modes of operation that require frequent key changes. Shouldn't "required" be capitalized here? -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 21:59:16 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Thu, 03 Mar 2011 21:59:01 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #82: Diameter compatibliity Message-ID: <066.64aab0948023e23ae56821583f5fe72a@trac.tools.ietf.org> #82: Diameter compatibliity Section 4.5 states: Proposals MUST include a Diameter compatibility section, although it is expected that the work will occur purely within RADIUS or in the transport, and therefore does not affect message data that is exchanged with Diameter. [BA] Since a Diameter compatibility section is no longer required, I recommend that this be changed to the following: Since it is expected that the work will occur purely within RADIUS or in the transport, message data exchanged with Diameter SHOULD NOT be affected. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 21:56:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Thu, 03 Mar 2011 21:56:25 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #81: Location Privacy Message-ID: <066.451f184eae2eab18c2c871e3f0339e04@trac.tools.ietf.org> #81: Location Privacy Section 4.2 states: If possible, it is desirable for proposals to provide for the encryption of existing attributes. This includes existing "hidden" attributes as well as attributes (such as location attributes) that require confidentiality. [BA] GEOPRIV requirements are described in RFC 3693; this should probably be referenced here. Also, "desirable" appears to be used as a synonym for RECOMMENDED here. Should this be changed? -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 21:48:46 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Thu, 03 Mar 2011 21:48:30 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #80: Section 3 Message-ID: <066.bf885c840855f6d7ca0e423b2fc28ee7@trac.tools.ietf.org> #80: Section 3 This section isn't just about encryption, but the state of RADIUS security in general. Suggest the following re-write: 3. The Current State of RADIUS Security RADIUS packets, as defined in [RFC2865], are protected by an MD5 message integrity check (MIC), within the Authenticator field of RADIUS packets other than Access-Request. The Message-Authenticator Attribute utilizes HMAC-MD5 to authenticate and integrity protect RADIUS packets. Various RADIUS attributes support hidden values, including: User-Password, Tunnel-Password, and various Vendor- Specific Attributes. Generally speaking, the hiding mechanism uses a stream cipher based on a key stream from an MD5 digest. Recent work on MD5 collisions does not immediately compromise any of these methods, absent knowledge of the RADIUS shared secret. However, the progress toward compromise of MD5's basic cryptographic assumptions has resulted in the deprecation of MD5 usage in a variety of applications. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 21:46:38 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: bernard_aboba@hotmail.com Date: Thu, 03 Mar 2011 21:46:22 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #79: Reference issues Message-ID: <066.c1f016202b867220eee064feef80ea2b@trac.tools.ietf.org> #79: Reference issues idnits currently finds the following NITs relating to references in the -02 document: Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2865' is defined on line 293, but no explicit reference was found in the text '[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Rem...' == Unused Reference: 'RFC3162' is defined on line 297, but no explicit reference was found in the text '[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RF...' == Unused Reference: 'RFC3579' is defined on line 300, but no explicit reference was found in the text '[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication...' == Unused Reference: 'RFC4962' is defined on line 307, but no explicit reference was found in the text '[RFC4962] Housley, R. and B. Aboba, "Guidance for Authentication, A...' Looking through the document, each of the "unused" references are actually included, but not in the referenced form (e.g. RFC 2865 instead of [RFC2865]). This should be cleaned up. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 21:44:12 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "radext issue tracker" Cc: radiusext@ops.ietf.org Auto-Submitted: auto-generated To: d.b.nelson@comcast.net, bernard_aboba@hotmail.com Date: Thu, 03 Mar 2011 21:43:44 -0000 Reply-To: radiusext@ops.ietf.org Subject: [radext] #78: Pre-November 2008 Copyright Notice Message-ID: <066.786840e236484a02f68d05bcae225353@trac.tools.ietf.org> #78: Pre-November 2008 Copyright Notice The current -02 document does not utilize the pre-November 2008 copyright notice. This issue is filed in case the authors wish to change the notice. Otherwise, this issue can be resolved "won't fix". Here is what the pre-November 2008 notice looks like; Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. -- ---------------------------------------+------------------------------------ Reporter: bernard_aboba@… | Owner: d.b.nelson@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: Crypto-Agility | Version: 1.0 Severity: Active WG Document | Keywords: ---------------------------------------+------------------------------------ Ticket URL: radext -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Thu, 03 Mar 2011 21:17:20 +0000 MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: radiusext@ops.ietf.org Subject: I-D Action:draft-ietf-radext-crypto-agility-requirements-02.txt Message-ID: <20110303211502.21331.20082.idtracker@localhost> Date: Thu, 03 Mar 2011 13:15:02 -0800 --NextPart 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 : Crypto-Agility Requirements for Remote Dial-In User Service (RADIUS) Author(s) : D. Nelson Filename : draft-ietf-radext-crypto-agility-requirements-02.txt Pages : 8 Date : 2011-03-03 This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-radext-crypto-agility-requirements-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-radext-crypto-agility-requirements-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-03130525.I-D@ietf.org> --NextPart-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: Envelope-to: radiusext-data0@psg.com Delivery-date: Wed, 02 Mar 2011 13:09:34 +0000 Message-ID: <4D6E4146.2040806@euro-comm.net> Date: Wed, 02 Mar 2011 16:08:22 +0300 From: Victor Gamov Organization: Eurocomm.net User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: radiusext@ops.ietf.org Subject: Re: I-D Action:draft-ietf-radext-radius-extensions-00.txt Content-Type: multipart/mixed; boundary="------------050005050407040405020306" This is a multi-part message in MIME format. --------------050005050407040405020306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi All ! To extend Type space and allow large values I propose following format with new unassigned Type: 0 1 2 3 +---------------------------------------------------------------+ |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+-------------------------------+ | Type | Length=0 | Actual Length | +---------------+---------------+-------------------------------+ | New Type (up to 65535 types) |Long Value (up to 65529 bytes).. +---------------+---------------+---------------+---------------+ Incompatible implementations will generate reject or discard such attributes due Length=0. To allow VSA with extended types (more than 255) and values (Type is new unassigned type): 0 1 2 3 +---------------------------------------------------------------+ |0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1| +---------------+---------------+-------------------------------+ | Type | Length=0 | Actual Length | +---------------+---------------+-------------------------------+ | Vendor ID | +---------------+---------------+---------------+---------------+ | VSA Type |Long Value (up to 65525 bytes).. +---------------+---------------+---------------+---------------+ In more general, second format may be used to extend RADIUS-standard attributes when 'Vendor ID' = 0 -- CU, Victor Gamov --------------050005050407040405020306 Content-Type: text/x-vcard; charset=utf-8; name="vit.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="vit.vcf" begin:vcard fn:Victor Gamov n:Gamov;Victor email;internet:vit@euro-comm.net tel;work:sip:04800112@euro-comm.net x-mozilla-html:FALSE version:2.1 end:vcard --------------050005050407040405020306-- -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: