From nobody Mon Mar 2 08:18:03 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407BA1A1B37 for ; Mon, 2 Mar 2015 08:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spR_PtWwaGWX for ; Mon, 2 Mar 2015 08:17:55 -0800 (PST) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE2F1A1A8D for ; Mon, 2 Mar 2015 08:17:55 -0800 (PST) Received: by lbiz11 with SMTP id z11so5139488lbi.3 for ; Mon, 02 Mar 2015 08:17:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=+4lfJpQJ3Zi5RANCmMhkvJTkHol0yFkJE3AmF4DZRiQ=; b=AWPPrmK7QQPqCb/oiPQBV92k0aN2+DE2jje7X0XHOODqagq07Qgm0n7ioQAAdus3t/ 7TGMkBdFe0w34vzMgUJ9NaKJSGUV4dKtZ5ppW780QF5rVRwTrvY9VMBMr17zClQsUA6F P/iM8Jskk5KsgeSjHa2WEu7TmopvQ//6J87d+O7P/MZV6XDV0h9RTiZnn0UPlb0YT2bb YtFBO/FHBOlu+VmzmG+8PISmZJj4TbDCxMc/2/VESv9NZJ2gxzsxy4xRgI42drATn2ct FsTYpyVo/U3Jf6XNTpew3/7EQb7/3H57L4KV6jihh2ExpfqryWrOmQX6+aTAE5TfuRrM EAXQ== MIME-Version: 1.0 X-Received: by 10.112.181.41 with SMTP id dt9mr25649996lbc.56.1425313073534; Mon, 02 Mar 2015 08:17:53 -0800 (PST) Received: by 10.112.167.101 with HTTP; Mon, 2 Mar 2015 08:17:53 -0800 (PST) In-Reply-To: References: Date: Mon, 2 Mar 2015 11:17:53 -0500 Message-ID: From: Kathleen Moriarty To: radext@ietf.org Content-Type: multipart/alternative; boundary=001a11c369867191aa0510508f49 Archived-At: Subject: Re: [radext] AD review of draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2015 16:18:01 -0000 --001a11c369867191aa0510508f49 Content-Type: text/plain; charset=UTF-8 Hi, I haven't seen any follow up yet and would like to progress this to IETF last call soon if possible. My comments are mainly nits or requests to further clarify text, so hopefully these will be easy to resolve before we get broader reviews on the drafts where these questions are likely to arise. Thank you, Kathleen On Wed, Feb 25, 2015 at 7:11 PM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > I reviewed draft-ietf-radext-dynamic-discovery and found it to be very > well written, and covering security and privacy considerations nicely as > well. Thank you for that. > > I just have a few nits and a question to see if some text can be further > clarified before progressing this to last call. I'd like to start IETF > last call very soon if the WG is ok with that. > > Nits & comments: > > Please expand out names of DNS labels on first use (NAPTR, SRV, RR, > etc.). They are obvious to most of us, but are not in the list of acronyms > that don't have to be spelled out, > https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > (If there is a *, RFC editor is okay with not expanding) > > Section 3.4.3 > In the algorithm, I am confused by step 12 that simply says "Proceed with > step 18." Are there conditions that would have you decide to skip steps > 13-17 or is this meant to be interpreted as proceed with step 18, then go > back to step 13? The example later shows that you skip 13-17, but why this > happens isn't clear to me. Did I miss an explanation? > > Section 3.4.4 > First paragraph: The second sentence is super long and the last one is > also a bit too long, can something be done to make these sentences easier > to read? > > Section 3.4.5 > Second to last sentence, just a nit: > s/control/controls/ > > The algorithm therefore control execution time with > TIMER. > > > Section 3.4.6 > There are some formatting issues at the start of this section, you are > probably aware of already. > > Thank you. > -- > > Best regards, > Kathleen > -- Best regards, Kathleen --001a11c369867191aa0510508f49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I haven't seen any follow up ye= t and would like to progress this to IETF last call soon if possible.=C2=A0= My comments are mainly nits or requests to further clarify text, so hopefu= lly these will be easy to resolve before we get broader reviews on the draf= ts where these questions are likely to arise.

Than= k you,
Kathleen

On Wed, Feb 25, 2015 at 7:11 PM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hello,

I reviewed draft-ietf-radext-dynamic-discovery and found it to be ver= y well written, and covering security and privacy considerations nicely as = well.=C2=A0 Thank you for that.

I just have a few = nits and a question to see if some text can be further clarified before pro= gressing this to last call.=C2=A0 I'd like to start IETF last call very= soon if the WG is ok with that. =C2=A0

Nits &= comments:

Please expand out names of DNS labels on fir= st use (NAPTR, SRV, RR, etc.).=C2=A0 They are obvious to most of us, but ar= e not in the list of acronyms that don't have to be spelled out,
https://www.rfc-editor.org/rfc-style-guide/abbrev.expansio= n.txt
(If there is a *, RFC editor is okay with not expanding= )

Section 3.4.3
In the algorithm, I am c= onfused by step 12 that simply says "Proceed with step 18." =C2= =A0Are there conditions that would have you decide to skip steps 13-17 or i= s this meant to be interpreted as proceed with step 18, then go back to ste= p 13?=C2=A0 The example later shows that you skip 13-17, but why this happe= ns isn't clear to me.=C2=A0 Did I miss an explanation?=C2=A0
=
Section 3.4.4
First paragraph: The second sentence= is super long and the last one is also a bit too long, can something be do= ne to make these sentences easier to read?

Section= 3.4.5
Second to last sentence, just a nit:
s/control/c= ontrols/
The algorithm there=
fore control execution time with
   TIMER.

Section 3.4.6
There are some f= ormatting issues at the start of this section, you are probably aware of al= ready.

Thank you.
--

Best regards,
Kathleen



--

Best regards,
Kath= leen
--001a11c369867191aa0510508f49-- From nobody Fri Mar 6 00:32:08 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69D5E1ACD2D; Fri, 6 Mar 2015 00:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDnqm8xyOh3h; Fri, 6 Mar 2015 00:32:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5238D1A005B; Fri, 6 Mar 2015 00:32:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306083205.28368.5424.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 00:32:05 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-dynamic-discovery-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 08:32:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS Authors : Stefan Winter Mike McCauley Filename : draft-ietf-radext-dynamic-discovery-13.txt Pages : 31 Date : 2015-03-06 Abstract: This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dynamic-discovery-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 6 00:32:11 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA61A903A; Fri, 6 Mar 2015 00:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah0IMB0_5zxA; Fri, 6 Mar 2015 00:32:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6C81A9149; Fri, 6 Mar 2015 00:32:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306083205.28368.83257.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 00:32:05 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-dynamic-discovery-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 08:32:07 -0000 A new version (-13) has been submitted for draft-ietf-radext-dynamic-discovery: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dynamic-discovery-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Mar 6 00:32:13 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B403C1A005B; Fri, 6 Mar 2015 00:32:07 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AA61A903A; Fri, 6 Mar 2015 00:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ah0IMB0_5zxA; Fri, 6 Mar 2015 00:32:06 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6C81A9149; Fri, 6 Mar 2015 00:32:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306083205.28368.83257.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 00:32:05 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-dynamic-discovery-13.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 08:32:07 -0000 A new version (-13) has been submitted for draft-ietf-radext-dynamic-discovery: http://www.ietf.org/internet-drafts/draft-ietf-radext-dynamic-discovery-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-dynamic-discovery-13 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Mar 6 00:35:35 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8B71ACD2B for ; Fri, 6 Mar 2015 00:35:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1-v2cQozPRS for ; Fri, 6 Mar 2015 00:35:32 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 734241A9149 for ; Fri, 6 Mar 2015 00:35:32 -0800 (PST) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id D02C243978 for ; Fri, 6 Mar 2015 09:35:30 +0100 (CET) Message-ID: <54F966D2.9020101@restena.lu> Date: Fri, 06 Mar 2015 09:35:30 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="iOwUcacIniMjvm44NSniChlJSEu4FUOkK" Archived-At: Subject: Re: [radext] AD review of draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 08:35:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --iOwUcacIniMjvm44NSniChlJSEu4FUOkK Content-Type: multipart/mixed; boundary="------------010107020002080102070909" This is a multi-part message in MIME format. --------------010107020002080102070909 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Kathleen, sorry for the late response. > I reviewed draft-ietf-radext-dynamic-discovery and found it to be very > well written, and covering security and privacy considerations nicely a= s > well. Thank you for that. >=20 > I just have a few nits and a question to see if some text can be furthe= r > clarified before progressing this to last call. I'd like to start IETF= > last call very soon if the WG is ok with that. =20 >=20 > Nits & comments: >=20 > Please expand out names of DNS labels on first use (NAPTR, SRV, RR, > etc.). They are obvious to most of us, but are not in the list of > acronyms that don't have to be spelled out, > https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > (If there is a *, RFC editor is okay with not expanding) Done for -13. > Section 3.4.3 > In the algorithm, I am confused by step 12 that simply says "Proceed > with step 18." Are there conditions that would have you decide to skip= > steps 13-17 or is this meant to be interpreted as proceed with step 18,= > then go back to step 13? The example later shows that you skip 13-17, > but why this happens isn't clear to me. Did I miss an explanation?=20 The algorithm contains one big if-then-else, but the steps are listed in sequence. Step 8 either continues at 9 or at 13. If it did continue at 9, it advances to 12 and then the code path beginning at step 13 is skipped. Both variants converge at step 18 (that's why 12 sends you to 18= ). > Section 3.4.4 > First paragraph: The second sentence is super long and the last one is > also a bit too long, can something be done to make these sentences > easier to read? I've split all those sentences for -13. > Section 3.4.5 > Second to last sentence, just a nit: > s/control/controls/ > > The algorithm therefore control execution time with > TIMER. Fixed, thanks. > Section 3.4.6 > There are some formatting issues at the start of this section, you are > probably aware of already. Yes... something I'd prefer the RFC editor to take on at some point. The line breaks are ugly, but I don't know how to nicely fix them. I've just issued rev -13 with all the above-mentioned changes. Please consult the diff at https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-rade= xt-dynamic-discovery-13.txt and let me know if you are satisfied. Since the draft has now completed your AD review and also an early secdir review (Brian Weis), I believe the draft is now ready for IETF LC.= Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------010107020002080102070909 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------010107020002080102070909-- --iOwUcacIniMjvm44NSniChlJSEu4FUOkK 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 iQIcBAEBCgAGBQJU+WbSAAoJEMDeajWKOdxmDXYP/iiWpI8DksXN4Noh1drgWvmC wzyYBPglPf5GwxMkk7SpS56I3U6fVw+VQI/7uTplD3cIkUnIJWeCieT9TMVQZ/QE +KFpNOv4Bnw/ANAWIIsEwJTYhso3GXQ4WmA7bdWP6qCpOSXLoLhT7011MPaTx2Eo +mqG2HBX77owGc1LtchHtdqx0Gb0qZF5BGzDHCWGdasAUHuPXmj7puo/8qHG6ceN d5E9rAw7+Yx15HdASAVFmC2D0ntfcSXBmN6Jue20zxCgFhKILOou5qoGL721Vjkr zBfdRmw8tZSbgAXd6Y7bkb1ECrt5pWz/FxcAc1jVBoHeaM2nn4ZiKnwSR+RM4P/9 yrMDXdCjkVX+bnaOlE282NwOJO4Rm8vFalE7/m1XZhcqKIWpEh+Xq6sAGByKqapK ZnV8LYA8aU3F+nbyWLdrCwlASMxG3rNyvDPv0/gX5YmeZyw1K7JsyPkC1cgS2LKQ BfncauX6jnYR/+WluQiaPckvlv9wUI19QuTWgnZnLcXdh2GqTaMQOCDPi9CZK7pm EBCeXeJemuCI8e/IUAatvpqv3FU4Iz8GsMihfOCbgT7vrQvhsIkICwGPqKYHkYK6 N0ppW+B2Y4ON4WgDSmxMkQAEs6ykLoOA4hf0FFdGA1cpbq74rAAH07L3tIrayzP4 P0Zpx5zrie1J4JuDuBW3 =OzV1 -----END PGP SIGNATURE----- --iOwUcacIniMjvm44NSniChlJSEu4FUOkK-- From nobody Fri Mar 6 03:51:40 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378771ACD9A for ; Fri, 6 Mar 2015 03:51:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUy40XbDs7mP for ; Fri, 6 Mar 2015 03:51:36 -0800 (PST) Received: from mail-qg0-x22b.google.com (mail-qg0-x22b.google.com [IPv6:2607:f8b0:400d:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 989AA1ACD9B for ; Fri, 6 Mar 2015 03:51:36 -0800 (PST) Received: by qgdz60 with SMTP id z60so11849831qgd.5 for ; Fri, 06 Mar 2015 03:51:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0gZcwEmOFC4ZGAnVFuiTbIst4Mf52BeDBR/LKfcW4bw=; b=VJZ0W2dXgjvWfgbkAA2ki7GWTAheS4hdxAufKzXALC6u/eYk7nRUXhHOQVj2fecp8q FB/adMbuTdhJu22R5MyVBCWqZPjzvE93aPJpamthM1O0QEpFJApIKoprLhM8qI9ox67z K8cjvzD929djd87FTyh35X5vKGfHVjXa9LmrmY80pj7oly+vDK4NHiNxzU3ncSWytcDM xpdgoClZ4XDClNp7hx7tnwreEALi81QiT0TYclHygwkN0eA6S+PZcgd4NJwOKII+Rhpn zi7tRlL68fg+aII9j4mRVagdCumAR3OhHl8u93d6Hh6tCu9DpyJ80pudM80SpRP71oqr y7hg== X-Received: by 10.140.108.116 with SMTP id i107mr17733459qgf.73.1425642695841; Fri, 06 Mar 2015 03:51:35 -0800 (PST) Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id 103sm4437449qkz.24.2015.03.06.03.51.34 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 03:51:34 -0800 (PST) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <54F966D2.9020101@restena.lu> Date: Fri, 6 Mar 2015 06:51:33 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54F966D2.9020101@restena.lu> To: Stefan Winter Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD review of draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 11:51:39 -0000 Hi, Sent from my iPhone > On Mar 6, 2015, at 3:35 AM, Stefan Winter wrote= : >=20 > Kathleen, >=20 > sorry for the late response. >=20 >> I reviewed draft-ietf-radext-dynamic-discovery and found it to be very >> well written, and covering security and privacy considerations nicely as >> well. Thank you for that. >>=20 >> I just have a few nits and a question to see if some text can be further >> clarified before progressing this to last call. I'd like to start IETF >> last call very soon if the WG is ok with that. =20 >>=20 >> Nits & comments: >>=20 >> Please expand out names of DNS labels on first use (NAPTR, SRV, RR, >> etc.). They are obvious to most of us, but are not in the list of >> acronyms that don't have to be spelled out, >> https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt >> (If there is a *, RFC editor is okay with not expanding) >=20 > Done for -13. >=20 >> Section 3.4.3 >> In the algorithm, I am confused by step 12 that simply says "Proceed >> with step 18." Are there conditions that would have you decide to skip >> steps 13-17 or is this meant to be interpreted as proceed with step 18, >> then go back to step 13? The example later shows that you skip 13-17, >> but why this happens isn't clear to me. Did I miss an explanation? >=20 > The algorithm contains one big if-then-else, but the steps are listed in > sequence. Step 8 either continues at 9 or at 13. If it did continue at > 9, it advances to 12 and then the code path beginning at step 13 is > skipped. Both variants converge at step 18 (that's why 12 sends you to 18)= . >=20 >> Section 3.4.4 >> First paragraph: The second sentence is super long and the last one is >> also a bit too long, can something be done to make these sentences >> easier to read? >=20 > I've split all those sentences for -13. >=20 >> Section 3.4.5 >> Second to last sentence, just a nit: >> s/control/controls/ >>=20 >> The algorithm therefore control execution time with >> TIMER. >=20 > Fixed, thanks. >=20 >> Section 3.4.6 >> There are some formatting issues at the start of this section, you are >> probably aware of already. >=20 > Yes... something I'd prefer the RFC editor to take on at some point. The > line breaks are ugly, but I don't know how to nicely fix them. >=20 > I've just issued rev -13 with all the above-mentioned changes. Please > consult the diff at >=20 > https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-radex= t-dynamic-discovery-13.txt >=20 > and let me know if you are satisfied. >=20 > Since the draft has now completed your AD review and also an early > secdir review (Brian Weis), I believe the draft is now ready for IETF LC. Excellent, thank you. Does the shepherd report require updating? If not, I= 'll request last call later today. Best regards, Kathleen >=20 > Greetings, >=20 > Stefan Winter >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education N= ationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > recipient's key is known to me >=20 > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 > <0x8A39DC66.asc> > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Fri Mar 6 09:50:50 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30BA91A1AB6 for ; Fri, 6 Mar 2015 09:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qEWccblSvwCy for ; Fri, 6 Mar 2015 09:50:45 -0800 (PST) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C9181A1A97 for ; Fri, 6 Mar 2015 09:50:44 -0800 (PST) Received: by labhs14 with SMTP id hs14so59124236lab.1 for ; Fri, 06 Mar 2015 09:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=41fmTc2XzB94lvcwuXLDfDAhGdP4CSNCkYJY7MBQAdk=; b=FCKJx4GmIWvtO5wBawCffi3HbLiftYHd48YlH500zsC8oVA9DEFhWaPonMkTM7BTUp V7AiqA5Z9WV82g3uweaTyZVZjdbbibPDOwffj1YpBEcnGbnEXHRMr/rFmaM//ypTGg50 e5e2gNRzkfHecZXA/t5M3Mxg9hHp3dLISP7uQRP3Q7TIZiIlCusRrbTeaqLotohJVDxb E2tV6quKt76E5Q+Rj8XsFItEgHE0vl0hPKhZKFE0vKUAd/jmEWyQYO+prOML3v4CBMul RJyxqnszxiExiqSDb+xpuuWSQ8n9dx2ojgC7JoYWFnchb9hO3Fbb23ufdcGHt/O/pja6 6L/A== MIME-Version: 1.0 X-Received: by 10.152.178.197 with SMTP id da5mr14431021lac.56.1425664242782; Fri, 06 Mar 2015 09:50:42 -0800 (PST) Received: by 10.112.167.101 with HTTP; Fri, 6 Mar 2015 09:50:42 -0800 (PST) In-Reply-To: References: <54F966D2.9020101@restena.lu> Date: Fri, 6 Mar 2015 12:50:42 -0500 Message-ID: From: Kathleen Moriarty To: Stefan Winter , Jouni Korhonen Content-Type: multipart/alternative; boundary=001a11340c68c298a00510a2528c Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] AD review of draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:50:49 -0000 --001a11340c68c298a00510a2528c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello Journi, Could you please update the shepherd report? Benoit is listed as the AD and that may be the only update needed, but a quick check would be good before I pull the trigger for last call. I'll look at this again later in the day in case I can request it today. Thanks, Kathleen On Fri, Mar 6, 2015 at 6:51 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hi, > > Sent from my iPhone > > > On Mar 6, 2015, at 3:35 AM, Stefan Winter > wrote: > > > > Kathleen, > > > > sorry for the late response. > > > >> I reviewed draft-ietf-radext-dynamic-discovery and found it to be very > >> well written, and covering security and privacy considerations nicely = as > >> well. Thank you for that. > >> > >> I just have a few nits and a question to see if some text can be furth= er > >> clarified before progressing this to last call. I'd like to start IET= F > >> last call very soon if the WG is ok with that. > >> > >> Nits & comments: > >> > >> Please expand out names of DNS labels on first use (NAPTR, SRV, RR, > >> etc.). They are obvious to most of us, but are not in the list of > >> acronyms that don't have to be spelled out, > >> https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > >> (If there is a *, RFC editor is okay with not expanding) > > > > Done for -13. > > > >> Section 3.4.3 > >> In the algorithm, I am confused by step 12 that simply says "Proceed > >> with step 18." Are there conditions that would have you decide to ski= p > >> steps 13-17 or is this meant to be interpreted as proceed with step 18= , > >> then go back to step 13? The example later shows that you skip 13-17, > >> but why this happens isn't clear to me. Did I miss an explanation? > > > > The algorithm contains one big if-then-else, but the steps are listed i= n > > sequence. Step 8 either continues at 9 or at 13. If it did continue at > > 9, it advances to 12 and then the code path beginning at step 13 is > > skipped. Both variants converge at step 18 (that's why 12 sends you to > 18). > > > >> Section 3.4.4 > >> First paragraph: The second sentence is super long and the last one is > >> also a bit too long, can something be done to make these sentences > >> easier to read? > > > > I've split all those sentences for -13. > > > >> Section 3.4.5 > >> Second to last sentence, just a nit: > >> s/control/controls/ > >> > >> The algorithm therefore control execution time with > >> TIMER. > > > > Fixed, thanks. > > > >> Section 3.4.6 > >> There are some formatting issues at the start of this section, you are > >> probably aware of already. > > > > Yes... something I'd prefer the RFC editor to take on at some point. Th= e > > line breaks are ugly, but I don't know how to nicely fix them. > > > > I've just issued rev -13 with all the above-mentioned changes. Please > > consult the diff at > > > > > https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-rade= xt-dynamic-discovery-13.txt > > > > and let me know if you are satisfied. > > > > Since the draft has now completed your AD review and also an early > > secdir review (Brian Weis), I believe the draft is now ready for IETF L= C. > > Excellent, thank you. Does the shepherd report require updating? If not= , > I'll request last call later today. > > Best regards, > Kathleen > > > > > Greetings, > > > > Stefan Winter > > > > -- > > Stefan WINTER > > Ingenieur de Recherche > > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educati= on Nationale et > > de la Recherche > > 6, rue Richard Coudenhove-Kalergi > > L-1359 Luxembourg > > > > Tel: +352 424409 1 > > Fax: +352 422473 > > > > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the > > recipient's key is known to me > > > > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC6= 6 > > <0x8A39DC66.asc> > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > --=20 Best regards, Kathleen --001a11340c68c298a00510a2528c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello Journi,

Could you please update t= he shepherd report?=C2=A0 Benoit is listed as the AD and that may be the on= ly update needed, but a quick check would be good before I pull the trigger= for last call.=C2=A0 I'll look at this again later in the day in case = I can request it today.

Thanks,
Kathleen=

On Fr= i, Mar 6, 2015 at 6:51 AM, Kathleen Moriarty <kathleen.mor= iarty.ietf@gmail.com> wrote:

> On Mar 6, 2015, at 3:35 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
>
> Kathleen,
>
> sorry for the late response.
>
>> I reviewed draft-ietf-radext-dynamic-discovery and found it to be = very
>> well written, and covering security and privacy considerations nic= ely as
>> well.=C2=A0 Thank you for that.
>>
>> I just have a few nits and a question to see if some text can be f= urther
>> clarified before progressing this to last call.=C2=A0 I'd like= to start IETF
>> last call very soon if the WG is ok with that.
>>
>> Nits & comments:
>>
>> Please expand out names of DNS labels on first use (NAPTR, SRV, RR= ,
>> etc.).=C2=A0 They are obvious to most of us, but are not in the li= st of
>> acronyms that don't have to be spelled out,
>> https://www.rfc-editor.org/rfc-style-guide/abbr= ev.expansion.txt
>> (If there is a *, RFC editor is okay with not expanding)
>
> Done for -13.
>
>> Section 3.4.3
>> In the algorithm, I am confused by step 12 that simply says "= Proceed
>> with step 18."=C2=A0 Are there conditions that would have you= decide to skip
>> steps 13-17 or is this meant to be interpreted as proceed with ste= p 18,
>> then go back to step 13?=C2=A0 The example later shows that you sk= ip 13-17,
>> but why this happens isn't clear to me.=C2=A0 Did I miss an ex= planation?
>
> The algorithm contains one big if-then-else, but the steps are listed = in
> sequence. Step 8 either continues at 9 or at 13. If it did continue at=
> 9, it advances to 12 and then the code path beginning at step 13 is > skipped. Both variants converge at step 18 (that's why 12 sends yo= u to 18).
>
>> Section 3.4.4
>> First paragraph: The second sentence is super long and the last on= e is
>> also a bit too long, can something be done to make these sentences=
>> easier to read?
>
> I've split all those sentences for -13.
>
>> Section 3.4.5
>> Second to last sentence, just a nit:
>> s/control/controls/
>>
>> The algorithm therefore control execution time with
>>=C2=A0 =C2=A0TIMER.
>
> Fixed, thanks.
>
>> Section 3.4.6
>> There are some formatting issues at the start of this section, you= are
>> probably aware of already.
>
> Yes... something I'd prefer the RFC editor to take on at some poin= t. The
> line breaks are ugly, but I don't know how to nicely fix them.
>
> I've just issued rev -13 with all the above-mentioned changes. Ple= ase
> consult the diff at
>
> https://to= ols.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-radext-dynam= ic-discovery-13.txt
>
> and let me know if you are satisfied.
>
> Since the draft has now completed your AD review and also an early
> secdir review (Brian Weis), I believe the draft is now ready for IETF = LC.

Excellent, thank you.=C2=A0 Does the shepherd report require up= dating?=C2=A0 If not, I'll request last call later today.

Best regards,
Kathleen

>
> Greetings,
>
> Stefan Winter
>
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Ed= ucation Nationale et
> de la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>
> Tel: +352 42= 4409 1
> Fax: +352 422473<= /a>
>
> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
> recipient's key is known to me
>
> http://pgp.mit.edu:11371/pks/lookup?op= =3Dget&search=3D0xC0DE6A358A39DC66
> <0x8A39DC66.asc>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext



--

Best regards,
Kath= leen
--001a11340c68c298a00510a2528c-- From nobody Fri Mar 6 09:53:39 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 027A51A1A97 for ; Fri, 6 Mar 2015 09:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNxvrfm-ihVR for ; Fri, 6 Mar 2015 09:53:35 -0800 (PST) Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410EC1A0137 for ; Fri, 6 Mar 2015 09:53:35 -0800 (PST) Received: by padet14 with SMTP id et14so56703444pad.0 for ; Fri, 06 Mar 2015 09:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xVJYnedezfc7VUWrbzz5mqk/k7nJxx3otSlqCWCNJBU=; b=cGIRDMkphdW5J5hCZjnFo6Vn0FeFr9b1eatvHa++0BVOr1J563dh1uNRiOmeHyYiX/ zRwOAN1/AG6B3K0UjNUyKtZn95hF7NRC7BF4W2OscbuQtmSTzIVgXt2KAeGCPbndSIzM YhqfJj5EWxFJAfZE4C2CAEG6/pE9VjqT+pS/W6UaeRdICVpRRjfqBt0FxE5N17zxqYrr Nlokr0L1ykyYXpEdoN0NC76+lMWymdjZu18VKQccI8mwCWopotth9wEYDR0m+qeL9Gyy O6HWrXqdcKpaVlycSW3j3WGO04qRiFIrcSMdK60ULUGTV9N6vAJt1u9y6tMuiG9mQAM7 fVvw== X-Received: by 10.69.12.234 with SMTP id et10mr27743536pbd.65.1425664414827; Fri, 06 Mar 2015 09:53:34 -0800 (PST) Received: from [10.180.201.184] ([166.177.250.59]) by mx.google.com with ESMTPSA id i5sm10155086pat.42.2015.03.06.09.53.32 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Mar 2015 09:53:33 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-8F636C1F-8E14-4107-9AC9-71E96BB22CEC Mime-Version: 1.0 (1.0) From: "Jouni.nosmap" X-Mailer: iPhone Mail (12B466) In-Reply-To: Date: Fri, 6 Mar 2015 09:53:29 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <54F966D2.9020101@restena.lu> To: Kathleen Moriarty Archived-At: Cc: Stefan Winter , "radext@ietf.org" Subject: Re: [radext] AD review of draft-ietf-radext-dynamic-discovery X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 17:53:38 -0000 --Apple-Mail-8F636C1F-8E14-4107-9AC9-71E96BB22CEC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Will do.=20 - jouni Sent from a smart phone.. Mind the typos.. > Kathleen Moriarty kirjoitti 6.3.2015 ke= llo 9.50: >=20 > Hello Journi, >=20 > Could you please update the shepherd report? Benoit is listed as the AD a= nd that may be the only update needed, but a quick check would be good befor= e I pull the trigger for last call. I'll look at this again later in the da= y in case I can request it today. >=20 > Thanks, > Kathleen >=20 >> On Fri, Mar 6, 2015 at 6:51 AM, Kathleen Moriarty wrote: >> Hi, >>=20 >> Sent from my iPhone >>=20 >> > On Mar 6, 2015, at 3:35 AM, Stefan Winter wr= ote: >> > >> > Kathleen, >> > >> > sorry for the late response. >> > >> >> I reviewed draft-ietf-radext-dynamic-discovery and found it to be very= >> >> well written, and covering security and privacy considerations nicely a= s >> >> well. Thank you for that. >> >> >> >> I just have a few nits and a question to see if some text can be furth= er >> >> clarified before progressing this to last call. I'd like to start IET= F >> >> last call very soon if the WG is ok with that. >> >> >> >> Nits & comments: >> >> >> >> Please expand out names of DNS labels on first use (NAPTR, SRV, RR, >> >> etc.). They are obvious to most of us, but are not in the list of >> >> acronyms that don't have to be spelled out, >> >> https://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt >> >> (If there is a *, RFC editor is okay with not expanding) >> > >> > Done for -13. >> > >> >> Section 3.4.3 >> >> In the algorithm, I am confused by step 12 that simply says "Proceed >> >> with step 18." Are there conditions that would have you decide to ski= p >> >> steps 13-17 or is this meant to be interpreted as proceed with step 18= , >> >> then go back to step 13? The example later shows that you skip 13-17,= >> >> but why this happens isn't clear to me. Did I miss an explanation? >> > >> > The algorithm contains one big if-then-else, but the steps are listed i= n >> > sequence. Step 8 either continues at 9 or at 13. If it did continue at >> > 9, it advances to 12 and then the code path beginning at step 13 is >> > skipped. Both variants converge at step 18 (that's why 12 sends you to 1= 8). >> > >> >> Section 3.4.4 >> >> First paragraph: The second sentence is super long and the last one is= >> >> also a bit too long, can something be done to make these sentences >> >> easier to read? >> > >> > I've split all those sentences for -13. >> > >> >> Section 3.4.5 >> >> Second to last sentence, just a nit: >> >> s/control/controls/ >> >> >> >> The algorithm therefore control execution time with >> >> TIMER. >> > >> > Fixed, thanks. >> > >> >> Section 3.4.6 >> >> There are some formatting issues at the start of this section, you are= >> >> probably aware of already. >> > >> > Yes... something I'd prefer the RFC editor to take on at some point. Th= e >> > line breaks are ugly, but I don't know how to nicely fix them. >> > >> > I've just issued rev -13 with all the above-mentioned changes. Please >> > consult the diff at >> > >> > https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-ra= dext-dynamic-discovery-13.txt >> > >> > and let me know if you are satisfied. >> > >> > Since the draft has now completed your AD review and also an early >> > secdir review (Brian Weis), I believe the draft is now ready for IETF L= C. >>=20 >> Excellent, thank you. Does the shepherd report require updating? If not= , I'll request last call later today. >>=20 >> Best regards, >> Kathleen >>=20 >> > >> > Greetings, >> > >> > Stefan Winter >> > >> > -- >> > Stefan WINTER >> > Ingenieur de Recherche >> > Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educati= on Nationale et >> > de la Recherche >> > 6, rue Richard Coudenhove-Kalergi >> > L-1359 Luxembourg >> > >> > Tel: +352 424409 1 >> > Fax: +352 422473 >> > >> > PGP key updated to 4096 Bit RSA - I will encrypt all mails if the >> > recipient's key is known to me >> > >> > http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC6= 6 >> > <0x8A39DC66.asc> >> > _______________________________________________ >> > radext mailing list >> > radext@ietf.org >> > https://www.ietf.org/mailman/listinfo/radext >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen --Apple-Mail-8F636C1F-8E14-4107-9AC9-71E96BB22CEC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Will do. 

- jouni

Sent from a smart phone.. Mind the typos..

Ka= thleen Moriarty <kath= leen.moriarty.ietf@gmail.com> kirjoitti 6.3.2015 kello 9.50:

<= /div>
Hello Journi,

<= /div>
Could you please update the shepherd report?  Benoit is liste= d as the AD and that may be the only update needed, but a quick check would b= e good before I pull the trigger for last call.  I'll look at this agai= n later in the day in case I can request it today.

= Thanks,
Kathleen

On Fri, Mar 6, 2015 at 6:51 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
Hi,

Sent from my iPhone

> On Mar 6, 2015, at 3:35 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
>
> Kathleen,
>
> sorry for the late response.
>
>> I reviewed draft-ietf-radext-dynamic-discovery and found it to be v= ery
>> well written, and covering security and privacy considerations nice= ly as
>> well.  Thank you for that.
>>
>> I just have a few nits and a question to see if some text can be fu= rther
>> clarified before progressing this to last call.  I'd like to s= tart IETF
>> last call very soon if the WG is ok with that.
>>
>> Nits & comments:
>>
>> Please expand out names of DNS labels on first use (NAPTR, SRV, RR,=
>> etc.).  They are obvious to most of us, but are not in the lis= t of
>> acronyms that don't have to be spelled out,
>> https://www.rfc-editor.org/rfc-style-guide/abbrev= .expansion.txt
>> (If there is a *, RFC editor is okay with not expanding)
>
> Done for -13.
>
>> Section 3.4.3
>> In the algorithm, I am confused by step 12 that simply says "Procee= d
>> with step 18."  Are there conditions that would have you decid= e to skip
>> steps 13-17 or is this meant to be interpreted as proceed with step= 18,
>> then go back to step 13?  The example later shows that you ski= p 13-17,
>> but why this happens isn't clear to me.  Did I miss an explana= tion?
>
> The algorithm contains one big if-then-else, but the steps are listed i= n
> sequence. Step 8 either continues at 9 or at 13. If it did continue at<= br> > 9, it advances to 12 and then the code path beginning at step 13 is
= > skipped. Both variants converge at step 18 (that's why 12 sends you to 1= 8).
>
>> Section 3.4.4
>> First paragraph: The second sentence is super long and the last one= is
>> also a bit too long, can something be done to make these sentences<= br> >> easier to read?
>
> I've split all those sentences for -13.
>
>> Section 3.4.5
>> Second to last sentence, just a nit:
>> s/control/controls/
>>
>> The algorithm therefore control execution time with
>>   TIMER.
>
> Fixed, thanks.
>
>> Section 3.4.6
>> There are some formatting issues at the start of this section, you a= re
>> probably aware of already.
>
> Yes... something I'd prefer the RFC editor to take on at some point. Th= e
> line breaks are ugly, but I don't know how to nicely fix them.
>
> I've just issued rev -13 with all the above-mentioned changes. Please > consult the diff at
>
> https://tools.= ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-radext-dynamic-di= scovery-13.txt
>
> and let me know if you are satisfied.
>
> Since the draft has now completed your AD review and also an early
> secdir review (Brian Weis), I believe the draft is now ready for IETF L= C.

Excellent, thank you.  Does the shepherd report require upd= ating?  If not, I'll request last call later today.

Best regards,
Kathleen

>
> Greetings,
>
> Stefan Winter
>
> --
> Stefan WINTER
> Ingenieur de Recherche
> Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Educati= on Nationale et
> de la Recherche
> 6, rue Richard Coudenhove-Kalergi
> L-1359 Luxembourg
>
> Tel: +352 424= 409 1
> Fax: +352 422473
>
> PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
> recipient's key is known to me
>
> http://pgp.mit.edu:11371/pks/lookup?op=3D= get&search=3D0xC0DE6A358A39DC66
> <0x8A39DC66.asc>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.ietf.org/mailman/listinfo/radext



--

Best regards,
Kathleen=
= --Apple-Mail-8F636C1F-8E14-4107-9AC9-71E96BB22CEC-- From nobody Fri Mar 6 11:52:20 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F387D1A6FF2 for ; Fri, 6 Mar 2015 11:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XwflBzWEtM5E for ; Fri, 6 Mar 2015 11:52:12 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659151A1EE8 for ; Fri, 6 Mar 2015 11:52:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C41E520652; Fri, 6 Mar 2015 14:50:44 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4oKojfPTfSg; Fri, 6 Mar 2015 14:50:44 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 6 Mar 2015 14:50:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 81EC982834; Fri, 6 Mar 2015 14:51:36 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <54EF26A3.6040502@um.es> Date: Fri, 06 Mar 2015 14:51:36 -0500 In-Reply-To: <54EF26A3.6040502@um.es> (Alejandro Perez Mendez's message of "Thu, 26 Feb 2015 14:58:59 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Review of draft-ietf-radext-bigger-packets-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:52:19 -0000 Hi. I'm about to upload a new version that includes all your fixes except: 2. Abstract and Introduction. I'm not convinced that the reason of having new use cases where more than 4096 bytes are required in RADIUS is motivated only by RFC6614. Other security mechanisms such as IPsec or a trusted network would be enough to motivate use cases such as those described in ABFAB and/or in the aaa-saml draft. In our RADIUS fragmentation draft we mention ABFAB as the motivation. We're not in agreement on this change. >From my standpoint RADIUS made sense for ABFAb because of RADSEC. IPsec is really hard to use for this sort of security and I don't believe in trusted networks:-) I'd appreciate additional comments from the WG on this issue. I appreciate your detailed review and thanks for all the great help. I think I've resolved the other points; several important catches in your comments. --Sam From nobody Fri Mar 6 11:57:29 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BDC1A7000; Fri, 6 Mar 2015 11:57:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UpKWDVVH7faJ; Fri, 6 Mar 2015 11:57:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E48F1A1BDA; Fri, 6 Mar 2015 11:57:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306195724.7315.17385.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 11:57:24 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] I-D Action: draft-ietf-radext-bigger-packets-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:57:26 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the RADIUS EXTensions Working Group of the IETF. Title : Larger Packets for RADIUS over TCP Author : Sam Hartman Filename : draft-ietf-radext-bigger-packets-03.txt Pages : 9 Date : 2015-03-06 Abstract: The RADIUS over TLS experiment described in RFC 6614 has opened RADIUS to new use cases where the 4096-octet maximum RADIUS packet proves problematic. This specification extends the RADIUS over TCP experiment (RFC 6113) to permit larger RADIUS packets. This specification compliments other ongoing work to permit fragmentation of RADIUS authorization information. This document registers a new RADIUS code, an action which requires IESG approval. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-radext-bigger-packets-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Mar 6 11:57:30 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DE11A7000; Fri, 6 Mar 2015 11:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDRQnt2OKu32; Fri, 6 Mar 2015 11:57:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B33231A6FF1; Fri, 6 Mar 2015 11:57:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306195724.7315.9459.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 11:57:24 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-bigger-packets-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:57:27 -0000 A new version (-03) has been submitted for draft-ietf-radext-bigger-packets: http://www.ietf.org/internet-drafts/draft-ietf-radext-bigger-packets-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Mar 6 11:57:31 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-bigger-packets.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 196001A7002; Fri, 6 Mar 2015 11:57:27 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-bigger-packets.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-bigger-packets.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00DE11A7000; Fri, 6 Mar 2015 11:57:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDRQnt2OKu32; Fri, 6 Mar 2015 11:57:25 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B33231A6FF1; Fri, 6 Mar 2015 11:57:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306195724.7315.9459.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 11:57:24 -0800 Archived-At: Subject: [radext] New Version Notification - draft-ietf-radext-bigger-packets-03.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 19:57:27 -0000 A new version (-03) has been submitted for draft-ietf-radext-bigger-packets: http://www.ietf.org/internet-drafts/draft-ietf-radext-bigger-packets-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-radext-bigger-packets/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-radext-bigger-packets-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. From nobody Fri Mar 6 15:12:20 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B491A870D; Fri, 6 Mar 2015 15:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5TW4dS83xgA; Fri, 6 Mar 2015 15:12:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2C41A1B24; Fri, 6 Mar 2015 15:12:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306231217.23734.30320.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 15:12:17 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 23:12:18 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Fri Mar 6 15:12:21 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8F69F1A8730; Fri, 6 Mar 2015 15:12:18 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B491A870D; Fri, 6 Mar 2015 15:12:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5TW4dS83xgA; Fri, 6 Mar 2015 15:12:17 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C2C41A1B24; Fri, 6 Mar 2015 15:12:17 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150306231217.23734.30320.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 15:12:17 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Mar 2015 23:12:18 -0000 IESG state changed to Last Call Requested from AD Evaluation ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Fri Mar 6 16:24:50 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F621A8776; Fri, 6 Mar 2015 16:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NT2y9F49xKIr; Fri, 6 Mar 2015 16:24:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C591A86EA; Fri, 6 Mar 2015 16:24:47 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <20150307002447.20539.50382.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:24:47 -0800 Archived-At: Cc: radext@ietf.org Subject: [radext] Last Call: (NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 00:24:49 -0000 The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2015-03-20. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS/TLS and RADIUS/DTLS. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Mar 6 16:24:58 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275801A8778; Fri, 6 Mar 2015 16:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLSzFNkIGTHk; Fri, 6 Mar 2015 16:24:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFFD1A8770; Fri, 6 Mar 2015 16:24:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307002448.20539.40229.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:24:48 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 00:24:51 -0000 Last call has been made for draft-ietf-radext-dynamic-discovery and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Fri Mar 6 16:25:05 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 57C251A8770; Fri, 6 Mar 2015 16:24:51 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 275801A8778; Fri, 6 Mar 2015 16:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLSzFNkIGTHk; Fri, 6 Mar 2015 16:24:50 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFFD1A8770; Fri, 6 Mar 2015 16:24:48 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.0.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150307002448.20539.40229.idtracker@ietfa.amsl.com> Date: Fri, 06 Mar 2015 16:24:48 -0800 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 00:24:51 -0000 Last call has been made for draft-ietf-radext-dynamic-discovery and state has been changed to In Last Call ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Fri Mar 6 18:15:49 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 267B71A87A8; Fri, 6 Mar 2015 18:12:11 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013FC1A87A5 for ; Fri, 6 Mar 2015 18:12:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, WEIRD_PORT=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKFv9WyhtxPn for ; Fri, 6 Mar 2015 18:12:08 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4D181A879E for ; Fri, 6 Mar 2015 18:12:08 -0800 (PST) Received: from smtprelay.restena.lu ([2001:a18:1::62]:37108) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YU4Dm-0002aK-Vi for draft-ietf-radext-dynamic-discovery.all@tools.ietf.org; Fri, 06 Mar 2015 18:12:08 -0800 Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8AF0543978; Fri, 6 Mar 2015 09:35:39 +0100 (CET) Message-ID: <54F966DB.8000901@restena.lu> Date: Fri, 06 Mar 2015 09:35:39 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brian Weis , The IESG , secdir@ietf.org, draft-ietf-radext-dynamic-discovery.all@tools.ietf.org References: In-Reply-To: OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh" X-SA-Exim-Connect-IP: 2001:a18:1::62 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery.all@tools.ietf.org X-SA-Exim-Mail-From: stefan.winter@restena.lu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-radext-dynamic-discovery.all@ietf.org Resent-Message-Id: <20150307021208.D4D181A879E@ietfa.amsl.com> Resent-Date: Fri, 6 Mar 2015 18:12:08 -0800 (PST) Resent-From: stefan.winter@restena.lu Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 18:15:46 -0800 Subject: Re: [radext] Secdir review of draft-ietf-radext-dynamic-discovery-12 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 02:12:11 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh Content-Type: multipart/mixed; boundary="------------050904090102080003050004" This is a multi-part message in MIME format. --------------050904090102080003050004 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello all, sorry for taking so long :-( > This document specifies a means to find authoritative RADIUS servers fo= r a given realm. This can be useful when authenticating/authorizing devic= es within a roaming consortium (e.g., eduroam). An authoritative RADIUS c= lient trying to authenticate/authorize a host or perform accounting for t= hat host finds a RADIUS server by querying DNS for service records define= d in this document. Once a candidate sever has been found in DNS, the que= rier initiates a RADIUS protocol to it protected by TLS, authorizes it ba= sed on information in its certificate, and then RADIUS happens in the usu= al fashion. The document is almost ready for publication, in my opinion. >=20 > There=92s not much background given, and having an overview of the solu= tion architecture in the Introduction would be useful. I.e., a descriptio= n and picture showing the actors and the communication flows between them= =2E I don=92t have complete confidence that I correctly understood which= actors are involved in the RASIUS/TLS transaction -- in some sections it= seems that RADIUS clients are initiating requests and sometimes RADIUS s= ervers and I thought only clients contacted servers. An overview of the a= ctors would probably have clarified that. I have added two ASCII art descriptions: how static request routing works (in an example deployment which uses top-level domain endings to partition the realm space) and one where DNS replaces these static routing rules. I hope the art and accompanying text clarifies the documen= t. > If I understand correctly how roaming consortiums currently work today,= a RADIUS client within a consortium needing to make a AAA call to a RADI= US server in another realm does not contact the server directly. Instead,= it routes the request through a hierarchy of RADIUS servers following ro= ots of trust. The trust model in this document seems to be bypass the roo= ts of trust, where the client directly contacts the server. This seems to= be discussed in the Section 6 (Privacy Considerations) discussion of =93= clearinghouses", but if the trust model is changed, this is a bigger impa= ct than privacy so ought to be discussed explicitly someplace in the docu= ment. It doesn't bypass trust; it moves trust away from static IP adress and shared secrets to a trust based on PKIX and DNS. The roots of trust still exist, they are just not RADIUS servers any more, but CAs, and they do their work out-of-band (CA issuing/revoking certs instead of a RADIUS proxy inspecting each packet and making a packet-by-packet trust decision). In other words, the RADIUS client and RADIUS server remain the same actors and they maintain their same level of trust as before. The impact on privacy is the most outstanding one, and is extensively discussed in the document. There is indeed another aspect, and that is a technical one: the hierarchy/star topology of intermediate servers can do sanitisation of packets as they pass by (typically, removing, adding, or re-writing RADIUS attributes); when these intermediates are not in place any more, a RADIUS server needs to expect more diversified packets coming in and it may need to do some sanitisation itself. A sentence to that effect is in the draft, inside privacy considerations. Maybe that's not the best place, but I do think that this beyond-privacy aspect is touched upon. I'm speaking of this sentence= : "However, there exist reasons why clearinghouses might still be used. One reason to keep a clearinghouse is to act as a gateway for multiple backends in a company; another reason may be a requirement to sanitise RADIUS datagrams (filter attributes, tag requests with new attributes, ... )." > Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the p= oint that certificate based cipher suites need to be used because there w= on=92t be any pre-distributed secret key material available. That=92s goo= d advice. I think the section should also give advice on choosing trust r= oots. This is important because the identity of the server was gotten in = an untrusted manner (from unsecured DNS), and the certificate it presents= contains information used for authorization of a server (i.e., SubjectA= ltName). If a RADIUS client were to accept a certificate signed by a wide= range of trust roots (e.g, the set of roots used by browsers, where the = trustability of many CAs in the hierarchy is unknown) then the RADIUS cli= ent would be ill advised to trust authorization information claims in th= e hierarchy. On the other hand, if the trust roots were restricted to a s= et of highly trusted trust roots maintained by the consortium, then the a= uthorization information in the certificate would be t rustable. This should be explained. I have added new text (thanks Alan for the suggestion, I've reused a few sentences from the RADIUS/DTLS document), 2.1.1.3 now has a new last paragraph. > Section 2.2 defines the NAIRealm name as a form of otherName. This make= s sense. But there is also a paragraph discussing sRVName, which is confu= sing. I think it=92s clarifying who sRVName isn=92t applicable; it would = be good state that plainly at the beginning of the paragraph. I'm not sure I can follow you here... NAIRealm is used to verify after discovery that the target server is authorised to handle requests for the realm that was queried from DNS. The querying itself may use either NAPTR records (preferred) or SRV records (fallback). The paragraph which discusses sRVName only makes clear why verifying sRVName against an SRV doesn't buy you anything. If you find the paragraph regarding the uselessness of sRVName confusing, I can take it out, but since issue has repeatedly been asked during the lifetime of the draft, I think it is useful to keep this explanatory statement in. > Section 5 (first paragraph) makes the point that the information gotte= n from DNS can=92t be trusted. But I would suggest a slight rewording: s/= can not be trusted/is not sufficient to identify an authorized server/. I'd prefer to keep my wording, as these are two different things: With DNS (no SEC), the result O (=3DIP addresses and ports) are potentially bogus (i.e. possibly incorrect *and* the resulting TLS connection may be to an unauthorised peer). With DNSSEC, the result O is verifiably correct, but the resulting TLS connection may still be to an unauthorised server. Your rewording would suggest that DNS-no-SEC only has a shortcoming re authorisation, but it's more than that. I've just issued rev -13 with all the above-mentioned changes. Please consult the diff at https://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-rade= xt-dynamic-discovery-13.txt and let me know if you are satisfied. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------050904090102080003050004 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------050904090102080003050004-- --1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh 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 iQIcBAEBCgAGBQJU+WbbAAoJEMDeajWKOdxmgpMQAMOdgXlqzSo1NmdZefQCEhKG qmkF8aCFAZ7U+BOIAwOF2yX/5ZiuH2hXm9skrC4bXq4PZ+cYfQMcG5ciFka72Jo7 vuGoyFuU/bQerSSKvTjmUVIZK9c4Cc50C3vFzG9n9HE/anV0gM5ExfFpu0ZDJapi LKa0r2kftrnFieGj5CkD5VsOcZpaoLSH5OvYKVn7MkU0x088qPJTrBq7ogaBN7nH c7Nl+7o74MI6lPGeg43dtm3DinPGC8EWFpTbQA+V6TpfMifcO1lxbyWC0Zu/T5k4 m4SidatQJ4ZZdyJswj5AUdfhdAqUBpJnDHjWVssE4zTTdrKJoCqYyljyyS+kJvv8 kur+OK/N3svhl02PgNlwTPPVJ+QWg9kj0XumgfG2Epb8e8gRNsl7WUFxlDkk5O40 19Ch7ZEEQ9zZ7eK0pg6vggeS6qWbWAn72blgENNqPgRdxOvn47HtTjx/lHRgcgKx 9EolMF7/oWoWZoO/eLruiH0G+92wvGlE/+inm0v15j5OmDbhVYE9cKGYEpXlAUxw +9RORBEAS7H5QKTms2hyIzhTk5xEwN13XNplCgokAiHf1MoyKoVb/2tTQHvflwV0 NioqTk00dOV8iY/+eMKTA8Q59ge21Dn8gP5xB72XDd9d2Ny4LCJr1TZ0tstvHy// 9FQAxXQuZgksfZSkmYTo =4TWs -----END PGP SIGNATURE----- --1RhkHwXgxvdXShGl07DPVpWgrGB2nujoh-- From nobody Fri Mar 6 18:15:50 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B9ACB1A87A5; Fri, 6 Mar 2015 18:12:13 -0800 (PST) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972481A87AA for ; Fri, 6 Mar 2015 18:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.401 X-Spam-Level: X-Spam-Status: No, score=0.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_NAIL=2.3, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz1YpuILhP8L for ; Fri, 6 Mar 2015 18:12:11 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C33A91A879E for ; Fri, 6 Mar 2015 18:12:08 -0800 (PST) Received: from smtprelay.restena.lu ([2001:a18:1::62]:37109) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YU4Dm-0002aJ-UR for draft-ietf-radext-dynamic-discovery.all@tools.ietf.org; Fri, 06 Mar 2015 18:12:08 -0800 Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7954B43995; Fri, 6 Mar 2015 09:35:48 +0100 (CET) Message-ID: <54F966E4.20002@restena.lu> Date: Fri, 06 Mar 2015 09:35:48 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: "Brian Weis (bew)" , Alan DeKok References: <2B42564B-1BC8-437D-AACD-69785A90A795@cisco.com> In-Reply-To: <2B42564B-1BC8-437D-AACD-69785A90A795@cisco.com> OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1" X-SA-Exim-Connect-IP: 2001:a18:1::62 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery.all@tools.ietf.org X-SA-Exim-Mail-From: stefan.winter@restena.lu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-radext-dynamic-discovery.all@ietf.org Resent-Message-Id: <20150307021211.C33A91A879E@ietfa.amsl.com> Resent-Date: Fri, 6 Mar 2015 18:12:08 -0800 (PST) Resent-From: stefan.winter@restena.lu Archived-At: Archived-At: X-Mailman-Approved-At: Fri, 06 Mar 2015 18:15:46 -0800 Cc: The IESG , "draft-ietf-radext-dynamic-discovery.all@tools.ietf.org" , "secdir@ietf.org" Subject: Re: [radext] [secdir] Secdir review of draft-ietf-radext-dynamic-discovery-12 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Mar 2015 02:12:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1 Content-Type: multipart/mixed; boundary="------------030302090704080506070500" This is a multi-part message in MIME format. --------------030302090704080506070500 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > The clarification below was very useful. Perhaps the authors will find= it valuable to include the references you mentioned, and clarify that th= ere is expected to be a limited number of trusted (preferably one) truste= d to issue certificates for the consortium use case. The NAI reference was already in the document, and I've pulled in text from the RADIUS/DTLS reference directly into the document. The text regarding the small set of CAs is now also in. Thanks, Stefan Winter >=20 > Thanks, > Brian >=20 > On Jan 4, 2015, at 8:48 PM, Alan DeKok wrot= e: >=20 >> On Dec 24, 2014, at 4:05 PM, Brian Weis wrote: >> >> I=92m not the document author, but I can help give some clarification= =2E >> >>> There=92s not much background given, and having an overview of the so= lution architecture in the Introduction would be useful. I.e., a descript= ion and picture showing the actors and the communication flows between th= em. >> >> The current roaming behaviour is discussed in the NAI document, Secti= on 3. Unfortunately, it also assumes some familiarity with the field. >> >> http://tools.ietf.org/html/draft-ietf-radext-nai-15#section-3 >> >> Perhaps the simplest explanation is that RADIUS is client-server. Cl= ients request authentication on behalf of users, and servers authenticate= the users. The key thing is that historically, proxying has been static= , and provisioning of proxy configuration has been entirely outside of th= e protocol. i.e. proxies operate by consensus and habit, not by standard= behaviour. >> >> A long description of the Eduroam consortium is available as an indiv= idual draft: >> >> http://tools.ietf.org/html/draft-wierenga-ietf-eduroam-04 >> >> However, *commercial* proxies do not operate in the eduroam model. C= ommercial proxies are largely =93star=94 configurations. An interconnect= company sits at the centre of a star. It may connect to one or more oth= er interconnect providers. Routes are largely static, and are usually up= dated by hand, after legal contracts have been exchanged. >> >> This document is standardizing provisioning of RADIUS proxying, via d= ynamic methods. >> >>> I don=92t have complete confidence that I correctly understood which = actors are involved in the RASIUS/TLS transaction -- in some sections it = seems that RADIUS clients are initiating requests and sometimes RADIUS se= rvers and I thought only clients contacted servers. An overview of the ac= tors would probably have clarified that. >> >> Clients are the only ones initiating requests. In some cases, the sy= stem running RADIUS can behave as a client or as a server, depending on i= t=92s needs. That makes it more complicated. >> >>> If I understand correctly how roaming consortiums currently work toda= y, a RADIUS client within a consortium needing to make a AAA call to a RA= DIUS server in another realm does not contact the server directly. >> >> s/does not/may not/ >> >>> Instead, it routes the request through a hierarchy of RADIUS servers = following roots of trust. >> >> That=92s how eduroam works. Commercial proxies are configured differ= ently. >> >> However, they both operate on a =93fire and forget=94 model. A RADIU= S server which wants to proxy a request somehow (magically, almost) deter= mines which upstream server to use. The =93magic=94 part of that process= is what the dynamic discovery document is trying to standardize. >> >>> Section 2.1.1.3 discusses the use of TLS cipher suites, and makes the= point that certificate based cipher suites need to be used because there= won=92t be any pre-distributed secret key material available. That=92s g= ood advice. I think the section should also give advice on choosing trust= roots. This is important because the identity of the server was gotten i= n an untrusted manner (from unsecured DNS), and the certificate it presen= ts contains information used for authorization of a server (i.e., Subjec= tAltName). If a RADIUS client were to accept a certificate signed by a wi= de range of trust roots (e.g, the set of roots used by browsers, where th= e trustability of many CAs in the hierarchy is unknown) then the RADIUS c= lient would be ill advised to trust authorization information claims in = the hierarchy. >> >> Current RADIUS practice uses a limited set of CAs. Generally, only o= ne. This use-case is *very* different than that for browsers. This docu= ment should make that clearer. Shipping a RADIUS server (or client) with= a list of pre-configured CAs is a *very bad* idea. RFC 6614 (RADIUS ove= r TLS) should probably have had such statements. RFC 7360 (RADIUS over D= TLS) has some related text which would be useful here: >> >> https://tools.ietf.org/html/rfc7360 >> >> Section 10.4: ... >> >> Therefore, clients SHOULD NOT be pre-configured with a list of known= >> public CAs by the vendor or manufacturer. Instead, the clients >> SHOULD start off with an empty CA list. The addition of a CA SHOULD= >> be done only when manually configured by an administrator. >> This scenario is the opposite of web browsers, where they are pre- >> configured with many known CAs. The goal there is security from >> third-party observers, but also the ability to communicate with any >> unknown site that presents a signed certificate. In contrast, the >> goal of RADIUS/DTLS is both security from third-party observers and >> the ability to communicate with only a small set of well-known >> servers. >> >>> On the other hand, if the trust roots were restricted to a set of hig= hly trusted trust roots maintained by the consortium, then the authorizat= ion information in the certificate would be trustable. This should be exp= lained. >> >> Generally there=92s only one root CA for a consortium. I=92m not sur= e what the use-case would be for multiple root CAs. >> >> Alan DeKok. >> >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------030302090704080506070500 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------030302090704080506070500-- --sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1 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 iQIcBAEBCgAGBQJU+WbkAAoJEMDeajWKOdxmPdoP/j2Jgiuu39S32NSJ6iLMR5Ty yyeUoWp3TEpRCCGKsTJiVVLtZi/U0rjXSOUDpdDAKhg2o7oYLOUejQRFTOCnnYS2 NJsMHO6H6piuh+E430U+q/4/aCO1wNdlPswW0pSdqrie61w4YJ3Ft+uro8jJuzwT nX8zAayJiG2JOx582oMcRi9KWhBrLPd2F5RCLMK2JI1ffZNATrFRlipCRz4HYFy0 jAepjKwqPrfRCGgDkb5z6aC10Cixh+2YerYcYMtpK+sycKZVEFuzrmjhkzMNCHPs ItSli+LZEQmC5FQCb3eRO1yW5WxGoNVqHAq/VkwUk9F5QTYeKqLsUa/fLUyxEjpU sxzPfS18UaWIYf5xXYDBWqUyilM0NtBI1YH2jsm91pyEITz2fvMSvBz8Lbo+zP9n z8MNl1jmjrbkdPkYikJ9QSj5fwgiBqusc8Omj1ckz2IHSLFVWQPXJMc9rYYIdt1l d63PSM58qG5imrLW3/+fsUlw5qHZxButdq/rucQTA5w6hFsD6C7xcksCIlRABDVk vZcGtTHxGSxq4cnO+eRKw1rKTUtpKUd/xasB2pqB4osv5bXaF04tpHHHbMPl9w2T 11WYkHISJq0RerhWslhWJRtGZLYYz49K/IPHkq4UzdhQq089+uSmpIzX0REm+MyQ JDWCDqmQ25msra83Qk9h =Z/DJ -----END PGP SIGNATURE----- --sWtGc8NO9vtOQ6WiHL8BfNQ3o1WNVMHs1-- From nobody Tue Mar 10 09:08:50 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948DF1A1B0D for ; Tue, 10 Mar 2015 09:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2hyEihEND5K for ; Tue, 10 Mar 2015 09:08:45 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 114451A00F0 for ; Tue, 10 Mar 2015 09:08:45 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id D4F3A7C00B for ; Tue, 10 Mar 2015 17:08:42 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id BB05C18013B for ; Tue, 10 Mar 2015 17:08:42 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 10 Mar 2015 17:08:42 +0100 From: To: "radext@ietf.org" Thread-Topic: IETF92 agenda slots Thread-Index: AdBbSkJd4jjkc2uAR5mmIxNpXLAgUQ== Date: Tue, 10 Mar 2015 16:08:42 +0000 Message-ID: <29597_1426003722_54FF170A_29597_7067_1_6B7134B31289DC4FAF731D844122B36EDC3337@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36EDC3337PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.10.150033 Archived-At: Subject: [radext] IETF92 agenda slots X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:08:49 -0000 --_000_6B7134B31289DC4FAF731D844122B36EDC3337PEXCVZYM13corpora_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, During this IETF, the RADEXT session is on Monday (Afternoon Session II) an= d we have a slot of 90mn. We have received so far only one request for a meeting slot: * draft-ietf-radext-ip-port-radius-ext-03 Is there any other request, either for WG or non-WG I-D? Please inform ASAP= the chairs. Please be aware that remote presentations are possible but the deadline for= requesting is March 17. Regards, Lionel & Stefan ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36EDC3337PEXCVZYM13corpora_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

During this IETF, the RADEXT= session is on Monday (Afternoon Session II) and we have a slot of 90mn.

We have received so far only= one request for a meeting slot:

 

* draft-ietf-radext-ip-port-= radius-ext-03

 

Is there any other request, = either for WG or non-WG I-D? Please inform ASAP the chairs.

Please be aware that remote = presentations are possible but the deadline for requesting is March 17.

 

Regards,

 

Lionel & Stefan

 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36EDC3337PEXCVZYM13corpora_-- From nobody Tue Mar 10 09:21:18 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9A091A1BB9 for ; Tue, 10 Mar 2015 09:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsk5dNjvcJYH for ; Tue, 10 Mar 2015 09:21:16 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D5741A1BE7 for ; Tue, 10 Mar 2015 09:21:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id DDEF42065A; Tue, 10 Mar 2015 12:20:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYnd3B4Yj4uk; Tue, 10 Mar 2015 12:20:06 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 10 Mar 2015 12:20:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 15BE782837; Tue, 10 Mar 2015 12:21:11 -0400 (EDT) From: Sam Hartman To: References: <29597_1426003722_54FF170A_29597_7067_1_6B7134B31289DC4FAF731D844122B36EDC3337@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 10 Mar 2015 12:21:11 -0400 In-Reply-To: <29597_1426003722_54FF170A_29597_7067_1_6B7134B31289DC4FAF731D844122B36EDC3337@PEXCVZYM13.corporate.adroot.infra.ftgroup> (lionel morand's message of "Tue, 10 Mar 2015 16:08:42 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] IETF92 agenda slots X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 16:21:17 -0000 I will be available remotely and hope that we can discuss any issues preventing draft-ietf-radext-bigger-packets from going to WGLC or the AD or whatever's next. I believe I've addressed all review comments, but if there's anything outstanding I'd like to deal with that. From nobody Tue Mar 10 10:16:36 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6A381A6FCB for ; Tue, 10 Mar 2015 10:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzCAcil7fnex for ; Tue, 10 Mar 2015 10:16:32 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4058C1A6F3A for ; Tue, 10 Mar 2015 10:16:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 0F4FE22404A2 for ; Tue, 10 Mar 2015 18:16:31 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXlwe4deCQUA for ; Tue, 10 Mar 2015 18:16:30 +0100 (CET) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id D02C22240126 for ; Tue, 10 Mar 2015 18:16:29 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <29597_1426003722_54FF170A_29597_7067_1_6B7134B31289DC4FAF731D844122B36EDC3337@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 10 Mar 2015 13:16:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1AC40A35-D41D-4815-8BCA-7B5A981C3ABD@deployingradius.com> References: <29597_1426003722_54FF170A_29597_7067_1_6B7134B31289DC4FAF731D844122B36EDC3337@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: radext@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [radext] IETF92 agenda slots X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2015 17:16:34 -0000 Charter updates would be useful. For me, getting the datatypes document accepted as a WG item and then = doing last call would be great. There=92s been no dissension and lots = of approval, so it should be good to go. Also the coa proxy document could go in. There=92s similarly been no = discussion and lots of agreement. On Mar 10, 2015, at 12:08 PM, = wrote: > Folks, > =20 > During this IETF, the RADEXT session is on Monday (Afternoon Session = II) and we have a slot of 90mn. > We have received so far only one request for a meeting slot: > =20 > * draft-ietf-radext-ip-port-radius-ext-03 > =20 > Is there any other request, either for WG or non-WG I-D? Please inform = ASAP the chairs. > Please be aware that remote presentations are possible but the = deadline for requesting is March 17. > =20 > Regards, > =20 > Lionel & Stefan > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Wed Mar 11 20:57:54 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0001A8A3A for ; Wed, 11 Mar 2015 20:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BHbuZxN07zYd for ; Wed, 11 Mar 2015 20:57:51 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698781A8A29 for ; Wed, 11 Mar 2015 20:57:51 -0700 (PDT) Received: from Philemon (ip-64-134-132-146.public.wayport.net [64.134.132.146]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 122A12CA0B; Wed, 11 Mar 2015 20:57:49 -0700 (PDT) From: "Jim Schaad" To: "'Alan DeKok'" , References: <29597_1426003722_54FF170A_29597_7067_1_6B7134B31289DC4FAF731D844122B36EDC3337@PEXCVZYM13.corporate.adroot.infra.ftgroup> <1AC40A35-D41D-4815-8BCA-7B5A981C3ABD@deployingradius.com> In-Reply-To: <1AC40A35-D41D-4815-8BCA-7B5A981C3ABD@deployingradius.com> Date: Wed, 11 Mar 2015 20:56:47 -0700 Message-ID: <0f1d01d05c78$941ec5e0$bc5c51a0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJHQ+EF9PcNMOQbq4ipwFNkES9wQgHiBU9qnBs9nhA= Content-Language: en-us Archived-At: Subject: Re: [radext] IETF92 agenda slots X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2015 03:57:53 -0000 +1 on getting data types adopted and last called in a very short timeframe. Issue the adoption now and after the adoptions succeeds issue the last call Jim > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok > Sent: Tuesday, March 10, 2015 10:16 AM > To: radext@ietf.org > Subject: Re: [radext] IETF92 agenda slots > > Charter updates would be useful. > > For me, getting the datatypes document accepted as a WG item and then > doing last call would be great. There's been no dissension and lots of approval, > so it should be good to go. > > Also the coa proxy document could go in. There's similarly been no discussion > and lots of agreement. > > > On Mar 10, 2015, at 12:08 PM, > wrote: > > > Folks, > > > > During this IETF, the RADEXT session is on Monday (Afternoon Session II) and > we have a slot of 90mn. > > We have received so far only one request for a meeting slot: > > > > * draft-ietf-radext-ip-port-radius-ext-03 > > > > Is there any other request, either for WG or non-WG I-D? Please inform ASAP > the chairs. > > Please be aware that remote presentations are possible but the deadline for > requesting is March 17. > > > > Regards, > > > > Lionel & Stefan > > > > > ________________________________________________________________ > ______ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les > pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and delete > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Fri Mar 13 03:13:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656A1A1BE0 for ; Fri, 13 Mar 2015 03:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJzLgT4LUt5B for ; Fri, 13 Mar 2015 03:13:12 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 435041A1BD2 for ; Fri, 13 Mar 2015 03:13:12 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id EE66443976 for ; Fri, 13 Mar 2015 11:13:10 +0100 (CET) Message-ID: <5502B836.5000100@restena.lu> Date: Fri, 13 Mar 2015 11:13:10 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: "radext@ietf.org" OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="biGo81oSPPFe1oSP2u7cW34w6tbSklqV9" Archived-At: Subject: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 10:13:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --biGo81oSPPFe1oSP2u7cW34w6tbSklqV9 Content-Type: multipart/mixed; boundary="------------090703080509060406060103" This is a multi-part message in MIME format. --------------090703080509060406060103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, as you may recall, we discussed new charter text at IETF91, which was unanimously accepted in the room. We still need to verify consensus on the list, so below is the proposed updated charter text. This mail starts a two week comment period on the charter text. Please send your comments to the list until 2015-03-27 2400 UTC. You'll notice that there is specific text for "data types", "CoA proxy" and "Populating EAP identity" in the draft charter's Work Items. Judging from the mailing list traffic and prior discussions at the last IETF meeting, I believe there is consensus that the working group wants to work on these problem. As soon as the charter is approved, I will issue an adoption call for the individual drafts which go in that direction. We should also adjust milestones (some items to be marked as Done, some new target dates for the ongoing work). These are not formally part of the charter update, but they fit nicely into this mail nontheless. For the completion dates, some authors have indicated a very short timeframe for completion, but I've set everything at least to "2 meetings ahead" -> November 2015; simply because our working group has a certain track record of always being slower than anticipated :-) Here is the text, see the IETF91 slides for a rationale of the changed bi= ts: "The RADIUS Extensions Working Group will focus on extensions to the RADIUS protocol pending approval of the new work from the Area Director and clarify its usage and definition. Furthermore, to ensure backward compatibility with existing RADIUS implementations, as well as compatibility between RADIUS and Diameter, the following restriction is imposed on extensions considered by the RADEXT WG: All documents produced MUST specify means of interoperation with legacy RADIUS and, if possible, be backward compatible with existing =E2=80=A8RA= DIUS RFCs, including RFCs 2865-2869, 3162, 3575, 3579, 3580, 4668-4673,4675, 5080, 5090, 5176 and 6158. Transport profiles should, if possible, be compatible with RFC 3539. The WG will review its existing RFCs=E2=80=99 document track categories a= nd where necessary or useful change document tracks, with minor changes in the documents if needed. Any changes to document tracks require approval by the responsible Area Director. Work Items The immediate goals of the RADEXT working group are to address the following issues: - CoA proxying. RFC 5176 permits proxying of CoA and Disconnect messages, but makes no provisions for how that is done in a roaming environment. This work item will provide descriptions of how to use the Operator-Name attribute in a roaming environment to proxy CoA packets. It will also define a new attribute which defines an opaque NAS identifier which can be used to uniquely identify a visited NAS, and whose value will not be modified when proxying, as is done with NAS-Identifier and NAS-IP-Address. - Encoding Rules for EAP-Response/Identity packets over RADIUS. Neither EAP (RFC3748) nor EAP over RADIUS (RFC3579) demand specific character encoding and normalisation rules for EAP Identity responses. RADIUS (RFC2865) requires User-Name attributes to be encoded in UTF-8. Where a NAS is required to verbatimly copy an EAP-Identity into a User-Name, invalid packets might be produced. This document will suggest restrictions on EAP Identities so that transport over AAA becomes correct under all circumstances (UTF-8) and deterministic (normalisation)= =2E - Data Types. RFC 2865 defines a number of data types, but later documents do not use those types in a consistent way. This work item will define data types, and update the IANA RADIUS Attribute Type registry so that each attribute has a data type. Where necessary, it will correct issues with previous specifications. This will be a standards track document. - Larger Packets. Support RADIUS packets greater than 4096-octets over RADIUS transports with this capability. - RADIUS Attributes for IP Port Configuration and Reporting. These attributes are used by devices that implement IP port ranges to configure and report TCP/UDP ports and ICMP identifiers, as well as mapping behaviors. These attributes can be used in the context of address sharing (e.g., NAT44 [RFC3022], Dual-Stack Lite AFTR [RFC6333], CGN [RFC6888], NAT64 [RFC6146], Provider WLAN (e.g., [TR-146]), etc.). Milestones (mark RFC4282bis as Done [RFC Editor Queue now]) (mark RADIUS packet fragemntation as Done [in RFC Editor Queue now]) (mark Dynamic Discovery as Done [in IETF LC now]) Nov 2015 - Submit CoA Proxying as Standards Track RFC Nov 2016 - Submit Populating EAP Identity as BCP RFC Nov 2015 - Data Types as Informational RFC Nov 2015 - Larger Packets for RADIUS over TCP as Experimental RFC Mar 2016 - IP Port RADIUS Extensions as Standards Track RFC Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------090703080509060406060103 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090703080509060406060103-- --biGo81oSPPFe1oSP2u7cW34w6tbSklqV9 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 iQIcBAEBCgAGBQJVArg2AAoJEMDeajWKOdxmZIUP/RS62Oa8xLf78/EN3EaR0hOq BGDfK19z2c2nMFxVEoS2aeIwMXKjjByyvI+vqNfurH4H7ubsbQ2dlbcuCkDw1tS+ uiQhn5G0bM/M9Ijoz6mzMNAwVLyS0P0DfAgpJrL+6/XUtm4FJ41Lm3rRDJqwuJyQ 1U1+zA0+k0stWP4hTfACEod59tfyG5LUQhC2UkKbheqho24wBXi+dfwDGiD+5xPK nXisdZ5UyC0Jg1xwHmn4p49yhtPh+Zq5ruKRM1R7H1CXf8ClxCVb8y6dA3jqGDVP Bc9Na6kMGg5QcdmCgjEZMc+8Sfle3Vx2aLmxp/nbL38k5/tPoA8VFfkv2y5mhqLN Mixrots4l7PCUcKxJv0hAzmpxpUEaC4Ja3rHp+OSEfwQ0Zrdof/XJYeLu1WGvlSW EzJiprFLhX4jsSzRxx9kZFl+3VC7M5Mt7Yn1bUm9pRf6BZfB5UYyUZnTLrmE5Xve CQG7PY8m6ZhIjY2wBC1U9cziOjtyNBpSJUQ60UX6V9b7MA+EEF41PVPATODo/SWW xiN0gG22TT7elb8UAq68lAb10lwNxt4TVjDx79CCGHlYAbLAjkk5rWudYzfiC621 iLEAu0MqcFSPE1OgbtMtedXeqZm4W1Pt/YnMvYYZvGhHAn4usoGup+gRfN63tVe5 AX6g6P4mvghkow1dNnXC =mxB7 -----END PGP SIGNATURE----- --biGo81oSPPFe1oSP2u7cW34w6tbSklqV9-- From nobody Fri Mar 13 08:30:36 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11C41A6EFE; Fri, 13 Mar 2015 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXSnIT2tMsLA; Fri, 13 Mar 2015 08:30:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF21A0263; Fri, 13 Mar 2015 08:30:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150313153032.30738.30340.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 08:30:32 -0700 From: IETF Secretariat Archived-At: Subject: [radext] Telechat update notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:30:34 -0000 Placed on agenda for telechat - 2015-04-09 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Fri Mar 13 08:30:37 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 06CC51A6F05; Fri, 13 Mar 2015 08:30:34 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11C41A6EFE; Fri, 13 Mar 2015 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, TVD_SPACE_RATIO=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXSnIT2tMsLA; Fri, 13 Mar 2015 08:30:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AF21A0263; Fri, 13 Mar 2015 08:30:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150313153032.30738.30340.idtracker@ietfa.amsl.com> Date: Fri, 13 Mar 2015 08:30:32 -0700 From: IETF Secretariat Archived-At: Subject: [radext] Telechat update notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 15:30:34 -0000 Placed on agenda for telechat - 2015-04-09 ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Thu Mar 19 09:06:12 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E11ACDF5; Thu, 19 Mar 2015 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NT3UoWWv7_q; Thu, 19 Mar 2015 09:06:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1181ACDE8; Thu, 19 Mar 2015 09:06:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150319160606.340.5948.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 09:06:06 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:06:10 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Thu Mar 19 09:06:13 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 925DE1ACE08; Thu, 19 Mar 2015 09:06:10 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E11ACDF5; Thu, 19 Mar 2015 09:06:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0NT3UoWWv7_q; Thu, 19 Mar 2015 09:06:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1181ACDE8; Thu, 19 Mar 2015 09:06:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150319160606.340.5948.idtracker@ietfa.amsl.com> Date: Thu, 19 Mar 2015 09:06:06 -0700 From: IETF Secretariat Archived-At: Subject: [radext] ID Tracker State Update Notice: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 16:06:10 -0000 IANA review state changed to IANA - Not OK ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ From nobody Fri Mar 20 00:08:45 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC651B2C60; Fri, 20 Mar 2015 00:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uv6y2UxKsnt; Fri, 20 Mar 2015 00:08:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6551B2C57; Fri, 20 Mar 2015 00:08:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150320070843.14320.9741.idtracker@ietfa.amsl.com> Date: Fri, 20 Mar 2015 00:08:43 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [radext] Last Call Expired: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 07:08:44 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Mar 20 00:08:48 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id E41321B2C65; Fri, 20 Mar 2015 00:08:44 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDC651B2C60; Fri, 20 Mar 2015 00:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uv6y2UxKsnt; Fri, 20 Mar 2015 00:08:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA6551B2C57; Fri, 20 Mar 2015 00:08:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: DraftTracker Mail System To: , , , , X-Test-IDTracker: no X-IETF-IDTracker: 5.12.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150320070843.14320.9741.idtracker@ietfa.amsl.com> Date: Fri, 20 Mar 2015 00:08:43 -0700 Archived-At: Cc: iesg-secretary@ietf.org Subject: [radext] Last Call Expired: X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 07:08:45 -0000 Please DO NOT reply to this email. I-D: ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ IETF Last Call has ended, and the state has been changed to Waiting for AD Go-Ahead. From nobody Fri Mar 20 11:23:23 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E40081A6F17 for ; Tue, 17 Mar 2015 08:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3vYywtMvzhT for ; Tue, 17 Mar 2015 08:59:05 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD8981A854D for ; Tue, 17 Mar 2015 08:59:03 -0700 (PDT) Received: by lbcds1 with SMTP id ds1so10385357lbc.3 for ; Tue, 17 Mar 2015 08:59:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4wKB7y0Xo9Hg/ImzAlzwpal4cSy8DJT2odP6anqmAT8=; b=CCtn70tmzkXmzD16VOt2GrOGYzInD3xPI08wIwIW9HGuRK5iX4hhqtfyfIcEvYPZGr H/FZjuCwcJHh5sT5J2yYg6D3J6B8c2qmYM8IYiRVMuyPFbxZZcQAR0gh8nKaXt9YTV4i vFO4cgW1wPa6E58f2AEUuQdbrkV1Aw5XJgYnuHTqNOAPoC7JFR1047TH2q6lXv4Psm94 1w3vD5sAynt0LOiQEeJkhPr+sfqzKNTPTGF7kp3vXOGAktvOjnFCJCyG6nk4F1N4kRms RGpdm8g+CVcT28NEDHB9Igsl1VFY2OFDYWQT4/LDZu316TqexHLVxqmk/icHPsMVuZul 6HFA== MIME-Version: 1.0 X-Received: by 10.112.181.41 with SMTP id dt9mr62059418lbc.56.1426607942214; Tue, 17 Mar 2015 08:59:02 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Tue, 17 Mar 2015 08:59:02 -0700 (PDT) In-Reply-To: <9BE727B3-42D6-4C3C-84E5-398B32D2D538@freeradius.org> References: <20150224204147.6CCC6181B3D@rfc-editor.org> <9BE727B3-42D6-4C3C-84E5-398B32D2D538@freeradius.org> Date: Tue, 17 Mar 2015 11:59:02 -0400 Message-ID: From: Kathleen Moriarty To: Alan DeKok Content-Type: multipart/alternative; boundary=001a11c36986a1281005117e0bcf Archived-At: X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:21 -0700 Cc: "gdommety@cisco.com" , "radext@ietf.org" , "lionel.morand@orange.com" , Winter Stefan , "joelja@bogus.com" , Bernard Aboba , "david@mitton.com" , "bclaise@cisco.com" , "meklund@cisco.com" , "mchiba@cisco.com" , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5176 (4280) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 15:59:08 -0000 --001a11c36986a1281005117e0bcf Content-Type: text/plain; charset=UTF-8 Hello, Is there agreement on the changes and do additional errata need to be filed for the added text in this thread? Thank you, Kathleen On Wed, Feb 25, 2015 at 9:46 AM, Alan DeKok wrote: > I agree. There should be an additional paragraph after the paragraph > below, saying: > > ... > Error-Cause MAY be included in a CoA-ACK and Disconnect-ACK packet to > indicate successful actions. If it is included in those packets, the > Value MUST > be within the range 200-299. > ... > > There is further discussion of CoA-ACK in the text describing the > allowed VALUEs. But there should be a short sentence in the Description, > too. > > On Feb 24, 2015, at 6:07 PM, Bernard Aboba > wrote: > > > The Description text should also be addressed in this Errata: > > > > Description > > > > It is possible that a Dynamic Authorization Server cannot honor > > Disconnect-Request or CoA-Request packets for some reason. The > > Error-Cause Attribute provides more detail on the cause of the > > problem. It MAY be included within CoA-NAK and Disconnect-NAK > > packets. > > > > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > > Sent: Tuesday, February 24, 2015 12:42 PM > > To: mchiba@cisco.com; gdommety@cisco.com; meklund@cisco.com; > david@mitton.com; Bernard Aboba; bclaise@cisco.com; joelja@bogus.com; > stefan.winter@restena.lu; lionel.morand@orange.com > > Cc: aland@freeradius.org; radext@ietf.org; rfc-editor@rfc-editor.org > > Subject: [Technical Errata Reported] RFC5176 (4280) > > > > The following errata report has been submitted for RFC5176, "Dynamic > Authorization Extensions to Remote Authentication Dial In User Service > (RADIUS)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=4280 > > > > -------------------------------------- > > Type: Technical > > Reported by: Alan DeKok > > > > Section: 3.6 > > > > Original Text > > ------------- > > 0 0 0+ 101 Error-Cause > > > > > > In both tables, for CoA and Disconnect messages. > > > > Corrected Text > > -------------- > > 0 0+ 0+ 101 Error-Cause > > > > > > In both tables, for CoA and Disconnect messages. > > > > Notes > > ----- > > Section 3.5 says that Error-Cause may be sent in a CoA-ACK or > Disconnect-ACK packet: > > > > ... > > Values 200-299 represent successful completion, so that these > > values may only be sent within CoA-ACK or Disconnect-ACK packets > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please use > "Reply All" to discuss whether it should be verified or rejected. When a > decision is reached, the verifying party (IESG) can log in to change the > status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5176 (draft-ietf-radext-rfc3576bis-13) > > -------------------------------------- > > Title : Dynamic Authorization Extensions to Remote > Authentication Dial In User Service (RADIUS) > > Publication Date : January 2008 > > Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. > Aboba > > Category : INFORMATIONAL > > Source : RADIUS EXTensions > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > -- Best regards, Kathleen --001a11c36986a1281005117e0bcf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

Is there agreement on the change= s and do additional errata need to be filed for the added text in this thre= ad?

Thank you,
Kathleen

On Wed, Feb 25, 2015 a= t 9:46 AM, Alan DeKok <aland@freeradius.org> wrote:
=C2=A0 I agree.=C2=A0 There should be an addit= ional paragraph after the paragraph below, saying:

...
=C2=A0 =C2=A0Error-Cause MAY be included in a CoA-ACK and Disconnect-ACK pa= cket to
=C2=A0 =C2=A0indicate successful actions.=C2=A0 If it is included in those = packets, the Value MUST
=C2=A0 =C2=A0be within the range 200-299.
...

=C2=A0 There is further discussion of CoA-ACK in the text describing the al= lowed VALUEs.=C2=A0 But there should be a short sentence in the Description= , too.

On Feb 24, 2015, at 6:07 PM, Bernard Aboba <Bernard.Aboba@microsoft.com> wrote:

> The Description text should also be addressed in this Errata:
>
>=C2=A0 =C2=A0Description
>
>=C2=A0 =C2=A0 =C2=A0 It is possible that a Dynamic Authorization Server= cannot honor
>=C2=A0 =C2=A0 =C2=A0 Disconnect-Request or CoA-Request packets for some= reason.=C2=A0 The
>=C2=A0 =C2=A0 =C2=A0 Error-Cause Attribute provides more detail on the = cause of the
>=C2=A0 =C2=A0 =C2=A0 problem.=C2=A0 It MAY be included within CoA-NAK a= nd Disconnect-NAK
>=C2=A0 =C2=A0 =C2=A0 packets.
>
>
> -----Original Message-----
> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]
> Sent: Tuesday, February 24, 2015 12:42 PM
> To: mchiba@cisco.com; gdommety@cisco.com; meklund@cisco.com; david@mitton.com; Bernard Aboba; = bclaise@cisco.com; joelja@bogus.com= ; stefan.winter@restena.lu<= /a>; lionel.morand@orange.com
> Cc: aland@freeradius.org; = radext@ietf.org; rfc-editor@rfc-editor.org
> Subject: [Technical Errata Reported] RFC5176 (4280)
>
> The following errata report has been submitted for RFC5176, "Dyna= mic Authorization Extensions to Remote Authentication Dial In User Service = (RADIUS)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?r= fc=3D5176&eid=3D4280
>
> --------------------------------------
> Type: Technical
> Reported by: Alan DeKok <al= and@freeradius.org>
>
> Section: 3.6
>
> Original Text
> -------------
>=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 = =C2=A0 0+=C2=A0 101=C2=A0 =C2=A0Error-Cause
>
>
> In both tables, for CoA and Disconnect messages.
>
> Corrected Text
> --------------
>=C2=A0 =C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A00+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 0+=C2=A0 101=C2=A0 =C2=A0Error-Cause
>
>
> In both tables, for CoA and Disconnect messages.
>
> Notes
> -----
> Section 3.5 says that Error-Cause may be sent in a CoA-ACK or Disconne= ct-ACK packet:
>
>=C2=A0 =C2=A0 =C2=A0 ...
>=C2=A0 =C2=A0 =C2=A0 Values 200-299 represent successful completion, so= that these
>=C2=A0 =C2=A0 =C2=A0 values may only be sent within CoA-ACK or Disconne= ct-ACK packets
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary= , please use "Reply All" to discuss whether it should be verified= or rejected. When a decision is reached, the verifying party (IESG) can lo= g in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC5176 (draft-ietf-radext-rfc3576bis-13)
> --------------------------------------
> Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Dynamic = Authorization Extensions to Remote Authentication Dial In User Service (RAD= IUS)
> Publication Date=C2=A0 =C2=A0 : January 2008
> Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: M. Chiba, G. Domme= ty, M. Eklund, D. Mitton, B. Aboba
> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : INFORMATIONAL
> Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : RADIUS EXTens= ions
> Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Operatio= ns and Management
> Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
> Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG
>

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



--
=

Best regards,
Kathleen
--001a11c36986a1281005117e0bcf-- From nobody Fri Mar 20 11:23:25 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601811A1A64; Thu, 19 Mar 2015 08:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeJROapT7uVl; Thu, 19 Mar 2015 08:50:34 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017031A1A0C; Thu, 19 Mar 2015 08:50:33 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2JFoXJf027070; Thu, 19 Mar 2015 15:50:33 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id C0B63C20366; Thu, 19 Mar 2015 15:50:33 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150307002447.20539.31287.idtracker@ietfa.amsl.com> References: <20150307002447.20539.31287.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #811747 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 19 Mar 2015 15:50:33 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:20 -0700 Cc: iesg@ietf.org, radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-dynamic-discovery.all@ietf.org Subject: [radext] [IANA #811747] Last Call: (NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:50:36 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-radext-dynamic-discovery-13. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has questions for the IANA actions requested in this draft. Further, some of the new requested values require Expert review. IANA understands that, upon approval of this document, there are six actions which must be completed. First, in the S-NAPTR Application Service Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at: http://www.iana.org/assignments/s-naptr-parameters/ three, new service tags will be registered as follows: Tag: aaa+auth Reference: [ RFC-to-be ] Tag: aaa+accr Reference: [ RFC-to-be ] Tag: aaa+dynauth Reference: [ RFC-to-be ] IANA Note --> As this document requests registrations in a Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the S-NAPTR Application Protocol Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at: http://www.iana.org/assignments/s-naptr-parameters/ two, new service tags will be registered as follows: Tag: radius.tls.tcp Reference: [ RFC-to-be ] Tag: radius.dtls.udp Reference: [ RFC-to-be ] IANA Note --> As above, this document requests registrations in a Specification Required registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, this document requests two service names - radiustls and radiusdtls - to be registered for both TCP and UDP in the Service Name and Transport Protocol Port Number Registry located at: http://www.iana.org/assignments/service-names-port-numbers Service Name: radiustls; radiusdtls Transport Protocols: TCP, UDP Assignee: IESG Contact: IETF Chair Description: Authentication, Accounting and Dynamic authorization via the RADIUS protocol. These service names are used to construct the SRV service labels "_radiustls" and "_radiusdtls" for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. Reference: [RFC-to-be] Question: What are the Defined TXT keys for each SRV names? The Defined TXT keys are required for SRV service names. The authors should submit a template at http://www.iana.org/form/ports-services for early allocation and put the Internet Draft as a reference according to RFC6335 as stated in section 8.1.1 of that document. Fourth, IANA understands that this draft makes use of the SRV Protocol identifiers "_tcp" and "_udp" which are mentioned as early as [RFC2782] but do not appear to be assigned in an actual registry. IANA is unable to find these assigned in any SRV Protocol related registry. IANA understands that the authors are choosing not to requesting a new registry "RADIUS/TLS SRV Protocol Registry" to support the formal registration of those identifiers. Fifth, a new value will be registered in the "SMI Security for PKIX Module Identifier Registry" which is located in: in http://www.iana.org/assignments/smi-numbers IANA notes that the authors have provided the following for a description: TBD99 id-mod-nai-realm-08 [RFC-to-be] IANA Note --> As this document requests registrations in a Specification Required registry as per RFC7299, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Sixth, a new value will be registered in the "SMI Security for PKIX Other Name Forms Registry which is located in: in http://www.iana.org/assignments/smi-numbers IANA notes that the authors have provided the following for a description: TBD98 id-on-nai [RFC-to-be] IANA Note --> As this document requests registrations in a Specification Required registry as per RFC7299, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. IANA understands that these six actions are the only ones required to be ocmpleted upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Sat Mar 07 00:25:13 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the RADIUS EXTensions WG (radext) to > consider the following document: > - 'NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-20. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies a means to find authoritative RADIUS servers > for a given realm. It is used in conjunction with either RADIUS/TLS > and RADIUS/DTLS. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Fri Mar 20 11:23:27 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 8D2DF1A1A66; Thu, 19 Mar 2015 08:50:36 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 601811A1A64; Thu, 19 Mar 2015 08:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeJROapT7uVl; Thu, 19 Mar 2015 08:50:34 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 017031A1A0C; Thu, 19 Mar 2015 08:50:33 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2JFoXJf027070; Thu, 19 Mar 2015 15:50:33 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id C0B63C20366; Thu, 19 Mar 2015 15:50:33 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150307002447.20539.31287.idtracker@ietfa.amsl.com> References: <20150307002447.20539.31287.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #811747 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 19 Mar 2015 15:50:33 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:21 -0700 Cc: iesg@ietf.org, radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-dynamic-discovery.all@ietf.org Subject: [radext] [IANA #811747] Last Call: (NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 15:50:36 -0000 (BEGIN IANA LAST CALL COMMENTS) IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-radext-dynamic-discovery-13. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. We received the following comments/questions from the IANA's reviewer: IANA has questions for the IANA actions requested in this draft. Further, some of the new requested values require Expert review. IANA understands that, upon approval of this document, there are six actions which must be completed. First, in the S-NAPTR Application Service Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at: http://www.iana.org/assignments/s-naptr-parameters/ three, new service tags will be registered as follows: Tag: aaa+auth Reference: [ RFC-to-be ] Tag: aaa+accr Reference: [ RFC-to-be ] Tag: aaa+dynauth Reference: [ RFC-to-be ] IANA Note --> As this document requests registrations in a Specification Required (see RFC 5226) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Second, in the S-NAPTR Application Protocol Tags subregistry of the Straightforward-NAPTR (S-NAPTR) Parameters registry located at: http://www.iana.org/assignments/s-naptr-parameters/ two, new service tags will be registered as follows: Tag: radius.tls.tcp Reference: [ RFC-to-be ] Tag: radius.dtls.udp Reference: [ RFC-to-be ] IANA Note --> As above, this document requests registrations in a Specification Required registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, this document requests two service names - radiustls and radiusdtls - to be registered for both TCP and UDP in the Service Name and Transport Protocol Port Number Registry located at: http://www.iana.org/assignments/service-names-port-numbers Service Name: radiustls; radiusdtls Transport Protocols: TCP, UDP Assignee: IESG Contact: IETF Chair Description: Authentication, Accounting and Dynamic authorization via the RADIUS protocol. These service names are used to construct the SRV service labels "_radiustls" and "_radiusdtls" for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. Reference: [RFC-to-be] Question: What are the Defined TXT keys for each SRV names? The Defined TXT keys are required for SRV service names. The authors should submit a template at http://www.iana.org/form/ports-services for early allocation and put the Internet Draft as a reference according to RFC6335 as stated in section 8.1.1 of that document. Fourth, IANA understands that this draft makes use of the SRV Protocol identifiers "_tcp" and "_udp" which are mentioned as early as [RFC2782] but do not appear to be assigned in an actual registry. IANA is unable to find these assigned in any SRV Protocol related registry. IANA understands that the authors are choosing not to requesting a new registry "RADIUS/TLS SRV Protocol Registry" to support the formal registration of those identifiers. Fifth, a new value will be registered in the "SMI Security for PKIX Module Identifier Registry" which is located in: in http://www.iana.org/assignments/smi-numbers IANA notes that the authors have provided the following for a description: TBD99 id-mod-nai-realm-08 [RFC-to-be] IANA Note --> As this document requests registrations in a Specification Required registry as per RFC7299, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Sixth, a new value will be registered in the "SMI Security for PKIX Other Name Forms Registry which is located in: in http://www.iana.org/assignments/smi-numbers IANA notes that the authors have provided the following for a description: TBD98 id-on-nai [RFC-to-be] IANA Note --> As this document requests registrations in a Specification Required registry as per RFC7299, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. IANA understands that these six actions are the only ones required to be ocmpleted upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. Please note that IANA cannot reserve specific values. However, early allocation is available for some types of registrations. For more information, please see RFC 7120. Thanks, Pearl Liang ICANN (END IANA LAST CALL COMMENTS) On Sat Mar 07 00:25:13 2015, iesg-secretary@ietf.org wrote: > > The IESG has received a request from the RADIUS EXTensions WG (radext) to > consider the following document: > - 'NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS' > as Experimental RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2015-03-20. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies a means to find authoritative RADIUS servers > for a given realm. It is used in conjunction with either RADIUS/TLS > and RADIUS/DTLS. > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > From nobody Fri Mar 20 11:23:28 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 441581A8958; Fri, 20 Mar 2015 01:52:51 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B581A6F02 for ; Fri, 20 Mar 2015 01:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.709 X-Spam-Level: X-Spam-Status: No, score=-0.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y_AxGHwHYTXN for ; Fri, 20 Mar 2015 01:52:49 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3C21A877C for ; Fri, 20 Mar 2015 01:52:48 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id B392B4101D; Fri, 20 Mar 2015 09:52:46 +0100 (CET) Message-ID: <550BDFD9.2030700@restena.lu> Date: Fri, 20 Mar 2015 09:52:41 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: drafts-lastcall@iana.org References: <20150307002447.20539.31287.idtracker@ietfa.amsl.com> In-Reply-To: OpenPGP: id=8A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="L7OWSVNnQhN1n4kISwXa9CNsjMG8KdQv6" Archived-At: X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:20 -0700 Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org Subject: Re: [radext] [IANA #811747] Last Call: (NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 08:52:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --L7OWSVNnQhN1n4kISwXa9CNsjMG8KdQv6 Content-Type: multipart/mixed; boundary="------------070509060804030209020602" This is a multi-part message in MIME format. --------------070509060804030209020602 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, two comments: > First, in the S-NAPTR Application Service Tags subregistry of the > Straightforward-NAPTR (S-NAPTR) Parameters registry located at: >=20 > http://www.iana.org/assignments/s-naptr-parameters/ >=20 > three, new service tags will be registered as follows: >=20 > Tag: aaa+auth > Reference: [ RFC-to-be ] >=20 > Tag: aaa+accr > Reference: [ RFC-to-be ] >=20 > Tag: aaa+dynauth > Reference: [ RFC-to-be ] There is a typo in your mail: the draft registers aaa+acct (note a t at the end, like "accounTing"). All occurences in the draft are for acct; no mention at all of accr. > Third, this document requests two service names - radiustls and radiusd= tls - to be registered for both TCP and UDP in the Service Name and Trans= port Protocol Port Number Registry located at: >=20 > http://www.iana.org/assignments/service-names-port-numbers >=20 > Service Name: radiustls; radiusdtls >=20 > Transport Protocols: TCP, UDP >=20 > Assignee: IESG >=20 > Contact: IETF Chair >=20 > Description: Authentication, Accounting and Dynamic authorization= > via the RADIUS protocol. These service names are used to > construct the SRV service labels "_radiustls" and "_radiusdtls" > for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively= =2E >=20 > Reference: [RFC-to-be] >=20 >=20 > Question: What are the Defined TXT keys for each SRV names? > The Defined TXT keys are required for SRV service names. I think I disagree (but I'm not quite sure ;-) . Reading RFC6763 Section 6, I read: "Note that this requirement for a mandatory TXT record applies exclusively to DNS-SD service advertising, i.e., services advertised using the PTR+SRV+TXT convention specified in this document. It is not a requirement of SRV records in general. The DNS SRV record datatype [RFC2782] may still be used in other contexts without any requirement for accompanying PTR and TXT records." As defined in the draft, the service name is NOT registered for DNS-SD and makes no use of accompanying PTR and TXT records. It is defined following RFC2782, defining a "Name" in that RFCs notion and if anything has an accompanying NAPTR. Please advise if you still insist on the definiton of a TXT. > The authors should submit a template at http://www.iana.org/form/ports-= services for early allocation and put the Internet Draft as a reference a= ccording to RFC6335 as stated in section 8.1.1 of that document.=20 Will do. I've submitted the two forms without a TXT now, hoping that IANA's answer to the above is "TXT is not required". I believe the other four issues do not require intervention by the authors; these are between IANA and the experts. If I'm wrong, please let me know. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------070509060804030209020602 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------070509060804030209020602-- --L7OWSVNnQhN1n4kISwXa9CNsjMG8KdQv6 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 iQIcBAEBCgAGBQJVC9/eAAoJEMDeajWKOdxm+PoP/REM2jfRphqZ44NwexBYikPE kP+MKTLcndVgfoSb1DUfskuSCXp0ydeFQ6FchVm+pZhX37oaRLDvxSoxJQ9FhVE6 cJF2/TXpw943zRQFzLTPDSHlez3f1P/IVI8bnOdhCybDGQ/wdCFY54ikyXnyOvoD Sp/LOd0UX0s3J/txwtLCrgvDnqdhjYYMSZxtYTz2unDDtdQiMbPdGFNMqwqK2sgP U6JaSZ24kEpP3VWAVpptsDb5sp7HXXoqBUCadl0nUmX2wxoIxcot8DI8EOr3gR1e ntWFhcrrJWzgBeGBmvtU7TVQMIn7qWPy34UKZAPh85AtS+6BlqEFFEnHjiiqVoSc nFEKpez6K3C7x+ExG0bImNHEuKmKKyizCMGZzRzolu5194hpL331ZvzMABLOKv8k l69A/jZZiuLPFaiHz1P2NJ7z6zL/3p0K9bKJT4rquAyWhNI2wxbt7KN6c8V3TrYb ivAuUSb+PvwwoQG239UHn9GuZR5oYYNz+lx/t4fmA0aDafjWgg1U8wUJKQOCvmXY 0ta1pUiOqnJsktQOoY/oHOfSyLZFieMt24w3cBhvMUCIJpjWyotD8eSAzEUDpSs7 zJeSAjiL6eTzboxmBV+B82XA6CiZ862jtbSFi+YOWKuSjuE+tABhqG8ZWUZ+m0DM +1R+eDIn932wrgqdWTWZ =LqXh -----END PGP SIGNATURE----- --L7OWSVNnQhN1n4kISwXa9CNsjMG8KdQv6-- From nobody Fri Mar 20 11:23:29 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 31D231A89AE; Fri, 20 Mar 2015 10:05:09 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172FA1A6F2B; Fri, 20 Mar 2015 10:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tribzuSKgDhP; Fri, 20 Mar 2015 10:05:07 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 681071A1BCB; Fri, 20 Mar 2015 10:05:07 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2KH572s000796; Fri, 20 Mar 2015 17:05:07 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 2FDF9C203E9; Fri, 20 Mar 2015 17:05:07 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <550BDFD9.2030700@restena.lu> References: <20150307002447.20539.31287.idtracker@ietfa.amsl.com> <550BDFD9.2030700@restena.lu> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814387 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Fri, 20 Mar 2015 17:05:07 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 20 Mar 2015 11:23:21 -0700 Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, iesg@ietf.org, stefan.winter@restena.lu Subject: [radext] [IANA #814387] Re: Last Call: (NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Mar 2015 17:05:09 -0000 Hello, We received this message you sent on 09:52:41 GMT. Thanks, ~pl On Fri Mar 20 09:17:30 2015, stefan.winter@restena.lu wrote: > Hello, > > two comments: > > First, in the S-NAPTR Application Service Tags subregistry of the > > Straightforward-NAPTR (S-NAPTR) Parameters registry located at: > > > > http://www.iana.org/assignments/s-naptr-parameters/ > > > > three, new service tags will be registered as follows: > > > > Tag: aaa+auth > > Reference: [ RFC-to-be ] > > > > Tag: aaa+accr > > Reference: [ RFC-to-be ] > > > > Tag: aaa+dynauth > > Reference: [ RFC-to-be ] > > There is a typo in your mail: the draft registers aaa+acct (note a t > at > the end, like "accounTing"). All occurences in the draft are for acct; > no mention at all of accr. > > > Third, this document requests two service names - radiustls and > > radiusdtls - to be registered for both TCP and UDP in the Service > > Name and Transport Protocol Port Number Registry located at: > > > > http://www.iana.org/assignments/service-names-port-numbers > > > > Service Name: radiustls; radiusdtls > > > > Transport Protocols: TCP, UDP > > > > Assignee: IESG > > > > Contact: IETF Chair > > > > Description: Authentication, Accounting and Dynamic authorization > > via the RADIUS protocol. These service names are used to > > construct the SRV service labels "_radiustls" and "_radiusdtls" > > for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. > > > > Reference: [RFC-to-be] > > > > > > Question: What are the Defined TXT keys for each SRV names? > > The Defined TXT keys are required for SRV service names. > > I think I disagree (but I'm not quite sure ;-) . Reading RFC6763 > Section > 6, I read: > > "Note that this requirement for a mandatory TXT record applies > exclusively to DNS-SD service advertising, i.e., services > advertised > using the PTR+SRV+TXT convention specified in this document. It is > not a requirement of SRV records in general. The DNS SRV record > datatype [RFC2782] may still be used in other contexts without any > requirement for accompanying PTR and TXT records." > > As defined in the draft, the service name is NOT registered for DNS-SD > and makes no use of accompanying PTR and TXT records. It is defined > following RFC2782, defining a "Name" in that RFCs notion and if > anything > has an accompanying NAPTR. > > Please advise if you still insist on the definiton of a TXT. > > > The authors should submit a template at > > http://www.iana.org/form/ports-services for early allocation and put > > the Internet Draft as a reference according to RFC6335 as stated in > > section 8.1.1 of that document. > > Will do. I've submitted the two forms without a TXT now, hoping that > IANA's answer to the above is "TXT is not required". > > I believe the other four issues do not require intervention by the > authors; these are between IANA and the experts. If I'm wrong, please > let me know. > > Greetings, > > Stefan Winter From nobody Sun Mar 22 10:26:46 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id A8F6E1A1AB9; Sat, 21 Mar 2015 10:52:13 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADC31A1AAD for ; Sat, 21 Mar 2015 10:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LML5X7H7A_m3 for ; Sat, 21 Mar 2015 10:52:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FAA1A1A11 for ; Sat, 21 Mar 2015 10:52:11 -0700 (PDT) Received: from mail-oi0-x233.google.com ([2607:f8b0:4003:c06::233]:35141) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YZNZC-0004SL-Cg for draft-ietf-radext-dynamic-discovery.all@tools.ietf.org; Sat, 21 Mar 2015 10:52:11 -0700 Received: by oiag65 with SMTP id g65so113693480oia.2 for ; Sat, 21 Mar 2015 10:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=TlwHyEy+6c43pPvmN/n5EHrPc77xCpLrcOxCUPl72zU=; b=s7ZLlQvrqxEBNNOczV8tR+71bDy0ENvBIn4ZpA5672MWdod1C2n83+8xFeVLBmQiDO 5F1h4CKG7+KUcitUXVVlt29k839biK8JCYRjbEf0BVHdCL1JKIkY2rxDUXZqO6/IQedg hXe6lDa1jUq5xjrruRVuFFLwpiS5Phfk57WNPxNdYKzzUIvbP4luUzU6AK3wrG4FpQTb shd/jSuzZbY2N8S6JrPlKuVgiaa8vLz+xI9nVfF68zqHyRknEkSZmZnL510kBOoAYG9k NN4TnLvngylUZEV+ro2Vhw3IGXKFnVm9rK8X5NiOCEE6wm6hL/5Ac7mMup84qBH9jY5V b5rA== MIME-Version: 1.0 X-Received: by 10.182.210.197 with SMTP id mw5mr70549370obc.26.1426960321686; Sat, 21 Mar 2015 10:52:01 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Sat, 21 Mar 2015 10:52:01 -0700 (PDT) Date: Sat, 21 Mar 2015 10:52:01 -0700 Message-ID: From: Martin Thomson To: "gen-art@ietf.org" , draft-ietf-radext-dynamic-discovery.all@tools.ietf.org Content-Type: text/plain; charset=UTF-8 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c06::233 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery.all@tools.ietf.org X-SA-Exim-Mail-From: martin.thomson@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-radext-dynamic-discovery.all@ietf.org Resent-Message-Id: <20150321175211.91FAA1A1A11@ietfa.amsl.com> Resent-Date: Sat, 21 Mar 2015 10:52:11 -0700 (PDT) Resent-From: martin.thomson@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Sun, 22 Mar 2015 10:26:44 -0700 Subject: [radext] Gen-ART review of draft-ietf-radext-dynamic-discovery-13 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2015 17:52:13 -0000 I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-radext-dynamic-discovery-13 Reviewer: Martin Thomson Review Date: 2015-03-21 IETF LC End Date: 2015-03-20 IESG Telechat date: 2015-04-19 Summary: This document is of a quality I rarely see even for proposed standard. It is certainly fit for publication as an experimental RFC. (In case it isn't clear, I agree with the decision to choose experimental here, this is in a tricky area and deployment experience will validate choices.) Major issues: None Minor issues: S-NAPTR tags for RADIUS are defined, but none for Diameter. I'm sure this was considered, but it seems odd on first reading. S2.1.1.2 uses SHOULD to recommend that clients retry with their other certificates. I'd recommend use of MAY here, unless you would like to expand on why this a SHOULD is valuable. S2.1.1.3.3. I know that this is experimental and all, but this seems a little too hand-wavy even for that. I think that this is the right design, but the section could be a little more confident (and precise) in the description of how this works. It took me a couple of goes to understand how this was intended to work. One important realization was that a common root for the realm needs to be configured. I'd like to see this section expanded slightly (my initial inclination would have been toward removal, but the content is in line with the experiment, so it's probably valuable). S2.2 says: Since the Domain Name System is not necessarily trustworthy (e.g. if DNSSEC is not deployed for the queried domain name), it is important to verify that the server which was contacted is authorized to service requests for the user which triggered the discovery process. This implies that DNS integrity is the only reason for authentication. To paraphrase Steve Bellovin: you hand your packets to the attacker to deliver. Also: It MAY substitute labels on the leftmost dot- separated part of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". Use the singular form here to avoid confusion: It MAY substitute the leftmost dot- separated label of the NAI with the single character "*" to indicate a wildcard match for "all labels in this part". S3.4.1 is the first mention of UTF-8 realms, which are not permitted by RFC 4282. This was a point of confusion for me. I note that the new nai draft permits UTF-8 realms. Please just cite that and remove the reference to 4282. S 3.4.3 doesn't cover how to handle NAPTR records with flags set to "a", though other parts of the document describe that. I think there is some refactoring of the dependency on the S-NAPTR algorithm, and an allowance for a default port. Nits/editorial comments: S1.3 Capital 'P' on first bullet S2.1.1.1 Missing period on first note. S2.1.1.2 Please provide a reference for "Effective TTL". S2.1.1.3 s/PKS/PSK/ and "used for in the subsequent" (S2.1.3 Please be consistent with the trailing period in DNS record entries) 2.1.3.c. "x-" ugh...RFC 6648 S.3.4.4 "If these TTLs are very low, thrashing of connections becomes possible; the Effective TTL mitigates that risk." - isn't this the MIN_EFF_TTL instead? S3.4.4 the last MAY here can be a SHOULD, I think S5 "the result O can not be trusted" -> "the result of the discovery process can not be trusted" From nobody Sun Mar 22 12:35:38 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A729E1A0AFE for ; Sun, 22 Mar 2015 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.511 X-Spam-Level: X-Spam-Status: No, score=-0.511 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtUTTCbroChs for ; Sun, 22 Mar 2015 12:35:35 -0700 (PDT) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5F01A0A85 for ; Sun, 22 Mar 2015 12:35:35 -0700 (PDT) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 22 Mar 2015 12:35:34 -0700 Date: Sun, 22 Mar 2015 12:35:39 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <5502B836.5000100@restena.lu> Message-ID: References: <5502B836.5000100@restena.lu> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 19:35:36 -0000 On Fri, 13 Mar 2015, Stefan Winter wrote: > as you may recall, we discussed new charter text at IETF91, which was > unanimously accepted in the room. > We still need to verify consensus on the list, so below is the proposed > updated charter text. This mail starts a two week comment period on the > charter text. Please send your comments to the list until 2015-03-27 > 2400 UTC. > - CoA proxying. RFC 5176 permits proxying of CoA and Disconnect > messages, but makes no provisions for how that is done in a roaming > environment. This work item will provide descriptions of how to use the > Operator-Name attribute in a roaming environment to proxy CoA packets. > It will also define a new attribute which defines an opaque NAS > identifier which can be used to uniquely identify a visited NAS, and > whose value will not be modified when proxying, as is done with > NAS-Identifier and NAS-IP-Address. Recommend following text: - CoA proxying. RFC 5176 permits proxying of CoA and Disconnect messages, but makes no provisions for how that is done in a roaming environment. This work item will provide descriptions of how to proxy Dynamic Authorization messages using realm based proxy. It will also define a new attribute to assist the visited network in processing and forwarding Dynamic Authorization requests to appropriate NAS. While I generally support approach and associated draft draft-dekok-radext-coa-proxy-00.txt have some concerns and would prefer to keep some prescriptive details out of the charter. regards, Peter From nobody Sun Mar 22 15:00:15 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9529C1A1DE2 for ; Sun, 22 Mar 2015 15:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PZIQR9R7ZWQ for ; Sun, 22 Mar 2015 15:00:12 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABA2F1A1BD7 for ; Sun, 22 Mar 2015 15:00:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 16C942240484; Sun, 22 Mar 2015 22:59:42 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVFnk463_MUp; Sun, 22 Mar 2015 22:59:41 +0100 (CET) Received: from [192.168.20.49] (198-84-181-115.cpe.teksavvy.com [198.84.181.115]) by power.freeradius.org (Postfix) with ESMTPSA id 82AD5224036C; Sun, 22 Mar 2015 22:59:40 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Sun, 22 Mar 2015 17:59:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> References: <5502B836.5000100@restena.lu> To: Peter Deacon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Winter Stefan , "radext@ietf.org" Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Mar 2015 22:00:14 -0000 On Mar 22, 2015, at 3:35 PM, Peter Deacon = wrote: > While I generally support approach and associated draft = draft-dekok-radext-coa-proxy-00.txt have some concerns and would prefer = to keep some prescriptive details out of the charter. The only practical way to do CoA proxying is via Operator-Name. Which = is why it=92s mentioned. The use of an opaque NAS identifier was done = at the specific request of the WG. So I believe there is WG consensus = for the approach taken. The draft has been available for some time now. = The idea has been presented at meetings going back 3-4 years, IIRC. = The only discussion of this topic has been supportive of this approach = taken here. What exactly is the benefit of making the charter more vague? You = have =93some concerns=94. Well.. I would appreciate discussing those = concerns openly, instead of changing the charter to address unspecified = issues. Will the approach recommended here a) not work? b) not be applicable to some situations? c) cause problems? As we=92ve also seen, documents can be updated to reflect issues not = known at the time the charter was written. e.g. the extended attributes = document was worked on for years, and then tossed and re-written from = scratch. I think any concerns you may have can be addressed in the = document review, instead of via charter modifications. Alan DeKok. From nobody Sun Mar 22 17:44:07 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF7E61A86F4 for ; Sun, 22 Mar 2015 17:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OF92mowIa_X for ; Sun, 22 Mar 2015 17:44:05 -0700 (PDT) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2601A0046 for ; Sun, 22 Mar 2015 17:44:05 -0700 (PDT) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 22 Mar 2015 17:44:04 -0700 Date: Sun, 22 Mar 2015 17:44:10 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> Message-ID: References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="972663056-10393-1427064572=:3600" Content-ID: Archived-At: Cc: Winter Stefan , "radext@ietf.org" Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 00:44:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --972663056-10393-1427064572=:3600 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Sun, 22 Mar 2015, Alan DeKok wrote: > On Mar 22, 2015, at 3:35 PM, Peter Deacon wrote: >> While I generally support approach and associated draft >> draft-dekok-radext-coa-proxy-00.txt have some concerns and would prefer >> to keep some prescriptive details out of the charter. > What exactly is the benefit of making the charter more vague? You have > “some concerns”. Well.. I would appreciate discussing those concerns > openly, instead of changing the charter to address unspecified issues. My understanding this would be a new item rather than change to an existing WG work item currently on the charter. Stefan solicited feedback and I gave it. The CoA draft as written would certainly continue to fall under my proposed change. I am aware of nothing lost by proposed text. Concern regards intent of Operator-NAS-Identifier. Dynamic authorization allows multiple sessions to be influenced with single requests. Sufficient / required session identifying attributes varies between NASes and sometimes across access technologies within the same NAS. There are no further constraints expressed in draft on both required / acceptable session identifying attributes and method of initial authentication proxy (realm based or other policy based) So I'll throw the question back at you.. how the heck is this supposed to work? Proxy of DM following initial realm based auth proxy: Operator-Name Operator-NAS-Identifier Acct-Session-Id NAS-IP Proxy of DM following initial policy based auth proxy: Operator-Name Operator-NAS-Identifier User-Name NAS-IP When the upstream proxy in a forwarding chain gets the request how is it supposed to know whether it is safe to pass up the chain without either keeping a lot of state or verifying some kind of secure stateless signature/token conveyed within Operator-NAS-Identifier? Section 3.1 of the draft makes it clear Operator-NAS-Identifier is not just a fungible label for a generic state attribute with the "20 octets" language and associated removal of NAS-Identifying attributes. I see two opportunities: Get to working by constraining both means of authentication proxy and session identifying attributes. Or you can get there by keeping state at which point the language of Operator-NAS-Identifier in my judgment is insufficient. While it may well resolve any ambiguities as to "where" the request is going it does so while missing the larger problem. > The idea has been presented at meetings going back 3-4 years, IIRC. > The only discussion of this topic has been supportive of this approach > taken here. As earlier I also support the general "idea". regards, Peter --972663056-10393-1427064572=:3600-- From nobody Sun Mar 22 18:34:55 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB9C1A873E for ; Sun, 22 Mar 2015 18:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTc7MCGL-Gxa for ; Sun, 22 Mar 2015 18:34:52 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2041A873D for ; Sun, 22 Mar 2015 18:34:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5FFD12240484; Mon, 23 Mar 2015 02:34:51 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k0Rp2eCK8Tm; Mon, 23 Mar 2015 02:34:50 +0100 (CET) Received: from [192.168.20.49] (198-84-181-115.cpe.teksavvy.com [198.84.181.115]) by power.freeradius.org (Postfix) with ESMTPSA id D65E62240192; Mon, 23 Mar 2015 02:34:49 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Sun, 22 Mar 2015 21:34:47 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> To: Peter Deacon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 01:34:54 -0000 On Mar 22, 2015, at 8:44 PM, Peter Deacon = wrote: > My understanding this would be a new item rather than change to an = existing WG work item currently on the charter. Stefan solicited = feedback and I gave it. The CoA draft as written would certainly = continue to fall under my proposed change. I am aware of nothing lost = by proposed text. Deleting text is pretty much the dictionary definition of =93losing = something=94. > Concern regards intent of Operator-NAS-Identifier. >=20 > Dynamic authorization allows multiple sessions to be influenced with = single requests. Maybe I=92m misunderstanding something, but no. A CoA or = Disconnect-Request packet addresses *one* session with *one* request. = Nothing in RFC 5176 suggests otherwise. > Sufficient / required session identifying attributes varies between = NASes and sometimes across access technologies within the same NAS. = There are no further constraints expressed in draft on both required / = acceptable session identifying attributes and method of initial = authentication proxy (realm based or other policy based) Because the draft doesn=92t address session identification. It just = addresses proxying. RFC 5176 addresses session identification. Badly, = IMHO, but that=92s the WG consensus. No one could agree on a solution, = so it was left pretty much the same as RFC 3576. i.e. session identification is explicitly outside of the scope of this = document. > So I'll throw the question back at you.. how the heck is this supposed = to work? The document explains it=92s assumptions and operating model in great = detail. If you don=92t understand it, ask a *specific* question about a = part you don=92t understand. I see no reason to re-post the document = here to answer your question. > When the upstream proxy in a forwarding chain gets the request how is = it supposed to know whether it is safe to pass up the chain without = either keeping a lot of state or verifying some kind of secure stateless = signature/token conveyed within Operator-NAS-Identifier? A proxy isn=92t supposed to know if a packet is =93safe=94 to proxy. = It just proxies the packet. That=92s how RADIUS works. > Section 3.1 of the draft makes it clear Operator-NAS-Identifier is not = just a fungible label for a generic state attribute with the "20 octets" = language and associated removal of NAS-Identifying attributes. Exactly. It=92s NOT a =93generic state attribute=94. It=92s not = intended to be one. All of the text explains in excruciating detail = what it is, what it means, and how it=92s used. I fail to see how there = is any potential for confusion. > I see two opportunities: >=20 > Get to working by constraining both means of authentication proxy and = session identifying attributes. Any constraint on proxying is out of scope of this work item. Any = change to session identification attributes is out of scope of this work = item. > Or you can get there by keeping state at which point the language of = Operator-NAS-Identifier in my judgment is insufficient. While it may = well resolve any ambiguities as to "where" the request is going it does = so while missing the larger problem. I suggest writing a document which addresses that larger problem. = Don=92t try to extend this work item. >> The idea has been presented at meetings going back 3-4 years, IIRC. >> The only discussion of this topic has been supportive of this = approach taken here. >=20 > As earlier I also support the general "idea". Which is nice. If you want to write a document which describes how proxies can = maintain per-user session state, and filter proxied CoA packets based on = that information=85 go right ahead. But that subject is out of scope = for this document. Your charter changes would allow this document to include text on = session identification, which is probably why you=92re suggesting them. = The time to fix session identification with CoA was with RFC 5176. That = ship has sailed, the subject is closed. Everything you=92ve said convinces me that the proposed charter text = should stay the same. RFC 5176 allows CoA packets to be proxied, but = doesn=92t specify how that=92s done. This document specifies how CoA = packets are proxied in a roaming environment. That=92s it, that=92s = all. The document doesn=92t address session identification attributes. It = doesn=92t address generic state attributes. It doesn=92t address how = proxies maintain per-user session state. It doesn=92t address how = proxies =93filter=94 packets they receive. It doesn=92t address all = kinds of topics. That=92s fine. Other topics are for other documents. Alan DeKok. From nobody Sun Mar 22 21:14:33 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4C61A87CD for ; Sun, 22 Mar 2015 21:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fz5g8sE11cLt for ; Sun, 22 Mar 2015 21:14:31 -0700 (PDT) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 42BC11A87C7 for ; Sun, 22 Mar 2015 21:14:31 -0700 (PDT) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Sun, 22 Mar 2015 21:14:30 -0700 Date: Sun, 22 Mar 2015 21:14:36 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> Message-ID: References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="992167078-9685-1427084076=:3600" Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 04:14:33 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --992167078-9685-1427084076=:3600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Sun, 22 Mar 2015, Alan DeKok wrote: > On Mar 22, 2015, at 8:44 PM, Peter Deacon wrote: > Maybe I’m misunderstanding something, but no. A CoA or > Disconnect-Request packet addresses *one* session with *one* request. > Nothing in RFC 5176 suggests otherwise. RFC5176 Section 2.3 explains atomicity requirements while CoA or DM requests match multiple sessions. >> Sufficient / required session identifying attributes varies between >> NASes and sometimes across access technologies within the same NAS. >> There are no further constraints expressed in draft on both required / >> acceptable session identifying attributes and method of initial >> authentication proxy (realm based or other policy based) > Because the draft doesn’t address session identification. It just > addresses proxying. RFC 5176 addresses session identification. Badly, > IMHO, but that’s the WG consensus. No one could agree on a solution, so > it was left pretty much the same as RFC 3576. This an important reason why I believe state will be required in some cases to facilitate correlation in the event insufficient information is available to do so. I believe the mechanism to support can be fully opaque like Operator-NAS-Identifier and fully implementation dependant I advocate only enabling communication channel exist. I believe Operator-NAS-Identifier's constraints make it insufficient for this role otherwise it would be sufficient. Section 3.1 20 octets language is insufficient and automatic removal of NAS identifying attributes may be counterproductive. I do not advocate for fixing Dynamic authorization or session identifying attributes. I do not advocate for fixing Proxy. In previous remarks possible courses of action were enumerated to assist in demonstrating why state is needed by implementations. With regards to CoA draft I would support either a separate State attribute or loosening constraints of Operator-NAS-Identifier. Regardless of concerns specific to CoA draft appreciate any consideration of my recommendation. regards, Peter --992167078-9685-1427084076=:3600-- From nobody Mon Mar 23 04:24:16 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F131A8988 for ; Mon, 23 Mar 2015 04:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1N79TlbKega for ; Mon, 23 Mar 2015 04:24:13 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id E05CA1A1BA9 for ; Mon, 23 Mar 2015 04:24:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DED9F2240490; Mon, 23 Mar 2015 12:23:41 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuN6x_Re3uPQ; Mon, 23 Mar 2015 12:23:41 +0100 (CET) Received: from [192.168.20.49] (198-84-181-115.cpe.teksavvy.com [198.84.181.115]) by power.freeradius.org (Postfix) with ESMTPSA id 757832240168; Mon, 23 Mar 2015 12:23:40 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Mon, 23 Mar 2015 07:23:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> To: Peter Deacon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 11:24:15 -0000 On Mar 23, 2015, at 12:14 AM, Peter Deacon = wrote: > RFC5176 Section 2.3 explains atomicity requirements while CoA or DM = requests match multiple sessions. OK=85 I hadn=92t noticed that before. It still doesn=92t change my = opinion of the charter changes, though, > This an important reason why I believe state will be required in some = cases to facilitate correlation in the event insufficient information is = available to do so. Correlation of what? I find that sentence so vague that I don=92t = know what it means. The draft implements CoA proxying based on Operator-Name. This is = sufficient for all proxies to get the packet to the visited domain, = independent of anything else in the packet. The Operator-Name *is* = =93sufficient information=94 for all proxies. The proxies need no other = information, and can safely ignore every single other attribute in the = packet. The draft allows for the visited network to get the packet to the NAS = based on Operator-NAS-Identifier. This is sufficient for the visited = network to get the packet to the correct NAS, independent of anything = else in the packet. The Operator-NAS-Identifier is =93sufficient = information=94 for the visited network. It needs no other information, = and can safely ignore every single other attribute in the packet. The rest of the information in the packet is interpreted by the NAS. > I believe the mechanism to support can be fully opaque like = Operator-NAS-Identifier and fully implementation dependant I advocate = only enabling communication channel exist. To support=85 what? You=92re making some kind of assumption, and not = explaining it here. > I believe Operator-NAS-Identifier's constraints make it insufficient = for this role otherwise it would be sufficient. Section 3.1 20 octets = language is insufficient and automatic removal of NAS identifying = attributes may be counterproductive. Why? > I do not advocate for fixing Dynamic authorization or session = identifying attributes. I do not advocate for fixing Proxy. In = previous remarks possible courses of action were enumerated to assist in = demonstrating why state is needed by implementations. I read those remarks. I still have no idea why you think state is = needed. > With regards to CoA draft I would support either a separate State = attribute or loosening constraints of Operator-NAS-Identifier. A separate State attribute to do=85 what? > Regardless of concerns specific to CoA draft appreciate any = consideration of my recommendation. I have no idea what you=92re recommending. Please explain. Your = remarks are cryptic and unhelpful. Alan DeKok. From nobody Mon Mar 23 04:56:58 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 2FD371A897B; Mon, 23 Mar 2015 01:17:14 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8951A897A for ; Mon, 23 Mar 2015 01:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, WEIRD_PORT=0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ykjx3ND-cWDm for ; Mon, 23 Mar 2015 01:17:11 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADB7F1A8979 for ; Mon, 23 Mar 2015 01:17:11 -0700 (PDT) Received: from smtprelay.restena.lu ([158.64.1.62]:38822) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YZxXp-00015J-UM for draft-ietf-radext-dynamic-discovery.all@tools.ietf.org; Mon, 23 Mar 2015 01:17:11 -0700 Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 1F59C40BFE; Mon, 23 Mar 2015 09:16:59 +0100 (CET) Message-ID: <550FCBFA.8080008@restena.lu> Date: Mon, 23 Mar 2015 09:16:58 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Martin Thomson , "gen-art@ietf.org" , draft-ietf-radext-dynamic-discovery.all@tools.ietf.org References: In-Reply-To: OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="2blGEnF5E4ORorT7rCDpKgPbujXiKL9MX" X-SA-Exim-Connect-IP: 158.64.1.62 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery.all@tools.ietf.org X-SA-Exim-Mail-From: stefan.winter@restena.lu X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-radext-dynamic-discovery.all@ietf.org Resent-Message-Id: <20150323081711.ADB7F1A8979@ietfa.amsl.com> Resent-Date: Mon, 23 Mar 2015 01:17:11 -0700 (PDT) Resent-From: stefan.winter@restena.lu Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 04:56:57 -0700 Subject: Re: [radext] Gen-ART review of draft-ietf-radext-dynamic-discovery-13 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 08:17:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --2blGEnF5E4ORorT7rCDpKgPbujXiKL9MX Content-Type: multipart/mixed; boundary="------------090907030509080201070202" This is a multi-part message in MIME format. --------------090907030509080201070202 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, thanks for those kind words :-) > Minor issues: >=20 > S-NAPTR tags for RADIUS are defined, but none for Diameter. I'm sure > this was considered, but it seems odd on first reading. Diameter defines its own S-NAPTR tags in its own RFCs - see the IANA registry at https://www.iana.org/assignments/s-naptr-parameters/s-naptr-parameters.xh= tml#s-naptr-parameters-2 for a list. The authors if the current RADIUS draft were aware of that and have defined the radius tags exactly analogous to the Diameter ones (e.g. diameter.tls.tcp matches radius.tls.tcp). > S2.1.1.2 uses SHOULD to recommend that clients retry with their other > certificates. I'd recommend use of MAY here, unless you would like to > expand on why this a SHOULD is valuable. Well... realm discovery is triggered typically by an end user trying to authenticate. If a client has a certificate but doesn't want to show it, this becomes an avoidable DoS for the user. Also, if the client doesn't always try the certificates in the same order, the connection setup also becomes indeterministic - sometimes it works, sometimes not. The clause makes a case for "don't give up prematurely" and makes the behaviour deterministic. So, I believe a SHOULD is the right thing to ask for here - would you prefer an updated draft with this reasoning included, or are the explanations in this mail sufficient? > S2.1.1.3.3. I know that this is experimental and all, but this seems a > little too hand-wavy even for that. I think that this is the right > design, but the section could be a little more confident (and precise) > in the description of how this works. It took me a couple of goes to > understand how this was intended to work. One important realization > was that a common root for the realm needs to be configured. I'd like > to see this section expanded slightly (my initial inclination would > have been toward removal, but the content is in line with the > experiment, so it's probably valuable). Oh, it's totally handwavy, agreed :-) The mechanism described here is not implemented anywhere, and DANE in general only deals with the server-side auth, leaving a gaping hole on the question how to validate client certs. So, it really is just a sketch - that's why I used that word in the text. Actually I find that approach rather elegant, but it would take people with a lot of energy to pick it up, complete the DANE specs for client-side auth, implement TLS libraries that can do this, and to actually deploy it. I'm not sure I know how to handle your comment text-wise... when it comes to the need of a common root, I would have hoped that there is already text making it clear, i.e.: "if DANE/TLSA records of all authorized servers are put into a DNSSEC zone with a common, consortium-specific branch of the DNS tree, then the entity executing the algorithm can retrieve TLSA Resource Records (TLSA RR) for the label "realm.commonroot" [...]" If you can suggest specific text that helps readers understand this easier, I'm all ears... > S2.2 says: > Since the Domain Name System is not > necessarily trustworthy (e.g. if DNSSEC is not deployed for the > queried domain name), it is important to verify that the server whic= h > was contacted is authorized to service requests for the user which > triggered the discovery process. >=20 > This implies that DNS integrity is the only reason for authentication. > To paraphrase Steve Bellovin: you hand your packets to the attacker to > deliver. Hmm... that text indeed is wrong / comes across badly. Actually, even if DNS is trustworthy, the authorisation needs to be checked. It's more like: (new) "Regardless whether the results from DNS discovery are trustworthy or not (e.g. DNSSEC in use), it is always important to verify that the server which was contacted is authorized to service requests for the user which triggered the discovery process." I've updated my working copy with that change; waiting for AD go-ahead to publish a -14 eventually. (What I planned to say there was that if DNS without SEC is used, not only the authorisation is in question and needs to be checked, but also the discovered IP/port; but that's not totally important in itself because the authorisation check comes unconditionally and covers both anyway) > Also: > It MAY substitute labels on the leftmost dot- > separated part of the NAI with the single character "*" to indicate = a > wildcard match for "all labels in this part". > Use the singular form here to avoid confusion: > It MAY substitute the leftmost dot- > separated label of the NAI with the single character "*" to indicate= a > wildcard match for "all labels in this part". Thanks, changed in my working copy. > S3.4.1 is the first mention of UTF-8 realms, which are not permitted > by RFC 4282. This was a point of confusion for me. I note that the > new nai draft permits UTF-8 realms. Please just cite that and remove > the reference to 4282. Right, currently the draft mentions both (see Terminology), but meanwhile the publication of the new NAI document is imminent, so 4282 can go away. I've purged it from my working copy. > S 3.4.3 doesn't cover how to handle NAPTR records with flags set to > "a", though other parts of the document describe that. I think there > is some refactoring of the dependency on the S-NAPTR algorithm, and an > allowance for a default port. That's already done in step 9, which basically hands off further resolution to S-NAPTR by stating: "For the extracted NAPTRs, perform successive resolution as defined in [RFC3958], section 2.2." If anything, poiting to section 2.2 is maybe too specific, because many parts of RFC3958 are about "s" and "a" NAPTR entries; do you think it makes the document more readable if I remove the "section 2.2" ? > Nits/editorial comments: >=20 > S1.3 Capital 'P' on first bullet Changed to lower case. > S2.1.1.1 Missing period on first note. Fixed, thanks. > S2.1.1.2 Please provide a reference for "Effective TTL". Effective TTL is defined in section 3.3 ("Terms"); I've added a forward-reference. > S2.1.1.3 s/PKS/PSK/ and "used for in the subsequent" Fixed and changed to just "in" (deleted "for") > (S2.1.3 Please be consistent with the trailing period in DNS record ent= ries) Added plenty of dots. > 2.1.3.c. "x-" ugh...RFC 6648 I believe eduroam's decision to make use of x-eduroam significantly predates RFC6648. In any case, that's how they use it; the draft just documents reality, however frowned-upon that reality may be :-) > S.3.4.4 "If these > TTLs are very low, thrashing of connections becomes possible; the > Effective TTL mitigates that risk." - isn't this the MIN_EFF_TTL ins= tead? Well, both - Effective TTL has MIN_EFF_TTL as one of its parameters. In a way, having MIN_EFF_TTL somewhere in the calculation prevents the thrashing; if looked at from a different angle, only Effective TTLs wise inclusion of that MIN_EFF_TTL in its calculations is the neuralgic spot that actually prevents it. So, I don't care. Do you insist on a text change? > S3.4.4 the last MAY here can be a SHOULD, I think Sounds reasonable. Changed. > S5 "the result O can not be trusted" -> "the result of the discovery > process can not be trusted" Changed. Thanks much for the review! Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------090907030509080201070202 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------090907030509080201070202-- --2blGEnF5E4ORorT7rCDpKgPbujXiKL9MX 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 iQIcBAEBCgAGBQJVD8v6AAoJEMDeajWKOdxm89YP/1y1pMS3bKcW0hOVobNxoWK6 P+R4vEqrhjT8ug/xWZ1mrChWCsyxDwPQtuTFU4rm6V/g5LghmUcJ3S5bYNCDY7Jc F7lnIsdHogGUdN6bsxEVcgd015KQIu99eqZzLbodyUSqc3FlvZerltc/CrJ72SMp HOwvV+7oLp4kSFFh9ZBWVDs1IG/fWHXXkXGuS6UAzt+lxRDkRm+DRX8qsvOZ8Azo Zd9TBW+MVJIO7onDyf3+acY20JzfBvufGQ85s0x/8Ls+3Iqz/mMJ5PLPCQ2sZvCB 7rIHIPVniLpBHtxgdxfBAuTJ4PZSkGawizYujduJjNmLpPyJYF03nn7s9gnVzvwt IMBWVfnRBEeKACzAvqvSf3dZcL7MhoSIOf/judabDbTYoVYXFGGUp6PHC/8nvg9e me0IPpk2uB7IyQgHL32KS9zHpSYpAMnXwY7TvDmTM7RcJ17WEpl2ly2PBtoj7SxM Cq6mclYp8/Vwp57W8Il7jn1lQf5ZjyOvnjOUovxRWdWAMSO3tK8bKgGSGg43Dq8V ht1wFmUbWx6TNAwdzne6shc5lGzktxW2YxeKTmVwtOPlaymczVoTXBdKJFcNWtfE DAtK4BmAY76nv1Sc08waRqMEwkXjQR9bj3ZadcY6ebR6N/HuFAkyNGwvgJMHJnuC dc7tMLUFljUN4v2Yij5V =veW/ -----END PGP SIGNATURE----- --2blGEnF5E4ORorT7rCDpKgPbujXiKL9MX-- From nobody Mon Mar 23 04:56:59 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F481A00E2 for ; Mon, 23 Mar 2015 01:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLR3GLYj1Dsw for ; Mon, 23 Mar 2015 01:40:42 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CC191A00DF for ; Mon, 23 Mar 2015 01:40:42 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 3BD5F41038; Mon, 23 Mar 2015 09:40:41 +0100 (CET) Message-ID: <550FD189.9050600@restena.lu> Date: Mon, 23 Mar 2015 09:40:41 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Kathleen Moriarty , Alan DeKok References: <20150224204147.6CCC6181B3D@rfc-editor.org> <9BE727B3-42D6-4C3C-84E5-398B32D2D538@freeradius.org> In-Reply-To: OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="a58QRS7MEsh2UV4LLrjH9AOOWeMLwv8hR" Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 04:56:57 -0700 Cc: "gdommety@cisco.com" , "radext@ietf.org" , "lionel.morand@orange.com" , "joelja@bogus.com" , Bernard Aboba , "david@mitton.com" , "bclaise@cisco.com" , "meklund@cisco.com" , "mchiba@cisco.com" , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5176 (4280) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 08:40:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --a58QRS7MEsh2UV4LLrjH9AOOWeMLwv8hR Content-Type: multipart/mixed; boundary="------------030406020006020800080204" This is a multi-part message in MIME format. --------------030406020006020800080204 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello, > Is there agreement on the changes and do additional errata need to be > filed for the added text in this thread? There was no disagreement on the Errata - it seems to be correct. I'm not enough into process questions to answer the second part, so: the text sketches make sense, but do we need to file a second errata, or can we "mangle" the original errata text to include this? Seems a bit strange to me to have two Errata for one underlying issue; I'd prefer to have all changes in one ... Since most of you are in Denver, maybe shortly touching this question in the meeting makes sense? Greetings, Stefan Winter >=20 > Thank you, > Kathleen >=20 > On Wed, Feb 25, 2015 at 9:46 AM, Alan DeKok > wrote: >=20 > I agree. There should be an additional paragraph after the > paragraph below, saying: >=20 > ... > Error-Cause MAY be included in a CoA-ACK and Disconnect-ACK pack= et to > indicate successful actions. If it is included in those packets= , > the Value MUST > be within the range 200-299. > ... >=20 > There is further discussion of CoA-ACK in the text describing the= > allowed VALUEs. But there should be a short sentence in the > Description, too. >=20 > On Feb 24, 2015, at 6:07 PM, Bernard Aboba > > > wrote: >=20 > > The Description text should also be addressed in this Errata: > > > > Description > > > > It is possible that a Dynamic Authorization Server cannot ho= nor > > Disconnect-Request or CoA-Request packets for some reason. = The > > Error-Cause Attribute provides more detail on the cause of t= he > > problem. It MAY be included within CoA-NAK and Disconnect-N= AK > > packets. > > > > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org > ] > > Sent: Tuesday, February 24, 2015 12:42 PM > > To: mchiba@cisco.com ; gdommety@cisco.co= m > ; meklund@cisco.com > ; david@mitton.com > ; Bernard Aboba; bclaise@cisco.com > ; joelja@bogus.com > ; stefan.winter@restena.lu > ; lionel.morand@orange.com > > > Cc: aland@freeradius.org ; > radext@ietf.org ; rfc-editor@rfc-editor.org= > > > Subject: [Technical Errata Reported] RFC5176 (4280) > > > > The following errata report has been submitted for RFC5176, > "Dynamic Authorization Extensions to Remote Authentication Dial In > User Service (RADIUS)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D4280= > > > > -------------------------------------- > > Type: Technical > > Reported by: Alan DeKok > > > > > Section: 3.6 > > > > Original Text > > ------------- > > 0 0 0+ 101 Error-Cause > > > > > > In both tables, for CoA and Disconnect messages. > > > > Corrected Text > > -------------- > > 0 0+ 0+ 101 Error-Cause > > > > > > In both tables, for CoA and Disconnect messages. > > > > Notes > > ----- > > Section 3.5 says that Error-Cause may be sent in a CoA-ACK or > Disconnect-ACK packet: > > > > ... > > Values 200-299 represent successful completion, so that thes= e > > values may only be sent within CoA-ACK or Disconnect-ACK pac= kets > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, > please use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) ca= n > log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5176 (draft-ietf-radext-rfc3576bis-13) > > -------------------------------------- > > Title : Dynamic Authorization Extensions to Remote > Authentication Dial In User Service (RADIUS) > > Publication Date : January 2008 > > Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton,= > B. Aboba > > Category : INFORMATIONAL > > Source : RADIUS EXTensions > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 >=20 >=20 >=20 > --=20 >=20 > Best regards, > Kathleen >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------030406020006020800080204 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------030406020006020800080204-- --a58QRS7MEsh2UV4LLrjH9AOOWeMLwv8hR 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 iQIcBAEBCgAGBQJVD9GJAAoJEMDeajWKOdxmO/YP/0TAjEl1F0xcGZ4sD0wECmCG VBPCfITjjlNOsWgTA86FIFsvsqx6zwle95kMtJF/YQeyVi8eqfkIcoV4kf5/hRLp stbCEETzAU+NO+85WKSBpr5Jh21A4DXmGxJMTTDyAcbHqPEFrxl1x95QYGQ8NOYA C6TwmgwzyMoSGXnNVWfh41iyZCzFY/dhEDXowzn2KMZLhqonaky0TOv/t5mPpWI6 M2E//k9+k4eegk4kJf+MhoykYQ8bJzuY4s5BCGR+S0Wy3lVzpWdasqsJQ7qZEdmL QCjhksYSoHgQPA1WEvz1+fVNx4tgWodB3ZzTNuIfuIJrlveTeHdVzUWuszmdF9kx JcfI7XpodypyThArV9DGsbgfxR6m1R2x1b/CwRmEaOwhDvkD6zw2he995557gior vPltrgNOKqTMKHAf5JKB8y8yBltTpdbJ0mDlDw1iitiQgbDClpBC5ixlYSeylfsB +/lgh4e995gBhwIBKB1+R9tSlo+Nh5ce+TezUy1ah994C+1/3HdoiBk/Ac00ILH1 GveEq/b3yUjF58wUPi8EklwRJmkpUK1ugGNzKhPnyYmdF+BmgcYoGybG8+NsoYUs ADYQGUE/tfRpKlo4qnG+NwToRziDTNd0NK3QMBuhNIjo2xf55BWkEETRpaPtkL7m 9VFL7DZ38fpf/yODqIDg =+T8c -----END PGP SIGNATURE----- --a58QRS7MEsh2UV4LLrjH9AOOWeMLwv8hR-- From nobody Mon Mar 23 07:15:27 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 618D91A8AB6; Mon, 23 Mar 2015 07:06:49 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6481A8A8F for ; Mon, 23 Mar 2015 07:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.334 X-Spam-Level: X-Spam-Status: No, score=-1.334 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8r71V1k-9AP for ; Mon, 23 Mar 2015 07:06:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D129A1A8A84 for ; Mon, 23 Mar 2015 07:06:47 -0700 (PDT) Received: from mail-ob0-x22c.google.com ([2607:f8b0:4003:c01::22c]:32931) by zinfandel.tools.ietf.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Ya30A-0006XW-No for draft-ietf-radext-dynamic-discovery.all@tools.ietf.org; Mon, 23 Mar 2015 07:06:47 -0700 Received: by obcxo2 with SMTP id xo2so123659345obc.0 for ; Mon, 23 Mar 2015 07:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QJW9JQi3puyJLvWAodwNchx7V1jzQanz85hZPs+QE2U=; b=grJ5D4dAjzVHgF/e5DZQheXyltp/XWc3SKazdA1s0tNEi2ZiuIVrxQQ5XX5dzsr6y5 AHQ3C6R9SegUpDH9F094Ocfa3BqPQn1XUnBbT9EABOpDOD8nYhjpYYAlpuLpev4o3wtJ CCw9C3u78arLOg2Fj9zfepvWtXjLVXHZ3x5qk2L9CfXdax1UB+9T9EmwbM+UEg/KuZEF nHcjpb/aG0J56LKbdpX2XNzxx7iwahPHBZWfx2FLKxGzE9uFT9ZttUQz2pcb8edj4Oag 6aEr5c2jpGZIloBpdDLmTfSpaAC1vZ/SJMUqp5vr9HcUdUMavkgn8oCM53gz28vtm/bc xXdw== MIME-Version: 1.0 X-Received: by 10.202.64.9 with SMTP id n9mr70519555oia.20.1427119597949; Mon, 23 Mar 2015 07:06:37 -0700 (PDT) Received: by 10.202.48.151 with HTTP; Mon, 23 Mar 2015 07:06:37 -0700 (PDT) In-Reply-To: <550FCBFA.8080008@restena.lu> References: <550FCBFA.8080008@restena.lu> Date: Mon, 23 Mar 2015 07:06:37 -0700 Message-ID: From: Martin Thomson To: Stefan Winter Content-Type: text/plain; charset=UTF-8 X-SA-Exim-Connect-IP: 2607:f8b0:4003:c01::22c X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery.all@tools.ietf.org X-SA-Exim-Mail-From: martin.thomson@gmail.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-radext-dynamic-discovery.all@ietf.org Resent-Message-Id: <20150323140647.D129A1A8A84@ietfa.amsl.com> Resent-Date: Mon, 23 Mar 2015 07:06:47 -0700 (PDT) Resent-From: martin.thomson@gmail.com Archived-At: Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 07:15:26 -0700 Cc: "gen-art@ietf.org" , draft-ietf-radext-dynamic-discovery.all@tools.ietf.org Subject: Re: [radext] Gen-ART review of draft-ietf-radext-dynamic-discovery-13 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 14:06:49 -0000 Thanks. I think that you have everything in hand. I'm happy with the promised changes. On 23 March 2015 at 01:16, Stefan Winter wrote: > Diameter defines its own S-NAPTR tags in its own RFCs Ack. >> S2.1.1.2 uses SHOULD to recommend that clients retry with their other >> certificates. I'd recommend use of MAY here, unless you would like to >> expand on why this a SHOULD is valuable. > > Well... realm discovery is triggered typically by an end user trying to > authenticate. If a client has a certificate but doesn't want to show it, > this becomes an avoidable DoS for the user. Also, if the client doesn't > always try the certificates in the same order, the connection setup also > becomes indeterministic - sometimes it works, sometimes not. > > The clause makes a case for "don't give up prematurely" and makes the > behaviour deterministic. > > So, I believe a SHOULD is the right thing to ask for here - would you > prefer an updated draft with this reasoning included, or are the > explanations in this mail sufficient? I think that mentioning the consequences would be wise. The incentives are certainly properly aligned. (I do worry about the inordinate number of protocol steps this is going to introduce, but I guess that is the point of the experiment.) >> S2.1.1.3.3. I know that this is experimental and all, but this seems a >> little too hand-wavy even for that. I think that this is the right >> design, but the section could be a little more confident (and precise) >> in the description of how this works. It took me a couple of goes to >> understand how this was intended to work. One important realization >> was that a common root for the realm needs to be configured. I'd like >> to see this section expanded slightly (my initial inclination would >> have been toward removal, but the content is in line with the >> experiment, so it's probably valuable). > > Oh, it's totally handwavy, agreed :-) The mechanism described here is > not implemented anywhere, and DANE in general only deals with the > server-side auth, leaving a gaping hole on the question how to validate > client certs. So, it really is just a sketch - that's why I used that > word in the text. > > Actually I find that approach rather elegant, but it would take people > with a lot of energy to pick it up, complete the DANE specs for > client-side auth, implement TLS libraries that can do this, and to > actually deploy it. > > I'm not sure I know how to handle your comment text-wise... when it > comes to the need of a common root, I would have hoped that there is > already text making it clear, i.e.: > > "if > DANE/TLSA records of all authorized servers are put into a DNSSEC > zone with a common, consortium-specific branch of the DNS tree, then > the entity executing the algorithm can retrieve TLSA Resource Records > (TLSA RR) for the label "realm.commonroot" [...]" > > If you can suggest specific text that helps readers understand this > easier, I'm all ears... Much of the rest of the document is more precise about the steps involved. I got the sense that the DANE text was rushed or cursory. I'd rather see a more precise description of the steps that a client would use; or the text could be removed; or the text could be reduced to something even more vague ("You could use TLSA records for this.") > Actually, even if DNS is trustworthy, the authorisation needs to be > checked. It's more like: > > (new) > "Regardless whether the results from DNS discovery are trustworthy or > not (e.g. DNSSEC in use), it is always important to verify that the > server which was contacted is authorized to service requests for the > user which triggered the discovery process." WFM > (What I planned to say there was that if DNS without SEC is used, not > only the authorisation is in question and needs to be checked, but also > the discovered IP/port; but that's not totally important in itself > because the authorisation check comes unconditionally and covers both > anyway) Right. >> S 3.4.3 doesn't cover how to handle NAPTR records with flags set to >> "a", though other parts of the document describe that. I think there >> is some refactoring of the dependency on the S-NAPTR algorithm, and an >> allowance for a default port. > > That's already done in step 9, which basically hands off further > resolution to S-NAPTR by stating: "For the extracted NAPTRs, perform > successive resolution as defined in [RFC3958], section 2.2." > > If anything, poiting to section 2.2 is maybe too specific, because many > parts of RFC3958 are about "s" and "a" NAPTR entries; do you think it > makes the document more readable if I remove the "section 2.2" ? No, that's fine. I was just concerned about the port part; I see that it is there, but it's fairly obtuse. (My reaction is partly in error: I was relying on my memory of 3958 a little too much.) [...] From nobody Mon Mar 23 09:01:06 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBC81A8F4D for ; Mon, 23 Mar 2015 08:21:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxQNyFs3F-Mg for ; Mon, 23 Mar 2015 08:21:23 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBD11A89FF for ; Mon, 23 Mar 2015 08:21:22 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 9B7441B8119; Mon, 23 Mar 2015 16:21:20 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 6D64B38406B; Mon, 23 Mar 2015 16:21:20 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 16:21:19 +0100 From: To: Stefan Winter , Kathleen Moriarty , Alan DeKok Thread-Topic: [radext] [Technical Errata Reported] RFC5176 (4280) Thread-Index: AQHQZUUNgQ9E5L6DoUSDHImUavRR6Z0qKrvw Date: Mon, 23 Mar 2015 15:21:19 +0000 Message-ID: <16769_1427124080_55102F70_16769_5008_1_6B7134B31289DC4FAF731D844122B36EE83D0A@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <20150224204147.6CCC6181B3D@rfc-editor.org> <9BE727B3-42D6-4C3C-84E5-398B32D2D538@freeradius.org> <550FD189.9050600@restena.lu> In-Reply-To: <550FD189.9050600@restena.lu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.23.75418 Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 09:01:03 -0700 Cc: "gdommety@cisco.com" , "radext@ietf.org" , "joelja@bogus.com" , Bernard Aboba , "david@mitton.com" , "bclaise@cisco.com" , "meklund@cisco.com" , "mchiba@cisco.com" , RFC Errata System Subject: Re: [radext] [Technical Errata Reported] RFC5176 (4280) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 15:21:26 -0000 Hi, I think also that two separate Errata should be created. Regards, Lionel -----Message d'origine----- De=A0: Stefan Winter [mailto:stefan.winter@restena.lu]=20 Envoy=E9=A0: lundi 23 mars 2015 09:41 =C0=A0: Kathleen Moriarty; Alan DeKok Cc=A0: gdommety@cisco.com; radext@ietf.org; MORAND Lionel IMT/OLN; joelja@b= ogus.com; Bernard Aboba; david@mitton.com; bclaise@cisco.com; meklund@cisco= .com; mchiba@cisco.com; RFC Errata System Objet=A0: Re: [radext] [Technical Errata Reported] RFC5176 (4280) Hello, > Is there agreement on the changes and do additional errata need to be=20 > filed for the added text in this thread? There was no disagreement on the Errata - it seems to be correct. I'm not enough into process questions to answer the second part, so: the te= xt sketches make sense, but do we need to file a second errata, or can we "= mangle" the original errata text to include this? Seems a bit strange to me= to have two Errata for one underlying issue; I'd prefer to have all change= s in one ... Since most of you are in Denver, maybe shortly touching this question in th= e meeting makes sense? Greetings, Stefan Winter >=20 > Thank you, > Kathleen >=20 > On Wed, Feb 25, 2015 at 9:46 AM, Alan DeKok > wrote: >=20 > I agree. There should be an additional paragraph after the > paragraph below, saying: >=20 > ... > Error-Cause MAY be included in a CoA-ACK and Disconnect-ACK packet= to > indicate successful actions. If it is included in those packets, > the Value MUST > be within the range 200-299. > ... >=20 > There is further discussion of CoA-ACK in the text describing the > allowed VALUEs. But there should be a short sentence in the > Description, too. >=20 > On Feb 24, 2015, at 6:07 PM, Bernard Aboba > > > wrote: >=20 > > The Description text should also be addressed in this Errata: > > > > Description > > > > It is possible that a Dynamic Authorization Server cannot honor > > Disconnect-Request or CoA-Request packets for some reason. The > > Error-Cause Attribute provides more detail on the cause of the > > problem. It MAY be included within CoA-NAK and Disconnect-NAK > > packets. > > > > > > -----Original Message----- > > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org > ] > > Sent: Tuesday, February 24, 2015 12:42 PM > > To: mchiba@cisco.com ; gdommety@cisco.com > ; meklund@cisco.com > ; david@mitton.com > ; Bernard Aboba; bclaise@cisco.com > ; joelja@bogus.com > ; stefan.winter@restena.lu > ; lionel.morand@orange.com > > > Cc: aland@freeradius.org ; > radext@ietf.org ; rfc-editor@rfc-editor.org > > > Subject: [Technical Errata Reported] RFC5176 (4280) > > > > The following errata report has been submitted for RFC5176, > "Dynamic Authorization Extensions to Remote Authentication Dial In > User Service (RADIUS)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=3D5176&eid=3D4280 > > > > -------------------------------------- > > Type: Technical > > Reported by: Alan DeKok > > > > > Section: 3.6 > > > > Original Text > > ------------- > > 0 0 0+ 101 Error-Cause > > > > > > In both tables, for CoA and Disconnect messages. > > > > Corrected Text > > -------------- > > 0 0+ 0+ 101 Error-Cause > > > > > > In both tables, for CoA and Disconnect messages. > > > > Notes > > ----- > > Section 3.5 says that Error-Cause may be sent in a CoA-ACK or > Disconnect-ACK packet: > > > > ... > > Values 200-299 represent successful completion, so that these > > values may only be sent within CoA-ACK or Disconnect-ACK packe= ts > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, > please use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) can > log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5176 (draft-ietf-radext-rfc3576bis-13) > > -------------------------------------- > > Title : Dynamic Authorization Extensions to Remote > Authentication Dial In User Service (RADIUS) > > Publication Date : January 2008 > > Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, > B. Aboba > > Category : INFORMATIONAL > > Source : RADIUS EXTensions > > Area : Operations and Management > > Stream : IETF > > Verifying Party : IESG > > >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 >=20 >=20 >=20 > -- >=20 > Best regards, > Kathleen >=20 >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Nationale = et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient= 's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon Mar 23 10:01:25 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 119AF1ACD94; Mon, 23 Mar 2015 09:45:48 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2EB31ACD93; Mon, 23 Mar 2015 09:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, J_CHICKENPOX_37=0.6, J_CHICKENPOX_55=0.6, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNI_R9jdeZHd; Mon, 23 Mar 2015 09:45:45 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 182951ACD7A; Mon, 23 Mar 2015 09:45:31 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2NGjUgS000692; Mon, 23 Mar 2015 16:45:30 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id CE51EC20682; Mon, 23 Mar 2015 16:45:30 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: <20150307002447.20539.31287.idtracker@ietfa.amsl.com> <550BDFD9.2030700@restena.lu> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814387 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 23 Mar 2015 16:45:30 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 10:01:22 -0700 Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, iesg@ietf.org, stefan.winter@restena.lu Subject: [radext] [IANA #814387] Re: Last Call: (NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS) to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-lastcall@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:45:48 -0000 Hello, Please see inline comments. On Fri Mar 20 17:05:06 2015, pearl.liang wrote: > Hello, > > We received this message you sent on 09:52:41 GMT. > > Thanks, > ~pl > > On Fri Mar 20 09:17:30 2015, stefan.winter@restena.lu wrote: > > Hello, > > > > two comments: > > > First, in the S-NAPTR Application Service Tags subregistry of the > > > Straightforward-NAPTR (S-NAPTR) Parameters registry located at: > > > > > > http://www.iana.org/assignments/s-naptr-parameters/ > > > > > > three, new service tags will be registered as follows: > > > > > > Tag: aaa+auth > > > Reference: [ RFC-to-be ] > > > > > > Tag: aaa+accr > > > Reference: [ RFC-to-be ] > > > > > > Tag: aaa+dynauth > > > Reference: [ RFC-to-be ] > > > > There is a typo in your mail: the draft registers aaa+acct (note a t > > at > > the end, like "accounTing"). All occurences in the draft are for acct; > > no mention at all of accr. > > Thanks for catching that. > > > Third, this document requests two service names - radiustls and > > > radiusdtls - to be registered for both TCP and UDP in the Service > > > Name and Transport Protocol Port Number Registry located at: > > > > > > http://www.iana.org/assignments/service-names-port-numbers > > > > > > Service Name: radiustls; radiusdtls > > > > > > Transport Protocols: TCP, UDP > > > > > > Assignee: IESG > > > > > > Contact: IETF Chair > > > > > > Description: Authentication, Accounting and Dynamic authorization > > > via the RADIUS protocol. These service names are used to > > > construct the SRV service labels "_radiustls" and "_radiusdtls" > > > for discovery of RADIUS/TLS and RADIUS/DTLS servers, respectively. > > > > > > Reference: [RFC-to-be] > > > > > > > > > Question: What are the Defined TXT keys for each SRV names? > > > The Defined TXT keys are required for SRV service names. > > > > I think I disagree (but I'm not quite sure ;-) . Reading RFC6763 > > Section Sure. We simply put 'None' for that field if there is nothing filled in the request. We are working on the new assignments you submitted via the template form. > > 6, I read: > > > > "Note that this requirement for a mandatory TXT record applies > > exclusively to DNS-SD service advertising, i.e., services > > advertised > > using the PTR+SRV+TXT convention specified in this document. It is > > not a requirement of SRV records in general. The DNS SRV record > > datatype [RFC2782] may still be used in other contexts without any > > requirement for accompanying PTR and TXT records." > > > > As defined in the draft, the service name is NOT registered for DNS-SD > > and makes no use of accompanying PTR and TXT records. It is defined > > following RFC2782, defining a "Name" in that RFCs notion and if > > anything > > has an accompanying NAPTR. > > > > Please advise if you still insist on the definiton of a TXT. > > > > > The authors should submit a template at > > > http://www.iana.org/form/ports-services for early allocation and put > > > the Internet Draft as a reference according to RFC6335 as stated in > > > section 8.1.1 of that document. > > > > Will do. I've submitted the two forms without a TXT now, hoping that > > IANA's answer to the above is "TXT is not required". > > > > I believe the other four issues do not require intervention by the > > authors; these are between IANA and the experts. If I'm wrong, please > > let me know. > > Those require expert review are pending experts' replies. I'm not sure what you mean by "between IANA and the experts." We only initiate the expert review. If experts have questions, we will forward their comments to the authors, and the authors should answer experts' questions. Thanks ~pl Pearl Liang ICANN > > Greetings, > > > > Stefan Winter > From nobody Mon Mar 23 10:01:26 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94BF11ACD21 for ; Mon, 23 Mar 2015 09:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.912 X-Spam-Level: X-Spam-Status: No, score=-106.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aqmE25s0shkQ for ; Mon, 23 Mar 2015 09:51:50 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 117781A8A17 for ; Mon, 23 Mar 2015 09:51:50 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CFFDA180459; Mon, 23 Mar 2015 09:50:24 -0700 (PDT) To: mchiba@cisco.com, gdommety@cisco.com, meklund@cisco.com, david@mitton.com, bernarda@microsoft.com, bclaise@cisco.com, joelja@bogus.com, stefan.winter@restena.lu, lionel.morand@orange.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20150323165024.CFFDA180459@rfc-editor.org> Date: Mon, 23 Mar 2015 09:50:24 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 10:01:22 -0700 Cc: radext@ietf.org, aland@freeradius.org, rfc-editor@rfc-editor.org Subject: [radext] [Technical Errata Reported] RFC5176 (4311) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 16:52:00 -0000 The following errata report has been submitted for RFC5176, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5176&eid=4311 -------------------------------------- Type: Technical Reported by: Alan DeKok Section: 2.3 Original Text ------------- Section 2.3 says: In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory. Corrected Text -------------- In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory, except Proxy-State. See Section 3.1 for a discussion of how the NAS must handle Proxy-State. Notes ----- This was seen with vendor equipment. CoA proxying was done to the NAS, and the proxy was adding and forwarding Proxy-State as required by Section 3.1. However, the NAS was returning a CoA-NAK with Error-Cause = Unsupported-Attribute. The issue comes because Proxy-State is called out in Section 3.1 for special handling. However, that special handling isn't called out in Section 2.3. As a result, implementors can get confused. The RADEXT WG is rechartering with a document to address CoA proxying. We will also be addressing this issue in that document. There are additional attributes which a NAS should ignore, OR which should be filtered out by the proxy closest to the NAS. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5176 (draft-ietf-radext-rfc3576bis-13) -------------------------------------- Title : Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) Publication Date : January 2008 Author(s) : M. Chiba, G. Dommety, M. Eklund, D. Mitton, B. Aboba Category : INFORMATIONAL Source : RADIUS EXTensions Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Mon Mar 23 11:09:39 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 0B0BF1AD05F; Mon, 23 Mar 2015 10:54:55 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58951AD05D; Mon, 23 Mar 2015 10:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGptrBMYESjB; Mon, 23 Mar 2015 10:54:54 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57B721AD01E; Mon, 23 Mar 2015 10:54:54 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2NHssfF004446; Mon, 23 Mar 2015 17:54:54 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 2202CC205AE; Mon, 23 Mar 2015 17:54:54 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <20150320180710.25070.83728.idtracker@ietfa.amsl.com> References: <20150320180710.25070.83728.idtracker@ietfa.amsl.com> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814463 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 23 Mar 2015 17:54:54 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 11:09:37 -0700 Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, radext-chairs@ietf.org, iesg@ietf.org Subject: [radext] [IANA #814463] Evaluation: to Experimental RFC X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-eval@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 17:54:56 -0000 IESG: IANA NOT OK. Comments in tracker IANA Actions - YES The new requested registrations are pending expert review. Thank you, Pearl Liang ICANN On Fri Mar 20 18:07:35 2015, iesg-secretary@ietf.org wrote: > Evaluation for can be > found > at http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic- > discovery/ > > Last call to expire on: 2015-03-20 00:00 PDT > > > Please return the full line with your position. > > Yes No-Objection Discuss Abstain > Kathleen Moriarty [ X ] [ ] [ ] [ ] > > > Has enough positions to pass. > > DISCUSSES AND COMMENTS > ====================== > > ---- following is a DRAFT of message to be sent AFTER approval --- > From: The IESG > To: IETF-Announce > Cc: RFC Editor , > radext mailing list , > radext chair > Subject: Document Action: 'NAI-based Dynamic Peer Discovery for > RADIUS/TLS and RADIUS/DTLS' to Experimental RFC (draft-ietf-radext- > dynamic-discovery-13.txt) > > The IESG has approved the following document: > - 'NAI-based Dynamic Peer Discovery for RADIUS/TLS and RADIUS/DTLS' > (draft-ietf-radext-dynamic-discovery-13.txt) as Experimental RFC > > This document is the product of the RADIUS EXTensions Working Group. > > The IESG contact persons are Benoit Claise, Kathleen Moriarty and Joel > Jaeggli. > > A URL of this Internet Draft is: > http://datatracker.ietf.org/doc/draft-ietf-radext-dynamic-discovery/ > > > > > > Technical Summary > > This document specifies a means to find authoritative RADIUS servers > for a given (NAI) realm using the DNS infrastructure. It can be used > in > conjunction with either RADIUS/TLS and RADIUS/DTLS, or even with > current RADIUS transport if transport level security is not a > concern. > The solution similar but more up to date version of Diameter DNS-based > peer discovery. > > Working Group Summary > > There was working group consensus for this draft and a few > implementations. > > Document Quality > > There are multiple implementations and the solution is also > deployed as part of the global Eduroam consortium RADIUS > roaming infrastructure. > The document needs S-NAPTR and the Service Name and Transport > Protocol Port Number registry expert reviews during IANA allocations. > > Personnel > > The Document Shepherd is Jouni Korhonen and the Area Director is > Kathleen Moriarty. > > The IANA Expert(s) for the registry added (S-NAPTR Application > Service and Protocol Tags) in this document is Jouni Korhonen > (jouni.nospam@gmail.com) > > > IANA Note > > Expert review is requested for > 1) "radiustls" and "radiusdtls" from the Service Name and Transport > Protocol Port Number registry > The IANA experts pool is Joe Touch; Eliot Lear, Allison Mankin, > Markku Kojo, Kumiko Ono, Martin Stiemerling, Lars Eggert, Alexey > Melnikov and Wes Eddy > No. Service names are FCFS. > 2) a number of Object Identifiers > The IANA expert is Russ Housley. pending Expert review. From nobody Mon Mar 23 11:14:29 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC9A1AD0CF for ; Mon, 23 Mar 2015 11:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2f2gb_WEiIhv for ; Mon, 23 Mar 2015 11:14:25 -0700 (PDT) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8121AD0CE for ; Mon, 23 Mar 2015 11:14:25 -0700 (PDT) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 23 Mar 2015 11:14:24 -0700 Date: Mon, 23 Mar 2015 11:14:30 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> Message-ID: References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1035896201-25012-1427127805=:3600" Content-ID: Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 18:14:27 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1035896201-25012-1427127805=:3600 Content-Type: text/plain; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: On Mon, 23 Mar 2015, Alan DeKok wrote: To clear up any confusion I will go back and expand on my previous question. Roaming network consisting of a number of participating organizations all sharing access. 'Home' system, roaming network (RoamA,B,C) and 'Visit' systems all controlled by separate companies. Each use different RADIUS systems. The word STATE refers to Operator-NAS-Identifier or something like it. +------+ +-------+ +-------+ +-------+ +-------+ +----------+ | Home | - | RoamA | - | RoamB | - | RoamC | - | Visit | - | VisitNAS | +------+ +-------+ +-------+ +-------+ +-------+ +----------+ Scenario A: 'Home' user logs on to 'VisitNAS' as user@home using realm proxy, Access-Request proxied to home server and user admitted to the network. At a later time home server decides to send a DM request to disconnect user@home. It transmits a request to RoamA containing roughly: Operator-Name="1visit" Operator-NAS-Identifier=010100100101010 Acct-Session-Id="dontchawishwewerealwaysunique" NAS-Port-Id="Astern123" NAS-IP-Address=10.1.1.1 This request does NOT contain User-Name. Issues: - 'RoamA' can either use STATE included in the request to verify Acct-Session-Id is related to a session belonging to 'Home' before it enters the roaming network or it can simply punt responsibility up thru the proxy chain. - If 'RoamA' decides to punt to 'RoamB' or 'RoamC' the same problem of using STATE to verify Acct-Session-Id is related is encountered. Also since there is no standard way of communicating 'Home' originated the request roaming network will need to manage some OOB or proprietary method of facilitating origination information so that it can render a coherent judgment. - If RoamA-C all fail to verify Acct-Session-Id the request responsibility is punted to 'Visit' - If 'Visit' trusts the roaming network and STATE is never used to verify relationship of DM to 'Home' the effective outcome any 'Home' network is able to disconnect any of their competitors users with only knowledge of session identifying attributes. - If 'Visit' is more cautious and can get trusted originating 'Home' information from 'Roam' and STATE this could be used to verify the relationship itself. Scenario B: 'Home' user logs on to 'VisitNAS' as user using policy based proxy on a VSA. Access-Request proxied to home server and user admitted to the network. At a later time home server decides to send a DM request to disconnect user. It transmits a request to RoamA containing roughly: Operator-Name="1visit" Operator-NAS-Identifier=010100100101010 User-Name="user" Acct-Session-Id="dontchawishwewerealwaysunique" NAS-Port-Id="Astern123" NAS-IP-Address=10.1.1.1 This request does NOT contain VSA used for policy based proxy. Issues are identical to scenario A. STATE is helpful in addressing situations where there is a mismatch between session identification and means of proxy. > The draft implements CoA proxying based on Operator-Name. This is > sufficient for all proxies to get the packet to the visited domain, > independent of anything else in the packet. The Operator-Name *is* > “sufficient information” for all proxies. The proxies need no other > information, and can safely ignore every single other attribute in the > packet. No unfortunately this does not work across administrative domains as operators are able to affect operation of unrelated sessions belonging to other operators without the checks in place. While all parties explicitly trust roaming infrastructure they may not necessarily trust each other. regards, Peter --1035896201-25012-1427127805=:3600-- From nobody Mon Mar 23 15:29:41 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id B4BFE1A1B1E; Mon, 23 Mar 2015 14:23:41 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942EB1A1AFF; Mon, 23 Mar 2015 14:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0tevKQnRqTqI; Mon, 23 Mar 2015 14:23:39 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C52BE1A1A9D; Mon, 23 Mar 2015 14:23:39 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2NLNdIU014362; Mon, 23 Mar 2015 21:23:39 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 9305CC20665; Mon, 23 Mar 2015 21:23:39 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <201503200852.t2K8qCpf012076@smtp1.lax.icann.org> References: <201503200852.t2K8qCpf012076@smtp1.lax.icann.org> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814383 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 23 Mar 2015 21:23:39 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 15:29:39 -0700 Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, chair@ietf.org, iesg@ietf.org Subject: [radext] [IANA #814383] Application for a Service Name "radiusdtls" X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-prot-param@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:23:41 -0000 Dear IESG/Authors: We have processed this request (included below). This message is to confirm that we have registered the following as per draft-ietf-radext-dynamic-discovery-13: radiusdtls tcp Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiusdtls" for discovery of RADIUS/DTLS servers [IESG] [IETF_Chair] 2015-03-23 [draft-ietf-radext-dynamic-discovery-13] Defined TXT keys: None radiusdtls udp Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiusdtls" for discovery of RADIUS/DTLS servers [IESG] [IETF_Chair] 2015-03-23 [draft-ietf-radext-dynamic-discovery-13] Defined TXT keys: None Please see: http://www.iana.org/assignments/service-names-port-numbers When the document has been approved for publication as an RFC, we will update the draft string to the approved RFC number. Thank you, Pearl Liang ICANN On Fri Mar 20 08:52:15 2015, chair@ietf.org wrote: > > Application for a Port Number and/or Service Name > > Assignee: IESG > Contact Person: IETF Chair > > Resource Request: > > [ ] Port Number > [x] Service Name > > Transport Protocols: > [ ] TCP > [x] UDP > [ ] SCTP > [ ] DCCP > > Service Code: [] > Service Name: [radiusdtls] > Desired Port Number: [] > Description: [Authentication, Accounting and Dynamic > authorization via the RADIUS protocol. This service name is used to > construct the SRV service label "_radiusdtls" for discovery of > RADIUS/DTLS servers.] > > Reference: > [http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-13] > > Defined TXT Keys: > > 1. If broadcast/multicast is used, how and what for? > [Not used.] > > 2. If UDP is requested, please explain how traffic is limited, and > whether the > protocol reacts to congestion. > [The payload transmitted via servers which can be discovered with this > draft is RADIUS. RADIUS is a AAA protocol with severe size > limitations. It is explicitly NOT designed for bulk data transfer.] > > 3. If UDP is requested, please indicate whether the service is solely > for the discovery of hosts supporting this protocol. > [The service name here is only used for the discovery of hosts > supporting the RADIUS/DTLS protocol as defined in RFC7360.] > > 4. Please explain how your protocol supports versioning. > [The protocol immediately initiates DTLS (no STARTTLS or similar). > DTLS version negotiation follows as usual.] > > 5. If your request is for more than one transport, please explain in > detail how the protocol differs over each transport. > [No other transport besides UDP requested; note however the parallel > service name radiustls which will be requested for RADIUS/TLS over > TCP.] > > 6. Please describe how your protocol supports security. Note that > presently > there is no IETF consensus on when it is appropriate to use a > second port > for an insecure version of a protocol. > [Traditional RADIUS over UDP has no version negotiation and no > protocol phase which would allow the equivalent of STARTTLS. A new > port is thus required and was assigned in RFC7360. The service name > requested here only allows to discover servers supporting RFC7360 in > DNS. The discovery algorithm in this draft uses DNSSEC where > available, but has provisions for server authorisation verification in > the absence of DNSSEC (using PKIX certificate extensions).] > > 7. Please explain why a unique port assignment is necessary as > opposed to a > port in range (49152-65535) or existing port. > [No port is requested here (RFC7360 already has a port for > RADIUS/DTLS).] > > 8. Please explain the state of development of your protocol. > [The discovery protocol as defined in the reference draft is already > in use on the internet by a large roaming consortium. The consortium > only makes use of RADIUS/TLS though, so no actual hosts have been > discovered for RADIUS/DTLS.] > > 9. If SCTP is requested, is there an existing TCP and/or UDP service > name or > port number assignment? If yes, provide the existing service name > and port number. > [SCTP is not requested.] > > 10. What specific SCTP capability is used by the application such > that a > user who has the choice of both TCP (and/or UDP) and SCTP ports > for > this application would choose SCTP? See RFC 4960 section 7.1. > [SCTP is not requested.] > > 11. Please provide any other information that would be helpful in > understanding how this protocol differs from existing assigned > services. > [] From nobody Mon Mar 23 15:29:44 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 50C301A1B40; Mon, 23 Mar 2015 14:26:01 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC031A1B1E; Mon, 23 Mar 2015 14:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYVMd_HZ5UhA; Mon, 23 Mar 2015 14:25:59 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10F101A1AFF; Mon, 23 Mar 2015 14:25:59 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2NLPwM7014447; Mon, 23 Mar 2015 21:25:58 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id C6895C20682; Mon, 23 Mar 2015 21:25:58 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: <201503200844.t2K8iwiC011679@smtp1.lax.icann.org> References: <201503200844.t2K8iwiC011679@smtp1.lax.icann.org> Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814379 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Mon, 23 Mar 2015 21:25:58 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 15:29:39 -0700 Cc: draft-ietf-radext-dynamic-discovery.all@ietf.org, chair@ietf.org, iesg@ietf.org Subject: [radext] [IANA #814379] Application for a Service Name "radiustls" X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: iana-prot-param@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:26:01 -0000 Dear IESG/Authors: We have processed this request (included below). This message is to confirm that we have registered the following as per draft-ietf-radext-dynamic-discovery-13: radiustls tcp Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiustls" for discovery of RADIUS/TLS servers [IESG] [IETF_Chair] 2015-03-23 [draft-ietf-radext-dynamic-discovery-13] Defined TXT keys: None radiustls udp Authentication, Accounting and Dynamic authorization via the RADIUS protocol. This service name is used to construct the SRV service label "_radiustls" for discovery of RADIUS/TLS servers [IESG] [IETF_Chair] 2015-03-23 [draft-ietf-radext-dynamic-discovery-13] Defined TXT keys: None Please see: http://www.iana.org/assignments/service-names-port-numbers When the document has been approved for publication as an RFC, we will update the draft string to the approved RFC number. Thank you, Pearl Liang ICANN On Fri Mar 20 08:44:59 2015, chair@ietf.org wrote: > > Application for a Port Number and/or Service Name > > Assignee: IESG > Contact Person: IETF Chair > > Resource Request: > > [ ] Port Number > [x] Service Name > > Transport Protocols: > [x] TCP > [ ] UDP > [ ] SCTP > [ ] DCCP > > Service Code: [] > Service Name: [radiustls] > Desired Port Number: [] > Description: [Authentication, Accounting and Dynamic > authorization via the RADIUS protocol. This service name is used to > construct the SRV service label "_radiustls" for discovery of > RADIUS/TLS servers.] > > Reference: > [http://tools.ietf.org/html/draft-ietf-radext-dynamic-discovery-13] > > Defined TXT Keys: > > 1. If broadcast/multicast is used, how and what for? > [Not used.] > > 2. If UDP is requested, please explain how traffic is limited, and > whether the > protocol reacts to congestion. > [Not requested.] > > 3. If UDP is requested, please indicate whether the service is solely > for the discovery of hosts supporting this protocol. > [Not requested.] > > 4. Please explain how your protocol supports versioning. > [The protocol immediately initiates TLS (no STARTTLS). TLS version > negotiation follows as usual.] > > 5. If your request is for more than one transport, please explain in > detail how the protocol differs over each transport. > [No other transport besides TCP requested; note however the parallel > service name radiusdtls which will be requested for RADIUS/DTLS over > UDP.] > > 6. Please describe how your protocol supports security. Note that > presently > there is no IETF consensus on when it is appropriate to use a > second port > for an insecure version of a protocol. > [Traditional RADIUS over UDP has no version negotiation and no > protocol phase which would allow the equivalent of STARTTLS. A new > port is thus required and was assigned in RFC6614. The service name > requested here only allows to discover servers supporting RFC6614 in > DNS. The discovery algorithm in this draft uses DNSSEC where > available, but has provisions for server authorisation verification in > the absence of DNSSEC (using PKIX certificate extensions).] > > 7. Please explain why a unique port assignment is necessary as > opposed to a > port in range (49152-65535) or existing port. > [No port is requested here (RFC6614 already has a port for > RADIUS/TLS).] > > 8. Please explain the state of development of your protocol. > [The protocol is already in use on the internet by a large roaming > consortium.] > > 9. If SCTP is requested, is there an existing TCP and/or UDP service > name or > port number assignment? If yes, provide the existing service name > and port number. > [SCTP is not requested.] > > 10. What specific SCTP capability is used by the application such > that a > user who has the choice of both TCP (and/or UDP) and SCTP ports > for > this application would choose SCTP? See RFC 4960 section 7.1. > [SCTP is not requested.] > > 11. Please provide any other information that would be helpful in > understanding how this protocol differs from existing assigned > services. > [] From nobody Mon Mar 23 15:30:01 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFF71A1AB9 for ; Mon, 23 Mar 2015 14:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6_q2cG6Wn0E for ; Mon, 23 Mar 2015 14:12:57 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88FC01A1A9D for ; Mon, 23 Mar 2015 14:12:56 -0700 (PDT) Received: by qgfa8 with SMTP id a8so166124028qgf.0 for ; Mon, 23 Mar 2015 14:12:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=byHEkImNBIcFCN83TR61u94B9of5lf1BFa6txtU/ock=; b=rSOwfvAHev3tEBo0LWRqcTGJ4lhjk479z6/U2d881t3lsdN3jgcrU1JDJG4vM2slVA hoPKjxIZCWcQJK6sie2Qm3SK4ux4zqrNaeQPDvQp2pyArqLQUSDeYLiw412jUlzBPIBh 9Qvp81sA3svgBaIT6pJebMmevTxln70MiYoF5Nzp6x8K7GzoYt2vzni3/iGynpGFC6PF p/+zkUpcjs0b7hPYtoNE0flAcAOQIIH+TT8NN99uumhPHfb1Dz+3qSNfip/EWhuyhJBI pI8bPKGuE244Qm19r/L58t46Amo/ZobUUHK5WuSPcMd5OKHmwG1JVh/AV/5KZUl5RqcY 9pTQ== MIME-Version: 1.0 X-Received: by 10.140.42.195 with SMTP id c61mr1536114qga.94.1427145175833; Mon, 23 Mar 2015 14:12:55 -0700 (PDT) Received: by 10.96.15.198 with HTTP; Mon, 23 Mar 2015 14:12:55 -0700 (PDT) Date: Mon, 23 Mar 2015 16:12:55 -0500 Message-ID: From: suprita To: radext@ietf.org Content-Type: multipart/mixed; boundary=001a113abef440610f0511fb218b Archived-At: X-Mailman-Approved-At: Mon, 23 Mar 2015 15:29:53 -0700 Subject: [radext] RADIUS EXTensions : IETF 92 : Meeting Minutes. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 21:12:59 -0000 --001a113abef440610f0511fb218b Content-Type: multipart/alternative; boundary=001a113abef44061080511fb2189 --001a113abef44061080511fb2189 Content-Type: text/plain; charset=UTF-8 Dear All, Attached is the meeting minutes of the RADEXT meet at IETF92 on Monday 23rd March 2015 at 15:20 pm. Apologies for any miss. (first time attendee and first time meeting minutes taker.) Thank you, Suprita Sah Networ Engineer Reliance JIO Infocomm Limited (India) --001a113abef44061080511fb2189 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear All,

Attached is the meeting minut= es of the RADEXT meet at IETF92 on Monday 23rd March 2015 at =C2=A015:20 pm= .

Apologies for any miss.

(first time attendee and first time meeting minutes taker.)

=
Thank you,

Suprita Sah
Networ= Engineer
Reliance JIO Infocomm Limited (India)
--001a113abef44061080511fb2189-- --001a113abef440610f0511fb218b Content-Type: text/plain; charset=US-ASCII; name="RADEXT-meeting minurtes.txt" Content-Disposition: attachment; filename="RADEXT-meeting minurtes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_i7mdale00 UkFERVhULSAzLjIwIHBtDQoNCkNoYWlyIEJhc2hpbmcuDQoNClNBTS1yZW1vdGUNClN0ZWZhbi1y ZW1vdGUNCg0KQWdlbmRhIEJhc2hpbmcNCkRFQU4tcHJlc28tSVAgcG9ydA0KU2FtLXByZXNvLUxv Z2ljYWwNCi0tLS0tLS0tLS0tLQ0KQ2hhaXIgc3RhdHVzIHVwZGF0ZS1hcyBwZXIgc2xpZGUNCi0t LS0tLS0tLS0NCkRlYW4gLSBJUCBQb3J0IENvbmZpZ3VyYXRpb24gYW5kIFJlcG9ydGluZw0KDQoz LjMwIHBtIDpEZWFuIENoZW5nOiANCm1ham9yIGNvbW1lbnQgbGFzdCBJRVRGLg0KY3VycmVudCBz dGF1cyA6IGFsbCBjb21tZW50cyB0YWtlbiBjYXJlIG9mOiBsb25kb24sIHRvcnJvbnRvLCBob251 bHVsdS4NCg0KbmV3OiBwb3J0IGxpbWl0LCByYW5nZSwgTUFQIEZvcndhcmRlcg0KbW9kaWZ5IHRo ZSBUTFYncy0gbW9kaWZ5IHJmYyA2OTI5DQpzcGxpdCB0aGUgVExWIGludG8gdjQgYW5kIHY2DQph dHRyaWJ1dGU6IG1hbmRhdG9yeS9vcHRpb25hbCBhdHRyaWJ1dGVzLg0KDQpJUEZJWCBFbGVtZW50 OiAzIHByb3Bvc2VkLg0KDQoqKmNoYWlyIDogY29tbWVudHM6IGRlZmluZSB0aGUgZWxlbWVudHMg b2YgdGhyZWUgZWxlbWVudHMgaW5zaWRlIHRoZSByZWNvbW1lbmRhdGlvbiB0byBJQU5BIGZvciBj b25zaWRlcmF0aW9uL2FwcHJvdmFsLiA6IERlYW4gQWdyZWVzLg0KY3VycmVudCByZXZpc2lvbi0z LiBXRyBsYXN0IGNhbGwgcmVxdWVzdGVkLg0KKipOb3QgbWFueSByZWFkIHRoZSBsYXRlc3QgdmVy c2lvbi4NCioqbm8gY29tbWVudHMgZnJvbSBBTEFOLCB0aGVyZSB3ZXJlIGNvbW1lbnRzIGZyb20g aGltIGZvciBmaXJzDQoqKiBDaGVmb24gc2F5cy0gIHJlZmVyIEphYmJlciBzY3JpYmUuDQoqKiBT YW0gc2F5cy0gZGlzY3VzcyB0aGUgbmVlZCBmb3IgcHJvdG9jb2wuIFNBTSdzIGNvbW1lbnQgaXMg Zm9yIGhpcyBkcmFmdCBvbiBiaWdnZXIgcGFja2V0cy4NCg0KKipDaGFpciA6IGNoZWNrIHByb2Nl ZHVyZSwgZnJvbSBJQU5BLCBmb3IgcHJvY2VzcyBmb3IgYWxsb2NhdGluZyB2YWx1ZSBmb3IgSVBG SVggZWxlbWVudC4NCioqRGVhbiA6IGRvbid0IGtub3cgZGV0YWlsLCB0aGVyZSBpcyBhIHJmYy0g MTYgcGllY2UgIG51bWJlciwgcHJvdmlkZSBhIG51bWJlciB0aGVyZSwgYW5kIHJmYy0xNyBzb21l dGhpbmcsIHN5bWVudGljcyBleHBsYWluaW5nIHRoZSBzYW1lLiBUaGUgbGluayBpcyB0aGVyZSBv biBzbGlkZSA4LiBmb3IgSVBGSVggY3VycmVudCBhc3NpZ25lZCB2YWx1ZXMuDQoNCioqQ2hhaXI6 IE1vaGFtbWVkIGNsYXJpZmllZCBzb21ldGhpbmcgKD8pDQoNCioqU3RlZmFuIDogdGhpcyBkb2Mg aXMgb2theSBmb3IgY29tbWVudCBmb3IgbGFzdCBjYWxsLCBJIHdpbGwgcmV2aWV3IHRoaXMgZG9j IHdoaWxlIHRoZSBsYXN0IGNhbGwgaXMgaW5pdGlhdGVkLiANCioqQ2hhaXIgOiBMQyBjYWxsIHdp bGwgYmUgaW5pdGlhdGVkLiBBTEFOIGNvbW1lbnRzIGlzIGFsc28gYXdhaXRlZC4NCg0KUHJvY2Vz cyB3aWxsIGNvbnRpbnVlIGZvciBJRVNIIFN1Ym1pc3Npb24uDQoNCi0tLS0tLS0tLS0tLS0tLS0t DQoNClNhbS0gTGFyZ2VyIFBhY2tldHMgZm9yIFJhZGl1cyBvdmVyIFRDUC4NCi1jYXB0dXJlcyBh bGwgY29tbWVudHMNCi1SZWFkeSBmb3IgTGFzdCBjYWxsLg0KDQpRdWVzdGlvbnMgPw0KDQotTGFz dCBJRVRGIDogcHBsIHdlcmUgaGFwcHksIHdpdGggY29udGVudC4NCg0KKipDaGFpcjogTEFTdCBj YWxsIHdpbGwgYmUgaW5pdGlhdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0NCk5ldyBwcm9wb3NhbHM6 DQoNCkFsYW4gLSBEeW5hbWljIEF1dGggcHJveHkNCi1XRyBkb2N1bWVudA0KLXVuZGVyZ29pbmcg ZGlzY3Vzc2lvbiBiZXR3ZWVuIHBldGVyIGFuZCBBTGFuLCBhbmQgZXhhY3QgY29udGVudCBvZiB0 aGUgZG9jLg0KLUFsYW4tIHJlbHkgb24gT3BlcmF0b3IgbmFtZSBpRA0KLVBldGVyLSBzaG91bGQg cHJvdmlkZSBtb3JlIGluZm8gb24gc3RhdGUgbWFuYWdlbWVudCBhbmQgcHJveHkuDQoNCnJlYWN0 aW9uIG9uIG1haWxpbmcgbGlzdHMgKD8pDQoNCioqQ2hhaXI6IFJlbHkgb24gdGhlIGRvYywgcHJv Z3Jlc3MgdGhpcyBkcmFmdCBhcyBXRyBkb2MuIGNoYW5nZXMgdG8gYmUgbWFkZSBhZnRlciBwcm9w b3NhbC4NClN0ZWZhbiBpcyBpbmxpbmUgKD8pDQpldmVyeWJvZHkgaXMgaGFwcHkNCi0tLS0NCkVB UDBSZXNwb25zZS9pZGVudGl0eQ0KU3RlZmFuLSBjYW4gYmUgdXNlZCBmb3IgZnV0dXJlIHVzZS4g YW5kIHByb3ZpZGUgY29tbWVudHMsIGFuZCBzZWUgaG93IHRvIHByb2dyZXNzIHRoaXMgZG9jLg0K cHJvcG9zZWQgZm9yIEJDUCBhbHNvDQoNClN0ZWZhbiA6IHdhaXRpbmcgZm9yIG15IGRvYyB1cGRh dGUuDQptb3JlL2xlc3MgZGlzY3Vzc2VkIGxhc3QgbWVldGluZw0KLS0tLS0NClJhZGl1cyBEYXRh IHR5cGVzDQpBbGFuIC0gY29tcGxldGUgZm9yIG5vdy4uDQppbmZvcm1hdGlvbiByZmMuDQotLS0t LS0tLS0tLS0tDQpjb21tZW50cyBvbiBuZXcgcHJvcG9zYWxzOiBOT05FLg0KLS0tDQpXRyBDaGFp ciA6IA0KDQpFcnJhdGEgaW4gcmZjIDUxNzYgOiB0d28gZXJyYXRhLiBib3RoIFN0ZWZhbiBhbmQg QkVyYSBhZ3JlZXMuDQpib3RoIGVycmF0YTogVmVyaWZpZWQuDQoNCmRpc2N1c3Npb24gb24gb25l IGVycmF0YSBvciB0d28gZXJyYXRhLiBuZWVkcyB0byBiZSByZWZlcnJlZCBiYWNrIGZyb20gdGhl IGNvbXBsZXRlIGxpc3QuDQotLS0tLQ0KUmV2aXNpb24gb2YgdGhlIGNoYXJ0ZXINCmRlYzIwMTIt IGN1cnJlbnQgY2hhcnRlcg0KDQpuZXcgY29tbWVudHMgdG8gYmUgcmVjZWl2ZWQgYnkgMjd0aCBN YXJjaC4NCm5ldyBjaGFydGVyIHNoYXJlZC4NCi0tLS0tDQpuZXh0IHN0ZXAgOg0KDQpDaGFydGVy IHJldmlldyBhbmQgY29tbWVudHMNCioqQ2hhaXI6IHJldmlldyBhbGwgdGhlIGRvY3VtZW50cy4N Ci0tLS0NClN1bW1hcnk6DQoNCkxDIGNvbW1lbnRzLg0KQ2hhcnRlciByZXZpZXcu --001a113abef440610f0511fb218b-- From nobody Mon Mar 23 15:32:28 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5321A1BDB for ; Mon, 23 Mar 2015 15:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNzeVeETAs-B for ; Mon, 23 Mar 2015 15:32:25 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 390381A1BDC for ; Mon, 23 Mar 2015 15:32:22 -0700 (PDT) Received: by lagg8 with SMTP id g8so145958145lag.1 for ; Mon, 23 Mar 2015 15:32:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DuXd5+fdB7PPiie9PG4Ep+xWGF9f3/SXYrevhB/PR60=; b=oJPe/4TGgbbVGVgMUD99O+coN1txj38ALl4FkHLP1AQnPxrW+k2n0btHvEit5wg4XB 8Qsx02lCKniTtJNx4ePHKx/9v0p1EYZuUHSvttKxCNyQbwqncE3RfOyLrjzFnJi6OJil 5w+RCrL9K9tUre65/XGPYCRS+KUMKlN3YDVwmfkfCjZLhKYKnC5EtAkN+QFTv3Q/YQ85 1yjIu0E6u7xD17MkQP6zYDz+lYgSOUFlT7CNd6OhZ0NTmUm5iVj8+28vXRuGTpBH/deP xMCB58JZS+tv0iR1XBQhRCaPATvpfpdNlCjDzmi7SO53YM3miKcUXJf28j3uXi3iNRR1 S1kA== MIME-Version: 1.0 X-Received: by 10.112.51.35 with SMTP id h3mr1006638lbo.113.1427149940759; Mon, 23 Mar 2015 15:32:20 -0700 (PDT) Received: by 10.112.167.101 with HTTP; Mon, 23 Mar 2015 15:32:20 -0700 (PDT) In-Reply-To: References: Date: Mon, 23 Mar 2015 18:32:20 -0400 Message-ID: From: Kathleen Moriarty To: suprita Content-Type: multipart/alternative; boundary=001a11336dba42a1230511fc3d2c Archived-At: Cc: "radext@ietf.org" Subject: Re: [radext] RADIUS EXTensions : IETF 92 : Meeting Minutes. X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:32:27 -0000 --001a11336dba42a1230511fc3d2c Content-Type: text/plain; charset=UTF-8 Thank you, Suprita for taking the minutes! Best regards, Kathleen On Mon, Mar 23, 2015 at 5:12 PM, suprita wrote: > Dear All, > > Attached is the meeting minutes of the RADEXT meet at IETF92 on Monday > 23rd March 2015 at 15:20 pm. > > Apologies for any miss. > > (first time attendee and first time meeting minutes taker.) > > Thank you, > > Suprita Sah > Networ Engineer > Reliance JIO Infocomm Limited (India) > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > -- Best regards, Kathleen --001a11336dba42a1230511fc3d2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you, Suprita for taking the minutes!

<= div>Best regards,
Kathleen
=
On Mon, Mar 23, 2015 at 5:12 PM, suprita <suprita.nitw@gmail.com> wrote:
Dear All,

Attached is the meeti= ng minutes of the RADEXT meet at IETF92 on Monday 23rd March 2015 at =C2=A0= 15:20 pm.

Apologies for any miss.

(first time attendee and first time meeting minutes taker.)
<= div>
Thank you,

Suprita Sah
Networ Engineer
Reliance JIO Infocomm Limited (India)

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




--

Best regards,
Ka= thleen
--001a11336dba42a1230511fc3d2c-- From nobody Mon Mar 23 15:39:37 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B67D1A000E for ; Mon, 23 Mar 2015 15:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4fDnLVTxBHD for ; Mon, 23 Mar 2015 15:39:32 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 189871A00B7 for ; Mon, 23 Mar 2015 15:39:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 7929A2240490; Mon, 23 Mar 2015 23:38:55 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n8w0iFlhKiv; Mon, 23 Mar 2015 23:38:54 +0100 (CET) Received: from dhcp-943f.meeting.ietf.org (dhcp-943f.meeting.ietf.org [31.133.148.63]) by power.freeradius.org (Postfix) with ESMTPSA id 05F2B2240192; Mon, 23 Mar 2015 23:38:53 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Mon, 23 Mar 2015 17:38:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> To: Peter Deacon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 22:39:35 -0000 On Mar 23, 2015, at 1:14 PM, Peter Deacon = wrote: > To clear up any confusion I will go back and expand on my previous = question. That helps a lot, thanks. > - 'RoamA' can either use STATE included in the request to verify = Acct-Session-Id is related to a session belonging to 'Home' before it = enters the roaming network or it can simply punt responsibility up thru = the proxy chain. The RADIUS answer is that RoamA simply proxies the request. It does = no verification or filtering of proxied packets. > - If 'RoamA' decides to punt to 'RoamB' or 'RoamC' the same problem of = using STATE to verify Acct-Session-Id is related is encountered. Also = since there is no standard way of communicating 'Home' originated the = request roaming network will need to manage some OOB or proprietary = method of facilitating origination information so that it can render a = coherent judgment. Yes. Exactly. The proxies just proxy the packets. Nothing more > - If RoamA-C all fail to verify Acct-Session-Id the request = responsibility is punted to =91Visit' Yes. Exactly. > - If 'Visit' trusts the roaming network and STATE is never used to = verify relationship of DM to 'Home' the effective outcome any 'Home' = network is able to disconnect any of their competitors users with only = knowledge of session identifying attributes. Unfortunately, yes. That=92s an issue with 5176. And with this = document. I don=92t think fixing roaming is in scope for it. The recommended way to address this issue is to use Acct-Session-Id, = and User-Name in the CoA packets. That information is =93private=94, = and random home servers can=92t guess it. Proxies can still watch the = traffic and forge disconnects=85 but they=92re trusted. That=92s the = nature of the trust relationship they have with the other parties. > - If 'Visit' is more cautious and can get trusted originating 'Home' = information from 'Roam' and STATE this could be used to verify the = relationship itself. There is little or nothing to be gained by having the proxies (or = visited network) maintain any kind of session state. Doing so would be = costly, and would only make it more difficult for malicious home servers = to disconnect their competitors users. All of the proxies could still = disconnect any users, because they=92re proxies, and have all of the = state information. > Scenario B: >=20 > 'Home' user logs on to 'VisitNAS' as user using policy based proxy on = a VSA. Access-Request proxied to home server and user admitted to the = network. >=20 > At a later time home server decides to send a DM request to disconnect = user. It transmits a request to RoamA containing roughly: >=20 > Operator-Name=3D"1visit" > Operator-NAS-Identifier=3D010100100101010 > User-Name=3D"user" > Acct-Session-Id=3D"dontchawishwewerealwaysunique" > NAS-Port-Id=3D"Astern123" > NAS-IP-Address=3D10.1.1.1 >=20 > This request does NOT contain VSA used for policy based proxy. It doesn=92t need to. It contains the Operator-Name, which is = sufficient for the CoA packets to be proxied to the visited network. > Issues are identical to scenario A. Yes. > STATE is helpful in addressing situations where there is a mismatch = between session identification and means of proxy. I=92m not sure I agree. >> The draft implements CoA proxying based on Operator-Name. This is = sufficient for all proxies to get the packet to the visited domain, = independent of anything else in the packet. The Operator-Name *is* = =93sufficient information=94 for all proxies. The proxies need no other = information, and can safely ignore every single other attribute in the = packet. >=20 > No unfortunately this does not work across administrative domains as = operators are able to affect operation of unrelated sessions belonging = to other operators without the checks in place. While all parties = explicitly trust roaming infrastructure they may not necessarily trust = each other. i.e. what you=92re saying is that there is a requirement for home = server A to NOT be allowed to disconnect users for home server B in a = visited network. That is a *new* requirement, which doesn=92t negate my = comments above. I want to solve one problem at a time. Operator-Name and = Operator-NAS-Identifier are sufficient to get the packet to the visited = NAS. Your earlier comments seemed to say that they were NOT = sufficient, which is what was unclear. To solve the NEW problem of forged disconnects, we need a NEW = solution. i.e. rely on Acct-Session-Id, which is hard to guess. I = think that would be sufficient for most intents and purposes. If you have *specific* suggestions for a solution, I=92d be happy to = hear them. But please explain it clearly. Most of the time your posts = are full of unstated assumptions, which makes it nearly impossible to = understand them. Alan DeKok. From nobody Mon Mar 23 16:03:40 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6C51A0155 for ; Mon, 23 Mar 2015 16:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ddvsGRs50Sf for ; Mon, 23 Mar 2015 16:03:36 -0700 (PDT) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id 42A2A1A0263 for ; Mon, 23 Mar 2015 16:03:36 -0700 (PDT) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 23 Mar 2015 16:03:36 -0700 Date: Mon, 23 Mar 2015 16:03:42 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> Message-ID: References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="1059913119-7280-1427151822=:3600" Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 23:03:39 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1059913119-7280-1427151822=:3600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8BIT On Mon, 23 Mar 2015, Alan DeKok wrote: >> No unfortunately this does not work across administrative domains as >> operators are able to affect operation of unrelated sessions belonging >> to other operators without the checks in place. While all parties >> explicitly trust roaming infrastructure they may not necessarily trust >> each other. > i.e. what you’re saying is that there is a requirement for home server > A to NOT be allowed to disconnect users for home server B in a visited > network. That is a *new* requirement, which doesn’t negate my comments > above. I recommend effective means of isolation of administrative domains be explicitly required as part of any charter for this work item. Even if many of details are left up to implementations there has to be a reasonable enabling means. Without it I don't support the work item as resulting product would not be suitable for deployment. regards, Peter --1059913119-7280-1427151822=:3600-- From nobody Mon Mar 23 16:21:53 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8301A040C for ; Mon, 23 Mar 2015 16:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFbFYfwDcnNE for ; Mon, 23 Mar 2015 16:21:50 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5FEE1A03A6 for ; Mon, 23 Mar 2015 16:21:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 72C1920675; Mon, 23 Mar 2015 19:19:42 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rzbcCAmBw1t; Mon, 23 Mar 2015 19:19:41 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Mon, 23 Mar 2015 19:19:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 719CF87201; Mon, 23 Mar 2015 19:21:17 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> Date: Mon, 23 Mar 2015 19:21:17 -0400 In-Reply-To: <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> (Alan DeKok's message of "Mon, 23 Mar 2015 17:38:52 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: radext@ietf.org, Peter Deacon Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Mar 2015 23:21:52 -0000 >>>>> "Alan" =3D=3D Alan DeKok writes: Alan> i.e. what you=E2=80=99re saying is that there is a requirement = for Alan> home server A to NOT be allowed to disconnect users for home Alan> server B in a visited network. That is a *new* requirement, Alan> which doesn=E2=80=99t negate my comments above. Alan> I want to solve one problem at a time. Operator-Name and Alan> Operator-NAS-Identifier are sufficient to get the packet to Alan> the visited NAS. Your earlier comments seemed to say that Alan> they were NOT sufficient, which is what was unclear. I think solving this requirement would be necessary for moving COA to the standards track or removing the health warning in 5176. I'm fine not solving that problem provided that we have a fairly serious health warning on this draft. For this and other reasons COA massively fails to meet our current security expectations for standards track. --Sam From nobody Tue Mar 24 00:20:53 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7611B2CB8 for ; Tue, 24 Mar 2015 00:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H3TDmfCJAB7w for ; Tue, 24 Mar 2015 00:20:49 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [158.64.1.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74DE21B2CB7 for ; Tue, 24 Mar 2015 00:20:49 -0700 (PDT) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id A921E40BFE for ; Tue, 24 Mar 2015 08:20:47 +0100 (CET) Message-ID: <5511104F.2030006@restena.lu> Date: Tue, 24 Mar 2015 08:20:47 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: radext@ietf.org References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> In-Reply-To: OpenPGP: id=AD3091F3AB24E05F4F722C03C0DE6A358A39DC66; url=http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="CVLSawr1iwahAbuX5xN4ruLRI32FNk38F" Archived-At: Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 07:20:52 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CVLSawr1iwahAbuX5xN4ruLRI32FNk38F Content-Type: multipart/mixed; boundary="------------030204000100090505050800" This is a multi-part message in MIME format. --------------030204000100090505050800 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello, thanks Alan, Peter and Sam for taking the discussion to this point. You have collectively revealed the issue that was causing the confusion; and it leads to a need to tweak the charter IMHO: Either the document needs to consider safeguards against "generous disconnects" in other domains - I understand from the discussion that this is a very hard problem - or the document can't be standards track and needs a big warning that such generous disconnects are a security problem in this draft. I understand that this problem has always been there; it's not new in this draft but a problem of RFC5176 itself - it is only exacerbated now because proxying was previously totally undefined (making sending malign DM/CoA packets a private workflow and hard) and now becomes mostly defined and thus more easily exploitable. The latter solution, off of standards track, is easier: the target track and milestone info for the document could be changed towards Informational (matching RFC5176 itself) and the WG would during the normal WG workflow suggest appropriate warning text for the draft. I like that way out, if everyone else can live with it. I'd appreciate comments from the working group on that topic, particularly from the three of you of course :-) Greetings, Stefan Winter On 24.03.2015 00:21, Sam Hartman wrote: >>>>>> "Alan" =3D=3D Alan DeKok writes: >=20 >=20 > Alan> i.e. what you=E2=80=99re saying is that there is a requirem= ent for > Alan> home server A to NOT be allowed to disconnect users for home > Alan> server B in a visited network. That is a *new* requirement, > Alan> which doesn=E2=80=99t negate my comments above. >=20 > Alan> I want to solve one problem at a time. Operator-Name and > Alan> Operator-NAS-Identifier are sufficient to get the packet to > Alan> the visited NAS. Your earlier comments seemed to say that > Alan> they were NOT sufficient, which is what was unclear. >=20 >=20 > I think solving this requirement would be necessary for moving COA to > the standards track or removing the health warning in 5176. >=20 > I'm fine not solving that problem provided that we have a fairly seriou= s > health warning on this draft. > For this and other reasons COA massively fails to meet our current > security expectations for standards track. >=20 > --Sam >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext >=20 --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=C3=A9seau T=C3=A9l=C3=A9informatique de l'Education= Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=3Dget&search=3D0xC0DE6A358A39DC66 --------------030204000100090505050800 Content-Type: application/pgp-keys; name="0x8A39DC66.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x8A39DC66.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v2 mQINBFIplEwBEADTSz+DS8nio+RSvfSLLfaOnCGi1nqpn8Pb1laVUyEvnAAzZ5je miS88GxfiDH6hUGlWzcaW0hCfUHGiohr485adbjxRksPngWgAt/1bRxpifsW3zOb Fjgog01WWQV5Sihlwc4zr8zvYbFA5BJZ6YdkR9C5J015riv5OS30WTjA65SSXgYr b7zJWPwmegTFwE093uBFvC39waz3xYpVu5j87nO6w2MVQt/8sY2/2BFPEq+xfOaj l18UEwc7w8SCgnZdlVNcmEK4UBvJuwS/1lsR2JeQa8Gu1EDxC7PRgMgNXsDSWnnB e9aVmfG54+6ILe1QH2dwk9sPBQT5w2+vjijrb3Dv9ur+1kN+TNU2XE436jVpnnY/ 3OsLdix30STQn4Q/XOm7YoVMeDwwviefilRxzK0dXA+wKj92T68Od82CFxuZqPAg BCVmWfQM91iK9piqFK+QP+R3vF6+NGDBdwbe68iVKs0v5L8XmbxBQndjpmo+lo2a smBR2TAIfZHaKdgtBw13u3GPVVKlg/Mpko8ki9JOSem2aFyi3kQEVKptWgXT3POl 97DWJzsR5VyKz6GOx9kJAEISRyLZwm0wqh8+9LCza5oeIKW381lzq1b9x30vOh8C BSQQJ+cG9ko0yPHAj7Suw2TmPXx1qMctmE6Ahq82ZW30SljdZby8WQuR2wARAQAB tDxTdGVmYW4gV2ludGVyIChSRVNURU5BIGtleSAyMDEzKykgPHN0ZWZhbi53aW50 ZXJAcmVzdGVuYS5sdT6JAjkEEwECACMFAlIplEwCGwMHCwkIBwMCAQYVCAIJCgsE FgIDAQIeAQIXgAAKCRDA3mo1ijncZj7/D/99hVS+mJr8dSPCaDaUFFxBiT2eI1Lo R8VKEerTCRw5BsdL6pN2eRJZ9NmsqWo1ynWVHEzO91bNZ+oZGgyoNohcBAI7p+r0 qUTzkyqwdZO4kMm0pqKoM9xkP3tf2mjGujKjOz4Y7S7wnz2ZFokeUsecoRVJF/++ /qHnmeWLn44J1HUKLHYCjMu+QXGOgGXgz024jQ5eUrnPwzNp0Z90AFVHlWC+bymt y/ToIUUCQqS5Ff0jzdWLd8U695OG9iGvjBQT1LdEjsfbAwuKV5UcnpxNqUpUwKa5 9hdX5/2cMZP07FI1UXwnBlxa8rJfdb13FLjSKX4vUUHedYUZMjMPgcwl1a+zGE22 lHiSQWgP8QLA/W3BLsi22ERCEPZBfexOeOtaWIItDIz18fIaQoMDoRPshzar0JI2 CzLYsyeKySAtYJEHFVoLmMvhkwzBmgqA/BEswUA67CfCr1jFHRXdpmWM7YkyAmMa 9q6LwquWKS5+MXlUXe/3oZUcgpw/T9Uuy3Jo3RdS7B3jFcWaVr6KsO/A9u1gr/aY n5M+iJTQSj4vzqtkQaJTpSspRZoKa66HZt3IwSYiDiYZqtM83ynuj9kjnZzGfnuT aNIi996q6Mptr33mOzIE1wmMqnJYwTr3EcNtf483q/qrJwh5ES8Q9xY7aat/ZcSl 8fKubW4TlfVr8YhGBBARAgAGBQJSKZUGAAoJEPo5vdH/HhVmYTgAn24eoqO/O98o vNpt08Uab/+/tmYKAJ9kjXm9Njz5h33efzeelZUa484rr7kCDQRSKZRMARAAvBPp n7FQq7LQ5glohtbL6XIEo1U4X67S0TzUYieENSWSVYuWYIhCBldmWdmH8Bpj/qHe qdon7v+SLtR4WngzMR9toupKcFfHnbP9kpazTSB2ySHxXWGX1gJOpPXdCcg9iveK BHEsDn00ThTcPsvtXpnnzET16pXIvOXO0bxTmVZ4INIF1SWgvYma/g8kBbgXLpkj 8tOywBqFiiYPEZlDeCxDHiMgUDh6olda9K/0TZFTdMPUgjKuubfAeaDNCOrVt4Rj mFOaRLikcZocmgJhm3z/j25x7/mnNu+0di1H/S67YGQJ+pqCFInzIXDx7aRW2+JC iqsY2X3xOPWZZzjyis5SNnfOcPH3gt2hYz1fy+thsBGf4NgCN01JRqIJ2/MOQCgU dwh+9l8xqaJvCkUHM4hVh4W62MAe1u7UEqQbvvNEqxM5034vcvlE+/LRkrDCspw+ 2YJ9QyroLerVRwW5DVleP8Ifi8VB3yD80nqXYs9aqRy0BkDNIQ43ERhESMt8dJqr NkxgC6pemZrhNwyDh+hy2kPNGQh/iBpdKuH1o3E24TIZoV2v3YHvzob7aAYHddE/ PofAXhJW7I9mAs+HdWDmnI8ckuPDFpFH+Y/BFGvEXgcnJAJ1wEvf+4LuiIi0MHjR 4EWFn9vvoFDAIqD10h3FSd3D59HGtdSsNn4XaCsAEQEAAYkCHwQYAQIACQUCUimU TAIbDAAKCRDA3mo1ijncZhBtEACL036ddjc5pFoYIdoUY1vT8SMXJNquewCnL1qu DADzqDZFU5GNlQEy10krSfBwlTb9ahTtE0JFrOdZwUZtoa1Pgfr8nU6KOgrXPHbN jS/9dyc5CwGVVIpOavIm2CsMVDJ9LCF/NT+u/t1k6eGfHhPVl3dUQyDa/lzc1chK UIVQYQkFmr0A/iXP+29lFCaI+IeyU0bSdZhezDwUROn5vEx+fiPZyHDShCb+BxJv /o2LQp9JHenCiSbO+ioRZdxgbWfoKBuXOfmSStqMWXas/gZ5vS3xq72LNtKPRxgp jX3P8Zml1XDqpcBau7eK75VKE0Yd06YxnUIsbcEzInUc3uzW/u0DFpXYkMJb0XIv JyUt5yYPKfV13N8kSkPi5pLxm8yuftXMzfgeFMR7nafY3glTVj/TxElzg6xeZNqf C2ZjIbBtZg9ylHU8u8wwB+dX282crs0R3N9A064C71/cXlBqcjzjlKH2NUIWGxr+ od3TXFIFjszSU3NgMPKrWNhFLLwS81MpbkOe73s6aDhS8RDyNucoxtKXriLR+4Xi u4+pyj5ukYP1JqpB3ZobY/XZgCnJMye+7xeTpIDJ1LPORxM3NNAElyb26lxAK2P+ km+EpI0Zzz6rNSCfg5jYQ474+e/GBgaSG4MlaPoZ+XAfN46u1Xjjv1/AkkA4IA6m 5zP5og=3D=3D =3D3NUt -----END PGP PUBLIC KEY BLOCK----- --------------030204000100090505050800-- --CVLSawr1iwahAbuX5xN4ruLRI32FNk38F 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 iQIcBAEBCgAGBQJVERBPAAoJEMDeajWKOdxmHpoP/2cvnvfrMfmvbe3YeBMnFB6U lOQbeMkegPVYoXoTBXMhubkbhRbegNp8bKkeXFsyY+GVXllKFLUvCnYsK0viouPJ xArVIyApCHfh5U+x4xS/hW76kdzFu1v59o46AIXPJwBNfGcgC4J/LPgvip7Qz5t4 hx0F8LlFcwVwOn067g7o0nl4naK+s/t7jwTXy5+jvTu9l5VjF6qBY9J10Hh5/547 qTE2m8WlJ3HsBUr8/KEVxEDv1o/lCFx+lTZh2VhaIRzztNhIGtyWXWLWgC2Gegne oA6eA3VAhYBcg0HrpWbKHbX6UxuxyQV7PGqAb5fRfOunZvLqTw+zpIAjD2adQU5k qIzNyvOUXpt6fNz9ILurMV/6mtFUsRys4bK2iviHK7+HnXCLX48bMFsqQ7reqQQI IRgTBXaB1FUq8IXFywqzvqEwKe+cPBoDVomC6mWz7ITkv7MzFXPHDaY2hgqrOAVz DjxzME/5f13djZNCx3RF4+fnJl9eBPJ6wk4f9tn6NIqefsvZwGrqL/PzDAXSxZeT w9aLpbl6c3zK6cKBfVbEDyTkz+5o9LNtu80ZC5riArWH1m2u7C0Ghr6lPR0lgLeK Qj6O3/n1tPIjEipVSZ0L4FxUMtLBGktpn3GqJEMxnf605H7hRlotR43ARjMCNH9p MX9YeGFYVIK4E7cffi1S =Hejc -----END PGP SIGNATURE----- --CVLSawr1iwahAbuX5xN4ruLRI32FNk38F-- From nobody Tue Mar 24 04:47:28 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9993D1A8993 for ; Tue, 24 Mar 2015 04:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id br4ujmcPbzIl for ; Tue, 24 Mar 2015 04:47:26 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id CC4131A88E6 for ; Tue, 24 Mar 2015 04:47:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4245B22404DA; Tue, 24 Mar 2015 12:47:24 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xx180lqnNChW; Tue, 24 Mar 2015 12:47:16 +0100 (CET) Received: from dhcp-943f.meeting.ietf.org (dhcp-943f.meeting.ietf.org [31.133.148.63]) by power.freeradius.org (Postfix) with ESMTPSA id A5CBC2240192; Tue, 24 Mar 2015 12:47:15 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Tue, 24 Mar 2015 06:47:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> To: Peter Deacon X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 11:47:27 -0000 On Mar 23, 2015, at 6:03 PM, Peter Deacon = wrote: > I recommend effective means of isolation of administrative domains be = explicitly required as part of any charter for this work item. I don=92t see a need for the charter to be updated. Security is = always a factor in every work item. It doesn=92t need to be explicitly = called out. > Even if many of details are left up to implementations there has to be = a reasonable enabling means. Without it I don't support the work item = as resulting product would not be suitable for deployment. You=92re assuming that without the charter update, everyone will = ignore the problem. I don=92t think that=92s realistic. Alan DeKok. From nobody Tue Mar 24 04:59:53 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D8F1B2E82 for ; Tue, 24 Mar 2015 04:59:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avciKS638aDF for ; Tue, 24 Mar 2015 04:59:51 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 458631B2E80 for ; Tue, 24 Mar 2015 04:59:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 96EF522404DA; Tue, 24 Mar 2015 12:59:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F7frmKvcSMM6; Tue, 24 Mar 2015 12:59:19 +0100 (CET) Received: from dhcp-943f.meeting.ietf.org (dhcp-943f.meeting.ietf.org [31.133.148.63]) by power.freeradius.org (Postfix) with ESMTPSA id 887A422403D4; Tue, 24 Mar 2015 12:59:18 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Tue, 24 Mar 2015 06:59:16 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6C5BFB5E-133B-4D3A-AB80-81D1C0F9AE38@deployingradius.com> References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: radext@ietf.org, Peter Deacon Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 11:59:52 -0000 On Mar 23, 2015, at 6:21 PM, Sam Hartman = wrote: > I think solving this requirement would be necessary for moving COA to > the standards track or removing the health warning in 5176. I agree. Let=92s say that each proxy selectively forwards CoA packets based on = it=92s knowledge of the user sessions. This means that every proxy has = to maintain information on every user session, which is untenable. Or maybe the sessions contain some kind of state that the proxy can = cryptographically verify. That means sharing the cryptographic keys = with all proxies, which is also untenable. In the end, I don=92t see this as a session state problem. It=92s a = routing problem. For a situation Visited -> Proxy -> Home, packets are = usually forwarded based on User-Name, and realm. When the Home server = wants to disconnect a user, it typically sends User-Name as part of the = session identification attributes. So all that=92s needed is for the = proxy to look up that realm. i.e. the algorithm is this: forwarding proxy: receive packet with User-Name, look up realm, and = forward packet to that realm. CoA proxy: receive packet with Operator-Name and User-Name. Look up = realm from *User-Name*. If the source of the packet does not match a = known destination for that realm, then drop the packet as being = non-compliant. Otherwise, look up realm from *Operator-Name*, and = forward the CoA packet there. This solution does have limitations. It requires that the forwarding = path contain information about CoA clients. It requires that proxying = is done on User-Name. However, I think that those restrictions are reasonable. All of the = cross-organization roaming I=92m aware of is done via User-Name, so this = solution imposes no operational changes on current systems. Alan DeKok. From nobody Tue Mar 24 07:28:52 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AE11A877E for ; Tue, 24 Mar 2015 07:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGN-9FcAxARk for ; Tue, 24 Mar 2015 07:28:43 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044231A8784 for ; Tue, 24 Mar 2015 07:28:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 3D6352066F; Tue, 24 Mar 2015 10:26:33 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNX7jgWZygzL; Tue, 24 Mar 2015 10:26:32 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Mar 2015 10:26:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 55EF18720D; Tue, 24 Mar 2015 10:28:09 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> <5511104F.2030006@restena.lu> Date: Tue, 24 Mar 2015 10:28:09 -0400 In-Reply-To: <5511104F.2030006@restena.lu> (Stefan Winter's message of "Tue, 24 Mar 2015 08:20:47 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:28:50 -0000 Ah, I didn't catch that the COA proxy document was labeled standards track. That's not OK unless we're moving 5176, which I don't support absent some serious changes. So, yes I support same status as 5176. --Sam From nobody Tue Mar 24 07:59:50 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854FE1A87E0 for ; Tue, 24 Mar 2015 07:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NfGUnj0d_aVZ for ; Tue, 24 Mar 2015 07:59:46 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566EF1A87D2 for ; Tue, 24 Mar 2015 07:59:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 16D0420678; Tue, 24 Mar 2015 10:58:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euD2x7N5HPDP; Tue, 24 Mar 2015 10:58:04 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Mar 2015 10:58:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5A17B8720D; Tue, 24 Mar 2015 10:59:43 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> <6C5BFB5E-133B-4D3A-AB80-81D1C0F9AE38@deployingradius.com> Date: Tue, 24 Mar 2015 10:59:43 -0400 In-Reply-To: <6C5BFB5E-133B-4D3A-AB80-81D1C0F9AE38@deployingradius.com> (Alan DeKok's message of "Tue, 24 Mar 2015 06:59:16 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: radext@ietf.org, Peter Deacon Subject: Re: [radext] Secure COA X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 14:59:48 -0000 >>>>> "Alan" =3D=3D Alan DeKok writes: Alan> On Mar 23, 2015, at 6:21 PM, Sam Hartman wrote: >> I think solving this requirement would be necessary for moving >> COA to the standards track or removing the health warning in >> 5176. Alan> I agree. Alan> Let=E2=80=99s say that each proxy selectively forwards CoA pack= ets Alan> based on it=E2=80=99s knowledge of the user sessions. This means= that Alan> every proxy has to maintain information on every user session, Alan> which is untenable. I actually can think of ways of approaching this. This scaling problem seems no worse than some scaling problems websites face and some of the solutions there seem applicable. However, this seems like the wrong approach to me, because it is more complex than needed. Alan> Or maybe the sessions contain some kind of state that the Alan> proxy can cryptographically verify. That means sharing the Alan> cryptographic keys with all proxies, which is also untenable. It's much less obvious to me that this is untenible. We definitely have key distribution mechanisms that seem up to the task. This is especially true in deployments where the original access request travels through the same operators as the COA packet travels in reverse. In that case, operators can add/transform their own state, and need only manage keys within their own domain. Alan> In the end, I don=E2=80=99t see this as a session state problem. Alan> It=E2=80=99s a routing problem. For a situation Visited -> Proxy= -> Alan> Home, packets are usually forwarded based on User-Name, and Alan> realm. When the Home server wants to disconnect a user, it Alan> typically sends User-Name as part of the session Alan> identification attributes. So all that=E2=80=99s needed is for t= he Alan> proxy to look up that realm. Alan> i.e. the algorithm is this: Alan> forwarding proxy: receive packet with User-Name, look up Alan> realm, and forward packet to that realm. Alan> CoA proxy: receive packet with Operator-Name and User-Name. Alan> Look up realm from *User-Name*. If the source of the packet Alan> does not match a known destination for that realm, then drop Alan> the packet as being non-compliant. Otherwise, look up realm Alan> from *Operator-Name*, and forward the CoA packet there. This seems fairly weak to me. I'd be much more comfortable with a solution that took routing and session state into account. From nobody Tue Mar 24 08:42:29 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C59DE1A8934 for ; Tue, 24 Mar 2015 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpMTIVHaZSQB for ; Tue, 24 Mar 2015 08:42:21 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 88FD31A8A7F for ; Tue, 24 Mar 2015 08:42:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 02C2B2240853; Tue, 24 Mar 2015 16:42:11 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qoia9_je3KJg; Tue, 24 Mar 2015 16:42:10 +0100 (CET) Received: from dhcp-a5d0.meeting.ietf.org (dhcp-a5d0.meeting.ietf.org [31.133.165.208]) by power.freeradius.org (Postfix) with ESMTPSA id 99C092240363; Tue, 24 Mar 2015 16:42:09 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Tue, 24 Mar 2015 05:42:07 -1000 Content-Transfer-Encoding: quoted-printable Message-Id: <32EBB4F3-56D8-434B-83CD-9CD570A62F18@deployingradius.com> References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> <6C5BFB5E-133B-4D3A-AB80-81D1C0F9AE38@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: radext@ietf.org, Peter Deacon Subject: Re: [radext] Secure COA X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:42:25 -0000 To back up a bit, most of the forgery problem can be avoided by noting = that the Operator-NAS-Identifier is itself a unique key. If the visited = realm creates many values for the attribute, then guessing correct = values is hard, and forgery is trivially detectable. i.e. if each user session has a different Operator-NAS-Identifier, = then a home server can forge a CoA packet, but it will get detected by = the visited realm as a forgery. The proxies need to do nothing. The visited realm could simply track user sessions in a database (as = they mostly do now), and create unique Operator-NAS-Identifiers for each = user. When receiving a CoA request, look up the identifier in a DB, and = get the IP of the NAS from there. Or, the visited realm could be = stateless, and encrypt the real NAS IP address with a combination of a = secret local key, and the destination realm. This makes a unique (and = secret) identifier for each realm, and for each NAS in the visited = realm. Remember, all of these packets are sent within a trusted network. The = systems aren=92t open to the wider internet, and there isn=92t a = requirement to protect against DoS attacks from every single IP on the = planet. I view the forgery problem as something which is best dealt with by = non-technical means. *Detecting* forgery is a technical requirement. = But *preventing* forgery isn=92t necessarily a requirement. i.e. it=92s OK for the visited realm to detect a forged request, = ignore it, and escalate the problem to an administrator. The = intermediate proxies don=92t need to detect or prevent the forgery. = That=92s a hard problem to solve. On Mar 24, 2015, at 4:59 AM, Sam Hartman = wrote: re: crypto keys > It's much less obvious to me that this is untenible. > We definitely have key distribution mechanisms that seem up to the = task. > This is especially true in deployments where the original access = request > travels through the same operators as the COA packet travels in > reverse. > In that case, operators can add/transform their own state, and need = only > manage keys within their own domain. If we do want the proxies to get involved, we could use per-proxy = encryption keys. Each proxy has it=92s own secret key, K_p. The proxy uses the key to = encrypt the Operator-NAS-Identifier when proxying auth / acct packets to = a home server. It uses the same key to decrypt the = Operator-NAS-Identifier when proxying CoA / Disconnect packets to the = visited realm. Forged packets from home servers get decrypted to = nonsense, and the visited realm will reject the CoA packet. The reason this works is that no one but the visited realm can = interpret Operator-NAS-Identifier. Therefore, it=92s safe to transform = the value in a =93conservative=94 or reversible way. re: User-Name verification. > This seems fairly weak to me. It=92s not perfect, but it=92s not wrong. It=92s a good idea to do, = in any case. > I'd be much more comfortable with a solution that took routing and > session state into account. I agree. In the end, I think the solutions to this are pretty simple. CoA = proxies can protect themselves by doing reverse realm lookups on = User-Name. Visited realms can prevent forgery by using unique = Operator-NAS-Identifiers within a large space. Alan DeKok. From nobody Tue Mar 24 08:44:15 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB551A8935 for ; Tue, 24 Mar 2015 08:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFrDQl76J9SP for ; Tue, 24 Mar 2015 08:44:06 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F5D21A8948 for ; Tue, 24 Mar 2015 08:44:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 737782067A; Tue, 24 Mar 2015 11:42:26 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MG5qoEGjs8LU; Tue, 24 Mar 2015 11:42:26 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 24 Mar 2015 11:42:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 22D3A8720D; Tue, 24 Mar 2015 11:44:04 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> <6C5BFB5E-133B-4D3A-AB80-81D1C0F9AE38@deployingradius.com> <32EBB4F3-56D8-434B-83CD-9CD570A62F18@deployingradius.com> Date: Tue, 24 Mar 2015 11:44:04 -0400 In-Reply-To: <32EBB4F3-56D8-434B-83CD-9CD570A62F18@deployingradius.com> (Alan DeKok's message of "Tue, 24 Mar 2015 05:42:07 -1000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org, Peter Deacon Subject: Re: [radext] Secure COA X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 15:44:10 -0000 What you say here makes sense too. >>>>> "Alan" == Alan DeKok writes: Alan> To back up a bit, most of the forgery problem can be avoided Alan> by noting that the Operator-NAS-Identifier is itself a unique Alan> key. If the visited realm creates many values for the Alan> attribute, then guessing correct values is hard, and forgery Alan> is trivially detectable. Alan> i.e. if each user session has a different Alan> Operator-NAS-Identifier, then a home server can forge a CoA Alan> packet, but it will get detected by the visited realm as a Alan> forgery. The proxies need to do nothing. Alan> The visited realm could simply track user sessions in a Alan> database (as they mostly do now), and create unique Alan> Operator-NAS-Identifiers for each user. When receiving a CoA Alan> request, look up the identifier in a DB, and get the IP of the Alan> NAS from there. Or, the visited realm could be stateless, and Alan> encrypt the real NAS IP address with a combination of a secret Alan> local key, and the destination realm. This makes a unique Alan> (and secret) identifier for each realm, and for each NAS in Alan> the visited realm. From nobody Tue Mar 24 09:33:47 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E47F81A90F1 for ; Tue, 24 Mar 2015 09:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVioK5prpuyc for ; Tue, 24 Mar 2015 09:33:44 -0700 (PDT) Received: from aspen.iea-software.com (www.iea-software.com [70.89.142.193]) by ietfa.amsl.com (Postfix) with ESMTP id B28981A90C4 for ; Tue, 24 Mar 2015 09:33:42 -0700 (PDT) Received: from SMURF.peterd.ws (unverified [10.0.3.195]) by aspen.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 24 Mar 2015 09:33:40 -0700 Date: Tue, 24 Mar 2015 09:33:47 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <5511104F.2030006@restena.lu> Message-ID: References: <5502B836.5000100@restena.lu> <9C712CB9-7834-4049-9318-54E769F7661D@deployingradius.com> <2DB68EA1-97A6-4263-9E7F-9BD24B567C7A@deployingradius.com> <5FA970CC-2E05-4EFC-8AE6-840D334B28E4@deployingradius.com> <1A6EF1EA-3412-4AAA-9646-3FD18EC0C4E4@deployingradius.com> <5511104F.2030006@restena.lu> User-Agent: Alpine 2.20.1 (WNT 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII; FORMAT=flowed Content-ID: Archived-At: Cc: radext@ietf.org Subject: Re: [radext] Proposed new charter text X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Mar 2015 16:33:46 -0000 On Tue, 24 Mar 2015, Stefan Winter wrote: > I like that way out, if everyone else can live with it. I'd appreciate > comments from the working group on that topic, particularly from the > three of you of course :-) +------+ +-------+ +-------+ +-------+ +-------+ +----------+ | Home | - | RoamA | - | RoamB | - | RoamC | - | Visit | - | VisitNAS | +------+ +-------+ +-------+ +-------+ +-------+ +----------+ My best estimation of how this would work was simply to specify a generic state attribute.. Dynamic-Proxy-State and call it a day. Any administrative domain (RoamA-C or Visit) requiring verification injects Dynamic-Proxy-State into Access-Request. Dynamic Auth Clients are required to forward this information when issuing DM/CoA requests. Any admin domain in the path requiring verification then checks Dynamic-Proxy-State.. ideally at the border (RoamA) where the identity of sender is well established but intra-domain implementations can coordinate however they want. If attribute is missing but required and triplet of proxy state, identity and session identifiers of request do not add up the request is rejected. It would have the following general properties: - Injectable by anyone in proxy path via Access-Request .. "0+" -- Ideally once per admin domain implying some form of implementation dependant Intra-domain coordination. - DACs must transmit ALL Dynamic-Proxy-State atttributes from access request. - Recommendations to keep size and number of Dynamic-Proxy-State attributes as low as possible but specify no cutoff or required minimum. This is basically it.. implementations can do whatever they want to implement it... They can keep a state table or stuff the attribute with source, session identifying hints, cryptographic signatures and not have to keep much of any state at all. It should provide general advice on design options, tradeoffs, recommendations and perils of which I'm sure we call all dream up plenty. I prefer a solution that does not depend on keeping secrets.. Even if competitors sniffed out Dynamic-Proxy-State from my wires and know all of the session identifiers for my customers it would be preferable if re-injecting this information (often sent in the clear right now): not yield fruit. regards, Peter From nobody Fri Mar 27 12:25:55 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCDE1B2EFD; Thu, 26 Mar 2015 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlAGDJvvM6-2; Thu, 26 Mar 2015 13:46:37 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940691B2EF9; Thu, 26 Mar 2015 13:46:35 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2QKkZ0g019175; Thu, 26 Mar 2015 20:46:35 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 36F8EC20665; Thu, 26 Mar 2015 20:46:35 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814254 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 26 Mar 2015 20:46:35 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 12:25:54 -0700 Cc: radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-dynamic-discovery.all@ietf.org Subject: [radext] [IANA #814254] Expert review for draft-ietf-radext-dynamic-discovery-13 (S-NAPTR Parameters) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-expert-review@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:46:38 -0000 Dear Authors, This draft requests three S-NAPTR Application Service Tags and two S-NAPTR Application Protocol Tags. The IESG designated expert, Jouni Korhonen, has reviewed and approved this. Note: This message is only to inform you the IESG expert review result. The actions requested in this document will not be completed until the document has been approved for publication as an RFC. Thanks, ~pl Pearl Liang ICANN From nobody Fri Mar 27 12:25:56 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 7F01A1B2F01; Thu, 26 Mar 2015 13:46:38 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCDE1B2EFD; Thu, 26 Mar 2015 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.19 X-Spam-Level: X-Spam-Status: No, score=-3.19 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlAGDJvvM6-2; Thu, 26 Mar 2015 13:46:37 -0700 (PDT) Received: from smtp1.lax.icann.org (smtp01.icann.org [192.0.33.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 940691B2EF9; Thu, 26 Mar 2015 13:46:35 -0700 (PDT) Received: from request3.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp1.lax.icann.org (8.13.8/8.13.8) with ESMTP id t2QKkZ0g019175; Thu, 26 Mar 2015 20:46:35 GMT Received: by request3.lax.icann.org (Postfix, from userid 48) id 36F8EC20665; Thu, 26 Mar 2015 20:46:35 +0000 (UTC) RT-Owner: pearl.liang From: "Pearl Liang via RT" In-Reply-To: References: Message-ID: X-RT-Loop-Prevention: IANA X-RT-Ticket: IANA #814254 X-Managed-BY: RT 4.2.9 (http://www.bestpractical.com/rt/) X-RT-Originator: pearl.liang@icann.org Content-Type: text/plain; charset="utf-8" X-RT-Original-Encoding: utf-8 Precedence: bulk Date: Thu, 26 Mar 2015 20:46:35 +0000 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: X-Mailman-Approved-At: Fri, 27 Mar 2015 12:25:54 -0700 Cc: radext@ietf.org, radext-chairs@ietf.org, draft-ietf-radext-dynamic-discovery.all@ietf.org Subject: [radext] [IANA #814254] Expert review for draft-ietf-radext-dynamic-discovery-13 (S-NAPTR Parameters) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Reply-To: drafts-expert-review@iana.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Mar 2015 20:46:38 -0000 Dear Authors, This draft requests three S-NAPTR Application Service Tags and two S-NAPTR Application Protocol Tags. The IESG designated expert, Jouni Korhonen, has reviewed and approved this. Note: This message is only to inform you the IESG expert review result. The actions requested in this document will not be completed until the document has been approved for publication as an RFC. Thanks, ~pl Pearl Liang ICANN From nobody Tue Mar 31 09:50:33 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79ECF1A03AA for ; Tue, 31 Mar 2015 09:50:32 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rM-IgklwkyDA for ; Tue, 31 Mar 2015 09:50:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F861A037C for ; Tue, 31 Mar 2015 09:50:30 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 958A5264205; Tue, 31 Mar 2015 18:50:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7BB0C27C071; Tue, 31 Mar 2015 18:50:28 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 18:50:28 +0200 From: To: "radext@ietf.org" Thread-Topic: Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 Thread-Index: AdBrzoIzGZAmzf18QgisvgcZtEu1tw== Date: Tue, 31 Mar 2015 16:50:27 +0000 Message-ID: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.31.153318 Archived-At: Cc: "radext-chairs@tools.ietf.org" Subject: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:50:32 -0000 During the RADEXT session at IETF92, , the authors of draft-winter-radext-p= opulating-eapidentity-01 have asked for adoption of this individual draft a= s WG document. This email officially starts a call for adoption for the following document= =20 http://tools.ietf.org/html/draft-winter-radext-populating-eapidentity-01 Please respond to this email to support the document and/or send comments b= y 2015-04-06. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd Especially Authors and Contributors of the draft: Are you personally aware of any IPR that applies to draft-winter-radext-pop= ulating-eapidentity-01? If so, has this IPR been disclosed in compliance wi= th IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please= reply to this email message regardless of whether or not you are personall= y aware of any relevant IPR. We might not be able to advance this document= to the next stage until we have received a reply from each author and list= ed contributor. If you are on the RADEXT WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Stefan ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Mar 31 09:50:58 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA131A037C for ; Tue, 31 Mar 2015 09:50:51 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvsPX5F2RRgW for ; Tue, 31 Mar 2015 09:50:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93F161A0266 for ; Tue, 31 Mar 2015 09:50:49 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id E4BBF2AC37C; Tue, 31 Mar 2015 18:50:47 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id CC3FEC80AB; Tue, 31 Mar 2015 18:50:47 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 18:50:47 +0200 From: To: "radext@ietf.org" Thread-Topic: Start of Call for Adoption for draft-dekok-radext-datatypes-05 Thread-Index: AdBr0gDTR+rpJ9jJR2irexMxfDFazQ== Date: Tue, 31 Mar 2015 16:50:47 +0000 Message-ID: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.31.153318 Archived-At: Cc: "radext-chairs@tools.ietf.org" Subject: [radext] Start of Call for Adoption for draft-dekok-radext-datatypes-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:50:52 -0000 During the RADEXT session at IETF92, , the authors of draft-dekok-radext-da= tatypes-05 have asked for adoption of this individual draft as WG document. This email officially starts a call for adoption for the following document= :=20 http://tools.ietf.org/html/draft-dekok-radext-datatypes-05 Please respond to this email to support the document and/or send comments b= y 2015-04-06. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd especially Authors and Contributors of the draft: Are you personally aware of any IPR that applies to draft-dekok-radext-data= types-05? If so, has this IPR been disclosed in compliance with IETF IPR ru= les? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please= reply to this email message regardless of whether or not you are personall= y aware of any relevant IPR. We might not be able to advance this document= to the next stage until we have received a reply from each author and list= ed contributor. If you are on the RADEXT WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Stefan ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Mar 31 09:51:03 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE2F1A0AF7 for ; Tue, 31 Mar 2015 09:51:02 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EgX7GurrwWYh for ; Tue, 31 Mar 2015 09:50:58 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E5841A06FD for ; Tue, 31 Mar 2015 09:50:58 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 1446D18C0AE; Tue, 31 Mar 2015 18:50:57 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id EB3B127C0AD; Tue, 31 Mar 2015 18:50:56 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 18:50:56 +0200 From: To: "radext@ietf.org" Thread-Topic: Start of Call for Adoption for draft-dekok-radext-coa-proxy-00 Thread-Index: AdBr0YU1xyKkiFqSRVOdVBdttCrY8A== Date: Tue, 31 Mar 2015 16:50:55 +0000 Message-ID: <11852_1427820657_551AD070_11852_405_1_6B7134B31289DC4FAF731D844122B36EEF68D5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.2.12.3031 Archived-At: Cc: "radext-chairs@tools.ietf.org" Subject: [radext] Start of Call for Adoption for draft-dekok-radext-coa-proxy-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:51:02 -0000 During the RADEXT session at IETF92, , the authors of draft-dekok-radext-co= a-proxy-00 have asked for adoption of this individual draft as WG document. This email officially starts a call for adoption for the following document= :=20 http://tools.ietf.org/html/draft-dekok-radext-coa-proxy-00 Please respond to this email to support the document and/or send comments b= y 2015-04-06. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd Especially Authors and Contributors of the draft: Are you personally aware of any IPR that applies to draft-dekok-radext-coa-= proxy-00? If so, has this IPR been disclosed in compliance with IETF IPR ru= les? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please= reply to this email message regardless of whether or not you are personall= y aware of any relevant IPR. We might not be able to advance this document= to the next stage until we have received a reply from each author and list= ed contributor. If you are on the RADEXT WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Stefan ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Mar 31 09:51:25 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657B51A06FD for ; Tue, 31 Mar 2015 09:51:20 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjtXrfmdzQxK for ; Tue, 31 Mar 2015 09:51:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F0351A0266 for ; Tue, 31 Mar 2015 09:51:13 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 5DD332AC37C; Tue, 31 Mar 2015 18:51:12 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3DA4C1580C5; Tue, 31 Mar 2015 18:51:12 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 18:51:11 +0200 From: To: "radext@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-radext-bigger-packets-03 Thread-Index: AdBr0BkOCU/I1ppRTMOlPqUQcobZ7A== Date: Tue, 31 Mar 2015 16:51:11 +0000 Message-ID: <10094_1427820672_551AD080_10094_7303_1_6B7134B31289DC4FAF731D844122B36EEF691F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.31.153318 Archived-At: Cc: "radext-chairs@tools.ietf.org" Subject: [radext] Start of WGLC for draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:51:20 -0000 During the RADEXT session at IETF92, the authors of draft-ietf-radext-bigge= r-packets-03 have asked for a Working Group Last Call. This email officially starts a Working Group Last Call for the following do= cument=20 http://tools.ietf.org/html/draft-ietf-radext-bigger-packets-03 Please respond to this email to support the document and/or send comments b= y 2015-04-13. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd Especially Authors and Contributors of the draft: Are you personally aware of any IPR that applies to draft-ietf-radext-bigge= r-packets-03? If so, has this IPR been disclosed in compliance with IETF IP= R rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please= reply to this email message regardless of whether or not you are personall= y aware of any relevant IPR. We might not be able to advance this document= to the next stage until we have received a reply from each author and list= ed contributor. If you are on the RADEXT WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Stefan ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Mar 31 09:51:37 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138141ACDC0 for ; Tue, 31 Mar 2015 09:51:33 -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=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP0awJOkKDoz for ; Tue, 31 Mar 2015 09:51:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DEB1ACD5B for ; Tue, 31 Mar 2015 09:51:26 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 975EC3740DC; Tue, 31 Mar 2015 18:51:25 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 730711580CC; Tue, 31 Mar 2015 18:51:25 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 18:51:24 +0200 From: To: "radext@ietf.org" Thread-Topic: Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 Thread-Index: AdBr0OfvWsGnfW7ITUyirhe2Cq01uw== Date: Tue, 31 Mar 2015 16:51:24 +0000 Message-ID: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.31.153318 Archived-At: Cc: "radext-chairs@tools.ietf.org" Subject: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:51:33 -0000 During the RADEXT session at IETF92, the authors of draft-ietf-radext-ip-po= rt-radius-ext-03 have asked for a Working Group Last Call. This email officially starts a Working Group Last Call for the following do= cument=20 http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-03 Please respond to this email to support the document and/or send comments b= y 2015-04-13. In addition, following the strategy for promoting compliance with the IPR d= isclosure rules (RFC6702), the chairs would like to check whether there ar= e claims of Intellectual Property Rights (IPR) on the document that need to= be disclosed. Therefore, the following questions are addressed to the WG a= nd Especially Authors and Contributors of the draft: Are you personally aware of any IPR that applies to draft-ietf-radext-ip-po= rt-radius-ext-03? If so, has this IPR been disclosed in compliance with IET= F IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) If you are a document author or listed contributor on this document, please= reply to this email message regardless of whether or not you are personall= y aware of any relevant IPR. We might not be able to advance this document= to the next stage until we have received a reply from each author and list= ed contributor. If you are on the RADEXT WG email list but are not an author or listed cont= ributor for this document, you are reminded of your opportunity for a volun= tary IPR disclosure under BCP 79. Please do not reply unless you want to = make such a voluntary disclosure. Online tools for filing IPR disclosures can be found at . Regards, Lionel & Stefan ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Mar 31 09:52:21 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578D71A037F for ; Tue, 31 Mar 2015 09:52:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cc_M3v69NiKc for ; Tue, 31 Mar 2015 09:52:18 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id B6C991A0372 for ; Tue, 31 Mar 2015 09:52:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2597E2240579; Tue, 31 Mar 2015 18:51:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hDfV2xH87ZqF; Tue, 31 Mar 2015 18:51:46 +0200 (CEST) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id C4F642240168; Tue, 31 Mar 2015 18:51:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 12:51:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-dekok-radext-datatypes-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:52:20 -0000 I support the adoption. I have no IPR on this document. On Mar 31, 2015, at 12:50 PM, = wrote: > During the RADEXT session at IETF92, , the authors of = draft-dekok-radext-datatypes-05 have asked for adoption of this = individual draft as WG document. >=20 > This email officially starts a call for adoption for the following = document:=20 >=20 > http://tools.ietf.org/html/draft-dekok-radext-datatypes-05 >=20 > Please respond to this email to support the document and/or send = comments by 2015-04-06. >=20 > In addition, following the strategy for promoting compliance with the = IPR disclosure rules (RFC6702), the chairs would like to check whether = there are claims of Intellectual Property Rights (IPR) on the document = that need to be disclosed. Therefore, the following questions are = addressed to the WG and especially Authors and Contributors of the = draft: >=20 > Are you personally aware of any IPR that applies to = draft-dekok-radext-datatypes-05? If so, has this IPR been disclosed in = compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 = for more details.) >=20 > If you are a document author or listed contributor on this document, = please reply to this email message regardless of whether or not you are = personally aware of any relevant IPR. We might not be able to advance = this document to the next stage until we have received a reply from each = author and listed contributor. >=20 > If you are on the RADEXT WG email list but are not an author or listed = contributor for this document, you are reminded of your opportunity for = a voluntary IPR disclosure under BCP 79. Please do not reply unless = you want to make such a voluntary disclosure. >=20 > Online tools for filing IPR disclosures can be found at = . >=20 > Regards, >=20 > Lionel & Stefan >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 09:57:17 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6931A0318 for ; Tue, 31 Mar 2015 09:57:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oN9-2KamCSR0 for ; Tue, 31 Mar 2015 09:57:15 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE321A006F for ; Tue, 31 Mar 2015 09:57:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id E6D032240597; Tue, 31 Mar 2015 18:57:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqTK3hOwdeDU; Tue, 31 Mar 2015 18:57:13 +0200 (CEST) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 740FE224024E; Tue, 31 Mar 2015 18:57:12 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <11852_1427820657_551AD070_11852_405_1_6B7134B31289DC4FAF731D844122B36EEF68D5@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 12:57:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <190A8CE8-BCEA-4684-B9B0-E7F78BF7F2F7@deployingradius.com> References: <11852_1427820657_551AD070_11852_405_1_6B7134B31289DC4FAF731D844122B36EEF68D5@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-dekok-radext-coa-proxy-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:57:16 -0000 I support adoption of this document. I have no IPR on this document. On Mar 31, 2015, at 12:50 PM, = wrote: > During the RADEXT session at IETF92, , the authors of = draft-dekok-radext-coa-proxy-00 have asked for adoption of this = individual draft as WG document. >=20 > This email officially starts a call for adoption for the following = document:=20 >=20 > http://tools.ietf.org/html/draft-dekok-radext-coa-proxy-00 >=20 > Please respond to this email to support the document and/or send = comments by 2015-04-06. >=20 > In addition, following the strategy for promoting compliance with the = IPR disclosure rules (RFC6702), the chairs would like to check whether = there are claims of Intellectual Property Rights (IPR) on the document = that need to be disclosed. Therefore, the following questions are = addressed to the WG and Especially Authors and Contributors of the = draft: >=20 > Are you personally aware of any IPR that applies to = draft-dekok-radext-coa-proxy-00? If so, has this IPR been disclosed in = compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 = for more details.) >=20 > If you are a document author or listed contributor on this document, = please reply to this email message regardless of whether or not you are = personally aware of any relevant IPR. We might not be able to advance = this document to the next stage until we have received a reply from each = author and listed contributor. >=20 > If you are on the RADEXT WG email list but are not an author or listed = contributor for this document, you are reminded of your opportunity for = a voluntary IPR disclosure under BCP 79. Please do not reply unless = you want to make such a voluntary disclosure. >=20 > Online tools for filing IPR disclosures can be found at = . >=20 > Regards, >=20 > Lionel & Stefan >=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 09:59:08 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 005DC1A0404 for ; Tue, 31 Mar 2015 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHXNf-fI8er5 for ; Tue, 31 Mar 2015 09:59:06 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DC1E1A1A73 for ; Tue, 31 Mar 2015 09:59:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B311220692; Tue, 31 Mar 2015 12:56:39 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QWta9YixHrhw; Tue, 31 Mar 2015 12:56:39 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (c-50-177-26-195.hsd1.ma.comcast.net [50.177.26.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 31 Mar 2015 12:56:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C99081821; Tue, 31 Mar 2015 12:58:33 -0400 (EDT) From: Sam Hartman To: References: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 12:58:33 -0400 In-Reply-To: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> (lionel morand's message of "Tue, 31 Mar 2015 16:51:24 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:59:08 -0000 >>>>> writes: > Are you personally aware of any IPR that applies to > draft-ietf-radext-ip-port-radius-ext-03? If so, has this IPR been > disclosed in compliance with IETF IPR rules? (See RFCs 3979, > 4879, 3669, and 5378 for more details.) Any necessary IPR disclosures I'm required to file have been filed. I have filed no disclosures. From nobody Tue Mar 31 10:00:00 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75C81A1A75 for ; Tue, 31 Mar 2015 09:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJiOxxcM2DtY for ; Tue, 31 Mar 2015 09:59:56 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4C31A0404 for ; Tue, 31 Mar 2015 09:59:56 -0700 (PDT) Received: from Philemon (unknown [69.59.217.42]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 4B21E2CA1E; Tue, 31 Mar 2015 09:59:56 -0700 (PDT) From: "Jim Schaad" To: , References: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 09:58:47 -0700 Message-ID: <039f01d06bd3$f55e64e0$e01b2ea0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIYBytR8V/Yiw90jCQkqchfLpq6OpynmYXA Content-Language: en-us Archived-At: Cc: radext-chairs@tools.ietf.org Subject: Re: [radext] Start of Call for Adoption for draft-dekok-radext-datatypes-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 16:59:58 -0000 Yes we should adopt this draft. > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of > lionel.morand@orange.com > Sent: Tuesday, March 31, 2015 9:51 AM > To: radext@ietf.org > Cc: radext-chairs@tools.ietf.org > Subject: [radext] Start of Call for Adoption for draft-dekok-radext-datatypes- > 05 > > During the RADEXT session at IETF92, , the authors of draft-dekok-radext- > datatypes-05 have asked for adoption of this individual draft as WG document. > > This email officially starts a call for adoption for the following document: > > http://tools.ietf.org/html/draft-dekok-radext-datatypes-05 > > Please respond to this email to support the document and/or send comments > by 2015-04-06. > > In addition, following the strategy for promoting compliance with the IPR > disclosure rules (RFC6702), the chairs would like to check whether there are > claims of Intellectual Property Rights (IPR) on the document that need to be > disclosed. Therefore, the following questions are addressed to the WG and > especially Authors and Contributors of the draft: > > Are you personally aware of any IPR that applies to draft-dekok-radext- > datatypes-05? If so, has this IPR been disclosed in compliance with IETF IPR > rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) > > If you are a document author or listed contributor on this document, please > reply to this email message regardless of whether or not you are personally > aware of any relevant IPR. We might not be able to advance this document to > the next stage until we have received a reply from each author and listed > contributor. > > If you are on the RADEXT WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity for a > voluntary IPR disclosure under BCP 79. Please do not reply unless you want > to make such a voluntary disclosure. > > Online tools for filing IPR disclosures can be found at > . > > Regards, > > Lionel & Stefan > > > ____________________________________________________________ > ____________________________________________________________ > _ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 10:00:56 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB1DD1A1AA8 for ; Tue, 31 Mar 2015 10:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfHSHLE9zlAf for ; Tue, 31 Mar 2015 10:00:51 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81AC31A1A92 for ; Tue, 31 Mar 2015 10:00:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id EA4BB22405AC; Tue, 31 Mar 2015 19:00:47 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr-h-G4LS7bn; Tue, 31 Mar 2015 19:00:47 +0200 (CEST) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id 4A719224024E; Tue, 31 Mar 2015 19:00:46 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <10094_1427820672_551AD080_10094_7303_1_6B7134B31289DC4FAF731D844122B36EEF691F@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 13:00:44 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7F6C8C5F-99AD-45A5-A4F5-E50F8D8C1F26@deployingradius.com> References: <10094_1427820672_551AD080_10094_7303_1_6B7134B31289DC4FAF731D844122B36EEF691F@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:00:55 -0000 I support adoption of this document. On Mar 31, 2015, at 12:51 PM, = wrote: > During the RADEXT session at IETF92, the authors of = draft-ietf-radext-bigger-packets-03 have asked for a Working Group Last = Call. >=20 > This email officially starts a Working Group Last Call for the = following document=20 >=20 > http://tools.ietf.org/html/draft-ietf-radext-bigger-packets-03 >=20 > Please respond to this email to support the document and/or send = comments by 2015-04-13. >=20 > In addition, following the strategy for promoting compliance with the = IPR disclosure rules (RFC6702), the chairs would like to check whether = there are claims of Intellectual Property Rights (IPR) on the document = that need to be disclosed. Therefore, the following questions are = addressed to the WG and Especially Authors and Contributors of the = draft: >=20 > Are you personally aware of any IPR that applies to = draft-ietf-radext-bigger-packets-03? If so, has this IPR been disclosed = in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 = for more details.) >=20 > If you are a document author or listed contributor on this document, = please reply to this email message regardless of whether or not you are = personally aware of any relevant IPR. We might not be able to advance = this document to the next stage until we have received a reply from each = author and listed contributor. >=20 > If you are on the RADEXT WG email list but are not an author or listed = contributor for this document, you are reminded of your opportunity for = a voluntary IPR disclosure under BCP 79. Please do not reply unless = you want to make such a voluntary disclosure. >=20 > Online tools for filing IPR disclosures can be found at = . >=20 > Regards, >=20 > Lionel & Stefan >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 10:20:13 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80A21A1B3C for ; Tue, 31 Mar 2015 10:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sb_-xbO9oa6m for ; Tue, 31 Mar 2015 10:20:06 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7D81A1B7B for ; Tue, 31 Mar 2015 10:20:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id A1B8B2068B; Tue, 31 Mar 2015 13:18:09 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cYdFWPrlRTFv; Tue, 31 Mar 2015 13:18:09 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 31 Mar 2015 13:18:09 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 52B1181821; Tue, 31 Mar 2015 13:20:05 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> <039f01d06bd3$f55e64e0$e01b2ea0$@augustcellars.com> Date: Tue, 31 Mar 2015 13:20:05 -0400 In-Reply-To: <039f01d06bd3$f55e64e0$e01b2ea0$@augustcellars.com> (Jim Schaad's message of "Tue, 31 Mar 2015 09:58:47 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: radext@ietf.org, radext-chairs@tools.ietf.org, lionel.morand@orange.com Subject: Re: [radext] Start of Call for Adoption for draft-dekok-radext-datatypes-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:20:11 -0000 I agree that we should adopt the datatypes draft; it is quite important. From nobody Tue Mar 31 10:25:08 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20481A1BFC for ; Tue, 31 Mar 2015 10:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRI2yomnpZ2l for ; Tue, 31 Mar 2015 10:24:58 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A994A1A1BD1 for ; Tue, 31 Mar 2015 10:24:58 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id C33532068E; Tue, 31 Mar 2015 13:23:01 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fgGc7tvvBDqh; Tue, 31 Mar 2015 13:23:01 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 31 Mar 2015 13:23:01 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7B7F781821; Tue, 31 Mar 2015 13:24:57 -0400 (EDT) From: Sam Hartman To: References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 13:24:57 -0400 In-Reply-To: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> (lionel morand's message of "Tue, 31 Mar 2015 16:50:27 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:25:06 -0000 >>>>> writes: > During the RADEXT session at IETF92, , the authors of > draft-winter-radext-populating-eapidentity-01 have asked for > adoption of this individual draft as WG document. This is important work. It should be adopted somewhere, and will get adequate review in radext. From nobody Tue Mar 31 10:30:18 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D85681A1A14 for ; Tue, 31 Mar 2015 10:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.909 X-Spam-Level: X-Spam-Status: No, score=-0.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxi5ayUKX2mI for ; Tue, 31 Mar 2015 10:30:16 -0700 (PDT) Received: from BLU004-OMC1S3.hotmail.com (blu004-omc1s3.hotmail.com [65.55.116.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDF11A03AA for ; Tue, 31 Mar 2015 10:30:15 -0700 (PDT) Received: from BLU181-W6 ([65.55.116.8]) by BLU004-OMC1S3.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 31 Mar 2015 10:30:15 -0700 X-TMN: [Iop+Hu0ueKyukY/0ywo1JMS5Z6AmT0lP] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_2aa90c50-9879-4c1a-b333-1351aef1d2a0_" From: Bernard Aboba To: Sam Hartman , "lionel.morand@orange.com" Date: Tue, 31 Mar 2015 10:30:14 -0700 Importance: Normal In-Reply-To: References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup>, MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2015 17:30:15.0199 (UTC) FILETIME=[59798AF0:01D06BD8] Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:30:18 -0000 --_2aa90c50-9879-4c1a-b333-1351aef1d2a0_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I agree that this work is important.=20 However=2C because it represents an update of RFC 3748=2C and the RADEXT WG= is not chartered to handle EAP maintenance=2C I do not believe it belongs = in this WG.=20 > From: hartmans@painless-security.com > To: lionel.morand@orange.com > Date: Tue=2C 31 Mar 2015 13:24:57 -0400 > CC: radext@ietf.org=3B radext-chairs@tools.ietf.org > Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-= populating-eapidentity-01 >=20 > >>>>> writes: >=20 > > During the RADEXT session at IETF92=2C =2C the authors of > > draft-winter-radext-populating-eapidentity-01 have asked for > > adoption of this individual draft as WG document. > This is important work. > It should be adopted somewhere=2C and will get adequate review in radext. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext = --_2aa90c50-9879-4c1a-b333-1351aef1d2a0_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I agree that this work is import= ant. =3B

However=2C because it represents an update = of RFC 3748=2C and the RADEXT WG is not chartered to handle EAP maintenance= =2C I do not believe it belongs in this WG. =3B
>=3B From: hartmans@painless-security.com
>=3B To: lionel.mora= nd@orange.com
>=3B Date: Tue=2C 31 Mar 2015 13:24:57 -0400
>=3B C= C: radext@ietf.org=3B radext-chairs@tools.ietf.org
>=3B Subject: Re: [= radext] Start of Call for Adoption for draft-winter-radext-populating-eapid= entity-01
>=3B
>=3B >=3B>=3B>=3B>=3B>=3B <=3Blione= l.morand@orange.com>=3B writes:
>=3B
>=3B >=3B During th= e RADEXT session at IETF92=2C =2C the authors of
>=3B >=3B draft= -winter-radext-populating-eapidentity-01 have asked for
>=3B >= =3B adoption of this individual draft as WG document.
>=3B This is imp= ortant work.
>=3B It should be adopted somewhere=2C and will get adequ= ate review in radext.
>=3B
>=3B ________________________________= _______________
>=3B radext mailing list
>=3B radext@ietf.org
= >=3B https://www.ietf.org/mailman/listinfo/radext
= --_2aa90c50-9879-4c1a-b333-1351aef1d2a0_-- From nobody Tue Mar 31 10:32:17 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 337DF1A1B25 for ; Tue, 31 Mar 2015 10:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39uk3v6Z6Q8b for ; Tue, 31 Mar 2015 10:32:14 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id E622C1A03A5 for ; Tue, 31 Mar 2015 10:32:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5A5BB2240592; Tue, 31 Mar 2015 19:32:13 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxog9sFMg035; Tue, 31 Mar 2015 19:32:12 +0200 (CEST) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id DFC542240579; Tue, 31 Mar 2015 19:32:11 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 13:32:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7BD5C839-E2F6-410D-A8A4-F16ADD5B1C02@deployingradius.com> References: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "lionel.morand@orange.com" X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:32:16 -0000 I'm not sure what Section 3.1.1 is for. It shouldn't be needed. The = document does NOT define a new extended type. It defines a new RADIUS = attribute. That attribute is allocated from the extended type space. My $0.02 is to remove Section 3.1.1, and all references to it. = Instead, just say: 3.1.2. IP-Port-Limit Attribute This attribute is of Extended-Type, and contains a set of embedded = TLVs ... Also, IANA should assign values. There's no need to call them out: Type: TBA1 - Extended-Type-1 (241), Extended-Type-2 (242), Extended- Type-3 (243), or Extended-Type-4 (244) per [RFC6929]. Just replace that with: Type: TBA1 It could be clearer that the same set of TLVs can be contained within = the encapsulating attribute. This means (e.g.) that IANA must allocate = *multiple* attributes, e.g. 241.33.1 IP-Port-Type TLV inside of IP-Port-Limit 241.34.1 P-Port-Type TLV inside of IP-Port-Forwarding-Map = Attribute etc. The IANA section isn't clear to me, either. e.g. o TBA1 (refer to Section 3.1.1): This value is for the Radius Type field and should be allocated from the number space of Extended- Type-1 (241), Extended-Type-2 (242), Extended-Type-3 (243), or Extended-Type-4 (244) per [RFC6929]. o TBA2 (refer to Section 3.1.1): This value is for the Extended-Type field and should be allocated from the Short Extended Space per [RFC6929]. That's unnecessary, and should be deleted. o TBA3 (refer to Section 3.2.1): This value is for the Type field of IP-Port-Type TLV. It should be allocated as TLV data type. It is within the TBA2 container and it extends the attribute tree as TBA1.TBA2.TBA3.[...]. Also, this value uniquely refers to IPFIX Element ID transportType (TBAx1). Just say something like "TBA3: IP-Port-Type allocated from within the = short extended space". The reference to IPFix should specify an IANA action: Add a note for that attribute, saying that this attribute = contains data from IPFix Element ID transportType TBAx1" If all of the TLVs can be used in all of the attributes, then the = allocation of the TLVs should be done for the *first* attribute. i.e. = IP-Port-Type is a sub-TLV of IP-Port-Limit, and should be assigned the = number "TBA3.1". It's OK to manually allocate numbers where they're = TLVs, and not been allocated before. The document should *also* tell IANA to prohibit allocation of TLVs = under the IP-Port-Forwarding-Map, etc. attributes. And note that those = attributes are all of type TLV, with TLVs defined by the IP-Port-Limit = attribute. That's it for now... Also, the document contains many data types which are explicitly = forbidden by RFC 6929. 8-bit, 16-bit, etc. While I know that these are = in IPFIX, I wouldn't recommend using them here. They should all be = moved to "integer" data types, with a note that the bits unused by IPFIX = *must* be zero. On Mar 31, 2015, at 12:51 PM, = wrote: > During the RADEXT session at IETF92, the authors of = draft-ietf-radext-ip-port-radius-ext-03 have asked for a Working Group = Last Call. >=20 > This email officially starts a Working Group Last Call for the = following document=20 >=20 > http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-03 >=20 > Please respond to this email to support the document and/or send = comments by 2015-04-13. >=20 > In addition, following the strategy for promoting compliance with the = IPR disclosure rules (RFC6702), the chairs would like to check whether = there are claims of Intellectual Property Rights (IPR) on the document = that need to be disclosed. Therefore, the following questions are = addressed to the WG and Especially Authors and Contributors of the = draft: >=20 > Are you personally aware of any IPR that applies to = draft-ietf-radext-ip-port-radius-ext-03? If so, has this IPR been = disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, = 3669, and 5378 for more details.) >=20 > If you are a document author or listed contributor on this document, = please reply to this email message regardless of whether or not you are = personally aware of any relevant IPR. We might not be able to advance = this document to the next stage until we have received a reply from each = author and listed contributor. >=20 > If you are on the RADEXT WG email list but are not an author or listed = contributor for this document, you are reminded of your opportunity for = a voluntary IPR disclosure under BCP 79. Please do not reply unless = you want to make such a voluntary disclosure. >=20 > Online tools for filing IPR disclosures can be found at = . >=20 > Regards, >=20 > Lionel & Stefan >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 10:35:35 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9531A1A1BF3 for ; Tue, 31 Mar 2015 10:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koNf6RrMJRyl for ; Tue, 31 Mar 2015 10:35:33 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF221A1B5D for ; Tue, 31 Mar 2015 10:35:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id B25DD2068F; Tue, 31 Mar 2015 13:33:06 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Z_hp3yQrrv2; Tue, 31 Mar 2015 13:33:06 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 31 Mar 2015 13:33:06 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 143C681821; Tue, 31 Mar 2015 13:35:02 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 13:35:02 -0400 In-Reply-To: (Bernard Aboba's message of "Tue, 31 Mar 2015 10:30:14 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:35:34 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> I agree that this work is important. However, because Bernard> it represents an update of RFC 3748, and the RADEXT WG is Bernard> not chartered to handle EAP maintenance, I do not believe Bernard> it belongs in this WG. We're in the middle of doing rechartering of the WG. It's quite clear that should we and the IESG choose we can charter this item without bringing EAP maintinance into this group. I'd be much more interested in thinking about whether we'll do a good job with the document and whether there's a better place to send it than an argument about the current text of the charter. The charter can be changed. --Sam From nobody Tue Mar 31 10:38:35 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2501A3B9C for ; Tue, 31 Mar 2015 10:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyqLV3o24DLX for ; Tue, 31 Mar 2015 10:38:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 57DD51A1F02 for ; Tue, 31 Mar 2015 10:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BA1062240592; Tue, 31 Mar 2015 19:38:02 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdL8vGZfl8Pd; Tue, 31 Mar 2015 19:38:00 +0200 (CEST) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id F3BE7224024E; Tue, 31 Mar 2015 19:37:58 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Tue, 31 Mar 2015 13:37:57 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8F1B85C8-A776-4F0A-A277-8221DBEF886C@deployingradius.com> References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup>, To: Aboba Bernard X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Sam Hartman , "radext@ietf.org" , "radext-chairs@tools.ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:38:35 -0000 I agree with Bernard... unless we (a) the work is needed, (b) there's = no other place to do it, and (c) we can agree on charter updates to = include this work. I believe (a) and (b) to be true. I would agree to update the charter = as per (c) On Mar 31, 2015, at 1:30 PM, Bernard Aboba = wrote: > I agree that this work is important.=20 >=20 > However, because it represents an update of RFC 3748, and the RADEXT = WG is not chartered to handle EAP maintenance, I do not believe it = belongs in this WG.=20 >=20 > > From: hartmans@painless-security.com > > To: lionel.morand@orange.com > > Date: Tue, 31 Mar 2015 13:24:57 -0400 > > CC: radext@ietf.org; radext-chairs@tools.ietf.org > > Subject: Re: [radext] Start of Call for Adoption for = draft-winter-radext-populating-eapidentity-01 > >=20 > > >>>>> writes: > >=20 > > > During the RADEXT session at IETF92, , the authors of > > > draft-winter-radext-populating-eapidentity-01 have asked for > > > adoption of this individual draft as WG document. > > This is important work. > > It should be adopted somewhere, and will get adequate review in = radext. > >=20 > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 10:50:48 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A52F1A7028 for ; Tue, 31 Mar 2015 10:50:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wFunx9WspW9 for ; Tue, 31 Mar 2015 10:50:29 -0700 (PDT) Received: from BLU004-OMC2S10.hotmail.com (blu004-omc2s10.hotmail.com [65.55.111.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DD561A7025 for ; Tue, 31 Mar 2015 10:50:29 -0700 (PDT) Received: from BLU181-W23 ([65.55.111.73]) by BLU004-OMC2S10.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 31 Mar 2015 10:50:28 -0700 X-TMN: [MH7x5dIGm8oogoXJmEpm54TXASWr0vJc] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_5ad9b134-d374-4a68-afb5-19758f74cb68_" From: Bernard Aboba To: "radext@ietf.org" Date: Tue, 31 Mar 2015 10:50:27 -0700 Importance: Normal In-Reply-To: References: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup>, <039f01d06bd3$f55e64e0$e01b2ea0$@augustcellars.com>, MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2015 17:50:28.0978 (UTC) FILETIME=[2CF18520:01D06BDB] Archived-At: Cc: "radext-chairs@tools.ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Start of Call for Adoption for draft-dekok-radext-datatypes-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:50:40 -0000 --_5ad9b134-d374-4a68-afb5-19758f74cb68_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This draft Is badly needed and should be adopted.=20 = --_5ad9b134-d374-4a68-afb5-19758f74cb68_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
This draft Is badly needed and s= hould be adopted.
= --_5ad9b134-d374-4a68-afb5-19758f74cb68_-- From nobody Tue Mar 31 10:53:21 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5181A8750 for ; Tue, 31 Mar 2015 10:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lZNQY0CGxCc for ; Tue, 31 Mar 2015 10:53:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 644531A870A for ; Tue, 31 Mar 2015 10:53:16 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id CE8B4190201; Tue, 31 Mar 2015 19:53:14 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id AFD7F3840A4; Tue, 31 Mar 2015 19:53:14 +0200 (CEST) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Tue, 31 Mar 2015 19:53:14 +0200 From: To: Bernard Aboba , Sam Hartman Thread-Topic: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 Thread-Index: AdBrzoIzGZAmzf18QgisvgcZtEu1twACRsrY///f7wD//9hIMA== Date: Tue, 31 Mar 2015 17:53:13 +0000 Message-ID: <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.6] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36EEF74CDPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.3.31.173618 Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:53:19 -0000 --_000_6B7134B31289DC4FAF731D844122B36EEF74CDPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Bernard, If not done in RADEXT, what would be your preferred recommendation? regards, Lionel De : Bernard Aboba [mailto:bernard_aboba@hotmail.com] Envoy=E9 : mardi 31 mars 2015 19:30 =C0 : Sam Hartman; MORAND Lionel IMT/OLN Cc : radext@ietf.org; radext-chairs@tools.ietf.org Objet : RE: [radext] Start of Call for Adoption for draft-winter-radext-pop= ulating-eapidentity-01 I agree that this work is important. However, because it represents an update of RFC 3748, and the RADEXT WG is = not chartered to handle EAP maintenance, I do not believe it belongs in thi= s WG. > From: hartmans@painless-security.com > To: lionel.morand@orange.com > Date: Tue, 31 Mar 2015 13:24:57 -0400 > CC: radext@ietf.org; radext-chairs@tools.ietf.org= > Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-= populating-eapidentity-01 > > >>>>> > writes: > > > During the RADEXT session at IETF92, , the authors of > > draft-winter-radext-populating-eapidentity-01 have asked for > > adoption of this individual draft as WG document. > This is important work. > It should be adopted somewhere, and will get adequate review in radext. > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36EEF74CDPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Bernard= ,

 = ;

If not don= e in RADEXT, what would be your preferred recommendation?=

 = ;

regards,

 = ;

Lionel

 = ;

De : Bern= ard Aboba [mailto:bernard_aboba@hotmail.com]
Envoy=E9 : mardi 31 mars 2015 19:30
=C0 : Sam Hartman; MORAND Lionel IMT/OLN
Cc : radext@ietf.org; radext-chairs@tools.ietf.org
Objet : RE: [radext] Start of Call for Adoption for draft-winte= r-radext-populating-eapidentity-01

 

I agree that this work is important. 

 

However, because it represents an update of RFC 3748, an= d the RADEXT WG is not chartered to handle EAP maintenance, I do not believ= e it belongs in this WG. 

 

> From: hartmans@painless-security.com
> To: lionel.morand@orange.c= om
> Date: Tue, 31 Mar 2015 13:24:57 -0400
> CC: radext@ietf.org; radext-chairs@tools.ietf.org
> Subject: Re: [radext] Start of Call for Adoption for draft-winter-rade= xt-populating-eapidentity-01
>
> >>>>> <l= ionel.morand@orange.com> writes:
>
> > During the RADEXT session at IETF92, , the authors of
> > draft-winter-radext-populating-eapidentity-01 have asked for
> > adoption of this individual draft as WG document.
> This is important work.
> It should be adopted somewhere, and will get adequate review in radext= .
>
> _______________________________________________
> radext mailing list
> radext@ietf.org
> https://www.i= etf.org/mailman/listinfo/radext

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36EEF74CDPEXCVZYM13corpora_-- From nobody Tue Mar 31 10:57:32 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A91B1A1B51 for ; Tue, 31 Mar 2015 10:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id txcvD0tI7eWU for ; Tue, 31 Mar 2015 10:57:29 -0700 (PDT) Received: from BLU004-OMC1S28.hotmail.com (blu004-omc1s28.hotmail.com [65.55.116.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B28A71A1B2A for ; Tue, 31 Mar 2015 10:57:28 -0700 (PDT) Received: from BLU181-W8 ([65.55.116.9]) by BLU004-OMC1S28.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 31 Mar 2015 10:57:27 -0700 X-TMN: [m7ULlzkO4agVNYCm8LFPwtzRK1BpQk9W] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_d77e3ea0-8297-4517-a8eb-586010500c38_" From: Bernard Aboba To: "lionel.morand@orange.com" , Sam Hartman Date: Tue, 31 Mar 2015 10:57:27 -0700 Importance: Normal In-Reply-To: <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup>, , , , <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 X-OriginalArrivalTime: 31 Mar 2015 17:57:27.0773 (UTC) FILETIME=[269090D0:01D06BDC] Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 17:57:31 -0000 --_d77e3ea0-8297-4517-a8eb-586010500c38_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rather than having the RADEXT WG decide where EAP work should be done in th= e IETF=2C bring it to the attention of the EAP community (by posting to sti= ll-functioning EAP-related mailing lists such as EAP and EMU) as well as pr= esenting it to area WGs for areas in which this work has traditionally been= done (and where EAP implementers are more likely to pay attention). That = would include SAAG (Security Area) and INTAREA. =20 =20 From: lionel.morand@orange.com To: bernard_aboba@hotmail.com=3B hartmans@painless-security.com Date: Tue=2C 31 Mar 2015 17:53:13 +0000 CC: radext@ietf.org=3B radext-chairs@tools.ietf.org Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-po= pulating-eapidentity-01 =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= Hi Bernard=2C=0A= =0A= If not done in RADEXT=2C what would be your preferred recommendation?=0A= =0A= regards=2C=0A= =0A= Lionel=0A= =0A= =0A= =0A= De : Bernard Aboba [mailto:bernard_aboba@hotmail.com]=0A= =0A= Envoy=E9 : mardi 31 mars 2015 19:30 =0A= =C0 : Sam Hartman=3B MORAND Lionel IMT/OLN =0A= Cc : radext@ietf.org=3B radext-chairs@tools.ietf.org =0A= Objet : RE: [radext] Start of Call for Adoption for draft-winter-radext-pop= ulating-eapidentity-01=0A= =0A= =0A= =0A= =0A= I agree that this work is important. =0A= =0A= =0A= =0A= =0A= However=2C because it represents an update of RFC 3748=2C and the RADEXT WG= is not chartered to handle EAP maintenance=2C I do not believe it belongs = in this WG. =0A= =0A= =0A= =0A= =0A= =0A= =0A= > From: =0A= hartmans@painless-security.com =0A= > To: lionel.morand@orange.com =0A= > Date: Tue=2C 31 Mar 2015 13:24:57 -0400 =0A= > CC: radext@ietf.org=3B =0A= radext-chairs@tools.ietf.org =0A= > Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-= populating-eapidentity-01 =0A= >=20 =0A= > >>>>> writes: =0A= >=20 =0A= > > During the RADEXT session at IETF92=2C =2C the authors of =0A= > > draft-winter-radext-populating-eapidentity-01 have asked for =0A= > > adoption of this individual draft as WG document. =0A= > This is important work. =0A= > It should be adopted somewhere=2C and will get adequate review in radext. =0A= >=20 =0A= > _______________________________________________ =0A= > radext mailing list =0A= > radext@ietf.org =0A= > https://www.ietf.org/mailman/listinfo/radext=0A= =0A= =0A= =0A= =0A= =0A= =0A= ___________________________________________________________________________= ______________________________________________=0A= =0A= Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc=0A= pas etre diffuses=2C exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur=2C veuillez le signaler=0A= a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration=2C=0A= Orange decline toute responsabilite si ce message a ete altere=2C deforme o= u falsifie. Merci.=0A= =0A= This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law=3B=0A= they should not be distributed=2C used or copied without authorisation.=0A= If you have received this email in error=2C please notify the sender and de= lete this message and its attachments.=0A= As emails may be altered=2C Orange is not liable for messages that have bee= n modified=2C changed or falsified.=0A= Thank you.=0A= =0A= =0A= _______________________________________________=0A= radext mailing list=0A= radext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/radext = --_d77e3ea0-8297-4517-a8eb-586010500c38_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Rather than having the RADEXT WG= decide where EAP work should be done in the IETF=2C bring it to the attent= ion of the EAP community (by posting to still-functioning EAP-related maili= ng lists such as EAP and EMU) as well as presenting it =3Bto area WGs f= or areas =3Bin which this work has traditionally been done (and where E= AP implementers are more likely to pay attention). =3B That would inclu= de SAAG (Security Area) and INTAREA. =3B =3B
 =3B
From: lionel.morand@orange.com
To: bernard_aboba@h= otmail.com=3B hartmans@painless-security.com
Date: Tue=2C 31 Mar 2015 17= :53:13 +0000
CC: radext@ietf.org=3B radext-chairs@tools.ietf.org
Subj= ect: Re: [radext] Start of Call for Adoption for draft-winter-radext-popula= ting-eapidentity-01

=0A= =0A= =0A= =0A= =0A= =0A= =0A=
=0A=

Hi= Bernard=2C

=0A=

&n= bsp=3B

=0A=

If= not done in RADEXT=2C what would be your preferred recommendation?<= /p>=0A=

&n= bsp=3B

=0A=

re= gards=2C

=0A=

&n= bsp=3B

=0A=

Li= onel

=0A=

&n= bsp=3B

=0A=
=0A=
=0A=

De =3B: Bernard Aboba [mailto:b= ernard_aboba@hotmail.com]=0A=
=0A= Envoy=E9 =3B: mardi 31 mars 2015 19:30
=0A= =C0 =3B: Sam Hartman=3B MORAND Lionel IMT/OLN
=0A= Cc =3B: radext@ietf.org=3B radext-chairs@tools.ietf.org
=0A= Objet =3B: RE: [radext] Start of Call for Adoption for draft-win= ter-radext-populating-eapidentity-01

=0A=
=0A=
=0A=

 =3B

=0A=
=0A=

I agree that this work is important. =3B

=0A=
=0A=

 =3B

=0A=
=0A=
=0A=

However=2C because it represents an update of RFC 3748=2C and the R= ADEXT WG is not chartered to handle EAP maintenance=2C I do not believe it = belongs in this WG. =3B

=0A=
=0A=
=0A=
=0A=
=0A=

 =3B

=0A=
=0A=

>=3B From: =0A= hartmans@painless-security.com
=0A= >=3B To: lionel.morand@orange= .com
=0A= >=3B Date: Tue=2C 31 Mar 2015 13:24:57 -0400
=0A= >=3B CC: radext@ietf.org=3B =0A= radext-chairs@tools.ietf.org
=0A= >=3B Subject: Re: [radext] Start of Call for Adoption for draft-winter-ra= dext-populating-eapidentity-01
=0A= >=3B
=0A= >=3B >=3B>=3B>=3B>=3B>=3B <=3Blionel.morand@orange.com>=3B writes:
=0A= >=3B
=0A= >=3B >=3B During the RADEXT session at IETF92=2C =2C the authors of
= =0A= >=3B >=3B draft-winter-radext-populating-eapidentity-01 have asked for<= br>=0A= >=3B >=3B adoption of this individual draft as WG document.
=0A= >=3B This is important work.
=0A= >=3B It should be adopted somewhere=2C and will get adequate review in ra= dext.
=0A= >=3B
=0A= >=3B _______________________________________________
=0A= >=3B radext mailing list
=0A= >=3B radext@ietf.org
=0A= >=3B https://www.ietf.org/mailman/listinfo/radext

=0A=
=0A=
=0A=
=0A=
=0A=
=0A=
=0A= 
______________________________________________________________________=
___________________________________________________=0A=
=0A=
Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc=0A=
pas etre diffuses=2C exploites ou copies sans autorisation. Si vous avez re=
cu ce message par erreur=2C veuillez le signaler=0A=
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration=2C=0A=
Orange decline toute responsabilite si ce message a ete altere=2C deforme o=
u falsifie. Merci.=0A=
=0A=
This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law=3B=0A=
they should not be distributed=2C used or copied without authorisation.=0A=
If you have received this email in error=2C please notify the sender and de=
lete this message and its attachments.=0A=
As emails may be altered=2C Orange is not liable for messages that have bee=
n modified=2C changed or falsified.=0A=
Thank you.=0A=
=0A= =0A=
_______________________________________________=0A= radext mailing list=0A= radext@ietf.org=0A= https://www.ietf.org/mailman/listinfo/radext
= --_d77e3ea0-8297-4517-a8eb-586010500c38_-- From nobody Tue Mar 31 11:05:44 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51FE01A8870 for ; Tue, 31 Mar 2015 11:05:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjR4WT8dJJjU for ; Tue, 31 Mar 2015 11:05:41 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A6E1A8867 for ; Tue, 31 Mar 2015 11:05:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 537D420694; Tue, 31 Mar 2015 14:03:42 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v1lvYyqmon1J; Tue, 31 Mar 2015 14:03:42 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Tue, 31 Mar 2015 14:03:42 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C0309805C8; Tue, 31 Mar 2015 14:05:37 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Tue, 31 Mar 2015 14:05:37 -0400 In-Reply-To: (Bernard Aboba's message of "Tue, 31 Mar 2015 10:57:27 -0700") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:05:42 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> Rather than having the RADEXT WG decide where EAP work Bernard> should be done in the IETF, bring it to the attention of Bernard> the EAP community (by posting to still-functioning Bernard> EAP-related mailing lists such as EAP and EMU) as well as Bernard> presenting it to area WGs for areas in which this work has Bernard> traditionally been done (and where EAP implementers are Bernard> more likely to pay attention). That would include SAAG Bernard> (Security Area) and INTAREA. Bernard> __________________________________________________________________ This has already been discussed in the EAP community I think you may be reopening something that we substantially discussed in the past. --Sam From nobody Tue Mar 31 11:46:22 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E67D1ACE96 for ; Tue, 31 Mar 2015 11:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SN18lA5LQsC for ; Tue, 31 Mar 2015 11:46:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAA931A9100 for ; Tue, 31 Mar 2015 11:46:19 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQX47048; Tue, 31 Mar 2015 18:46:18 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Mar 2015 19:46:17 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Tue, 31 Mar 2015 11:46:14 -0700 From: Dean cheng To: "lionel.morand@orange.com" , "radext@ietf.org" Thread-Topic: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 Thread-Index: AdBr0OfvWsGnfW7ITUyirhe2Cq01uwAEbfiA Date: Tue, 31 Mar 2015 18:46:13 +0000 Message-ID: References: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:46:21 -0000 I'm not aware of any IPR that applies to this draft. Dean >=20 > If you are a document author or listed contributor on this document, plea= se > reply to this email message regardless of whether or not you are personal= ly > aware of any relevant IPR. We might not be able to advance this document= to > the next stage until we have received a reply from each author and listed > contributor. >=20 From nobody Tue Mar 31 11:50:04 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E271ACEDD for ; Tue, 31 Mar 2015 11:50:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2vBkftMnFQ8 for ; Tue, 31 Mar 2015 11:50:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E981ACEDB for ; Tue, 31 Mar 2015 11:49:59 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQX47233; Tue, 31 Mar 2015 18:49:58 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.212.94.49) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 31 Mar 2015 19:49:57 +0100 Received: from SJCEML701-CHM.china.huawei.com ([169.254.3.13]) by SJCEML703-CHM.china.huawei.com ([169.254.5.137]) with mapi id 14.03.0158.001; Tue, 31 Mar 2015 11:49:51 -0700 From: Dean cheng To: Alan DeKok , "lionel.morand@orange.com" Thread-Topic: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 Thread-Index: AQHQa9io3cIZrfp3bEKyjtwpIkzi1J027lAA Date: Tue, 31 Mar 2015 18:49:50 +0000 Message-ID: References: <10094_1427820685_551AD08D_10094_7330_1_6B7134B31289DC4FAF731D844122B36EEF695D@PEXCVZYM13.corporate.adroot.infra.ftgroup> <7BD5C839-E2F6-410D-A8A4-F16ADD5B1C02@deployingradius.com> In-Reply-To: <7BD5C839-E2F6-410D-A8A4-F16ADD5B1C02@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.201] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Cc: "radext@ietf.org" , "radext-chairs@tools.ietf.org" Subject: Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-ext-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 18:50:03 -0000 Hello Alan, Thanks for your comments, and we'll take care of them in the next revision. Regards Dean > -----Original Message----- > From: radext [mailto:radext-bounces@ietf.org] On Behalf Of Alan DeKok > Sent: Tuesday, March 31, 2015 10:32 AM > To: lionel.morand@orange.com > Cc: radext@ietf.org; radext-chairs@tools.ietf.org > Subject: Re: [radext] Start of WGLC for draft-ietf-radext-ip-port-radius-= ext- > 03 >=20 > I'm not sure what Section 3.1.1 is for. It shouldn't be needed. The > document does NOT define a new extended type. It defines a new RADIUS > attribute. That attribute is allocated from the extended type space. >=20 > My $0.02 is to remove Section 3.1.1, and all references to it. Instead= , > just say: >=20 > 3.1.2. IP-Port-Limit Attribute >=20 > This attribute is of Extended-Type, and contains a set of embedded TLV= s ... >=20 > Also, IANA should assign values. There's no need to call them out: >=20 > Type: >=20 > TBA1 - Extended-Type-1 (241), Extended-Type-2 (242), Extended- > Type-3 (243), or Extended-Type-4 (244) per [RFC6929]. >=20 >=20 > Just replace that with: >=20 > Type: >=20 > TBA1 >=20 >=20 > It could be clearer that the same set of TLVs can be contained within t= he > encapsulating attribute. This means (e.g.) that IANA must allocate *mult= iple* > attributes, e.g. >=20 > 241.33.1 IP-Port-Type TLV inside of IP-Port-Limit > 241.34.1 P-Port-Type TLV inside of IP-Port-Forwarding-Map Attribute >=20 > etc. The IANA section isn't clear to me, either. e.g. >=20 > o TBA1 (refer to Section 3.1.1): This value is for the Radius Type > field and should be allocated from the number space of Extended- > Type-1 (241), Extended-Type-2 (242), Extended-Type-3 (243), or > Extended-Type-4 (244) per [RFC6929]. >=20 > o TBA2 (refer to Section 3.1.1): This value is for the Extended-Type > field and should be allocated from the Short Extended Space per > [RFC6929]. >=20 >=20 > That's unnecessary, and should be deleted. >=20 > o TBA3 (refer to Section 3.2.1): This value is for the Type field of > IP-Port-Type TLV. It should be allocated as TLV data type. It is > within the TBA2 container and it extends the attribute tree as > TBA1.TBA2.TBA3.[...]. Also, this value uniquely refers to IPFIX > Element ID transportType (TBAx1). >=20 > Just say something like "TBA3: IP-Port-Type allocated from within the s= hort > extended space". >=20 > The reference to IPFix should specify an IANA action: >=20 > Add a note for that attribute, saying that this attribute contains data > from IPFix Element ID transportType TBAx1" >=20 > If all of the TLVs can be used in all of the attributes, then the alloc= ation > of the TLVs should be done for the *first* attribute. i.e. IP-Port-Type = is a > sub-TLV of IP-Port-Limit, and should be assigned the number "TBA3.1". It= 's OK > to manually allocate numbers where they're TLVs, and not been allocated b= efore. >=20 > The document should *also* tell IANA to prohibit allocation of TLVs und= er > the IP-Port-Forwarding-Map, etc. attributes. And note that those attrib= utes > are all of type TLV, with TLVs defined by the IP-Port-Limit attribute. >=20 > That's it for now... >=20 > Also, the document contains many data types which are explicitly forbid= den > by RFC 6929. 8-bit, 16-bit, etc. While I know that these are in IPFIX, = I > wouldn't recommend using them here. They should all be moved to "integer= " > data types, with a note that the bits unused by IPFIX *must* be zero. >=20 >=20 > On Mar 31, 2015, at 12:51 PM, > wrote: >=20 > > During the RADEXT session at IETF92, the authors of draft-ietf-radext-i= p- > port-radius-ext-03 have asked for a Working Group Last Call. > > > > This email officially starts a Working Group Last Call for the > > following document > > > > http://tools.ietf.org/html/draft-ietf-radext-ip-port-radius-ext-03 > > > > Please respond to this email to support the document and/or send commen= ts by > 2015-04-13. > > > > In addition, following the strategy for promoting compliance with the I= PR > disclosure rules (RFC6702), the chairs would like to check whether there= are > claims of Intellectual Property Rights (IPR) on the document that need to= be > disclosed. Therefore, the following questions are addressed to the WG and > Especially Authors and Contributors of the draft: > > > > Are you personally aware of any IPR that applies to > > draft-ietf-radext-ip-port-radius-ext-03? If so, has this IPR been > > disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, > > 3669, and 5378 for more details.) > > > > If you are a document author or listed contributor on this document, pl= ease > reply to this email message regardless of whether or not you are personal= ly > aware of any relevant IPR. We might not be able to advance this document= to > the next stage until we have received a reply from each author and listed > contributor. > > > > If you are on the RADEXT WG email list but are not an author or listed > contributor for this document, you are reminded of your opportunity for a > voluntary IPR disclosure under BCP 79. Please do not reply unless you w= ant > to make such a voluntary disclosure. > > > > Online tools for filing IPR disclosures can be found at > . > > > > Regards, > > > > Lionel & Stefan > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 12:24:20 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486131ABD35 for ; Tue, 31 Mar 2015 12:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8uIq0lN5mII for ; Tue, 31 Mar 2015 12:24:17 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [195.154.231.44]) by ietfa.amsl.com (Postfix) with ESMTP id 293411AC39C for ; Tue, 31 Mar 2015 12:24:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8FC192240579; Tue, 31 Mar 2015 21:24:16 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2654vwCVyiO; Tue, 31 Mar 2015 21:24:16 +0200 (CEST) Received: from [192.168.20.59] (69-196-165-104.dsl.teksavvy.com [69.196.165.104]) by power.freeradius.org (Postfix) with ESMTPSA id B33412240363; Tue, 31 Mar 2015 21:24:14 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Alan DeKok In-Reply-To: Date: Tue, 31 Mar 2015 15:24:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: Sam Hartman X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: Aboba Bernard , "radext@ietf.org" , "radext-chairs@tools.ietf.org" , "lionel.morand@orange.com" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 19:24:19 -0000 On Mar 31, 2015, at 2:05 PM, Sam Hartman = wrote: > This has already been discussed in the EAP community > I think you may be reopening something that we substantially discussed > in the past. FWIW, the overlap between EMU and RADEXT is pretty large. There were = people on the EMU list who commented on this draft, and those people are = pretty much all here. I would support a notification to the EMU list that RADEXT is thinking = about adopting this draft as a WG item. But I think it would be the = same people reviewing it, no matter where it was accepted. I support it in RADEXT because while the document talks about EAP, the = *use-case* is largely RADIUS and Diameter roaming. Alan DeKok. From nobody Tue Mar 31 13:05:36 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B77F1ACE5F for ; Tue, 31 Mar 2015 13:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGqXWCvZpbd9 for ; Tue, 31 Mar 2015 13:05:32 -0700 (PDT) Received: from xenon24.um.es (xenon24.um.es [155.54.212.164]) by ietfa.amsl.com (Postfix) with ESMTP id 31E471A1EFC for ; Tue, 31 Mar 2015 13:05:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon24.um.es (Postfix) with ESMTP id 45E41CAD6 for ; Tue, 31 Mar 2015 22:05:30 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon24.um.es Received: from xenon24.um.es ([127.0.0.1]) by localhost (xenon24.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ycQHNkGDkFU3 for ; Tue, 31 Mar 2015 22:05:30 +0200 (CEST) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon24.um.es (Postfix) with ESMTPSA id 183A2B5D7 for ; Tue, 31 Mar 2015 22:05:28 +0200 (CEST) Message-ID: <551AFE08.6020007@um.es> Date: Tue, 31 Mar 2015 22:05:28 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: radext@ietf.org References: <5711_1427820647_551AD067_5711_8035_1_6B7134B31289DC4FAF731D844122B36EEF68A4@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [radext] Start of Call for Adoption for draft-dekok-radext-datatypes-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 20:05:35 -0000 I support the adoption of this document. El 31/03/15 a las 18:51, Alan DeKok escribió: > I support the adoption. I have no IPR on this document. > > On Mar 31, 2015, at 12:50 PM, wrote: > >> During the RADEXT session at IETF92, , the authors of draft-dekok-radext-datatypes-05 have asked for adoption of this individual draft as WG document. >> >> This email officially starts a call for adoption for the following document: >> >> http://tools.ietf.org/html/draft-dekok-radext-datatypes-05 >> >> Please respond to this email to support the document and/or send comments by 2015-04-06. >> >> In addition, following the strategy for promoting compliance with the IPR disclosure rules (RFC6702), the chairs would like to check whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed. Therefore, the following questions are addressed to the WG and especially Authors and Contributors of the draft: >> >> Are you personally aware of any IPR that applies to draft-dekok-radext-datatypes-05? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) >> >> If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. >> >> If you are on the RADEXT WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. >> >> Online tools for filing IPR disclosures can be found at . >> >> Regards, >> >> Lionel & Stefan >> >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 13:16:38 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAA51ACE98 for ; Tue, 31 Mar 2015 13:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ve8Rx9TnhYX for ; Tue, 31 Mar 2015 13:16:34 -0700 (PDT) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id 91EF41ACE8B for ; Tue, 31 Mar 2015 13:16:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 4B41ADCF2 for ; Tue, 31 Mar 2015 22:16:32 +0200 (CEST) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kA8esj-1auhB for ; Tue, 31 Mar 2015 22:16:32 +0200 (CEST) Received: from [10.42.0.179] (84.121.18.25.dyn.user.ono.com [84.121.18.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 2109812D for ; Tue, 31 Mar 2015 22:16:31 +0200 (CEST) Message-ID: <551B009E.3090309@um.es> Date: Tue, 31 Mar 2015 22:16:30 +0200 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: radext@ietf.org References: <10094_1427820672_551AD080_10094_7303_1_6B7134B31289DC4FAF731D844122B36EEF691F@PEXCVZYM13.corporate.adroot.infra.ftgroup> <7F6C8C5F-99AD-45A5-A4F5-E50F8D8C1F26@deployingradius.com> In-Reply-To: <7F6C8C5F-99AD-45A5-A4F5-E50F8D8C1F26@deployingradius.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [radext] Start of WGLC for draft-ietf-radext-bigger-packets-03 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 20:16:37 -0000 I also support the adoption of this document. El 31/03/15 a las 19:00, Alan DeKok escribió: > I support adoption of this document. > > On Mar 31, 2015, at 12:51 PM, wrote: > >> During the RADEXT session at IETF92, the authors of draft-ietf-radext-bigger-packets-03 have asked for a Working Group Last Call. >> >> This email officially starts a Working Group Last Call for the following document >> >> http://tools.ietf.org/html/draft-ietf-radext-bigger-packets-03 >> >> Please respond to this email to support the document and/or send comments by 2015-04-13. >> >> In addition, following the strategy for promoting compliance with the IPR disclosure rules (RFC6702), the chairs would like to check whether there are claims of Intellectual Property Rights (IPR) on the document that need to be disclosed. Therefore, the following questions are addressed to the WG and Especially Authors and Contributors of the draft: >> >> Are you personally aware of any IPR that applies to draft-ietf-radext-bigger-packets-03? If so, has this IPR been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more details.) >> >> If you are a document author or listed contributor on this document, please reply to this email message regardless of whether or not you are personally aware of any relevant IPR. We might not be able to advance this document to the next stage until we have received a reply from each author and listed contributor. >> >> If you are on the RADEXT WG email list but are not an author or listed contributor for this document, you are reminded of your opportunity for a voluntary IPR disclosure under BCP 79. Please do not reply unless you want to make such a voluntary disclosure. >> >> Online tools for filing IPR disclosures can be found at . >> >> Regards, >> >> Lionel & Stefan >> >> _________________________________________________________________________________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 14:34:04 2015 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F152E1A0151 for ; Tue, 31 Mar 2015 14:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wezGNa1ezb0 for ; Tue, 31 Mar 2015 14:34:00 -0700 (PDT) Received: from BLU004-OMC1S30.hotmail.com (blu004-omc1s30.hotmail.com [65.55.116.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 685811A87AA for ; Tue, 31 Mar 2015 14:34:00 -0700 (PDT) Received: from BLU406-EAS343 ([65.55.116.9]) by BLU004-OMC1S30.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.22751); Tue, 31 Mar 2015 14:33:59 -0700 X-TMN: [FB458vPYxMglnPTMQ1pNKObDjyuobCrd] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <11856_1427820628_551AD054_11856_4576_1_6B7134B31289DC4FAF731D844122B36EEF6888@PEXCVZYM13.corporate.adroot.infra.ftgroup> <30317_1427824394_551ADF0A_30317_14370_1_6B7134B31289DC4FAF731D844122B36EEF74CD@PEXCVZYM13.corporate.adroot.infra.ftgroup> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Tue, 31 Mar 2015 14:33:28 -0700 To: Alan DeKok X-OriginalArrivalTime: 31 Mar 2015 21:33:59.0253 (UTC) FILETIME=[66171850:01D06BFA] Archived-At: Cc: Sam Hartman , "lionel.morand@orange.com" , "radext-chairs@tools.ietf.org" , "radext@ietf.org" Subject: Re: [radext] Start of Call for Adoption for draft-winter-radext-populating-eapidentity-01 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Mar 2015 21:34:02 -0000 I would support notifying both the EMU and EAP lists.=20 > On Mar 31, 2015, at 12:24 PM, Alan DeKok wrote= : >=20 >> On Mar 31, 2015, at 2:05 PM, Sam Hartman = wrote: >> This has already been discussed in the EAP community >> I think you may be reopening something that we substantially discussed >> in the past. >=20 > FWIW, the overlap between EMU and RADEXT is pretty large. There were peo= ple on the EMU list who commented on this draft, and those people are pretty= much all here. >=20 > I would support a notification to the EMU list that RADEXT is thinking ab= out adopting this draft as a WG item. But I think it would be the same peop= le reviewing it, no matter where it was accepted. >=20 > I support it in RADEXT because while the document talks about EAP, the *u= se-case* is largely RADIUS and Diameter roaming. >=20 > Alan DeKok. >=20 > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From nobody Tue Mar 31 22:58:39 2015 Return-Path: X-Original-To: expand-draft-ietf-radext-dynamic-discovery.all@virtual.ietf.org Delivered-To: radext@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 65534) id 4D7E61A8856; Tue, 31 Mar 2015 21:54:11 -0700 (PDT) X-Original-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Delivered-To: xfilter-draft-ietf-radext-dynamic-discovery.all@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28DBE1A8852 for ; Tue, 31 Mar 2015 21:54:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.5 X-Spam-Level: X-Spam-Status: No, score=-9.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgfiQ0RI7wwO for ; Tue, 31 Mar 2015 21:54:10 -0700 (PDT) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517871A8851 for ; Tue, 31 Mar 2015 21:54:10 -0700 (PDT) Received: from rcdn-iport-5.cisco.com ([173.37.86.76]:29812) by zinfandel.tools.ietf.org with esmtps (TLS1.0:RSA_ARCFOUR_128_SHA1:128) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1YdAfI-0001vm-Qk for draft-ietf-radext-dynamic-discovery.all@tools.ietf.org; Tue, 31 Mar 2015 21:54:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=551; q=dns/txt; s=iport; t=1427864049; x=1429073649; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=uru6G7oRJqqKoaPBNlunvwc70nyhmhHtkc5kkGhsX6M=; b=U6pclGECyb8V5IjBd3j5JjQ+NpoX1QSHC0CSLU7k0h+d75rz8wdsvBzv A5EI/i8vEcxBT8yrsPK+rx5re24pzKmuXDUBj7H/OIDoky0Sr3cQ6D1IA qcJdskNTCgBJ6Ivf6GhKKO6tSmAinDYjKYiqfJ6H9q5NAVtZFNTQi//DL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ANBQDFeBtV/5FdJa1cgwaBM8t4gUZMAQEBAQEBfYQbeRIBgQAnBAENiDTODAEBAQEBAQEBAQEBAQEBAQEBAQEZkCGDHoEWAQSQYol1lDsig26CM38BAQE X-IronPort-AV: E=Sophos;i="5.11,503,1422921600"; d="scan'208";a="408264193" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP; 01 Apr 2015 04:54:01 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t314s0GY021157 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 Apr 2015 04:54:00 GMT Received: from xmb-aln-x04.cisco.com ([169.254.9.86]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0195.001; Tue, 31 Mar 2015 23:54:00 -0500 From: "Brian Weis (bew)" To: The IESG , "secdir@ietf.org" Thread-Topic: Secdir review of draft-ietf-radext-dynamic-discovery-13 Thread-Index: AQHQbDfeNoJmN5Gq3EulDPmlP6Vogw== Date: Wed, 1 Apr 2015 04:54:00 +0000 Message-ID: <779642F1-4094-4524-A6B8-EE4E40B1CF8A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.32.244.211] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SA-Exim-Connect-IP: 173.37.86.76 X-SA-Exim-Rcpt-To: draft-ietf-radext-dynamic-discovery.all@tools.ietf.org X-SA-Exim-Mail-From: bew@cisco.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) Resent-To: draft-ietf-radext-dynamic-discovery.all@ietf.org Resent-Message-Id: <20150401045410.517871A8851@ietfa.amsl.com> Resent-Date: Tue, 31 Mar 2015 21:54:10 -0700 (PDT) Resent-From: bew@cisco.com Archived-At: Archived-At: X-Mailman-Approved-At: Tue, 31 Mar 2015 22:58:38 -0700 Cc: "draft-ietf-radext-dynamic-discovery.all@tools.ietf.org" Subject: [radext] Secdir review of draft-ietf-radext-dynamic-discovery-13 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Apr 2015 04:54:11 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= .=20 Previously I reviewed draft-ietf-radext-dynamic-discovery-12, and while I d= idn=92t have any particular issues with it there were some questions and su= ggestions for clarifying trust model. The current draft added some really v= aluable text and figures. I believe it is ready to be published. Brian