From stefan.winter@restena.lu Mon Mar 4 07:46:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C8621F8C23 for ; Mon, 4 Mar 2013 07:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VuKxzbC2vR4 for ; Mon, 4 Mar 2013 07:46:45 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 3924C21F8C20 for ; Mon, 4 Mar 2013 07:46:42 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 1B2F5107B5; Mon, 4 Mar 2013 16:46:41 +0100 (CET) Received: from [IPv6:2001:a18:1:8:a052:157:aa11:9a4b] (unknown [IPv6:2001:a18:1:8:a052:157:aa11:9a4b]) by smtprelay.restena.lu (Postfix) with ESMTPS id 0B953106C2; Mon, 4 Mar 2013 16:46:41 +0100 (CET) Message-ID: <5134C1DD.1020204@restena.lu> Date: Mon, 04 Mar 2013 16:46:37 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Jim Schaad References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <026f01ce152a$f24ceb20$d6e6c160$@augustcellars.com> In-Reply-To: <026f01ce152a$f24ceb20$d6e6c160$@augustcellars.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2JVKXVLUBDWVALANUNHIL" X-Virus-Scanned: ClamAV Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:46:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2JVKXVLUBDWVALANUNHIL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > This depends on specific properties of the EAP method being used. It w= ould > not be true for a simple user name/password EAP method. I don't know = that > there is anything that would prevent a man-in-the-middle attack from > occurring in this situation would might result in leaked credentials an= d no > failure for the EAP peer to know about. >=20 > See Sam's draft in the EMU WG for more details. We (eduroam) require EAP methods capable of mutual authentication (typically by the EAP server presenting a server certificate) and require users to validate the server-side identity. It is well possible that some users neglect to configure the proper checks, and yes, these would be fooled into connecting to a different EAP server than expect. It is though, to a very large extent, their own fault then. But this is a bit of side-track issue not terribly relevant for the spec.= >> That is a decision for a deployer of the algorithm to make though: the= >> security considerations say that it's only safe with DNSSEC - which is= > true; >> every deployer is free to draw his own consequences from that. >=20 > Given the presence of the second sentence in the paragraph that is not = a > statement that I heard from the Security Considerations. Okay, I've made it more explicit in my current working copy: 3. Security Considerations The results from the execution of this algorithm are only trustworthy if each of the lookup steps by the name resolution library were cryptographically secured; i.e. if DNSSEC validation was turned on during the resolution AND all of the records were in a DNSSEC signed zone AND validation of all those records was successful. >> We've investigated the opportunities of DANE and it seems much rather >> like: DANE ignores the possibility that TLS handshakes can be mutual. >> Which is a bummer for things like RADIUS/TLS which /require/ mutual au= th. >=20 > I don't know that I agree with this. A very simple way to use DANE for= this > would be >=20 > Server gets client certificate > Server extracts client DNS name from certificate > Server does a TLSA lookup on the client DNS name and sees if it matches= the > certificate given per DANE rules >=20 > Assuming that we are looking a this being a generic proxy, that informa= tion > is going to be in the DNS for lookups back. Sure; it's not rocket science to specify this. It just hasn't been done; and I would find it undue for this document to invent something on its own. The proper place for such work would IMHO be in DANE for the generic use of TLS client authentication. It would be easy to refer to such a spec and make it a suggested way of verifying TLS keys. I've added the following text to my working copy' Security Consideration to make all this spelt out explicitly: The use of DNSSEC allows to verify TLS keys inside the DNS using DANE. It is in principle possible to use DANE and TLSA records to verify the authenticity, and possibly the authorisation of, a discovered RADIUS server by the RADIUS client which executed the algorithm. However, RADIUS/TLS and RADIUS/DTLS require mutual authentication; i.e. the RADIUS client's authenticity and authorisation are also verified by the RADIUS server as the client establishes the TLS connection. The DANE specification does not currently include a mechanism regarding the validation of a TLS credential of a client as it connects to a server (there is not per se a DNS label for which to do TLSA lookups). This makes DANE in its current state unsuitable for TLS connections discovered with the algorithm in this specification. If client authentication gets covered by future DANE extensions, this situation may change. > However I was really only looking at the use of DANE in the same forwar= d > direction that you are doing the discovery. This means that the mutual= auth > question is an interesting one and should be discussed as a reason for > perhaps not using the DANE work. It is actually quite promising - but client verification being underspecified currently makes it incomplete. I'll very gladly look at things again when there is a TLS client verification spec! >> I'd say: unless ABFAB people want to have text about the dynamic >> negotiation of TLS-PSK keying material with this algorithm (some ABFAB= s > are >> known to read the radext list :-) ), I'd feel inclined to write that P= SK > cipher >> suites are not appropriate for use with DNS-based dynamic discovery. >=20 > Given that ABFAB is basically doing a completely different dynamic > negotiation, I would be inclined to state that don't use PSK is a reaso= nable > position. Good! I've deleted the mention of TLS-PSK from the security considerations; and clarified the dangers of not using DNSSEC: When using DNS without DNSSEC security extensions for at least one of the replies to NAPTR, SRV and A/AAAA requests as described in section Section 2, the resulting set O can not be trusted. RADIUS transports have an out-of-DNS-band means to verify that the discovery attempt led to the intended target: certificate verification using a PKI. If the result set from DNS discovery is not trusted, deployments need to take sufficient care to verify during the TLS session establishment that they communicate with a peer they expect and deem authorised for RADIUS datagram exchange in their roaming environment. (The last sentence is a cliffhanger to add MTI text how to do this, depending on the outcome of the other discussion in the thread with Sam) Greetings, Stefan >=20 > Jim >=20 >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et de >> la Recherche 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >=20 >=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 ------enig2JVKXVLUBDWVALANUNHIL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE0weAACgkQ+jm90f8eFWa6JgCdH8fiLVwgqtKERqBdYPvlUamh r5AAn3pU02aeZrCyMnyQ7LH4DUsgFa5F =q4zV -----END PGP SIGNATURE----- ------enig2JVKXVLUBDWVALANUNHIL-- From hartmans@painless-security.com Mon Mar 4 07:55:55 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 302FD21F898B for ; Mon, 4 Mar 2013 07:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zcl8kdHbZvm for ; Mon, 4 Mar 2013 07:55:50 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 376AC21F897F for ; Mon, 4 Mar 2013 07:55:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 85FD220229; Mon, 4 Mar 2013 10:55:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2BC434486; Mon, 4 Mar 2013 10:55:48 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <026f01ce152a$f24ceb20$d6e6c160$@augustcellars.com> <5134C1DD.1020204@restena.lu> Date: Mon, 04 Mar 2013 10:55:48 -0500 In-Reply-To: <5134C1DD.1020204@restena.lu> (Stefan Winter's message of "Mon, 04 Mar 2013 16:46:37 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Jim Schaad Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 15:55:55 -0000 This is experimental, right? I'm trying to figure out how loud to grumble about the lack of a MTI certificate validation approach. From stefan.winter@restena.lu Mon Mar 4 08:05:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C138721F86EF for ; Mon, 4 Mar 2013 08:05:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mc1HK4y20slj for ; Mon, 4 Mar 2013 08:04:59 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9FF0221F8634 for ; Mon, 4 Mar 2013 08:04:59 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 079FE107B5 for ; Mon, 4 Mar 2013 17:04:59 +0100 (CET) Received: from [IPv6:2001:a18:1:8:a052:157:aa11:9a4b] (unknown [IPv6:2001:a18:1:8:a052:157:aa11:9a4b]) by smtprelay.restena.lu (Postfix) with ESMTPS id EC705106C2 for ; Mon, 4 Mar 2013 17:04:58 +0100 (CET) Message-ID: <5134C626.7090408@restena.lu> Date: Mon, 04 Mar 2013 17:04:54 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2VHDFPFLURLVRCUPRXUXK" X-Virus-Scanned: ClamAV Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:05:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2VHDFPFLURLVRCUPRXUXK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I strongly favor the first. I agree that it means that you need to hav= e > a field in the cert that contains the realm's name. > There are fairly obvious ways this can be done in a SAN. > RFc 4985 is an example of how microsoft does this. > My concern with the dnssec approach is that while it's easy to specify,= >=20 > I'm concerned that dnssec APIs are not widely available enough at > userspace levels outside the resolver that I'd have confidence > radsecproxy or freeradius or other radsec implementations could actuall= y > implement dnssec validation in the radius proxy right now. That's a reasonable concern to have, IMHO. I'd usually agree that the use of a SAN is a safer bet right now. Unfortunately, we've burnt our fingers on that one in eduroam already, so I'm somewhat reluctant to go down that path. Here's the war story. In an early beta deployment, we also considered the exact mention of the realm name the only safe thing to do. We used SAN:URI and filled it with a URN which contained the realm name (that is probably not the most obvious nor practicable way of doing things, but ... well.. it was an early beta). One of the things which are troublesome about this is that we found that even with dynamic discovery, proxies continued to exist: for most eduroam IdP's, operation of their own RADIUS/TLS enabled server, caring to get issued certificates, checking revocation and so on, was seen as too complex. Instead, they put the first-level aggregation server into DNS (with their agreement) to catch all their traffic and use normal RADIUS "routing tables" for the last hop to the actual IdP. That reduced the number of servers who needed to be "in the know" about dynamic discovery, and made the whole thing much more easily manageable. Except that all of a sudden, a RADIUS/TLS endpoint served hundreds of RADIUS NAI realms. With each realm required to be in the cert, the cert needs to changed whenever a new realm gets added or deleted. It also needs to remain in sync in near real-time with what the individual IdPs put into their DNS. This makes the whole dynamic discovery model a lot less self-service; there is always a CA operation involved. Our model of reverting to a generic "eligible eduroam IdP" (read as: "... or proxy for an eligible eduroam IdP") restored the self-service capabilities for the individual IdPs; they could add NAPTRs for their NAI realm at any time, and no changes on the certificates would be needed any more. I'm afraid that manageability issues will prevent the SAN approach from scaling to large consortia if any kind of aggregation is in use. Maybe if the SAN could include wildcards things would look better; an aggregation proxy could be given a cert for "*.lu and foo.net" for exampl= e. This, however, defeats the purpose of impersonation prevention because then that server could take the place of all .lu NAI realms, even if some of those want to handle their own business themselves. So... there's pros and cons. I wonder what you think of the reservations above. 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 ------enig2VHDFPFLURLVRCUPRXUXK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE0xioACgkQ+jm90f8eFWZksACfbkdNuASoa4waOLy9ZQXFaitE UgwAn3eXpNmSU2NHNFQ9SZvpiUuVzEXA =bBJ1 -----END PGP SIGNATURE----- ------enig2VHDFPFLURLVRCUPRXUXK-- From stefan.winter@restena.lu Mon Mar 4 08:05:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A8021F8942 for ; Mon, 4 Mar 2013 08:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+Fc5e-wg66J for ; Mon, 4 Mar 2013 08:05:46 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0EA21F87FF for ; Mon, 4 Mar 2013 08:05:46 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 7F13C107B5 for ; Mon, 4 Mar 2013 17:05:45 +0100 (CET) Received: from [IPv6:2001:a18:1:8:a052:157:aa11:9a4b] (unknown [IPv6:2001:a18:1:8:a052:157:aa11:9a4b]) by smtprelay.restena.lu (Postfix) with ESMTPS id 703A1106C2 for ; Mon, 4 Mar 2013 17:05:45 +0100 (CET) Message-ID: <5134C659.6070802@restena.lu> Date: Mon, 04 Mar 2013 17:05:45 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <026f01ce152a$f24ceb20$d6e6c160$@augustcellars.com> <5134C1DD.1020204@restena.lu> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2TGBGFMXXBIUOBHCOSQIH" X-Virus-Scanned: ClamAV Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:05:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2TGBGFMXXBIUOBHCOSQIH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > This is experimental, right? I'm trying to figure out how loud to > grumble about the lack of a MTI certificate validation approach. Correct. Stefan > _______________________________________________ > 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 ------enig2TGBGFMXXBIUOBHCOSQIH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE0xlkACgkQ+jm90f8eFWa20ACfW4HNQs+N93Aj0qNKYrtQ431e MWsAn2mfsA83UaOIuL2Mgmidx+mL7+y+ =o9Bd -----END PGP SIGNATURE----- ------enig2TGBGFMXXBIUOBHCOSQIH-- From hartmans@painless-security.com Mon Mar 4 08:10:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5137221F892D for ; Mon, 4 Mar 2013 08:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ask0Uz0uFAGi for ; Mon, 4 Mar 2013 08:10:19 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5957C21F887D for ; Mon, 4 Mar 2013 08:10:13 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 99C4C20229; Mon, 4 Mar 2013 11:10:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 385F84486; Mon, 4 Mar 2013 11:10:12 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <5134C626.7090408@restena.lu> Date: Mon, 04 Mar 2013 11:10:12 -0500 In-Reply-To: <5134C626.7090408@restena.lu> (Stefan Winter's message of "Mon, 04 Mar 2013 17:04:54 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2013 16:10:20 -0000 >>>>> "Stefan" == Stefan Winter writes: I'm missing something here. I'm not arguing that eduroam should use certificate validation. I'm simply arguing that there should be a MTI certificate validation strategy. We're documenting a generic mechanism here, not eduroam practice, right? I agree we want eduroam to comply with the spec, but an MTI security mechanism you choose not to use in your enviroment doesn't violate the spec. --Sam From ietf@augustcellars.com Mon Mar 4 18:08:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD42021F87CE for ; Mon, 4 Mar 2013 18:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvuNzb3R2K77 for ; Mon, 4 Mar 2013 18:08:20 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1860621F87C4 for ; Mon, 4 Mar 2013 18:08:19 -0800 (PST) Received: from Philemon (dhcp63-140-207-211.hil-tpanohx.orl.wayport.net [63.140.207.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 7FF0E2CA21; Mon, 4 Mar 2013 18:08:19 -0800 (PST) From: "Jim Schaad" To: "'Stefan Winter'" , References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <5134C626.7090408@restena.lu> In-Reply-To: <5134C626.7090408@restena.lu> Date: Mon, 4 Mar 2013 21:07:46 -0500 Message-ID: <009a01ce1946$3be101d0$b3a30570$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG6BiECksJl4xbIhvfkRt9hc11tPgGl6Lx2Aj/W81YB2RkCxADlQHzqAox4Ai2YdPsdkA== Content-Language: en-us Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 02:08:21 -0000 Stefan, Did you consider the use of SNI as part of your solution? This would = allow for the use a different certificates for each thing you proxy and thus = would reduce the need to re-issue certificates. The only thing that would be needed is to add a new certificate for each new proxied realm Jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On = Behalf > Of Stefan Winter > Sent: Monday, March 04, 2013 11:05 AM > To: radext@ietf.org > Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad >=20 > Hi, >=20 > > I strongly favor the first. I agree that it means that you need to > > have a field in the cert that contains the realm's name. > > There are fairly obvious ways this can be done in a SAN. > > RFc 4985 is an example of how microsoft does this. > > My concern with the dnssec approach is that while it's easy to > > specify, > > > > I'm concerned that dnssec APIs are not widely available enough at > > userspace levels outside the resolver that I'd have confidence > > radsecproxy or freeradius or other radsec implementations could > > actually implement dnssec validation in the radius proxy right now. >=20 > That's a reasonable concern to have, IMHO. I'd usually agree that the = use of a > SAN is a safer bet right now. Unfortunately, we've burnt our fingers = on that > one in eduroam already, so I'm somewhat reluctant to go down that = path. > Here's the war story. >=20 > In an early beta deployment, we also considered the exact mention of = the > realm name the only safe thing to do. We used SAN:URI and filled it = with a > URN which contained the realm name (that is probably not the most = obvious > nor practicable way of doing things, but ... well.. it was an early = beta). >=20 > One of the things which are troublesome about this is that we found = that > even with dynamic discovery, proxies continued to exist: for most = eduroam > IdP's, operation of their own RADIUS/TLS enabled server, caring to get issued > certificates, checking revocation and so on, was seen as too complex. > Instead, they put the first-level aggregation server into DNS (with = their > agreement) to catch all their traffic and use normal RADIUS "routing tables" > for the last hop to the actual IdP. >=20 > That reduced the number of servers who needed to be "in the know" = about > dynamic discovery, and made the whole thing much more easily > manageable. > Except that all of a sudden, a RADIUS/TLS endpoint served hundreds of > RADIUS NAI realms. With each realm required to be in the cert, the = cert > needs to changed whenever a new realm gets added or deleted. It also > needs to remain in sync in near real-time with what the individual = IdPs put > into their DNS. >=20 > This makes the whole dynamic discovery model a lot less self-service; there is > always a CA operation involved. >=20 > Our model of reverting to a generic "eligible eduroam IdP" (read as: > "... or proxy for an eligible eduroam IdP") restored the self-service > capabilities for the individual IdPs; they could add NAPTRs for their = NAI realm > at any time, and no changes on the certificates would be needed any = more. >=20 > I'm afraid that manageability issues will prevent the SAN approach = from > scaling to large consortia if any kind of aggregation is in use. >=20 > Maybe if the SAN could include wildcards things would look better; an > aggregation proxy could be given a cert for "*.lu and foo.net" for example. >=20 > This, however, defeats the purpose of impersonation prevention because > then that server could take the place of all .lu NAI realms, even if = some of > those want to handle their own business themselves. >=20 > So... there's pros and cons. I wonder what you think of the = reservations > above. >=20 > Greetings, >=20 > Stefan Winter >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et de > la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 From ietf@augustcellars.com Mon Mar 4 18:08:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D9E21F87D2 for ; Mon, 4 Mar 2013 18:08:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsjsJTiPEywT for ; Mon, 4 Mar 2013 18:08:49 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 86E2E21F87C4 for ; Mon, 4 Mar 2013 18:08:49 -0800 (PST) Received: from Philemon (dhcp63-140-207-211.hil-tpanohx.orl.wayport.net [63.140.207.211]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 11C7B2CA11; Mon, 4 Mar 2013 18:08:48 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , "'Stefan Winter'" References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <5134C626.7090408@restena.lu> In-Reply-To: Date: Mon, 4 Mar 2013 21:08:16 -0500 Message-ID: <009b01ce1946$4d821960$e8864c20$@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: AQG6BiECksJl4xbIhvfkRt9hc11tPgGl6Lx2Aj/W81YB2RkCxADlQHzqAox4Ai0ByoEIsJhmp7bQ Content-Language: en-us Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 02:08:50 -0000 Hear Hear!!!!! Jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Monday, March 04, 2013 11:10 AM > To: Stefan Winter > Cc: radext@ietf.org > Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad > > >>>>> "Stefan" == Stefan Winter writes: > > > > I'm missing something here. I'm not arguing that eduroam should use > certificate validation. I'm simply arguing that there should be a MTI certificate > validation strategy. We're documenting a generic mechanism here, not > eduroam practice, right? I agree we want eduroam to comply with the spec, > but an MTI security mechanism you choose not to use in your enviroment > doesn't violate the spec. > > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From jouni.nospam@gmail.com Mon Mar 4 21:02:06 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFD821F867B for ; Mon, 4 Mar 2013 21:02:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.071 X-Spam-Level: X-Spam-Status: No, score=0.071 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_EQ_IP_ADDR=1.119, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3BFiNAYI8Xz for ; Mon, 4 Mar 2013 21:02:05 -0800 (PST) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4867E21F8615 for ; Mon, 4 Mar 2013 21:02:05 -0800 (PST) Received: by mail-ea0-f176.google.com with SMTP id a13so999095eaa.7 for ; Mon, 04 Mar 2013 21:02:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=RHwYjJ41iSLrMy5PamddrsnF1oNbI09qk4HDtyap0+M=; b=ZQ+biI91G8HEqrvz3f27u5WmmkuVfXSsAbnbzSBA5XTK80iQPzbTOddj5BslSl55Zq MeVAdIbAjs2Xebi0+xY3byfmh61rKUoRBEBn5kcojeFkrT1TcGLbBOelW7QrfgJTVwu9 XZbixQHAGSiUePaeO1DVyNumUh5z23i/xwybbgAT5C+8ydfNW1R67d+6sAxSrmmZ4R7d 8ALnAILYflYvNjZNUDCbCbCVkjaTrL1T9xPeFTa8FQauarRaIptjZ25HNXYJ7ANsL6Nv 8X2rDgJmdWyUO9vorrXCN381trD7O/5kfKkjnnBnjZLcDuXyzcAv0hvYxGNLzEx0Vil0 ggAA== X-Received: by 10.14.1.130 with SMTP id 2mr66204352eed.15.1362459724324; Mon, 04 Mar 2013 21:02:04 -0800 (PST) Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPS id q5sm35417732eep.11.2013.03.04.21.02.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 04 Mar 2013 21:02:03 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: Date: Tue, 5 Mar 2013 07:02:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9268BB7F-9906-4C0B-8BFD-2B22451F578B@gmail.com> References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <5134C626.7090408@restena.lu> To: Sam Hartman , Stefan Winter X-Mailer: Apple Mail (2.1499) Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2013 05:02:06 -0000 I would encourage sparing few words for a MTI certificate validation = strategy. - Jouni On Mar 4, 2013, at 6:10 PM, Sam Hartman = wrote: >>>>>> "Stefan" =3D=3D Stefan Winter writes: >=20 >=20 >=20 > I'm missing something here. I'm not arguing that eduroam should use > certificate validation. I'm simply arguing that there should be a MTI > certificate validation strategy. We're documenting a generic = mechanism > here, not eduroam practice, right? I agree we want eduroam to comply > with the spec, but an MTI security mechanism you choose not to use in > your enviroment doesn't violate the spec. >=20 > --Sam > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Wed Mar 6 04:31:48 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C6021F8758 for ; Wed, 6 Mar 2013 04:31:48 -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=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_39=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrO17W3t21CG for ; Wed, 6 Mar 2013 04:31:47 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9F1D221F874C for ; Wed, 6 Mar 2013 04:31:47 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 8687710A06 for ; Wed, 6 Mar 2013 13:31:46 +0100 (CET) Received: from [IPv6:2001:a18:1:8:cf1:29dd:507b:4405] (unknown [IPv6:2001:a18:1:8:cf1:29dd:507b:4405]) by smtprelay.restena.lu (Postfix) with ESMTPS id 7A8E510A03 for ; Wed, 6 Mar 2013 13:31:46 +0100 (CET) Message-ID: <5137372F.8010800@restena.lu> Date: Wed, 06 Mar 2013 13:31:43 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <5134C626.7090408@restena.lu> <009a01ce1946$3be101d0$b3a30570$@augustcellars.com> In-Reply-To: <009a01ce1946$3be101d0$b3a30570$@augustcellars.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2KQAHQWBEEKMDVDASKFMX" X-Virus-Scanned: ClamAV Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:31:48 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2KQAHQWBEEKMDVDASKFMX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Did you consider the use of SNI as part of your solution? This would a= llow > for the use a different certificates for each thing you proxy and thus = would > reduce the need to re-issue certificates. The only thing that would be= > needed is to add a new certificate for each new proxied realm Back in the day: no :-) But looking at SNI now sure looks somewhat promising. It's not a clear winner though: SNI as per the current RFC6066 definition includes only DNS hostnames. The discovery algorithm in this draft will at some point end up at a host which is responsible for a realm - but that does not mean this hosts' DNS name is identical to the realm that was being queried. If ID management is outsourced, the realm and the hostname can be completely unrelated. In a "dream world" where SNI would allow SAN:othername as an indication, this might work pretty well though. It could combine Sam's "SAN:othername realm=3Dwhatever " construct and combine it with a client-side hint in SNI: please show me a certificate with this SAN:othername included. This would nicely bond together the realm, and the verification that the discovered server is authorised for that particular realm (disregarding the DNS host name). As you correctly point out, this would *still* be less than practical in a large-scale deployment, where an aggregation proxy would need to be issued "hundreds" of certificates by a CA, but it would at least in principle be a rather clean approach. That said, the only way to get other names besides DNS names into SNI would be by updating RFC6066. Certainly not impossible, but a big caliber= =2E Greetings, Stefan Winter > Jim >=20 >=20 >> -----Original Message----- >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Beha= lf >> Of Stefan Winter >> Sent: Monday, March 04, 2013 11:05 AM >> To: radext@ietf.org >> Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad >> >> Hi, >> >>> I strongly favor the first. I agree that it means that you need to >>> have a field in the cert that contains the realm's name. >>> There are fairly obvious ways this can be done in a SAN. >>> RFc 4985 is an example of how microsoft does this. >>> My concern with the dnssec approach is that while it's easy to >>> specify, >>> >>> I'm concerned that dnssec APIs are not widely available enough at >>> userspace levels outside the resolver that I'd have confidence >>> radsecproxy or freeradius or other radsec implementations could >>> actually implement dnssec validation in the radius proxy right now. >> >> That's a reasonable concern to have, IMHO. I'd usually agree that the = use > of a >> SAN is a safer bet right now. Unfortunately, we've burnt our fingers o= n > that >> one in eduroam already, so I'm somewhat reluctant to go down that path= =2E >> Here's the war story. >> >> In an early beta deployment, we also considered the exact mention of t= he >> realm name the only safe thing to do. We used SAN:URI and filled it wi= th a >> URN which contained the realm name (that is probably not the most obvi= ous >> nor practicable way of doing things, but ... well.. it was an early be= ta). >> >> One of the things which are troublesome about this is that we found th= at >> even with dynamic discovery, proxies continued to exist: for most edur= oam >> IdP's, operation of their own RADIUS/TLS enabled server, caring to get= > issued >> certificates, checking revocation and so on, was seen as too complex. >> Instead, they put the first-level aggregation server into DNS (with th= eir >> agreement) to catch all their traffic and use normal RADIUS "routing > tables" >> for the last hop to the actual IdP. >> >> That reduced the number of servers who needed to be "in the know" abou= t >> dynamic discovery, and made the whole thing much more easily >> manageable. >> Except that all of a sudden, a RADIUS/TLS endpoint served hundreds of >> RADIUS NAI realms. With each realm required to be in the cert, the cer= t >> needs to changed whenever a new realm gets added or deleted. It also >> needs to remain in sync in near real-time with what the individual IdP= s > put >> into their DNS. >> >> This makes the whole dynamic discovery model a lot less self-service; > there is >> always a CA operation involved. >> >> Our model of reverting to a generic "eligible eduroam IdP" (read as: >> "... or proxy for an eligible eduroam IdP") restored the self-service >> capabilities for the individual IdPs; they could add NAPTRs for their = NAI > realm >> at any time, and no changes on the certificates would be needed any mo= re. >> >> I'm afraid that manageability issues will prevent the SAN approach fro= m >> scaling to large consortia if any kind of aggregation is in use. >> >> Maybe if the SAN could include wildcards things would look better; an >> aggregation proxy could be given a cert for "*.lu and foo.net" for > example. >> >> This, however, defeats the purpose of impersonation prevention because= >> then that server could take the place of all .lu NAI realms, even if s= ome > of >> those want to handle their own business themselves. >> >> So... there's pros and cons. I wonder what you think of the reservatio= ns >> above. >> >> Greetings, >> >> Stefan Winter >> >> -- >> Stefan WINTER >> Ingenieur de Recherche >> Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education Natio= nale et de >> la Recherche 6, rue Richard Coudenhove-Kalergi >> L-1359 Luxembourg >> >> Tel: +352 424409 1 >> Fax: +352 422473 >=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 ------enig2KQAHQWBEEKMDVDASKFMX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3NzIACgkQ+jm90f8eFWatLgCfRakzdUsHOTsHtr63UXe1biWG A7oAn2CpzjBtKT6rhKR0pLDjA34TseVg =ICXs -----END PGP SIGNATURE----- ------enig2KQAHQWBEEKMDVDASKFMX-- From stefan.winter@restena.lu Wed Mar 6 04:38:44 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEBE21F8867 for ; Wed, 6 Mar 2013 04:38:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RmxKvDPIDqWG for ; Wed, 6 Mar 2013 04:38:44 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4975721F8826 for ; Wed, 6 Mar 2013 04:38:44 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 9EF3510A06 for ; Wed, 6 Mar 2013 13:38:43 +0100 (CET) Received: from [IPv6:2001:a18:1:8:cf1:29dd:507b:4405] (unknown [IPv6:2001:a18:1:8:cf1:29dd:507b:4405]) by smtprelay.restena.lu (Postfix) with ESMTPS id 8DB3510A03 for ; Wed, 6 Mar 2013 13:38:43 +0100 (CET) Message-ID: <513738D3.9030602@restena.lu> Date: Wed, 06 Mar 2013 13:38:43 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: radext@ietf.org References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <5134C626.7090408@restena.lu> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2NEMPBSAMHAVCDRLDBOHQ" X-Virus-Scanned: ClamAV Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:38:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NEMPBSAMHAVCDRLDBOHQ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > I'm missing something here. I'm not arguing that eduroam should use > certificate validation. I'm simply arguing that there should be a MTI > certificate validation strategy. We're documenting a generic mechanism= > here, not eduroam practice, right? I agree we want eduroam to comply > with the spec, but an MTI security mechanism you choose not to use in > your enviroment doesn't violate the spec. My issue is not that the MTI mechanism would not be identical to what eduroam does; far from it. My issue is that this particular mechanism is known to have scalability issues by practical experimentation. Of course we could make it MTI anyway. The consequence might well be that we require code in conforming servers that is later "never" used because its practical implications are clumsy. That would be "specifying MTI for MTI's sake" - without much real value in the real world, and code being written for no reason other than to comply with the "law". I don't really like that situation. Of course our scalability problems could be entirely homemade and not applicable to the rest of the world, and every other deployer will find the MTI mechanism as sketched perfectly fine, and the implementation code will be put to good use. Then I'd have no issues with specifying this; eduroam would simply be doing its own thing anyway. It's just that I'm not really convinced that this is the case. Greetings, Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2NEMPBSAMHAVCDRLDBOHQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE3ONMACgkQ+jm90f8eFWaqlwCff5tHdeHd381BhsxOpiHpA8rG o0MAniCJGs4m9Wpblr9ZcEz3EVlC73Fb =G9af -----END PGP SIGNATURE----- ------enig2NEMPBSAMHAVCDRLDBOHQ-- From hartmans@painless-security.com Wed Mar 6 04:53:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7158221F8937 for ; Wed, 6 Mar 2013 04:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2ygYwwaiS9x for ; Wed, 6 Mar 2013 04:53:00 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7A29F21F8936 for ; Wed, 6 Mar 2013 04:52:59 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 83FA32014B; Wed, 6 Mar 2013 07:52:50 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2582341CE; Wed, 6 Mar 2013 07:52:57 -0500 (EST) From: Sam Hartman To: Stefan Winter References: <065.a122826c6d7c009295065142646863ee@trac.tools.ietf.org> <512E23F3.3000307@restena.lu> <512E2846.5090702@restena.lu> <5134C626.7090408@restena.lu> <513738D3.9030602@restena.lu> Date: Wed, 06 Mar 2013 07:52:57 -0500 In-Reply-To: <513738D3.9030602@restena.lu> (Stefan Winter's message of "Wed, 06 Mar 2013 13:38:43 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] #148: Review of dynamic-discovery by Jim Schaad X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 12:53:00 -0000 I consider the lack of a MTI validation mechanism (cert or otherwise) that's credible a fatal flaw for standards-track. I prefer this spec have a MTI cert validation mechanism, but would rather see it published without than not published. From hartmans@painless-security.com Wed Mar 6 09:39:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A163921F8A56; Wed, 6 Mar 2013 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCqCV6BtmQAv; Wed, 6 Mar 2013 09:39:35 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 927A821F89B3; Wed, 6 Mar 2013 09:39:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1E01C2014B; Wed, 6 Mar 2013 12:39:17 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 83BE141CE; Wed, 6 Mar 2013 12:39:25 -0500 (EST) From: Sam Hartman To: abfab@ietf.org, radext@ietf.org, saag@ietf.org Date: Wed, 06 Mar 2013 12:39:25 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [radext] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:39:39 -0000 The ABFAB working group has been busy at work describing a federated identity and access management model that enables federated identity for a wide variety of use cases and applications; this work is currently drawing to a close. However, one of the typical problems in the federated world - and a problem that any ABFAB implementations needs to address - is managing the scaling of number of partners involved in the federation (this is because configuration changes need to be made at all interested partners when new entities join). Existing federation technologies attempt to solve this problem in a variety of ways (e.g. SAML metadata, hierarchical RADIUS federations) but each has their own unique disadvantages. A much more elegant, flexible, and extensible way to achieve the same goals would be beneficial - especially for when scaling up to the potential number of entities in a community of ABFAB-enabled partners. Alongside this, operationally, there is also a need to separate the authentication process from the creation of a new partnership across a set of federated entities - so as to allow existing credentials to be used for new communities of users with minimal operation and infrastructure costs. This is crucial in driving adoption of federated technologies on a wide scale, and in reducing the cost of operating and being a part of federation on such a wide scale. Trust Router is an attempt to build an infrastructure that solves these - and other - problems (see the full problem statement for more details). Essentially, trust Router works by distributing information about new and existing trust relationships across a network of entities. It achieves this distribution using protocols with many similarities to existing routing protocols, and avoids any requirement for technologies such as PKI. The broad applicability of a general infrastructure for routing trust information between arbitrary entities and allowing them to communicate securely means that this is potentially quite an exciting topic, and one ripe for standardisation. Come join us to talk all about trust and trust routing at our Bar BOF - to be held on Thursday March 14th @ 11:30AM, located in Caribbean 7. Documents to read: * Trust Router problem statement - http://tools.ietf.org/html/ draft-howlett-abfab-trust-router-ps-02 * ABFAB Architecture document - http://tools.ietf.org/html/ draft-ietf-abfab-arch-05 * Trust router protocol overview - http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02.txt From hartmans@painless-security.com Wed Mar 6 09:46:01 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B4021F8CFA; Wed, 6 Mar 2013 09:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylbPdggsiprA; Wed, 6 Mar 2013 09:46:01 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 05A3D21F8C12; Wed, 6 Mar 2013 09:45:56 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id A30A12014B; Wed, 6 Mar 2013 12:45:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4A20041CE; Wed, 6 Mar 2013 12:45:55 -0500 (EST) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: Date: Wed, 06 Mar 2013 12:45:55 -0500 In-Reply-To: (Klaas Wierenga's message of "Wed, 6 Mar 2013 17:43:10 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , "abfab@ietf.org" , "saag@ietf.org" Subject: Re: [radext] [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:46:01 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: Klaas> Sam, How does this relate to the trust router slot in Routing Klaas> Area Open Meeting? we're going to introduce the topic and try and get routing folks to go to the bar bof. We think having routing clue review the trust router would be valuable. From klaas@wierenga.net Wed Mar 6 11:55:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3177D21F8949; Wed, 6 Mar 2013 11:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-2XbCdbWZa5; Wed, 6 Mar 2013 11:54:57 -0800 (PST) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id D063A21F897A; Wed, 6 Mar 2013 11:54:44 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r26JseG9003213; Wed, 6 Mar 2013 20:54:40 +0100 Received: from 5355139f.cm-6-6a.dynamic.ziggo.nl ([83.85.19.159] helo=[192.168.1.87]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UDKP5-000KeL-Q5; Wed, 06 Mar 2013 20:53:31 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <3B80CEB5-B1D0-4A3B-A9E9-C8AABD854BEE@wierenga.net> X-Mailer: iPad Mail (10B146) From: Klaas Wierenga Date: Wed, 6 Mar 2013 20:54:41 +0100 To: Sam Hartman X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vJ8jSEag - 288397efad06 - 20130306 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "radext@ietf.org" , "abfab@ietf.org" , "Klaas Wierenga \(kwiereng\)" , "saag@ietf.org" Subject: Re: [radext] [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 19:55:02 -0000 On 6 mrt. 2013, at 18:45, Sam Hartman wrote: >>>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: > > Klaas> Sam, How does this relate to the trust router slot in Routing > Klaas> Area Open Meeting? > > we're going to introduce the topic and try and get routing folks to go > to the bar bof. > We think having routing clue review the trust router would be valuable. Agreed, makes a lot of sense. Klaas > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From kwiereng@cisco.com Wed Mar 6 09:43:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B18D21F8CF5; Wed, 6 Mar 2013 09:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVbpoI31w+k4; Wed, 6 Mar 2013 09:43:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B4E9021F8CEB; Wed, 6 Mar 2013 09:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3059; q=dns/txt; s=iport; t=1362591791; x=1363801391; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DasIbZK0n/TPwikN7ER4p4l0Kkft1EBAWy+FQIhJH+4=; b=AbLj++XzO9fpH3gIsRwlLovpXHHbumzHmVSz0Ua2FGAtx21dCTLBNufU xkA1CGGX56mKbVr3kGG9YsOU1y3iFoZ9sRxbiLzrKL7HIZUof2MiMVKrS lfH3uHkCdupEa9mSlU0L4a7gtf6RLByvxFttmSQnW5h2+hjCxa2Ya1jvO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKZ+N1GtJV2c/2dsb2JhbAA7CcRGgVoWc4IqAQEBAwEBAQE3NAMBBwULAgEIEiQQJwsXDgIEDgUUh3kGDLx+jUoIgQczB4JfYQOWS4Eeij2FFYMI X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208";a="184270458" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Mar 2013 17:43:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r26HhAPv015744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Mar 2013 17:43:11 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.138]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 11:43:10 -0600 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 Thread-Index: AQHOGpGXSYJnqNzinkOuD8EzixwzxZiY7v8G Date: Wed, 6 Mar 2013 17:43:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Thu, 07 Mar 2013 08:39:20 -0800 Cc: "radext@ietf.org" , "abfab@ietf.org" , "saag@ietf.org" Subject: Re: [radext] [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 17:43:16 -0000 Sam, How does this relate to the trust router slot in Routing Area Open Meeting? Klaas Sent from my iPad On 6 mrt. 2013, at 18:39, "Sam Hartman" wr= ote: > The ABFAB working group has been busy at work describing a federated iden= tity > and access management model that enables federated identity for a wide va= riety > of use cases and applications; this work is currently drawing to a close. >=20 > However, one of the typical problems in the federated world - and a probl= em > that any ABFAB implementations needs to address - is managing the scaling= of > number of partners involved in the federation (this is because configurat= ion > changes need to be made at all interested partners when new entities join= ). > Existing federation technologies attempt to solve this problem in a varie= ty of > ways (e.g. SAML metadata, hierarchical RADIUS federations) but each has t= heir > own unique disadvantages. A much more elegant, flexible, and extensible w= ay to > achieve the same goals would be beneficial - especially for when scaling = up to > the potential number of entities in a community of ABFAB-enabled partners= . >=20 > Alongside this, operationally, there is also a need to separate the > authentication process from the creation of a new partnership across a se= t of > federated entities - so as to allow existing credentials to be used for n= ew > communities of users with minimal operation and infrastructure costs. Thi= s is > crucial in driving adoption of federated technologies on a wide scale, an= d in > reducing the cost of operating and being a part of federation on such a w= ide > scale. >=20 > Trust Router is an attempt to build an infrastructure that solves these -= and > other - problems (see the full problem statement for more details). > Essentially, trust Router works by distributing information about new and > existing trust relationships across a network of entities. It achieves th= is > distribution using protocols with many similarities to existing routing > protocols, and avoids any requirement for technologies such as PKI. The b= road > applicability of a general infrastructure for routing trust information b= etween > arbitrary entities and allowing them to communicate securely means that t= his is > potentially quite an exciting topic, and one ripe for standardisation. >=20 > Come join us to talk all about trust and trust routing at our Bar BOF - t= o be > held on Thursday March 14th @ 11:30AM, located in Caribbean 7. >=20 > Documents to read: > * Trust Router problem statement - http://tools.ietf.org/html/ > draft-howlett-abfab-trust-router-ps-02 > * ABFAB Architecture document - http://tools.ietf.org/html/ > draft-ietf-abfab-arch-05 > * Trust router protocol overview - > http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02.txt > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From jouni.nospam@gmail.com Fri Mar 8 03:26:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733DF21F86C5 for ; Fri, 8 Mar 2013 03:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B71RopdUmUV3 for ; Fri, 8 Mar 2013 03:26:50 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9374B21F8698 for ; Fri, 8 Mar 2013 03:26:49 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id go11so1229672lbb.22 for ; Fri, 08 Mar 2013 03:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=9ohCXsBYTSGsMzL6FD8hsnw2wL1tY9f2e/3zLJaKuYE=; b=0I7F84xrI2tjh6x08728eB6sfDDQ3pm1d7wgfso9iyxPM8h3KnUFHYRt1Q3hi7Ojeb gqLEGg35ffPofoKBtDQkWGkya+F7CtS/amUzFhhgDMR4N7PTStcd1Pb+4DGscAilTx0q r/VyT8klNnWE1gCTTal8M4X2jUJtOVjYgYNNYeXIR5U+eztQaufvq7aAlWXx/xFCllbs MWVZml4Axe99AXQURKPpJJvnA8/9RT8K5BbJ5iTfEvVLhpvdSYa+jL1RAvy03EWw3t1E XPPzHO1l1tgASRklZloHytHn+JV8GkBSPcex3TXQ3LXJ8PN/FO6pv+oB5k6FfbLaHAu6 WE2A== X-Received: by 10.112.26.10 with SMTP id h10mr942268lbg.63.1362742008557; Fri, 08 Mar 2013 03:26:48 -0800 (PST) Received: from [192.168.250.164] ([194.100.71.98]) by mx.google.com with ESMTPS id m1sm1553524lbh.5.2013.03.08.03.26.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Mar 2013 03:26:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Jouni Korhonen In-Reply-To: <51275AA9.4070306@um.es> Date: Fri, 8 Mar 2013 13:26:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> <51275AA9.4070306@um.es> To: Alejandro Perez Mendez , "radext@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 11:26:50 -0000 Folks, It seems the document as such still needs more work to be acceptable as a WG item. We will have time for a discussion around the fragmentation in Orlando meeting agenda and see then where to head to. Related to this, we will also have a presentation of the other alternative proposals seen on the list. - Jouni & Mauricio On Feb 22, 2013, at 1:46 PM, Alejandro Perez Mendez wrote: >=20 >> I support adopting the previous version of this draft >> (draft-perez-radext-radius-fragmentation-04) and would support = adopting >> the current version (draft-perez-radext-radius-fragmentation-05) if a >> mechanism was added for fragmented information in access-request = prior >> to authentication. That is, I disagree with one of the changes the >> authors made between 04 and 05. >=20 > Hi Sam, >=20 > we have been discussing this aspect internally, and we have concluded = that the support of fragmentation prior to authentication will be = re-incorporated into the next version of the document, though it will be = noted that it may have the potential to allow DoS attacks. >=20 > Best regards, > Alejandro >=20 >=20 >>=20 >> --Sam >> _______________________________________________ >> 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 hartmans@painless-security.com Fri Mar 8 04:40:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0C421F8630 for ; Fri, 8 Mar 2013 04:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RuoFv6oUAa0l for ; Fri, 8 Mar 2013 04:40:50 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DC87521F862D for ; Fri, 8 Mar 2013 04:40:49 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2E2C72016B; Fri, 8 Mar 2013 07:40:36 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D75A341CE; Fri, 8 Mar 2013 07:40:44 -0500 (EST) From: Sam Hartman To: Jouni Korhonen References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> <51275AA9.4070306@um.es> Date: Fri, 08 Mar 2013 07:40:44 -0500 In-Reply-To: (Jouni Korhonen's message of "Fri, 8 Mar 2013 13:26:48 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 12:40:50 -0000 Jouni> Folks, Jouni> It seems the document as such still needs more work to be Jouni> acceptable as a WG item. We will have time for a discussion Jouni> around the fragmentation in Orlando meeting agenda and see Jouni> then where to head to. Jouni> Related to this, we will also have a presentation of the Jouni> other alternative proposals seen on the list. Jouni> - Jouni & Mauricio do you have someone to speak to the alternative of just use TCP when possible? I actually don't consider it a strict alternative, but I do think it should be discussed and would be happy to help present if you don't have anything lined up. My personal preference is that we use TCP when possible and this draft when not. --Sam From aland@deployingradius.com Fri Mar 8 06:55:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61ED621F8493; Fri, 8 Mar 2013 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iuwg11+4BCZ; Fri, 8 Mar 2013 06:55:01 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF36B21F8491; Fri, 8 Mar 2013 06:55:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C89E72240DAF; Fri, 8 Mar 2013 15:54:59 +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 784y89NoH5QO; Fri, 8 Mar 2013 15:54:59 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.60]) by power.freeradius.org (Postfix) with ESMTPSA id 9421B224036D; Fri, 8 Mar 2013 15:54:58 +0100 (CET) Message-ID: <5139FBC1.7030909@deployingradius.com> Date: Fri, 08 Mar 2013 09:54:57 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> <51275AA9.4070306@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" , Alejandro Perez Mendez Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2013 14:55:02 -0000 Jouni Korhonen wrote: > It seems the document as such still needs more work to be > acceptable as a WG item. We will have time for a discussion > around the fragmentation in Orlando meeting agenda and see > then where to head to. After much discussion in the past week, the fragmentation draft authors have decided to change the draft, and re-issue it under a new name. The name change reflects a change in focus which we hope makes fragmentation easier to understand. The net result is the same, but the underlying theory is different. I'll give a short explanation here. The first goal is to work with existing RADIUS proxies. This goal is satisfied by using Access-Request / Access-Accept. A User-Name is included in the Access-Request, so that existing proxies can forward the packets. The second goal is to do this *only* for authorization. There is no need to support "large data" for CoA, Accounting, etc. This goal is satisfied by using Access-Request / Access-Accept. The third goal is to not change existing authentication methods or packet flows. This goal is new, and results in the name change. We are no longer fragmenting "access requests", we are exchanging large amounts of authorization data. The third goal is satisfied by exchanging *references* to the authorization data in the Access-Request and Access-Accept. These references satisfy the requirements of RFC 6158, as pointed out by Bernard. The problem we're solving then becomes "how to dynamically provision authorization data". When defined that way, the discussion becomes simpler. The exchange of this data no longer affects existing authentication methods. The exchange of large data happens pretty much as discussed in the current draft. There are technical details, of course. These details again become simpler when they don't affect existing methods. The resulting exchange is then done in three steps. 1. send pre-authentication authorization data NAS to Server. 2. authentication (as is done now) 3. send post-authentication authorization data Server to NAS. Step (1) finishes with a token which is used in the Access-Request for step (2). Step (2) finishes with a token in the Access-Accept, which refers to step (3). Either or both of steps (1) and (2) can be omitted. If the authorization data is small enough, it can just be put into packets for step (2). I hope that this explanation is clear, and satisfies the concerns raised here. We hope to have an updated draft ready by next week. Alan DeKok. From jounikor@gmail.com Sun Mar 10 09:29:24 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 582E321F863C for ; Sun, 10 Mar 2013 09:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2EnAaRVK2ZK for ; Sun, 10 Mar 2013 09:29:23 -0700 (PDT) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id E304721F8633 for ; Sun, 10 Mar 2013 09:29:23 -0700 (PDT) Received: by mail-pb0-f42.google.com with SMTP id xb4so2886183pbc.1 for ; Sun, 10 Mar 2013 09:29:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version:x-mailer; bh=FsrVY5soYUtEH4C9ylgas16rj5mEM4i2uAQre+qXqNQ=; b=EK/A27FQ9ZWlBPTaQ9lGASUto1dtcEFA/uR8TSSyBm/Tpzhn6FHS8gvT/3avEOhtci +7sGH+hVOz5dOrS7woSyOw0uU+AQ7J2QC82d9bDRur4MazOGO2wfwRDNULVv2WmLIddK KyIV4yDpbBiLkihoRWiQF/h8cTPwRx2PDlOlHnq+Hb/8QT5H2/Zlvtd4pUu4rSv4Rlq8 nnZOUIurf/0UB1n+/+SO87DhqAOLAsyF/5SCiuRzTUTpm4zSpJTXTfjbW4UwK4p0JyWe Msmc+bnjg3ey5vPhv8vXCgnc0YC3U9CscsnpLzFYl05TelW+TWcrIRXkwIigsTxCxleR sF7A== X-Received: by 10.68.9.67 with SMTP id x3mr20750883pba.219.1362932963595; Sun, 10 Mar 2013 09:29:23 -0700 (PDT) Received: from [130.129.134.193] ([130.129.134.193]) by mx.google.com with ESMTPS id ri1sm16056288pbc.16.2013.03.10.09.29.21 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Mar 2013 09:29:23 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Sun, 10 Mar 2013 18:29:28 +0200 To: "radext@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) Subject: [radext] Presentations slides X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2013 16:29:24 -0000 Folks, Those with an agenda slot please send your slides to the chairs by Monday noon. From mauricio.sanchez@hp.com Mon Mar 11 11:58:47 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A4721F8DE9 for ; Mon, 11 Mar 2013 11:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 95EaZghF9eaB for ; Mon, 11 Mar 2013 11:58:46 -0700 (PDT) Received: from g6t0186.atlanta.hp.com (g6t0186.atlanta.hp.com [15.193.32.63]) by ietfa.amsl.com (Postfix) with ESMTP id C3E8721F8D9A for ; Mon, 11 Mar 2013 11:58:45 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g6t0186.atlanta.hp.com (Postfix) with ESMTPS id 4136B2C471; Mon, 11 Mar 2013 18:58:45 +0000 (UTC) Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 11 Mar 2013 18:57:34 +0000 Received: from G6W2486.americas.hpqcorp.net ([169.254.9.135]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.02.0328.009; Mon, 11 Mar 2013 18:57:34 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: [radext] Presentations slides Thread-Index: AQHOHaxun5Af4yID1UmDJMED6sPq+Zigli0A Date: Mon, 11 Mar 2013 18:57:34 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [15.193.49.23] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3445858654_65993123" MIME-Version: 1.0 Cc: Jouni Korhonen Subject: Re: [radext] Presentations slides X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 18:58:47 -0000 --B_3445858654_65993123 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Thanks to those of you that have sent in your slides. For those that haven't (and you know who you are), please do so ASAP. Thanks, RADEXT chairs On 3/10/13 9:29 AM, "Jouni Korhonen" wrote: >Folks, > >Those with an agenda slot please send your slides to the >chairs by Monday noon. > > >_______________________________________________ >radext mailing list >radext@ietf.org >https://www.ietf.org/mailman/listinfo/radext --B_3445858654_65993123 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg19iOCZiOl4vu7Szrzi7y4ZkD Zn4HnwIPXyq8ys3OqcgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwMzExMTg1NzM0WjANBgkqhkiG9w0BAQEFAASCAQCDaP76NDNGoJ2+nw0NyfEBm+jf oeBXSXZAGTpOHEmu67f4HzpZ+Gbq9V2sGIN82BxwYtzFF8YZ54WNYDGdsQTOlxdeAb06kGF/ cPESwoeTM+s61CzIMUub0Fg6wgzOG+5mfB8byngOAb6NoBiXA0PKUsmTuPW65gUHydaVj4gx 0zRnW90PDj0dcvNb57Q71nWnqopnlCItdG4QbL0m6ijsPymU0mktdpSt2YGIiG1Hs4yujit3 vxCIrj9+yEd/huluRvDepsa3/XRgC1MST14dOv84mS7RdZ6IErn1tHx3Jsmils7Bm44STjhL Hpjsl/6/BzASRRPYx/wxVKkdIvjC --B_3445858654_65993123-- From aland@deployingradius.com Wed Mar 13 07:00:33 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E840F21F8CBB for ; Wed, 13 Mar 2013 07:00:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVMnMR4622lj for ; Wed, 13 Mar 2013 07:00:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5616121F8CB8 for ; Wed, 13 Mar 2013 07:00:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CE8232240DB8 for ; Wed, 13 Mar 2013 15:00:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRBGeunukVZp for ; Wed, 13 Mar 2013 15:00:32 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id BE69022408AD for ; Wed, 13 Mar 2013 15:00:31 +0100 (CET) Message-ID: <5140867E.9020303@deployingradius.com> Date: Wed, 13 Mar 2013 10:00:30 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:00:34 -0000 This message is to correct misconceptions I heard at the RADEXT mike yesterday. They seem to be rooted in the confusion between what is *allowed* and what is *required*. Peter's draft *requires* re-assembly at every intermediate node. Alejandro's draft *allows* re-assembly at every intermediate node. Peter's draft *forbids* existing proxies from using fragmentation. Alejandro's draft *allows* existing proxies to use fragmentation. To me, the more flexible approach is better on a number of fronts. First, it works with existing systems, which is (for me) a hard requirement. Second, it allows systems to be *gradually* upgraded. The gradual upgrade path means that Alejandro's draft can be deployed today, and fixed over time. The "fork-lift ugrade" required by Peter's draft means that everyone has to upgrade for anyone to see any benefit. The IETF has sufficient proof that fork-lift upgrades rarely work. Alan DeKok. From hartmans@painless-security.com Wed Mar 13 07:07:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6488421F8D8E for ; Wed, 13 Mar 2013 07:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[AWL=0.380, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id emRtwkW8DbFM for ; Wed, 13 Mar 2013 07:07:14 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB121F8D8D for ; Wed, 13 Mar 2013 07:07:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-922b.meeting.ietf.org [130.129.10.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 93DC5201F7; Wed, 13 Mar 2013 10:06:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 977A841CF; Wed, 13 Mar 2013 10:07:11 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5140867E.9020303@deployingradius.com> Date: Wed, 13 Mar 2013 10:07:11 -0400 In-Reply-To: <5140867E.9020303@deployingradius.com> (Alan DeKok's message of "Wed, 13 Mar 2013 10:00:30 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:07:15 -0000 Alan, I agree with you that we should support Alejandro's draft. However, I think we're early enough in the deployment of RADSEC and RADIUS over TCP that having a better approach for fragmenting over those technologies is desirable. From aland@deployingradius.com Wed Mar 13 07:08:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCB621F8D9C for ; Wed, 13 Mar 2013 07:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hmoa1I7CRxfk for ; Wed, 13 Mar 2013 07:08:14 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0967F21F8D9A for ; Wed, 13 Mar 2013 07:08:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D43142241054; Wed, 13 Mar 2013 15:08:13 +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 rXv9vcObe2Oz; Wed, 13 Mar 2013 15:08:13 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id 5E5DA22408AD; Wed, 13 Mar 2013 15:08:13 +0100 (CET) Message-ID: <5140884C.80606@deployingradius.com> Date: Wed, 13 Mar 2013 10:08:12 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <5140867E.9020303@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 14:08:14 -0000 Sam Hartman wrote: > Alan, I agree with you that we should support Alejandro's draft. > However, I think we're early enough in the deployment of RADSEC and > RADIUS over TCP that having a better approach for fragmenting over those > technologies is desirable. Absolutely. Alan DeKok. From peterd@iea-software.com Wed Mar 13 09:01:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA76321F8DF0 for ; Wed, 13 Mar 2013 09:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5L1h99zMwiX for ; Wed, 13 Mar 2013 09:01:36 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC8321F8DEE for ; Wed, 13 Mar 2013 09:01:35 -0700 (PDT) Received: from littlesmurf (unverified [10.0.1.17]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 13 Mar 2013 09:01:35 -0700 Date: Wed, 13 Mar 2013 09:01:35 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5140867E.9020303@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 16:01:36 -0000 On Wed, 13 Mar 2013, Alan DeKok wrote: > This message is to correct misconceptions I heard at the RADEXT mike > yesterday. They seem to be rooted in the confusion between what is > *allowed* and what is *required*. Hi Alan, I think my discussion with Sam was more in regards to flights of packets. I hope there is no confusion left on this topic as I have gone out of my way to stress the differences on the list. Last slide of my presentation spoke to this question. > today, and fixed over time. The "fork-lift ugrade" required by Peter's > draft means that everyone has to upgrade for anyone to see any benefit. > The IETF has sufficient proof that fork-lift upgrades rarely work. Another way to look at the situation from the perspective of only subset of systems which do not implement the specifications is that existing systems are seeing different information when Alex's approach is switched on. Unless these proxy systems are expected to do little else than forward messages based on User-Name realm you are likely to cause breakage with unknowable consequences. I have a preference for not working at all over breaking existing things especially when "things" are of sort authentication or authorization. regards, Peter From aland@deployingradius.com Wed Mar 13 10:33:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB2C21F8E10 for ; Wed, 13 Mar 2013 10:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.67 X-Spam-Level: X-Spam-Status: No, score=-100.67 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSgXvWVVQFIn for ; Wed, 13 Mar 2013 10:33:17 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF6A21F8DFC for ; Wed, 13 Mar 2013 10:33:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 04F962240DB8; Wed, 13 Mar 2013 18:32: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 Xg6i1VVXripy; Wed, 13 Mar 2013 18:32:38 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id B754122408AD; Wed, 13 Mar 2013 18:32:37 +0100 (CET) Message-ID: <5140B834.4050302@deployingradius.com> Date: Wed, 13 Mar 2013 13:32:36 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 17:33:18 -0000 Peter Deacon wrote: > I think my discussion with Sam was more in regards to flights of packets. I was referring to Sams comments about fragility of the Alejandro draft, and that reassembly was preferred. > I hope there is no confusion left on this topic as I have gone out of my > way to stress the differences on the list. Last slide of my > presentation spoke to this question. Yes. It's why I mentioned the fork-lift upgrade. > Another way to look at the situation from the perspective of only subset > of systems which do not implement the specifications is that existing > systems are seeing different information when Alex's approach is > switched on. I'm not sure how to parse that sentence. > Unless these proxy systems are expected to do little else than forward > messages based on User-Name realm you are likely to cause breakage with > unknowable consequences. Vague predictions of disaster aren't helpful. There are already many proxies that do *not* re-write packet contents. Most of the proxies in Eduroam, for example. That serves as proof it *can* work without breakage. For servers which need to re-write packet contents, the answer is the same as for your proposal: upgrade. So this proposal is in some cases better, but no worse than your proposal. > I have a preference for not working at all over breaking existing things > especially when "things" are of sort authentication or authorization. Please describe *what* will break, and *how* it will break. We've had this conversation repeatedly. Doom and gloom aren't good protocol design. Facts and evidence are. Alan DeKok. From peterd@iea-software.com Wed Mar 13 11:07:58 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B924121F8E3F for ; Wed, 13 Mar 2013 11:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJS5aqHJy5CB for ; Wed, 13 Mar 2013 11:07:57 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 89AF921F8E0B for ; Wed, 13 Mar 2013 11:07:55 -0700 (PDT) Received: from littlesmurf (unverified [10.0.1.17]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id for ; Wed, 13 Mar 2013 11:07:53 -0700 Date: Wed, 13 Mar 2013 11:07:52 -0700 (Pacific Daylight Time) From: Peter Deacon To: "radext@ietf.org" Message-ID: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [radext] Meeting laundry list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:07:58 -0000 Some thoughts from meeting. ----- RADIUS/DTLS I still think my scheme using 4 byte header from issue #64 in the tracker could be useful to improve DTLS draft for following reasons. - Remove dependencies on TLS content type and RADIUS packet code - Prevent sync problems with UDP NAT state association - Allow single DTLS session to be used to support more than 255 unacknowledged requests. This would simplify client implementations from having to pool and maintain multiple sessions to the same server. - Resolves "pothole" problem where a source port is selected from which RADIUS server already has an open session and therefore ignores anything not associated to the session. ----- Stefan - loop detection We have had a trivial proxy loop detection system in production in our implementations for several years. It works on the assumption any request the same proxy system sees again completes a cycle. In our implementation a systems identifier is embedded in the proxy state attribute. When a request for proxy is received we check for matching system identifier in the current stack of proxy states and drop the request if one is found. ----- ieee802ext Had a chance to read thru this draft a bit before and after the meeting - looks good here. ----- Datatypes I like the general idea of a type registry that can be referenced but I'm not sure how much utility there is at this point. It could see it being more expressive to have a new complex type in the registry to map things we don't want to add a separate entry for like Tunnel-Password rather than collapsing to string. Thanks to chairs and all for a great meeting :) regards, Peter From peterd@iea-software.com Wed Mar 13 11:23:54 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6067221F8E4C for ; Wed, 13 Mar 2013 11:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-1.929, BAYES_00=-2.599, FRT_PROFIT1=3.858] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5yOtUAhlPE8 for ; Wed, 13 Mar 2013 11:23:53 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id C4E6621F8E3C for ; Wed, 13 Mar 2013 11:23:53 -0700 (PDT) Received: from littlesmurf (unverified [10.0.1.17]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 13 Mar 2013 11:23:53 -0700 Date: Wed, 13 Mar 2013 11:23:52 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5140B834.4050302@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:23:54 -0000 On Wed, 13 Mar 2013, Alan DeKok wrote: > Peter Deacon wrote: >> I think my discussion with Sam was more in regards to flights of packets. > I was referring to Sams comments about fragility of the Alejandro > draft, and that reassembly was preferred. Yes, this was about movement of packets thru the system rather than compatibility. > There are already many proxies that do *not* re-write packet contents. > Most of the proxies in Eduroam, for example. That serves as proof it > *can* work without breakage. Changing contents is only a small half of the equation. The other half is making decisions based upon the same content. regards, Peter From aland@deployingradius.com Wed Mar 13 11:38:34 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B643311E809C for ; Wed, 13 Mar 2013 11:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.323 X-Spam-Level: X-Spam-Status: No, score=-102.323 tagged_above=-999 required=5 tests=[AWL=0.276, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JojuB3dHdBHU for ; Wed, 13 Mar 2013 11:38:33 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3F55C11E80A4 for ; Wed, 13 Mar 2013 11:38:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8D05B2240DB8; Wed, 13 Mar 2013 19:38:32 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GsxXBYSp26g; Wed, 13 Mar 2013 19:38:30 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id 493C222408AD; Wed, 13 Mar 2013 19:38:30 +0100 (CET) Message-ID: <5140C7A4.7030509@deployingradius.com> Date: Wed, 13 Mar 2013 14:38:28 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 18:38:35 -0000 Peter Deacon wrote: > Changing contents is only a small half of the equation. The other half > is making decisions based upon the same content. Sure. Which is why the draft says that User-Name is included in each fragment. The requirements for fragmentation come from abfab (among others). All of the known use-cases are for proxy federations, where User-Name is used for proxying. If you have other use-cases, please explain. Alan DeKok. From peterd@iea-software.com Wed Mar 13 12:02:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB09411E8179 for ; Wed, 13 Mar 2013 12:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.956 X-Spam-Level: X-Spam-Status: No, score=-1.956 tagged_above=-999 required=5 tests=[AWL=0.643, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id crhanfZm1+8e for ; Wed, 13 Mar 2013 12:02:48 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 6C17D11E8176 for ; Wed, 13 Mar 2013 12:02:48 -0700 (PDT) Received: from littlesmurf (unverified [10.0.1.19]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 13 Mar 2013 12:02:47 -0700 Date: Wed, 13 Mar 2013 12:02:49 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5140C7A4.7030509@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:02:49 -0000 On Wed, 13 Mar 2013, Alan DeKok wrote: >> Changing contents is only a small half of the equation. The other half >> is making decisions based upon the same content. > Sure. Which is why the draft says that User-Name is included in each > fragment. > The requirements for fragmentation come from abfab (among others). > All of the known use-cases are for proxy federations, where User-Name is > used for proxying. Hu? What requirements? regards, Peter From aland@deployingradius.com Wed Mar 13 12:30:50 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 309DA21F89CB for ; Wed, 13 Mar 2013 12:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.358 X-Spam-Level: X-Spam-Status: No, score=-102.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anOtMH26Z2di for ; Wed, 13 Mar 2013 12:30:49 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8689421F8431 for ; Wed, 13 Mar 2013 12:30:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BBF4C2240DB8; Wed, 13 Mar 2013 20:30:47 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9Td79sdJsKW; Wed, 13 Mar 2013 20:30:47 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id E653622408AD; Wed, 13 Mar 2013 20:30:46 +0100 (CET) Message-ID: <5140D3E5.6040008@deployingradius.com> Date: Wed, 13 Mar 2013 15:30:45 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Mar 2013 19:30:50 -0000 Peter Deacon wrote: > On Wed, 13 Mar 2013, Alan DeKok wrote: >> The requirements for fragmentation come from abfab (among others). >> All of the known use-cases are for proxy federations, where User-Name is >> used for proxying. > > Hu? What requirements? The use-cases were discussed on this list, on the abfab list, and in the face to face meetings. The requirements are to satisfy the use-cases. Why, exactly, are you unfamiliar with them? I also said: >> If you have other use-cases, please explain. Since you didn't respond, I can only assume you have no use-cases for the solution you're proposing. As such, it is a solution in search of a problem, and isn't relevant to this working group. Alan DeKok. From aland@deployingradius.com Wed Mar 13 18:39:51 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771221F870F for ; Wed, 13 Mar 2013 18:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.385 X-Spam-Level: X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ZWh2r8wxhyW for ; Wed, 13 Mar 2013 18:39:50 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CAB9521F86EC for ; Wed, 13 Mar 2013 18:39:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 56F8A2241156; Thu, 14 Mar 2013 02:39:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bf54-n5ePDOL; Thu, 14 Mar 2013 02:39:14 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id D23F42241054; Thu, 14 Mar 2013 02:39:13 +0100 (CET) Message-ID: <51412A40.3090509@deployingradius.com> Date: Wed, 13 Mar 2013 21:39:12 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Meeting laundry list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 01:39:51 -0000 Peter Deacon wrote: > Datatypes > > I like the general idea of a type registry that can be referenced but > I'm not sure how much utility there is at this point. > > It could see it being more expressive to have a new complex type in the > registry to map things we don't want to add a separate entry for like > Tunnel-Password rather than collapsing to string. This seems reasonable. There are 26 "string" attributes defined in the RFCs. Of these, only a few appear to be carrying raw data. Many carry pre-defined complex data types. Alan DeKok. From peterd@iea-software.com Wed Mar 13 23:45:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A31F21F8D5B for ; Wed, 13 Mar 2013 23:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=0.482, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAY-AHlPsy5R for ; Wed, 13 Mar 2013 23:45:10 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id B886D21F8CB9 for ; Wed, 13 Mar 2013 23:45:10 -0700 (PDT) Received: from littlesmurf.peterd.ws (unverified [10.0.3.39]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Wed, 13 Mar 2013 23:45:10 -0700 Date: Wed, 13 Mar 2013 23:45:09 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5140D3E5.6040008@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 06:45:11 -0000 On Wed, 13 Mar 2013, Alan DeKok wrote: >>> The requirements for fragmentation come from abfab (among others). >>> All of the known use-cases are for proxy federations, where User-Name is >>> used for proxying. >> Hu? What requirements? > The use-cases were discussed on this list, on the abfab list, and in > the face to face meetings. The requirements are to satisfy the use-cases. I recall Alex indicating a desire to provide a generally applicable solution. Is this still the case or is his draft intended only to address specific needs of specific groups? If offered as a general solution I would assume there would be parity in consideration of possible implications to more than specific groups. regards, Peter From alex@um.es Thu Mar 14 06:42:04 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBE5F11E812D for ; Thu, 14 Mar 2013 06:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f60aJczosVHD for ; Thu, 14 Mar 2013 06:42:04 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2197311E8129 for ; Thu, 14 Mar 2013 06:42:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id A683353984 for ; Thu, 14 Mar 2013 14:41:58 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id EkS+06+DCNm0 for ; Thu, 14 Mar 2013 14:41:58 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 1855F53986 for ; Thu, 14 Mar 2013 14:41:47 +0100 (CET) Message-ID: <5141D39B.1020609@um.es> Date: Thu, 14 Mar 2013 14:41:47 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 13:42:05 -0000 El 14/03/13 07:45, Peter Deacon escribió: > On Wed, 13 Mar 2013, Alan DeKok wrote: > >>>> The requirements for fragmentation come from abfab (among others). >>>> All of the known use-cases are for proxy federations, where >>>> User-Name is >>>> used for proxying. > >>> Hu? What requirements? >> The use-cases were discussed on this list, on the abfab list, and in >> the face to face meetings. The requirements are to satisfy the >> use-cases. > > I recall Alex indicating a desire to provide a generally applicable > solution. Is this still the case or is his draft intended only to > address specific needs of specific groups? Hello Peter, initially it was intented to be generic. However, after recent discussions (please, refer to Alan's mail 08/Mar/13), we come out with the conlusion that fragmentation does not make much sense out of sending authorization-related data, as it does not seem a good idea to interfere with authentication flows. Other flows like accounting are alraedy discussed in the draft. That's why we are considering updating the draft's name. Regards, Alejandro > > If offered as a general solution I would assume there would be parity > in consideration of possible implications to more than specific groups. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Thu Mar 14 07:06:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7A11E8160 for ; Thu, 14 Mar 2013 07:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PVNVg-h7G8fq for ; Thu, 14 Mar 2013 07:06:08 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B0F8311E815F for ; Thu, 14 Mar 2013 07:06:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DDFBA2241054; Thu, 14 Mar 2013 15:06:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQlwi+-Fgz82; Thu, 14 Mar 2013 15:06:06 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id ACA5C224054D; Thu, 14 Mar 2013 15:06:05 +0100 (CET) Message-ID: <5141D94C.5060709@deployingradius.com> Date: Thu, 14 Mar 2013 10:06:04 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 14:06:09 -0000 Peter Deacon wrote: > I recall Alex indicating a desire to provide a generally applicable > solution. Is this still the case or is his draft intended only to > address specific needs of specific groups? Alejandro's comments apply here. > If offered as a general solution I would assume there would be parity in > consideration of possible implications to more than specific groups. What real-world problem is solved by *generalized* fragmentation support? Accounting? CoA? Disconnect? Please explain. Alan DeKok. From hartmans@painless-security.com Thu Mar 14 08:20:28 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98E411E8142 for ; Thu, 14 Mar 2013 08:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xe3DbzYPvUb5 for ; Thu, 14 Mar 2013 08:20:27 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2C12B11E82AE for ; Thu, 14 Mar 2013 08:20:23 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-906c.meeting.ietf.org [130.129.8.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 4C8DD20180 for ; Thu, 14 Mar 2013 11:19:54 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 39DFF41CF; Thu, 14 Mar 2013 11:20:18 -0400 (EDT) From: Sam Hartman To: radext@ietf.org Date: Thu, 14 Mar 2013 11:20:18 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 15:20:28 -0000 Hi. we've had a lot of messages on fragmentation. Here's where we are in my understanding. Please correct me if I'm wrong. 1) Alex's draft supports fragmentation through existing proxies. Alex, Alan, and I believe this is important to support. Peter said a while back that he's not opposed to having a way to do this but support through existing proxies is not his focus because that support doesn't support arbitrary command codes such as accounting. 2) Alan, Jim Schaad, Margaret Wasserman and I believe it is strongly desirable to use large packets to handle fragmentation when using TCP or TLS. Peter supports this with his fragmentation inquery concept. 3) Peter would like to support fragmentation over UDP in a manner that supports all command codes. As a consequence this doesn't work with existing proxies. This is is fragmentation data concept. Peter believes the overhead of setting up TCP may be too high for some situations. 4) I don't support fragmentation data because I believe TCP/TLS is sufficient of a solution in cases where you are willing to upgrade equipment. Peter's solution will be much harder to standardize. In addition, I don't think the overhead of TCP connection establishment is significant with tuned equipment. 5) Alan doesn't support the fragmentation data concept from Peter's proposal. I don't remember the reasons he cites. 6) Alex's draft involves reassembley both at the IP layer because packets larger than MTU are sent as well as reassembley at the RADIUS layer (it's a fragmentation mechanism after all.) I believe this is inherent when you want to support existing proxies. However, it does have transport implications that make it desirable to use an alternative mechanism when you can upgrade equipment. In my mind I'm not being critical of Alex's draft; I'm just trying to scope when it makes sense. From alex@um.es Thu Mar 14 09:47:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D7DF11E80E7 for ; Thu, 14 Mar 2013 09:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T+p7thln-9Ev for ; Thu, 14 Mar 2013 09:47:14 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id A4C6A21F8545 for ; Thu, 14 Mar 2013 09:47:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id BA6F45D8FF for ; Thu, 14 Mar 2013 17:47:13 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CrYIkYfHE+dU for ; Thu, 14 Mar 2013 17:47:13 +0100 (CET) Received: from [192.168.1.102] (79.109.146.222.dyn.user.ono.com [79.109.146.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id 86B5E5D8DF for ; Thu, 14 Mar 2013 17:47:11 +0100 (CET) Message-ID: <5141FF0E.8080702@um.es> Date: Thu, 14 Mar 2013 17:47:10 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 16:47:15 -0000 Hi Sam, see my comment inline, please. > Hi. > we've had a lot of messages on fragmentation. Here's where we are in my > understanding. > Please correct me if I'm wrong. > > 1) Alex's draft supports fragmentation through existing proxies. Alex, > Alan, and I believe this is important to support. > Peter said a while back that he's not opposed to having a way to do this > but support through existing proxies is not his focus because that > support doesn't support arbitrary command codes such as accounting. > > 2) Alan, Jim Schaad, Margaret Wasserman and I believe it is strongly > desirable to use large packets to handle fragmentation when using TCP or > TLS. Peter supports this with his fragmentation inquery concept. > > 3) Peter would like to support fragmentation over UDP in a manner that > supports all command codes. As a consequence this doesn't work with > existing proxies. This is is fragmentation data concept. Peter believes > the overhead of setting up TCP may be too high for some situations. > > 4) I don't support fragmentation data because I believe TCP/TLS is > sufficient of a solution in cases where you are willing to upgrade > equipment. Peter's solution will be much harder to standardize. In > addition, I don't think the overhead of TCP connection establishment is > significant with tuned equipment. > > > > 5) Alan doesn't support the fragmentation data concept from Peter's > proposal. I don't remember the reasons he cites. > > 6) Alex's draft involves reassembley both at the IP layer because > packets larger than MTU are sent as well as reassembley at the RADIUS > layer (it's a fragmentation mechanism after all.) I believe this is > inherent when you want to support existing proxies. However, it does > have transport implications that make it desirable to use an alternative > mechanism when you can upgrade equipment. In my mind I'm not being > critical of Alex's draft; I'm just trying to scope when it makes sense. Well, the idea is to maintain chunk size below PMTU, hence there would no need to reassemble at IP layer and thus we avoid UDP fragmentation. That's one of the reasons why we don't want to interfere with RADIUS-EAP which already fills RADIUS packets up to the PMTU. Regards, Alejandro > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Thu Mar 14 10:19:08 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12CC111E81C4 for ; Thu, 14 Mar 2013 10:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yhfQSZMFua5 for ; Thu, 14 Mar 2013 10:19:07 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6411E81C0 for ; Thu, 14 Mar 2013 10:19:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-906c.meeting.ietf.org [130.129.8.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id A4D3520180; Thu, 14 Mar 2013 13:18:39 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 81A1541CF; Thu, 14 Mar 2013 13:19:05 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <5141FF0E.8080702@um.es> Date: Thu, 14 Mar 2013 13:19:05 -0400 In-Reply-To: <5141FF0E.8080702@um.es> (Alejandro Perez Mendez's message of "Thu, 14 Mar 2013 17:47:10 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:19:08 -0000 How do you plan to figure out what the path mtu is? From aland@deployingradius.com Thu Mar 14 10:58:47 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB8A11E80F2 for ; Thu, 14 Mar 2013 10:58:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FhsSmIydGoF for ; Thu, 14 Mar 2013 10:58:45 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id C244D11E8110 for ; Thu, 14 Mar 2013 10:58:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 898DC2241054; Thu, 14 Mar 2013 18:58: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 qFW4QiFascrB; Thu, 14 Mar 2013 18:58:41 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id ECB82224031D; Thu, 14 Mar 2013 18:58:40 +0100 (CET) Message-ID: <51420FCF.7000207@deployingradius.com> Date: Thu, 14 Mar 2013 13:58:39 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <5141FF0E.8080702@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 17:58:47 -0000 Sam Hartman wrote: > How do you plan to figure out what the path mtu is? Telephone. Or email. The MTU should be settable by the proxy. The administrator then plays with it until it works. I've spent some time reading up on UDP PTMU discovery. In short, it doesn't work well in IPv4. It's worse in IPv6. Pretty much all of the UDP applications I've seen turn PMTU discovery off. Enabling it means that the kernel may do PMTU discover on every packet sent by the application. That's bad. Alan DeKok. From alex@um.es Thu Mar 14 11:09:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F70C21F8DEE for ; Thu, 14 Mar 2013 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5czHAsvk4QPb for ; Thu, 14 Mar 2013 11:09:41 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 6621721F8DE9 for ; Thu, 14 Mar 2013 11:09:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id ED81C5D617; Thu, 14 Mar 2013 19:09:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id UcA7TB7bF9n5; Thu, 14 Mar 2013 19:09:39 +0100 (CET) Received: from [192.168.1.102] (79.109.146.222.dyn.user.ono.com [79.109.146.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id CB7FF5D5FD; Thu, 14 Mar 2013 19:09:37 +0100 (CET) Message-ID: <51421260.8070907@um.es> Date: Thu, 14 Mar 2013 19:09:36 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Sam Hartman References: <5141FF0E.8080702@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:09:42 -0000 Hi Sam, it seems to be several RFC dealing with that specific problem (4821, 1191, 1981). Sorry if I'm assuming they work, but actually they don't. I assumed that was somehow trivial. Regards, Alejandro El 14/03/13 18:19, Sam Hartman escribió: > How do you plan to figure out what the path mtu is? From hartmans@painless-security.com Thu Mar 14 11:19:07 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FA2321F8640 for ; Thu, 14 Mar 2013 11:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ve45KLwA-xCL for ; Thu, 14 Mar 2013 11:19:06 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 15FD311E819C for ; Thu, 14 Mar 2013 11:19:00 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-906c.meeting.ietf.org [130.129.8.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 8D21620180; Thu, 14 Mar 2013 14:18:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 11C0F41CF; Thu, 14 Mar 2013 14:18:57 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5141FF0E.8080702@um.es> <51420FCF.7000207@deployingradius.com> Date: Thu, 14 Mar 2013 14:18:57 -0400 In-Reply-To: <51420FCF.7000207@deployingradius.com> (Alan DeKok's message of "Thu, 14 Mar 2013 13:58:39 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:19:07 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> How do you plan to figure out what the path mtu is? Alan> Telephone. Or email. No, but if multiple proxies are involved, how do you get the information to the other side of the path. --Sam From aland@deployingradius.com Thu Mar 14 11:25:35 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87CB721F8ED5 for ; Thu, 14 Mar 2013 11:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5eLtvxKSDyN for ; Thu, 14 Mar 2013 11:25:35 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 885DD21F8F2F for ; Thu, 14 Mar 2013 11:25:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id F15522241054; Thu, 14 Mar 2013 19:24:58 +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 N9rq9Vsn9V0Y; Thu, 14 Mar 2013 19:24:58 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id 2537A224036D; Thu, 14 Mar 2013 19:24:58 +0100 (CET) Message-ID: <514215F8.9050509@deployingradius.com> Date: Thu, 14 Mar 2013 14:24:56 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <5141FF0E.8080702@um.es> <51420FCF.7000207@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:25:35 -0000 Sam Hartman wrote: > No, but if multiple proxies are involved, how do you get the information > to the other side of the path. The same way people do now. Email or telephone. :( It's ugly and non-scalable, but it works. A workable PMTU discovery would involve some kind of multi-proxy capability negotiation. Or, everyone sets PMTU to 576 octets, and hopes for the best. Alan DeKok. From hartmans@painless-security.com Thu Mar 14 11:32:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1308911E81FB for ; Thu, 14 Mar 2013 11:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ibFxaJQa8LL for ; Thu, 14 Mar 2013 11:32:42 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7D24711E81B0 for ; Thu, 14 Mar 2013 11:32:42 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-906c.meeting.ietf.org [130.129.8.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0F0F420180; Thu, 14 Mar 2013 14:32:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CB75A41CF; Thu, 14 Mar 2013 14:32:38 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <5141FF0E.8080702@um.es> <51420FCF.7000207@deployingradius.com> <514215F8.9050509@deployingradius.com> Date: Thu, 14 Mar 2013 14:32:38 -0400 In-Reply-To: <514215F8.9050509@deployingradius.com> (Alan DeKok's message of "Thu, 14 Mar 2013 14:24:56 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Alejandro Perez Mendez Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 18:32:43 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Sam Hartman wrote: >> No, but if multiple proxies are involved, how do you get the >> information to the other side of the path. Alan> The same way people do now. Email or telephone. :( That doesn't seem realistic. Consider a case like eduroam. I have a path that goes from a->b->c->d It seems reasonable for the operators of a and b to call each other. But how does a learn the mtu between c and d? Phone or e-mail don't seem like reasonable options for that. From aland@deployingradius.com Thu Mar 14 13:30:21 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C015811E815B for ; Thu, 14 Mar 2013 13:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+2kf8E49MN3 for ; Thu, 14 Mar 2013 13:30:12 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7991811E80FB for ; Thu, 14 Mar 2013 13:30:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 6DFA022403DE; Thu, 14 Mar 2013 21:30:10 +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 qr22cV5risTf; Thu, 14 Mar 2013 21:30:09 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id A09F4224029E; Thu, 14 Mar 2013 21:30:09 +0100 (CET) Message-ID: <51423350.2000704@deployingradius.com> Date: Thu, 14 Mar 2013 16:30:08 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman , "radext@ietf.org" References: <5141FF0E.8080702@um.es> <51420FCF.7000207@deployingradius.com> <514215F8.9050509@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Mar 2013 20:30:22 -0000 Sam Hartman wrote: > That doesn't seem realistic. It's not. > Consider a case like eduroam. > I have a path that goes from a->b->c->d > > It seems reasonable for the operators of a and b to call each other. > But how does a learn the mtu between c and d? We need a way for RADIUS servers to exchange MTU for specific paths. This information probably needs to be part of a capabilities exchange, and / or a RADIUS routing protocol. Alan DeKok. From mauricio.sanchez@hp.com Thu Mar 14 21:49:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C00521F9072 for ; Thu, 14 Mar 2013 21:49:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.161 X-Spam-Level: X-Spam-Status: No, score=-109.161 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_BLANKS=0.041, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUdAutC0HdTu for ; Thu, 14 Mar 2013 21:49:38 -0700 (PDT) Received: from g5t0008.atlanta.hp.com (g5t0008.atlanta.hp.com [15.192.0.45]) by ietfa.amsl.com (Postfix) with ESMTP id 50FBE21F906F for ; Thu, 14 Mar 2013 21:49:36 -0700 (PDT) Received: from G6W4001.americas.hpqcorp.net (g6w4001.atlanta.hp.com [16.205.80.210]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by g5t0008.atlanta.hp.com (Postfix) with ESMTPS id BD26924709; Fri, 15 Mar 2013 04:49:35 +0000 (UTC) Received: from G6W3997.americas.hpqcorp.net (16.205.80.212) by G6W4001.americas.hpqcorp.net (16.205.80.210) with Microsoft SMTP Server (TLS) id 14.2.328.9; Fri, 15 Mar 2013 04:47:38 +0000 Received: from G6W2486.americas.hpqcorp.net ([169.254.9.135]) by G6W3997.americas.hpqcorp.net ([16.205.80.212]) with mapi id 14.02.0328.009; Fri, 15 Mar 2013 04:47:38 +0000 From: "Sanchez, Mauricio (HP Networking)" To: "radext@ietf.org" Thread-Topic: preliminary minutes Thread-Index: AQHOITg3mUnM+tqQnU2qju65joYi5Q== Date: Fri, 15 Mar 2013 04:47:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [15.193.49.15] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3446135505_3235857" MIME-Version: 1.0 Cc: "jouni.nospam@gmail.com" Subject: [radext] preliminary minutes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 04:49:42 -0000 --B_3446135505_3235857 Content-type: multipart/mixed; boundary="B_3446135504_3263429" --B_3446135504_3263429 Content-type: multipart/alternative; boundary="B_3446135504_3267595" --B_3446135504_3267595 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Attached are preliminary notes. Any corrections/additions welcome. Thanks to Steve H. for note taking. -Jouni and Mauricio --B_3446135504_3267595 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable

Attached  a= re preliminary notes. Any corrections/additions welcome. 


Thanks t= o Steve H. for note taking. 


-Jouni and Mauricio 



--B_3446135504_3267595-- --B_3446135504_3263429 Content-type: text/plain; name="minutes_ietf86.txt" Content-disposition: attachment; filename="minutes_ietf86.txt" Content-transfer-encoding: base64 UkFERVhUCklFVEYgODYKT3JsYW5kbywgRkwKCkZyaWRheSwgQXVnIDMsIDIwMTIKTWVldGlu ZyBzdGFydGVkIDU6MDFQTSBhbmQgYWRqb3VybmVkIDY6MzFQTQoKQ2hhaXJzOg0KSm91bmkg S29yaG9uZW4gPGpvdW5pLmtvcmhvbmVuIGF0IG5zbi5jb20+DQpNYXVyaWNpbyBTYW5jaGV6 IDxtYXVyaWNpby5zYW5jaGV6IGF0IGhwLmNvbT4NCg0KQUQ6DQpCZW5vaXQgQ2xhaXNlIDxi Y2xhaXNlIGF0IGNpc2NvLmNvbT4gCgoqUHJlbGltaW5hcmllcyoKClN0ZXZlIHZvbHVudGVy ZWVkIHRvIHRha2Ugbm90ZXMuCgpNYXVyaWNpbyByZXZpZXdlZCBkb2N1bWVudCBzdGF0dXM6 CgoyIGRvY3MgaW4gUkZDIEVkaXRvcidzIHF1ZXVlLiBFeHBlY3QgcHVibGljYXRpb24gYnkg bmV4dCBJRVRGCmRyYWZ0LWlldGYtcmFkZXh0LWlwdjYtYWNjZXNzLCBkcmFmdC1pZXRmLXJh ZGV4dC1yYWRpdXMtZXh0ZW5zaW9ucwoKMSBkb2MgaW4gV0dMQwpkcmFmdC1pZXRmLXJhZGV4 dC1pZWVlODAyZXh0CgoyIGRvY3MgaW4gV0dMQywgc29vbiBoZWFkaW5nIGJhY2sgdG8gV0dM QwpkcmFmdC1pZXRmLXJhZGV4dC1kdGxzLCBkcmFmdC1pZXRmLXJhZGV4dC1keW5hbWljLWRp c2NvdmVyeQoKMSBhY3RpdmUgV0cgZHJhZnQgLSBOQUkKZHJhZnQtaWV0Zi1yYWRleHQtbmFp CgoyIHByb3Bvc2FscyBmb3IgbmV3IFdHIGRyYWZ0cwpkcmFmdC1wZXJlei1yYWRleHQtcmFk aXVzLWZyYWdlbWVudGF0aW9uLCBkcmFmdC1kZWFjb24tcmFkZXh0LWV4dGVuZGVkLXJlcXVl c3QKCjYgZHJhZnRzIHRoYXQgYXJlIG91dHNpZGUgb2Ygb3VyIGNoYXJ0ZXIKZHJhZnQteWVo LXJhZGV4dC1leHQtdHJhZmZpYy1zdGF0aXN0aWNzLCBkcmFmdC13aW50ZXItcmFkZXh0LWZh bmN5YWNjb3VudGluZywKZHJhZnQtaGFsd2FzaWEtcmFkZXh0LWNhcGFiaWxpdHktbmVnb3Rp YXRpb24sIGRyYWZ0LWRla29rLXJhZGl1cy1pcGZpeCwKZHJhZnQtZGVrb2stcmFkZXh0LWRh dGF0eXBlcywgZHJhZnQteHVlLXJhZGV4dC1rZXktbWFuYWdlbWVudAoKTWF1cmljaW8gcG9p bnRlZCBvdXQgdGhhdCBvdXIgcHJvZ3Jlc3MgdG8gZGF0ZSBpcwpzbG93ZXIgdGhhbiB0aGUg bWlsZXN0b25lcyBpbiBvdXIgY2hhcnRlci4gTW9zdCBkcmFmdHMKYXJlIGJlaGluZCBzY2hl ZHVsZSBidXQgbm90IHNldmVyZWx5IHNvLiBXZSdsbCB0cnkgdG8Kc3BlZWQgdGhpbmdzIHVw IGEgYml0LgoKQWxhbiBEZUtvayBwcmVzZW50ZWQgYnkgU2t5cGUgb24gTkFJLCBSQURJVVMg RXh0ZW5zaW9uLAphbmQgRFRMUy4KCipOQUkqCgpBbGFuIG1hZGUgdXBkYXRlcyBiYXNlZCBv biBjb21tZW50cyBmcm9tIEppbSBTY2hhYWQgYW5kIEJlcm5hcmQKQWJvYmEuIE5vdyB0aGF0 IHBlb3BsZSBhcmUgdXNpbmcgRUFQIGluIG1hbnkgcGxhY2VzLCB3ZSB3YW50IHRvCm1ha2Ug TkFJIGEgdXNlciBpZGVudGlmaWVyIHVzZWQgbW9yZSBicm9hZGx5LgoKTGlvbmVsIE1vcmFu ZCBhc2tlZCB3aHkgd2UncmUgc3RpbGwgdXNpbmcgdGhlIHdvcmRpbmcgIk5ldHdvcmsKQWNj ZXNzIElkZW50aWZpZXIiIGlmIHdlIHdhbnQgdG8gdXNlIGl0IGluIG90aGVyIHBsYWNlcy4g QmVybmFyZApBYm9iYSBnYXZlIHRoZSBoaXN0b3J5IG9mIGhvdyB3ZSBnb3QgaGVyZS4gV2hl biB0aGUgTkFJIHdhcwpjcmVhdGVkLCBpdCB3YXMganVzdCBmb3IgbmV0d29yayBhY2Nlc3Mu IE5vdyBpdCdzIHVzZWQgaW4KdGhlIFNJUCBSQURJVVMgZG9jdW1lbnQgYW5kIGluIEhUVFAg YWxzby4gVGhhdCBoYXMgbm90aGluZyB0byBkbwp3aXRoIG5ldHdvcmsgYWNjZXNzLiBBbmQg dGhlIFNJUCBVUkkgdXNlcyBkaWZmZXJlbnQgZm9ybWF0cyBmb3IKdGhlaXIgaWRlbnRpZmll ci4gTWF5YmUgd2Ugc2hvdWxkIHNheSB0aGF0IHNvbWUgb2YgdGhlIHRoaW5ncwp0aGF0IGdv IGluIGEgUkFESVVTIHVzZXIgaWRlbnRpZmllciBmaWVsZCBhcmUgbm90IGFuIE5BSS4gQnV0 CnRoaXMgd2lsbCBjYXVzZSBwcm9ibGVtcyBzaW5jZSBtYW55IHN5c3RlbXMgYXNzdW1lIHRo YXQgaXQKaXMgYW4gTkFJLiBBbGFuIHNhaWQgdGhhdCBpdCB3b3VsZCBiZSBuaWNlIHRvIGZp bmQgYSB3YXkgdG8KbWFrZSB0aGlzIGFsbCB3b3JrLiBQZW9wbGUgc2VuZCBhbGwgc29ydHMg b2YgaWRlbnRpZmllcnMKb3ZlciBSQURJVVMgYW5kIGl0IG1haW5seSB3b3Jrcy4gQmVybmFy ZCBzYWlkIG1heWJlIHRoYXQncwpiZWNhdXNlIHBlb3BsZSBhcmUganVzdCB1c2luZyBpdCBp biBtaW5pbWFsIHdheXMuIEFsYW4gc2F5cwp3ZSBkb24ndCBuZWVkIHRvIGZpeCB0aGUgU0lQ IHByb2JsZW0sIG5lY2Vzc2FyaWx5LiBBdCBsZWFzdCwKd2Ugc2hvdWxkIGdldCB0aGlzIGRv Y3VtZW50IHVwZGF0ZWQuIE1hdXJpY2lvIHNhaWQgaGUncyBnbGFkCnRvIGhhdmUgYSBtYW5h Z2VhYmxlIHNjb3BlIGhlcmU6IGp1c3QgdGhlIE5BSS4KCipSQURJVVMgRXh0ZW5zaW9ucyoK CkluIGdvb2Qgc2hhcGUhCgoqRFRMUyoKCkxvdHMgb2YgZ29vZCB1cGRhdGVzLiBOZXcgaXNz dWUgZnJvbSBOYW5jeSBDYW0tV2luZ2V0LgoKSm9lIFNhbG93ZXkgc2FpZCB0aGF0IGRvaW5n IHNlY3VyZSBhbmQgaW5zZWN1cmUgb24gdGhlCnNhbWUgcG9ydCBtYXkgbm90IGJlIG9wdGlt YWwsIGZyb20gYW4gaW1wbGVtZW50YXRpb24KcGVyc3BlY3RpdmUuIFRoZSBjdXJyZW50IG1l Y2hhbmlzbSBpcyBhIGhhY2suIExldCdzCmp1c3QgdXNlIFVEUCBwb3J0cy4gRmlyZXdhbGwg dHJhdmVyc2FsIGlzbid0IGEgZ29vZApyYXRpb25hbGUgZm9yIHNlbmRpbmcgYWxsIHRyYWZm aWMgb24gb25lIHBvcnQuCgpCZXJuYXJkIEFib2JhIHNhaWQgdGhhdCBEVExTIG11bHRpcGxl eGluZyBpcyB1c2VkIGluCm90aGVyIHBsYWNlcyBhbHNvLiBXZSBzaG91bCBjaGVjayB0byBt YWtlIHN1cmUgdGhhdAp3ZSdyZSByZWx5aW5nIG9uIHNvbWV0aGluZyB0aGF0J3MgbGlrZWx5 IHRvIGJlIGNvbnN0YW50LgoKKlJBRElVUyBBdHRyaWJ1dGVzKgoKQmVybmFyZCBBYm9iYSBy ZXZpZXdlZCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgcmVjZW50bHkuCgpEYW4ncyBjb21tZW50 IDEzMCB3YXMgdGhhdCByZWplY3RpbmcgYmFzZWQgb24gdGhlc2UgYXR0cmlidXRlcwppcyBs aWtlbHkgdG8ganVzdCBjb25mdXNlIHRoZSB1c2VyLiBCZXJuYXJkIGhhcyBhZGRlZCBzb21l CnRleHQgb24gdGhpcyBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4g U2FtCkhhcnRtYW4gc2FpZCB0aGF0IHNvbWUgb2YgdGhlc2UgYXR0cmlidXRlcyBtaWdodCB0 ZWxsIHlvdQp3aGV0aGVyIHlvdSdyZSB0YWxraW5nIHRvIHRoZSByaWdodCBhY2Nlc3MgcG9p bnQuCgpKb2UncyBjb21tZW50IDEzMSBzdWdnZXN0ZWQgYWRkaW5nIHNvbWUgV0xBTi1SZWFz b24tQ29kZXMKdG8gbWF0Y2ggbmV3IG9uZXMgY3JlYXRlZCBieSBJRUVFIDgwMi4gQmVybmFy ZCBzYWlkIHRoYXQKc2luY2UgSUVFRSA4MDIgaXMgbWFpbnRhaW5pbmcgYSByZWdpc3RyeSBm b3IgdGhpcyBsZXQncwpub3QgaGF2ZSBhbiBJQU5BIHJlZ2lzdHJ5LiBKdXN0IHBvaW50IHRv IElFRUUgODAyLgoKRG9yb3RoeSdzIGNvbW1lbnQgMTMzIHJlcXVlc3RlZCB0aGF0IFdMQU4t UmVhc29uLUNvZGUgYmUKYWxsb3dlZCBpbiBBY2NvdW50aW5nLVJlcXVlc3QgcGFja2V0cy4g QmVybmFyZCB3aWxsIGRvIHRoYXQuCkxldCdzIG5vdCBjb3B5IHRoZXNlIGludG8gdGhlIEFj Y3QtVGVybWluYXRlLUNhdXNlLiBQZW9wbGUKY2FuIGp1c3QgbG9vayBpbiB0aGUgV0xBTi1S ZWFzb24tQ29kZS4gUGV0ZXIgRGVhY29uIHNhaWQKbWF5YmUgaXQgbWFrZXMgc2Vuc2UgdG8g c2F5IHRoYXQgeW91IHNob3VsZCBlaXRoZXIgaGF2ZQpBY2N0LVRlcm1pbmF0ZS1DYXVzZSBv ciBXTEFOLVJlYXNvbi1Db2RlIGJ1dCBub3QgYm90aC4KQmVybmFyZCBhZ3JlZWQuCgpXaWxs IGRvIGFub3RoZXIgZXhwZWRpdGVkIFdHTEMuIExpb25lbCBzYWlkIHRoYXQgM0dQUApoYXMg c29tZSBzcGVjcyBiYXNlZCBvbiB0aGlzLiBOZWVkIHRvIGJyaW5nIGl0IHRvIFJGQwpzdGF0 dXMgQVNBUC4gTWF1cmljaW8gc2FpZCB3ZSdsbCBnZXQgdGhpcyBtb3ZpbmcuCgoqRHluYW1p YyBEaXNjb3ZlcnkqCgpTdGVmYW4gV2ludGVyIHByZXNlbnRlZCBvbiB0aGlzLiBSYW4gLTA1 IHRocm91Z2ggV0dMQy4KR290IGxvdHMgb2YgY29tbWVudHMgYWZ0ZXIgdGhhdCBmcm9tIEpp bSBTY2hhYWQuIEFkZHJlc3NlZAptb3N0IG9mIHRoZSBzbWFsbCBpc3N1ZXMgaW4gLTA2LiBX YW50IHRvIGRpc2N1c3MgYmlnIGlzc3Vlcy4KCkRvIHdlIG5lZWQgYSBNVEkgY2VydGlmaWNh dGUgdmFsaWRhdGlvbiBtZWNoYW5pc20/ClByb2JhYmx5IHllcyBidXQgd2hhdCBzaG91bGQg aXQgYmU/IE1heWJlIGEgY2VydGlmaWNhdGUKd2hvc2UgU3ViamVjdCBBbHQgTmFtZSBpcyBh biBvdGhlck5hbWUgdGhhdCBtYXRjaGVzCnRoZSByZWFsbSBvZiB0aGUgTkFJLiBPciB1c2Ug RE5TU0VDLiBlZHVyb2FtIGp1c3QKdXNlcyBhIHBvbGljeSBPSUQgdGhhdCBzYXlzIHRoaXMg aXMgYW4gSWRQLiBETlNTRUMKaXMgY29tcGxleCB0byBpbXBsZW1lbnQuIFRoZSBvbmx5IHBy YWN0aWNhbCB0aGluZwpzZWVtcyB0byBiZSBvdGhlck5hbWUuIFRvIGltcHJvdmUgc2NhbGFi aWxpdHkgd2hlbgpvbmUgc2VydmVyIGhhbmRsZXMgbWFueSByZWFsbXMsIHdlIGNvdWxkIHVz ZSB3aWxkY2FyZHMuCgpKaW0gU2NoYWFkIGFza2VkIHdoaWNoIG90aGVyTmFtZSB0eXBlIHNo b3VsZCBiZSB1c2VkLgpTdGVmYW4gc2FpZCBtYXliZSBOQUlSZWFsbS4gU2FtIHNhaWQgaGUg aW50ZW5kZWQgdG8Kc3VnZ2VzdCByZXVzaW5nIGEgZG9jdW1lbnQgZnJvbSBTdGVmYW4gU2Fu dGVzc29uCmZvciBETlMgU1JWLiBIZSBzZW50IHRoZSBSRkMgbnVtYmVyIHRvIHRoZSBsaXN0 LgpTdGVmYW4gd2lsbCBsb29rIGludG8gdGhhdC4KCkFub3RoZXIgaXNzdWUgaXMgaG93IHRv IGhhbmRsZSB0aGUgaXNzdWUgd2hlcmUKdGhlIHJlc3VsdCBvZiB0aGUgZHluYW1pYyBkaXNj b3ZlcnkgcHJvY2VzcyBpcwp0aGUgc2VydmVyIHRoYXQgYXNrZWQuIElmIGl0IGZvcndhcmRz IHRoZSByZXF1ZXN0CnRvIGl0c2VsZiwgdGhhdCB3aWxsIGNyZWF0ZSBhbiBpbmZpbml0ZSBs b29wLiBCdXQKdGhpcyBpbmRpY2F0ZXMgYSBzZXJpb3VzIGNvbmZpZ3VyYXRpb24gcHJvYmxl bS4KU3RlZmFuIGFyZ3VlcyB0aGF0IHRoZSBiZXN0IHdheSB0byBoYW5kbGUgdGhpcwppcyB0 byBjb25zaWRlciB0aGF0IGR5bmFtaWMgZGlzY292ZXJ5IGhhcyBmYWlsZWQuCgpXaGF0IHNo b3VsZCB3ZSBkbyB3aGVuIGRpc2NvdmVyeSBpcyB0YWtpbmcKdG9vIGxvbmc/IFRoYXQgcHJv YmFibHkgaW5kaWNhdGVzIGEgZmFpbHVyZS4KSmltIGFza2VkIGZvciB0aGUgZG9jdW1lbnQg dG8gc2F5IHdoeSB0aGluZ3MKaGF2ZSBmYWlsZWQuIFN0ZWZhbiB3aWxsIHRha2UgdGhpcyB0 byB0aGUgbGlzdC4KCipTdXBwb3J0IG9mIEZyYWdtZW50YXRpb24qCgpEaWVnbyBMb3BleiBw cmVzZW50ZWQgb24gZHJhZnQtcGVyZXotcmFkZXh0LXJhZGl1cy1mcmFnbWVudGF0aW9uLgpI ZSBhcG9sb2dpemVzIHRoYXQgdGhlIHNsaWRlcyBoZSdzIHVzaW5nIGFyZSBvbGQuCkhlIGhh cyB1cGRhdGVkIHRoZW0gdG8gcmVmbGVjdCB0aGUgbGF0ZXN0IGNvbnNlbnN1cwp0byByZXN1 Ym1pdCB0aGUgZHJhZnQgd2l0aCBuYXJyb3dlZCBzY29wZSBidXQgaGUKY2FuJ3QgZmluZCB0 aG9zZSBuZXcgc2xpZGVzLgoKLTA1IHdhcyBzdWJtaXR0ZWQgZm9yIGNvbnNpZGVyYXRpb24g Zm9yIFdHIGFkb3B0aW9uLgpUaGV5IGhhdmUgYWRkcmVzc2VkIGNvbW1lbnRzIGluIGEgbmV3 IC0wNiBidXQgdGhhdAp2ZXJzaW9uIGhhcyBub3QgYmVlbiBzdWJtaXR0ZWQgeWV0LgoKVGhl IHByb2JsZW0gaXMgaG93IHRvIHByb3ZpZGUgYmlnIFNBTUwgYXNzZXJ0aW9ucwplaXRoZXIg YmVmb3JlIG9yIGFmdGVyIGF1dGhlbnRpY2F0aW9uLiBUaGUgYXV0aG9ycwpoYWQgdGFsa2Vk IGFib3V0IHNlbmRpbmcgYSBVUkwuIFRoZXknbGwgYWRkIHRoaXMKaWRlYSBiYWNrIHRvIHRo ZSBkb2N1bWVudCBmb3IgY29uc2lkZXJhdGlvbi4KClRoZSBjdXJyZW50IHBsYW4gaXMgdG8g b25seSBzdXBwb3J0IGZyYWdtZW50YXRpb24KYmVmb3JlIGFuZCBhZnRlciBSQURJVVMgYXV0 aGVudGljYXRpb24uIFRoZXkgaW52aXRlCmNvbW1lbnRzIG9uIHRoaXMgaWRlYSBvciBhbnl0 aGluZyBlbHNlIGluIHRoZSBkcmFmdC4KClRoZXJlIGlzIGFuIG9wZW4gc291cmNlIGltcGxl bWVudGF0aW9uIGF2YWlsYWJsZS4KClNob3VsZCBoYXZlIGEgbmV3IGRyYWZ0IGluIHRoZSBu ZXh0IGZldyB3ZWVrcy4KCipFeHRlbmRlZCBSZXF1ZXN0KgoKUGV0ZXIgRGVhY29uIHByZXNl bnRlZCBvbiBkcmFmdC1kZWFjb24tcmFkZXh0LWV4dGVuZGVkLXJlcXVlc3QuClRoZXJlIGFy ZSB0d28gcGFydHMgb2YgaGlzIHByb3Bvc2FsOiBGcmFnbWVudC1EYXRhCmFuZCBGcmFnbWVu dC1JbnF1aXJlLiBUaGUgbGF0dGVyIGlzIHVzZWQgdG8gY29uZmlybQp0aGF0IGJvdGggc2lk ZXMgc3VwcG9ydCBwYWNrZXRzIGxvbmdlciB0aGFuIDQwOTYgYnl0ZXMuClNlZSBoaXMgc2xp ZGVzIGZvciBtb3JlIGRldGFpbHMuCgpTYW0gc2FpZCB0aGF0IEFsZXggYW5kIERpZWdvJ3Mg ZHJhZnQgaXMgYmV0dGVyIGlmIHlvdQpuZWVkIHRvIHdvcmsgdGhyb3VnaCBleGlzdGluZyBw cm94aWVzIGJ1dCBpdCBjYW4gcmVzdWx0CmluIG11bHRpLWxheWVyIGZyYWdtZW50YXRpb24u IFVuZm9ydHVuYXRlbHksIHlvdXIgZHJhZnQKaGFzIHNpbWlsYXIgcHJvYmxlbXMuIEkgdGhp bmsgd2Ugc2hvdWxkIHNheSAiVXNlIFRDUApvciBUTFMgd2hlbiB5b3UgY2FuIGJ1dCB1c2Ug QWxleCBhbmQgRGllZ28ncyBkcmFmdCBpZgp5b3UgbmVlZCB0byB3b3JrIHRocm91Z2ggZXhp c3RpbmcgcHJveGllcy4iIFBldGVyIHNhaWQKdGhhdCBUQ1AgaXMgdGhlIGJlc3Qgd2F5IHRv IHNlbmQgYnVsayBkYXRhLiBBbmQgQWxleCdzCmRyYWZ0IHJlcXVpcmVzIGEgcm91bmQgdHJp cCBhY3Jvc3MgYWxsIHByb3hpZXMgZm9yCmVhY2ggZnJhZ21lbnQuIFdlIHJhbiBvdXQgb2Yg dGltZSBhbmQgYWdyZWVkIHRvIHRha2UKdGhlIGRpc2N1c3Npb24gdG8gdGhlIGxpc3QuCgoq RWR1cm9hbSBBcmNoaXRlY3R1cmUgZm9yIE5ldHdvcmsgUm9hbWluZyoKCktsYWFzIFdpZXJl bmdhIHBvaW50ZWQgb3V0IHRoYXQgdGhpcyBkcmFmdCBkZXNjcmliZXMKaG93IGVkdXJvYW0g d29ya3MuIEJ1dCB0aGUgcmVhbCByZWFzb24gdG8gd3JpdGUgaXQKaXMgdG8gZG9jdW1lbnQg dGhlIGxlc3NvbnMgbGVhcm5lZCBpbiBydW5uaW5nIGEKbGFyZ2UgUkFESVVTIHByb3h5IGVu dmlyb25tZW50LiBGb3IgZXhhbXBsZSwgZGVhZApwZWVyIGRpc2NvdmVyeSBtdXN0IGJlIGhh bmRsZWQuIFBsZWFzZSByZWFkIHRoZSBkcmFmdAp0byBsZWFybiBtb3JlIGFib3V0IHRoZXNl IGlzc3VlcyBhbmQgaG93IHRoZXkgaGF2ZQpiZWVuIGhhbmRsZWQgdGhyb3VnaCB0aGluZ3Mg bGlrZSBSQURJVVMvVExTLgpIZSBpbnZpdGVkIHJldmlldyBhbmQgY29tbWVudHMuCgoqRGF0 YSBUeXBlcyoKCkFsYW4gRGVLb2sgcHJlc2VudGVkIG9uIGRyYWZ0LWRla29rLXJhZGV4dC1k YXRhdHlwZXMKUGVvcGxlIGRvbid0IHVzZSBSQURJVVMgZGF0YSB0eXBlcyBjb25zaXN0ZW50 bHkuClRoaXMgZHJhZnQgc3VnZ2VzdHMgY3JlYXRpbmcgYW4gSUFOQSByZWdpc3RyeSBmb3IK UkFESVVTIGRhdGEgdHlwZXMgYW5kIHJlZmVyZW5jaW5nIHRoZW0gaW4gdGhlClJBRElVUyBh dHRyaWJ1dGUgcmVnaXN0cnkuIFRoaXMgd291bGQgbWFrZSB0aGUKc3RhbmRhcmRzIHdvcmxk IG1hdGNoIHdoYXQncyBkb25lIGluIFJBRElVUyBzZXJ2ZXJzLgoKUGV0ZXIgYXNrZWQgaG93 IG9kZCBkYXRhIHR5cGVzIGFyZSBoYW5kbGVkLiBBbGFuCnNhaWQgdGhvc2UgYXJlIGNvbnNp ZGVyZWQgU3RyaW5nLgo= --B_3446135504_3263429-- --B_3446135505_3235857 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIVXwYJKoZIhvcNAQcCoIIVUDCCFUwCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJ/MIIH+TCCBuGgAwIBAgIQW4k5wUL7YloEpOVNCxcNjjANBgkqhkiG9w0BAQUFADCB 9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55MR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQg aHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xhc3MgMiBN YW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENvbGxhYm9y YXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzIwHhcNMTIwOTI2MDAwMDAwWhcNMTQw OTI2MjM1OTU5WjCBnjEgMB4GA1UEChQXSGV3bGV0dC1QYWNrYXJkIENvbXBhbnkxJjAkBgNV BAsUHUVtcGxveW1lbnQgU3RhdHVzIC0gRW1wbG95ZWVzMQ8wDQYDVQQLEwZTL01JTUUxGTAX BgNVBAMTEE1hdXJpY2lvIFNhbmNoZXoxJjAkBgkqhkiG9w0BCQEWF21hdXJpY2lvLnNhbmNo ZXpAaHAuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloXM4DJlquSNxT+X mgHkZBI15A2U8R9K0nRaXPMi7fxOzKJBFyLo3FIYQqhrbSaFFliRgRqx9AFqICnM063baYtG DT7ySQ2u9Ewm54kNxAJBR/+EJVoR+/MEq5u/N9FDd3wB5PnFUdfnJ56jsZNhAhUcILwoWxcv fp3hCI7r92O/y2Qmz0PrVf5d+0y0OiJqH7/Pf/uy8D0IivgEUnyKC+VO9MwUwXWzxA1rF1+z +czuQnuWO8nKUHl3EySJL97mM9fm8MCYQrTIBKKf0XpIpzQ+5QQorSHdJKoWVcMMWLtaJY9J A5DWMjKJA0cjD6cSEV8iwN+V58lnKXFGcRyETwIDAQABo4ID1jCCA9IwOwYDVR0RBDQwMoEX bWF1cmljaW8uc2FuY2hlekBocC5jb22BF21hdXJpY2lvX3NhbmNoZXpAaHAuY29tMAwGA1Ud EwEB/wQCMAAwDgYDVR0PAQH/BAQDAgWgMFkGA1UdHwRSMFAwTqBMoEqGSGh0dHA6Ly9vbnNp dGVjcmwudmVyaXNpZ24uY29tL0hld2xldHRQYWNrYXJkQ29tcGFueVNNSU1FRzIvTGF0ZXN0 Q1JMLmNybDAfBgNVHSMEGDAWgBQifdOkq1esVn+pf0FEGpW8W/ir7jAdBgNVHQ4EFgQUYP/x peEEwA0JEKvMwMyDDurpqCowggEyBggrBgEFBQcBAQSCASQwggEgMCcGCCsGAQUFBzABhhto dHRwOi8vaHAtb2NzcC52ZXJpc2lnbi5jb20wgfQGCCsGAQUFBzACpIHnMIHkMTEwLwYDVQQD EyhDb2xsYWJvcmF0aW9uIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IEcyMTAwLgYDVQQLEydD bGFzcyAyIE9uU2l0ZSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExOjA4BgNVBAsTMVRlcm1z IG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhKGMpMDkxHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21w YW55MIIBPQYDVR0gBIIBNDCCATAwggEsBgtghkgBhvhFAQcXAjCCARswKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwge4GCCsGAQUFBwICMIHhMB4WF0hld2xl dHQtUGFja2FyZCBDb21wYW55MAMCAQIagb5BdXRob3JpdHkgdG8gYmluZCBIUCBkb2VzIG5v dCBjb3JyZXNwb25kIHdpdGggdXNlIG9yIHBvc3Nlc3Npb24gb2YgdGhpcyBjZXJ0aWZpY2F0 ZS4gSXNzdWVkIHRvIGZhY2lsaXRhdGUgY29tbXVuaWNhdGlvbiB3aXRoIEhQLiBWZXJpU2ln bidzIENQUyBpbmNvcnAuIEJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWdu MBYGA1UdJQEB/wQMMAoGCCsGAQUFBwMEMEsGCSqGSIb3DQEJDwQ+MDwwDgYIKoZIhvcNAwIC AgCAMA4GCCqGSIb3DQMCAgIAQDAOBggqhkiG9w0DBAICAIAwCgYIKoZIhvcNAwcwDQYJKoZI hvcNAQEFBQADggEBAHWuCgf6c4Dj8NT1yYJpcuw18irgCh6aSdvVPwUroQwgZYcsCG9OqsVf /2H6zrefDswtfKHDK6jhy2MmL+Ohhdkzl+i9vXJw1ZtnoiRQdhjQs2sAqwI8N/aQ56hogrU9 754lDYZzesp6OabKBj9+t+XVX/lBovsme59hUlwmgOuG4AVfLf0N2CftTwdD5kDCx2aAnlG0 FdYOC/Cdf/tk4c89GogQPwQpNNjw+M6cJX9OWhUGVQ2jI/PuJvlPlP+oyXzAtS3sEejaxBPI h5nQCwseT7DQm2rbCSa1dc0h8ScezllGSZHca/ySZbJcf8vSRbk3tBsPKHbqNZqzEqfERVQw ggZhMIIFSaADAgECAhA7VxO2sCE1+15GdcpsssThMA0GCSqGSIb3DQEBBQUAMIHKMQswCQYD VQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRy dXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1 dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFBy aW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw0wOTA5MDIwMDAwMDBaFw0x OTA5MDEyMzU5NTlaMIH3MQswCQYDVQQGEwJVUzEgMB4GA1UEChMXSGV3bGV0dC1QYWNrYXJk IENvbXBhbnkxHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRl cm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA5MTUwMwYD VQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQTExMC8G A1UEAxMoQ29sbGFib3JhdGlvbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBHMjCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAKdha2jarqqFZAxLy1DLMOhzIY6J/sotb/5GowNu 4yK3coUTI+IPjwb3gUx67QO8Pe0cdVCjz+grzmgBOcVLaFvWo2GbTuZHYlBcs1h7G1IEoysv sjTuEKB3hM2kIvyVlDmHr/wFeWGCaBAyMrKLBBC0tfzOuIhNlLc6/i8YloXWqkkROI4oG5uA 8uGsi86gL+X+6CC6yTWekoai4hhgqT/u63pU8kYBV5hF/0ijf2t/ScGaCkjVHSJGMq+8JjSP fs8pYXgyYIbpPpGQwA9zV7+BBlTFHzoOVBHYQCdC8ONA+Kaimtno9R9FIqStRBHUU5veEc3x PM/Lwz/PnXIDqgsCAwEAAaOCAhIwggIOMBIGA1UdEwEB/wQIMAYBAf8CAQAwcAYDVR0gBGkw ZzBlBgtghkgBhvhFAQcXAjBWMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j b20vY3BzMCoGCCsGAQUFBwICMB4aHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwNAYD VR0fBC0wKzApoCegJYYjaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi1nMy5jcmwwDgYD VR0PAQH/BAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRlTGFiZWw0LTIw NDgtMTQyMB0GA1UdDgQWBBQifdOkq1esVn+pf0FEGpW8W/ir7jCB8AYDVR0jBIHoMIHloYHQ pIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IQYXDLSYxf mEUp57Cm2VBbejANBgkqhkiG9w0BAQUFAAOCAQEAdoqZeNFwhaMs169I9T6WV8Ogu0yXxIYR BUkixQrPwW9OtXymgDUb8uKPHDhicfM8vgAlSh6hEMmWO017rCZoo57pWaN4xkebP44wlsqo 1ig5VcfN7cnrspDklTA+tP3v8afJxuE2bChgVCeet6BxOr2rvNB1ItdT87KcWxV1COpJqzQu U8N8BhR7oPEUiCRtXpFrfmTrYewl1xm1bZk3cAp9CKjDYClVJEwZIgD67DezmWQK+VBk+ofE VAv9CNB/TFwrUpV7inKrSbf7FqkIIbwzvIR1If11NWxDmtioyQsoFnO5/5wLQTSsO17YBYLo boLVLG3RgY7bX5288HU2WDCCBBkwggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEB BQUAMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsT FlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNz IDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHMzAeFw05OTEw MDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsT MShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBD BgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8KDcLVLNtn uS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8QzicT ngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDL HMQjPR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23S rGY/lozghNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOC AQEANCYVPMCNTUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDz mN+k5qQx39McC0bcciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfO RF3UG5CYDR5ClLEALATQdKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6 uuNkSLB/+zYl2pXQ8SQUF90YgGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I5 4bFD4CjPt+dabBNrSbP/4xh8iYszXawz16f52jpVyVgQ+arvWrbPS0vfKjGCAqQwggKgAgEB MIIBDDCB9zELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF0hld2xldHQtUGFja2FyZCBDb21wYW55 MR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExMTAvBgNVBAMTKENv bGxhYm9yYXRpb24gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgRzICEFuJOcFC+2JaBKTlTQsX DY4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg5klUttjPd+NuHRDjo7EtFYZV diniB16soktBEO2fv5MwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUx DxcNMTMwMzE1MDI1MTQ0WjANBgkqhkiG9w0BAQEFAASCAQBKLY/IfJTB0LMf8YJY8P6zqmFy iYKtJ36CikbXZX/BjrVWIJDR/33L2N58jIZyFXVqyIajJPXnYZ+q2cQOP0sIotEE0B7t2QFZ 5VD2VN8Wk0PwEqATCXRtWteq5fvL2tHrbe7d6l7oiMVbpm1byaWcD8pSMs2fgULht+js+aff 8djd2fEpLm3g8+vK1V4LL11tdJhhhuMIMiPqOue3AJd3QzJ68F8TAw01mf5jY3y7V73WOBkg kzbH6JPgbh48eBdu8ymiGFkyjZygRvA6ZxTpT3pEPEF/7Ugv7C/OT0RPrBMQ8tZ6x0+QqLWo gReMRy3wVOou1BzoFwrfi9I8a0uS --B_3446135505_3235857-- From peterd@iea-software.com Thu Mar 14 22:11:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993EE21F91DC for ; Thu, 14 Mar 2013 22:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlbf39Qmn-99 for ; Thu, 14 Mar 2013 22:11:40 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id DDD3821F91B0 for ; Thu, 14 Mar 2013 22:11:39 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 14 Mar 2013 22:11:33 -0700 Date: Thu, 14 Mar 2013 22:11:31 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <5141D39B.1020609@um.es> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D39B.1020609@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 05:11:40 -0000 On Thu, 14 Mar 2013, Alejandro Perez Mendez wrote: >> I recall Alex indicating a desire to provide a generally applicable >> solution. Is this still the case or is his draft intended only to >> address specific needs of specific groups? > initially it was intented to be generic. However, after recent > discussions (please, refer to Alan's mail 08/Mar/13), we come out with Hi Alex, Drilling down from the question of command code coverage do you intend this to be a generally applicable solution or something only to meet the needs of specific groups and specific technologies? If it is only for specific technologies or groups I would just ask to try and clarify this point. For example if I wanted to push a configuration file in an authorization message using one of these newfangled "long attributes" would your draft be something I could use to do that? If it is to be generally applicable albeit with the limited command code coverage then I would assume there would be some parity in consideration of implications to the general audience rather than relying on inside operational knowledge of specific groups to reason about implications. For example we have operators with production use of processing and proxy based on attributes other than User-Name. > the conlusion that fragmentation does not make much sense out of sending > authorization-related data, as it does not seem a good idea to interfere > with authentication flows. Other flows like accounting are alraedy > discussed in the draft. See this text from RFC 6158 section 3.1: "In the case of RADIUS accounting, transporting large amounts of data would require a sequence of Accounting-Request packets. This is a nontrivial change to RADIUS, since RADIUS accounting clients would need to be modified to split the attribute stream across multiple Accounting-Requests, and billing servers would need to be modified to reassemble and interpret the attribute stream." draft-perez-radext-radius-fragmentation-05 section 3.4.1 "There is no need to fragment accounting packets. While the accounting process can send large amounts of data, that data is typically composed of many small updates. That is, there is no demonstrated need to send indivisible blocks of more than 4K of data. The need to send large amounts of data per user session often originates from the need for flow-based accounting. In this use- case, the client may send accounting data for many thousands of flows, where all those flows are tied to one user session. The existing Acct-Multi-Session-Id attribute defined in [RFC2866] Section 5.11 has been proven to work here." With regards to CoA (Section 3.4.2) this scheme is less than ideal due to additional round trips, lack of feedback, lack of ability to implement fallback mechanisms and lack of separation of admission from session management. We have separate systems (Not RADIUS servers) managing aspects of dynamic authorization. regards, Peter From peterd@iea-software.com Thu Mar 14 22:22:30 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 261C111E80D1 for ; Thu, 14 Mar 2013 22:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWifKE3TX0ft for ; Thu, 14 Mar 2013 22:22:29 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8BCAB11E80A3 for ; Thu, 14 Mar 2013 22:22:29 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 14 Mar 2013 22:22:25 -0700 Date: Thu, 14 Mar 2013 22:22:23 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5141D94C.5060709@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 05:22:30 -0000 On Thu, 14 Mar 2013, Alan DeKok wrote: > Peter Deacon wrote: >> I recall Alex indicating a desire to provide a generally applicable >> solution. Is this still the case or is his draft intended only to >> address specific needs of specific groups? > Alejandro's comments apply here. >> If offered as a general solution I would assume there would be parity in >> consideration of possible implications to more than specific groups. > What real-world problem is solved by *generalized* fragmentation > support? Accounting? CoA? Disconnect? What real-world problem do "long attributes" solve if you can't practically make use of them? If I want to push a cert, subscriber configuration file or filter list I have nothing but hacks for options if any of these items exceed 4096 bytes. regards, Peter From peterd@iea-software.com Thu Mar 14 23:59:26 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C2321F90F5 for ; Thu, 14 Mar 2013 23:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UscJHOplmUru for ; Thu, 14 Mar 2013 23:59:25 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id B0ACE21F90ED for ; Thu, 14 Mar 2013 23:59:25 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Thu, 14 Mar 2013 23:59:24 -0700 Date: Thu, 14 Mar 2013 23:59:22 -0700 (Pacific Daylight Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 06:59:26 -0000 On Thu, 14 Mar 2013, Sam Hartman wrote: > 1) Alex's draft supports fragmentation through existing proxies. Alex, > Alan, and I believe this is important to support. > Peter said a while back that he's not opposed to having a way to do this > but support through existing proxies is not his focus because that > support doesn't support arbitrary command codes such as accounting. I am not opposed to Alex's draft in principal assuming constraint of working with existing proxies that can't be upgraded. > 2) Alan, Jim Schaad, Margaret Wasserman and I believe it is strongly > desirable to use large packets to handle fragmentation when using TCP or > TLS. Peter supports this with his fragmentation inquery concept. > 3) Peter would like to support fragmentation over UDP in a manner that > supports all command codes. As a consequence this doesn't work with > existing proxies. This is is fragmentation data concept. Peter believes > the overhead of setting up TCP may be too high for some situations. I don't have a negative opinion of TCP setup time. Prefer UDP since there are no delays or dependencies on flight of other requests. No head of line where RTO effects a queue of requests rather than a single request. Tend to identify with sentiments of RFC 2865 section 2.4. On the other hand Fragment-Data wins no prize for round trip efficiency or congestion avoidance. > 4) I don't support fragmentation data because I believe TCP/TLS is > sufficient of a solution in cases where you are willing to upgrade A problem here is if you don't provide an analogue for UDP with the same capabilities then TCP and UDP universes cannot be bridged. It was intended to be separable so implementors can decide the best approach (TCP and or UDP) for their needs. > equipment. Peter's solution will be much harder to standardize. In Is this because there are two options (TCP and Fragment-Data) or something about Fragment-Data? regards, Peter From gabilm@um.es Fri Mar 15 00:30:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0100221F9099 for ; Fri, 15 Mar 2013 00:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKx1ibd5CDrm for ; Fri, 15 Mar 2013 00:30:25 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8C721F8EF6 for ; Fri, 15 Mar 2013 00:30:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 19AAA5D6F2 for ; Fri, 15 Mar 2013 08:30:20 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id L6nGmdwo4us2 for ; Fri, 15 Mar 2013 08:30:19 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (114.red-80-29-41.adsl.static.ccgg.telefonica.net [80.29.41.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPSA id C41A35D6DF for ; Fri, 15 Mar 2013 08:30:18 +0100 (CET) Message-ID: <5142CE09.4000505@um.es> Date: Fri, 15 Mar 2013 08:30:17 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D39B.1020609@um.es> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 07:30:27 -0000 Hi, El 15/03/13 06:11, Peter Deacon escribió: > On Thu, 14 Mar 2013, Alejandro Perez Mendez wrote: > >>> I recall Alex indicating a desire to provide a generally applicable >>> solution. Is this still the case or is his draft intended only to >>> address specific needs of specific groups? > >> initially it was intented to be generic. However, after recent >> discussions (please, refer to Alan's mail 08/Mar/13), we come out with > > Hi Alex, > > Drilling down from the question of command code coverage do you intend > this to be a generally applicable solution or something only to meet > the needs of specific groups and specific technologies? > > If it is only for specific technologies or groups I would just ask to > try and clarify this point. > I'm really confused. There are three or four last emails where Alan and Alex say it is for Authorization. > For example if I wanted to push a configuration file in an > authorization message using one of these newfangled "long attributes" > would your draft be something I could use to do that? I suppose you want to push configuration data, so yes > > If it is to be generally applicable albeit with the limited command > code coverage then I would assume there would be some parity in > consideration of implications to the general audience rather than > relying on inside operational knowledge of specific groups to reason > about implications. > > For example we have operators with production use of processing and > proxy based on attributes other than User-Name. > >> the conlusion that fragmentation does not make much sense out of >> sending authorization-related data, as it does not seem a good idea >> to interfere with authentication flows. Other flows like accounting >> are alraedy discussed in the draft. > > See this text from RFC 6158 section 3.1: > > "In the case of RADIUS accounting, transporting large amounts of data > would require a sequence of Accounting-Request packets. This is a > nontrivial change to RADIUS, since RADIUS accounting clients would > need to be modified to split the attribute stream across multiple > Accounting-Requests, and billing servers would need to be modified to > reassemble and interpret the attribute stream." > > draft-perez-radext-radius-fragmentation-05 section 3.4.1 > > "There is no need to fragment accounting packets. While the accounting > process can send large amounts of data, that data is typically > composed of many small updates. That is, there is no demonstrated need > to send indivisible blocks of more than 4K of data. The need to send > large amounts of data per user session often originates from the need > for flow-based accounting. In this use- case, the client may send > accounting data for > many thousands of flows, where all those flows are tied to one user > session. The existing Acct-Multi-Session-Id attribute defined in > [RFC2866] Section 5.11 has been proven to work here." > > > With regards to CoA (Section 3.4.2) this scheme is less than ideal due > to additional round trips, lack of feedback, lack of ability to > implement fallback mechanisms and lack of separation of admission from > session management. We have separate systems (Not RADIUS servers) > managing aspects of dynamic authorization. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de IngenierÂ’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From gabilm@um.es Fri Mar 15 00:32:00 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3577E21F90DE for ; Fri, 15 Mar 2013 00:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvmmU2Ef+DF2 for ; Fri, 15 Mar 2013 00:31:59 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9309F21F90B1 for ; Fri, 15 Mar 2013 00:31:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id A29B55399A for ; Fri, 15 Mar 2013 08:31:58 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hPIj9Mh1ARZR for ; Fri, 15 Mar 2013 08:31:58 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (114.red-80-29-41.adsl.static.ccgg.telefonica.net [80.29.41.114]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon11.um.es (Postfix) with ESMTPSA id EFCA8539AA for ; Fri, 15 Mar 2013 08:31:57 +0100 (CET) Message-ID: <5142CE6C.6050904@um.es> Date: Fri, 15 Mar 2013 08:31:56 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.5.1 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 07:32:00 -0000 El 15/03/13 06:22, Peter Deacon escribió: > On Thu, 14 Mar 2013, Alan DeKok wrote: > >> Peter Deacon wrote: >>> I recall Alex indicating a desire to provide a generally applicable >>> solution. Is this still the case or is his draft intended only to >>> address specific needs of specific groups? > >> Alejandro's comments apply here. > >>> If offered as a general solution I would assume there would be >>> parity in >>> consideration of possible implications to more than specific groups. > >> What real-world problem is solved by *generalized* fragmentation >> support? Accounting? CoA? Disconnect? > > What real-world problem do "long attributes" solve if you can't > practically make use of them? Do we have not mention before ABFAB? regards, Gabi. > > If I want to push a cert, subscriber configuration file or filter list > I have nothing but hacks for options if any of these items exceed 4096 > bytes. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de IngenierÂ’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From alex@um.es Fri Mar 15 01:07:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC2C921F8E36 for ; Fri, 15 Mar 2013 01:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fy4G7A3FggwF for ; Fri, 15 Mar 2013 01:07:38 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id C52F621F8E34 for ; Fri, 15 Mar 2013 01:07:37 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id E29B053979 for ; Fri, 15 Mar 2013 09:07:36 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mBBVgl4zGO-X for ; Fri, 15 Mar 2013 09:07:36 +0100 (CET) Received: from [155.54.205.73] (inf-205-73.inf.um.es [155.54.205.73]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 27BD55398A for ; Fri, 15 Mar 2013 09:07:35 +0100 (CET) Message-ID: <5142D6C7.2060509@um.es> Date: Fri, 15 Mar 2013 09:07:35 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D39B.1020609@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 08:07:38 -0000 El 15/03/13 06:11, Peter Deacon escribió: > On Thu, 14 Mar 2013, Alejandro Perez Mendez wrote: > >>> I recall Alex indicating a desire to provide a generally applicable >>> solution. Is this still the case or is his draft intended only to >>> address specific needs of specific groups? > >> initially it was intented to be generic. However, after recent >> discussions (please, refer to Alan's mail 08/Mar/13), we come out with > > Hi Alex, > > Drilling down from the question of command code coverage do you intend > this to be a generally applicable solution or something only to meet > the needs of specific groups and specific technologies? It is intended for the exchange of authorization data. It does not mean that it is constrained to any particular group. Anyone could use it. > > If it is only for specific technologies or groups I would just ask to > try and clarify this point. > > For example if I wanted to push a configuration file in an > authorization message using one of these newfangled "long attributes" > would your draft be something I could use to do that? Sure you could. I don't see anything precluding you to do that. > > If it is to be generally applicable albeit with the limited command > code coverage then I would assume there would be some parity in > consideration of implications to the general audience rather than > relying on inside operational knowledge of specific groups to reason > about implications. > > For example we have operators with production use of processing and > proxy based on attributes other than User-Name. Which attributes? Why is the Proxy assuming they are there? Does the NAS intentionally include them to allow proxying? Do they have other utility on the AS other than being used for proxying? Those are important questions. > >> the conlusion that fragmentation does not make much sense out of >> sending authorization-related data, as it does not seem a good idea >> to interfere with authentication flows. Other flows like accounting >> are alraedy discussed in the draft. > > See this text from RFC 6158 section 3.1: > > "In the case of RADIUS accounting, transporting large amounts of data > would require a sequence of Accounting-Request packets. This is a > nontrivial change to RADIUS, since RADIUS accounting clients would > need to be modified to split the attribute stream across multiple > Accounting-Requests, and billing servers would need to be modified to > reassemble and interpret the attribute stream." > > draft-perez-radext-radius-fragmentation-05 section 3.4.1 > > "There is no need to fragment accounting packets. While the > accounting process can send large amounts of data, that data is > typically composed of many small updates. That is, there is no > demonstrated need to send indivisible blocks of more than 4K of data. > The need to send large amounts of data per user session often > originates from the need for flow-based accounting. In this use- > case, the client may send accounting data for > many thousands of flows, where all those flows are tied to one user > session. The existing Acct-Multi-Session-Id attribute defined in > [RFC2866] Section 5.11 has been proven to work here." > > With regards to CoA (Section 3.4.2) this scheme is less than ideal due > to additional round trips, lack of feedback, lack of ability to > implement fallback mechanisms and lack of separation of admission from > session management. We have separate systems (Not RADIUS servers) > managing aspects of dynamic authorization. > > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Fri Mar 15 07:14:59 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2764E21F86F4 for ; Fri, 15 Mar 2013 07:14:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLIESZmKpp2K for ; Fri, 15 Mar 2013 07:14:53 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id BABE821F86F2 for ; Fri, 15 Mar 2013 07:14:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4F20622410F8; Fri, 15 Mar 2013 15:14:13 +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 DdRMUPSM9JKR; Fri, 15 Mar 2013 15:14:13 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id C69792240E2B; Fri, 15 Mar 2013 15:14:12 +0100 (CET) Message-ID: <51432CB3.1010200@deployingradius.com> Date: Fri, 15 Mar 2013 10:14:11 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 14:14:59 -0000 Peter Deacon wrote: > On Thu, 14 Mar 2013, Alan DeKok wrote: ... >> What real-world problem is solved by *generalized* fragmentation >> support? Accounting? CoA? Disconnect? > > What real-world problem do "long attributes" solve if you can't > practically make use of them? I'll take that as you don't have an answer to my question. > If I want to push a cert, subscriber configuration file or filter list I > have nothing but hacks for options if any of these items exceed 4096 bytes. We could allow RADIUS over TCP to have 64K packets. That would involve minimal changes to existing systems. It's not a "hack" by any stretch of the imagination. Fragmentation is only required for (a) UDP, and (b) authorization. Alan DeKok. From peterd@iea-software.com Fri Mar 15 08:08:49 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC6421F85E7 for ; Fri, 15 Mar 2013 08:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78z3eCgGsryg for ; Fri, 15 Mar 2013 08:08:48 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 938B421F85DB for ; Fri, 15 Mar 2013 08:08:48 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 15 Mar 2013 08:08:47 -0700 Date: Fri, 15 Mar 2013 08:08:46 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <51432CB3.1010200@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 15:08:49 -0000 On Fri, 15 Mar 2013, Alan DeKok wrote: >>> What real-world problem is solved by *generalized* fragmentation >>> support? Accounting? CoA? Disconnect? >> What real-world problem do "long attributes" solve if you can't >> practically make use of them? > I'll take that as you don't have an answer to my question. Any justification I make will be thrown back at me with workarounds. If I want to send a CoA to change a configuration file or filter list I sent during authentication then I should use a workaround described in 3.4.2 which require infrastructure changes and does NOT meet my needs. If I want to send detailed accounting messages in an accounting flow then I should arbitrarily partition a single transaction and come up with some unknown mechanism to understand if the full message has been received. If I want to send certificates during an access request then I should use a URL. I still don't understand why SAML can't be compressed, packed or referenced externally. It might be an operational headache but it can be done. For me it is not about what can be done it is about what is the most effective solution. I don't want a series of workarounds I want one solution. We have a new concept for long attributes allowing vendors to send large blocks of data in the command code of their choosing but there is no serious way to utilize this facility without running into the packet limit. >> If I want to push a cert, subscriber configuration file or filter list I >> have nothing but hacks for options if any of these items exceed 4096 bytes. > We could allow RADIUS over TCP to have 64K packets. That would > involve minimal changes to existing systems. It's not a "hack" by any > stretch of the imagination. And you could use Diameter. Its not a "hack" by any stretch of the imagination. I suspect you'll find more client vendors currently supporting Diameter than RADIUS over TCP. > Fragmentation is only required for (a) UDP, and (b) authorization. >From Alex's presentation even ABFAB has requirements for sending data prior to authentication. "Satisfy ABFAB requirements on supporting chunked data transfer prior to the authentication flow" regards, Peter From alex@um.es Fri Mar 15 09:32:30 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3655421F870F for ; Fri, 15 Mar 2013 09:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.849 X-Spam-Level: X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CHjMbUCHBv+d for ; Fri, 15 Mar 2013 09:32:29 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id F383F21F86E8 for ; Fri, 15 Mar 2013 09:32:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 6D13A53960 for ; Fri, 15 Mar 2013 17:32:24 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a5Uq0-Um8PlK for ; Fri, 15 Mar 2013 17:32:24 +0100 (CET) Received: from [192.168.1.102] (79.109.146.222.dyn.user.ono.com [79.109.146.222]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id 8FC0C53947 for ; Fri, 15 Mar 2013 17:32:23 +0100 (CET) Message-ID: <51434D16.8000401@um.es> Date: Fri, 15 Mar 2013 17:32:22 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:32:30 -0000 El 15/03/13 16:08, Peter Deacon escribió: > On Fri, 15 Mar 2013, Alan DeKok wrote: > >>>> What real-world problem is solved by *generalized* fragmentation >>>> support? Accounting? CoA? Disconnect? > >>> What real-world problem do "long attributes" solve if you can't >>> practically make use of them? > >> I'll take that as you don't have an answer to my question. > > Any justification I make will be thrown back at me with workarounds. > > If I want to send a CoA to change a configuration file or filter list > I sent during authentication then I should use a workaround described > in 3.4.2 which require infrastructure changes and does NOT meet my needs. > > If I want to send detailed accounting messages in an accounting flow > then I should arbitrarily partition a single transaction and come up > with some unknown mechanism to understand if the full message has been > received. > > If I want to send certificates during an access request then I should > use a URL. > > I still don't understand why SAML can't be compressed, packed or > referenced externally. It might be an operational headache but it can > be done. For me it is not about what can be done it is about what is > the most effective solution. I don't want a series of workarounds I > want one solution. > > We have a new concept for long attributes allowing vendors to send > large blocks of data in the command code of their choosing but there > is no serious way to utilize this facility without running into the > packet limit. > >>> If I want to push a cert, subscriber configuration file or filter >>> list I >>> have nothing but hacks for options if any of these items exceed 4096 >>> bytes. > >> We could allow RADIUS over TCP to have 64K packets. That would >> involve minimal changes to existing systems. It's not a "hack" by any >> stretch of the imagination. > > And you could use Diameter. Its not a "hack" by any stretch of the > imagination. I suspect you'll find more client vendors currently > supporting Diameter than RADIUS over TCP. > >> Fragmentation is only required for (a) UDP, and (b) authorization. > > From Alex's presentation even ABFAB has requirements for sending data > prior to authentication. > > "Satisfy ABFAB requirements on supporting chunked data transfer prior > to the authentication flow" > Yes, but those are related to authorization. > regards, > Peter > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From peterd@iea-software.com Fri Mar 15 09:42:41 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D789721F85EE for ; Fri, 15 Mar 2013 09:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuG8JNOL4f2Q for ; Fri, 15 Mar 2013 09:42:40 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 19A0C21F8895 for ; Fri, 15 Mar 2013 09:42:39 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 15 Mar 2013 09:42:38 -0700 Date: Fri, 15 Mar 2013 09:42:36 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alejandro Perez Mendez In-Reply-To: <51434D16.8000401@um.es> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> <51434D16.8000401@um.es> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 16:42:42 -0000 On Fri, 15 Mar 2013, Alejandro Perez Mendez wrote: >> From Alex's presentation even ABFAB has requirements for sending data prior >> to authentication. >> "Satisfy ABFAB requirements on supporting chunked data transfer prior to >> the authentication flow" > Yes, but those are related to authorization. Hi Alex, Thanks, I will wait for the draft. regards, Peter From aland@deployingradius.com Fri Mar 15 10:33:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCD621F84E6 for ; Fri, 15 Mar 2013 10:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IiC+Rv4f6s4M for ; Fri, 15 Mar 2013 10:33:42 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F73D21F8530 for ; Fri, 15 Mar 2013 10:33:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 90A912241133; Fri, 15 Mar 2013 18:33: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 ViXcuANnbTBz; Fri, 15 Mar 2013 18:33:31 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id 6E90C22405C5; Fri, 15 Mar 2013 18:33:31 +0100 (CET) Message-ID: <51435B6A.4060303@deployingradius.com> Date: Fri, 15 Mar 2013 13:33:30 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 17:33:43 -0000 Peter Deacon wrote: > Any justification I make will be thrown back at me with workarounds. Protocol design involves peer review and trade-offs between costs and benefits. There shouldn't be a problem discussing those trade-offs, and responding to peer review. For me, the "workarounds" you talk about are no worse, and in many cases better, than the ones you propose for your draft. > If I want to send a CoA to change a configuration file or filter list I > sent during authentication then I should use a workaround described in > 3.4.2 which require infrastructure changes and does NOT meet my needs. Q: How does CoA handle large filter lists today? A: It doesn't. Q: How do we handle it with your draft? A: With infrastructure changes Q: How do we handle it with Alejandro's draft? A: With infrastructure changes Q: Why does your draft "meet your needs", and Alejandro's draft doesn't? A: You're not saying. > If I want to send detailed accounting messages in an accounting flow > then I should arbitrarily partition a single transaction and come up > with some unknown mechanism to understand if the full message has been > received. Q: How are multiple flows for one session handled today? A: With Acct-Multi-Session-Id. (as has been pointed out repeatedly) Q: How do we handle it with your draft? A: With duplicate functionality, and infrastructure changes. Q: Why are you preferring infrastructure changes to re-using functionality? A: You're not saying. > If I want to send certificates during an access request then I should > use a URL. Q: How is this handled today? A: RFC 5904 defines a similar method, which isn't general. Q: Does sending a URL fulfill the requirements? A: No, as pointed out earlier on this list. Q: Was this point already addressed on the list? A: Yes. Multiple times. Q: Why are you ignoring those explanations? A: You're not saying. > I still don't understand why SAML can't be compressed, packed or > referenced externally. Q: Why are you ignoring previous explanations of this topic? A: You're not saying. > It might be an operational headache but it can > be done. For me it is not about what can be done it is about what is > the most effective solution. I don't want a series of workarounds I > want one solution. Q: Is there a need for a series of workarounds? A: No, as explained repeatedly here, and in the draft. > We have a new concept for long attributes allowing vendors to send large > blocks of data in the command code of their choosing but there is no > serious way to utilize this facility without running into the packet limit. Q: Are the long attributes useful without fragmentation? A: Yes. RFC 5904 (among others) could have used them. > And you could use Diameter. Its not a "hack" by any stretch of the > imagination. I suspect you'll find more client vendors currently > supporting Diameter than RADIUS over TCP. Q: Why is Diameter not acceptable for RADIUS infrastructure? A1: Because it's not supported by vendor NAS equipment. A2: Because proxy maintainers don't have $$ for commercial Diameter solutions. >> Fragmentation is only required for (a) UDP, and (b) authorization. > > From Alex's presentation even ABFAB has requirements for sending data > prior to authentication. Q: Have I said that already? A: Yes, in previous emails to this list. And we're back to the same sticking point. There is a serious communication problem here. I'm explaining my position, and you're not explaining yours. You're also pretending I haven't explained my position. It doesn't give me confidence in the utility of this conversation. Alan DeKok. From peterd@iea-software.com Fri Mar 15 11:21:10 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 887B821F8970 for ; Fri, 15 Mar 2013 11:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id apc0sPH1XjGp for ; Fri, 15 Mar 2013 11:21:08 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF3B21F87AF for ; Fri, 15 Mar 2013 11:21:08 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 15 Mar 2013 11:21:07 -0700 Date: Fri, 15 Mar 2013 11:21:06 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <51435B6A.4060303@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> <51435B6A.4060303@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 18:21:10 -0000 On Fri, 15 Mar 2013, Alan DeKok wrote: > Peter Deacon wrote: >> Any justification I make will be thrown back at me with workarounds. > Protocol design involves peer review and trade-offs between costs and > benefits. There shouldn't be a problem discussing those trade-offs, and > responding to peer review. > For me, the "workarounds" you talk about are no worse, and in many > cases better, than the ones you propose for your draft. >> If I want to send a CoA to change a configuration file or filter list I >> sent during authentication then I should use a workaround described in >> 3.4.2 which require infrastructure changes and does NOT meet my needs. > Q: How does CoA handle large filter lists today? > A: It doesn't. > Q: How do we handle it with your draft? > A: With infrastructure changes By infrastructure change I was referring to the idea of separability of dynamic authorization from RADIUS. The two systems need not overlap. For example RADIUS does not necessarily need visibility into a system dedicated to managing active sessions. Forcing them to overlap means you have to change systems, data flows, operational considerations..etc. With Fragment-Data or TCP or equivalent it is a low level detail handled by what amounts to transport layer, with no implications propagated up the stack. > Q: How do we handle it with Alejandro's draft? > A: With infrastructure changes > Q: Why does your draft "meet your needs", and Alejandro's draft doesn't? > A: You're not saying. I explained my reasons in response to Alex. "With regards to CoA (Section 3.4.2) this scheme is less than ideal due to additional round trips, lack of feedback, lack of ability to implement fallback mechanisms and lack of separation of admission from session management. We have separate systems (Not RADIUS servers) managing aspects of dynamic authorization." >> If I want to send detailed accounting messages in an accounting flow >> then I should arbitrarily partition a single transaction and come up >> with some unknown mechanism to understand if the full message has been >> received. > Q: How are multiple flows for one session handled today? > A: With Acct-Multi-Session-Id. (as has been pointed out repeatedly) I explained why this is insufficient repeatedly. Oddly enough RFC 6158 section 3.1 also echo's some of the same concern. > Q: How do we handle it with your draft? > A: With duplicate functionality, and infrastructure changes. The problem is I have to invent something (sessions) that do not exist. Even if I invented random session id's to make the transport layer happy I still need to invent a way of reasoning on whether the whole transaction is complete. > Q: Why are you preferring infrastructure changes to re-using functionality? > A: You're not saying. Installing a new version that upgrades transport details which have no effect up the stack is vastly different than updating backend infrastructure necessary to deal with this. >> If I want to send certificates during an access request then I should >> use a URL. > Q: How is this handled today? > A: RFC 5904 defines a similar method, which isn't general. > Q: Does sending a URL fulfill the requirements? > A: No, as pointed out earlier on this list. > Q: Was this point already addressed on the list? > A: Yes. Multiple times. > Q: Why are you ignoring those explanations? > A: You're not saying. >> I still don't understand why SAML can't be compressed, packed or >> referenced externally. > Q: Why are you ignoring previous explanations of this topic? > A: You're not saying. I understand the reasons but they do not make this impossible to overcome. It is just operationally inconvenient which is how I would also classify your suggestions. >> It might be an operational headache but it can >> be done. For me it is not about what can be done it is about what is >> the most effective solution. I don't want a series of workarounds I >> want one solution. > Q: Is there a need for a series of workarounds? > A: No, as explained repeatedly here, and in the draft. Not my question. >> We have a new concept for long attributes allowing vendors to send >> large blocks of data in the command code of their choosing but there is >> no serious way to utilize this facility without running into the packet >> limit. > Q: Are the long attributes useful without fragmentation? > A: Yes. RFC 5904 (among others) could have used them. Not my question. >> And you could use Diameter. Its not a "hack" by any stretch of the >> imagination. I suspect you'll find more client vendors currently >> supporting Diameter than RADIUS over TCP. > Q: Why is Diameter not acceptable for RADIUS infrastructure? > A1: Because it's not supported by vendor NAS equipment. Neither is RADIUS/TCP as near as I can tell. > A2: Because proxy maintainers don't have $$ for commercial Diameter > solutions. :) >>> Fragmentation is only required for (a) UDP, and (b) authorization. >> From Alex's presentation even ABFAB has requirements for sending data >> prior to authentication. > Q: Have I said that already? > A: Yes, in previous emails to this list. I get confused easily with the revisions. I was under the impression sending fragmented data to the server was being resurrected in the upcoming draft. I'm sorry for my misunderstanding of this point. regards, Peter From aland@deployingradius.com Fri Mar 15 12:06:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEA3B21F8688 for ; Fri, 15 Mar 2013 12:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFLc1yof5bGp for ; Fri, 15 Mar 2013 12:06:01 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF7E21F86C4 for ; Fri, 15 Mar 2013 12:06:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 8781F22410F8; Fri, 15 Mar 2013 20:06:00 +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 yW+CCgGtP-nL; Fri, 15 Mar 2013 20:06:00 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id AC3E92240E2B; Fri, 15 Mar 2013 20:05:59 +0100 (CET) Message-ID: <51437116.4040100@deployingradius.com> Date: Fri, 15 Mar 2013 15:05:58 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> <51435B6A.4060303@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 19:06:02 -0000 Peter Deacon wrote: > By infrastructure change I was referring to the idea of separability of > dynamic authorization from RADIUS. The two systems need not overlap. Sure. But if it's not RADIUS, then it's not up for discussion here. > For example RADIUS does not necessarily need visibility into a system > dedicated to managing active sessions. But it can use it... as with CoA. > Forcing them to overlap means you have to change systems, data flows, > operational considerations..etc. I'm not sure what you mean. You seem to be saying that because some systems don't do CoA via RADIUS, we should prevent other systems from doing CoA via RADIUS. > "With regards to CoA (Section 3.4.2) this scheme is less than ideal due > to additional round trips, lack of feedback, lack of ability to > implement fallback mechanisms and lack of separation of admission from > session management. We have separate systems (Not RADIUS servers) > managing aspects of dynamic authorization." Any fragmentation method has additional round trips over just using CoA-Request and CoA-Ack. I'm not sure what you mean by "lack of feedback", or "fallback mechanisms". And again, if you have non-RADIUS servers managing dynamic authorization, that is NOT a reason to limit other peoples implementation of RADIUS. This is a problem I've run into time and again. I'm OK with you using non-RADIUS systems. You're not OK with me using RADIUS systems. So you're trying to prevent a solution which works for RADIUS, because you don't want to use it. The only response I have then is "Why are you here?" If you're not using RADIUS, you shouldn't care what RADIUS people do. > I explained why this is insufficient repeatedly. Oddly enough RFC 6158 > section 3.1 also echo's some of the same concern. Well... no. The text in RFC 6158 says that splitting attributes across multiple Accounting-Request packets is wrong and unnecessary. Alejandro's draft points out that we are already doing accounting for multiple flows in RADIUS. There has been no demonstrated need to send more than 4K of *tightly related* data in accounting. RADIUS can do accounting for multiple streams in one session, via widely deployed and standardized methods. In contrast, the Abfab people want to send >4K blocks of data (SAML assertions), which cannot be split up into independent pieces. > The problem is I have to invent something (sessions) that do not exist. > Even if I invented random session id's to make the transport layer happy > I still need to invent a way of reasoning on whether the whole > transaction is complete. i.e. you're saying that existing use of Acct-Multi-Session-Id is impossible, and won't work. Well... reality disagrees with you. > I understand the reasons but they do not make this impossible to > overcome. It is just operationally inconvenient which is how I would > also classify your suggestions. We use RADIUS because it's inconvenient to use IPv4 over carrier pigeon. Operation convenience is absolutely part of protocol design. >>> It might be an operational headache but it can >>> be done. For me it is not about what can be done it is about what is >>> the most effective solution. I don't want a series of workarounds I >>> want one solution. > >> Q: Is there a need for a series of workarounds? >> A: No, as explained repeatedly here, and in the draft. > > Not my question. Then you're attacking a straw man. >> Q: Why is Diameter not acceptable for RADIUS infrastructure? > >> A1: Because it's not supported by vendor NAS equipment. > > Neither is RADIUS/TCP as near as I can tell. Good point. So... which is easier to implement for the NAS vendors? RADIUS over TCP, or Diameter? Alan DeKok. From peterd@iea-software.com Fri Mar 15 12:55:03 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B0D21F89C0 for ; Fri, 15 Mar 2013 12:55:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eo4ujxeF9WOO for ; Fri, 15 Mar 2013 12:55:02 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id B92B021F89AE for ; Fri, 15 Mar 2013 12:55:02 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Fri, 15 Mar 2013 12:55:02 -0700 Date: Fri, 15 Mar 2013 12:55:00 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <51437116.4040100@deployingradius.com> Message-ID: References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> <51435B6A.4060303@deployingradius.com> <51437116.4040100@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 19:55:03 -0000 On Fri, 15 Mar 2013, Alan DeKok wrote: >> For example RADIUS does not necessarily need visibility into a system >> dedicated to managing active sessions. >> Forcing them to overlap means you have to change systems, data flows, >> operational considerations..etc. > I'm not sure what you mean. You seem to be saying that because some > systems don't do CoA via RADIUS, we should prevent other systems from > doing CoA via RADIUS. With 3.4.2 approach RFC 5176 compliant RADIUS clients would be prevented from doing CoA containing large packets using RADIUS protocol without forced synchronization with RADIUS server infrastructure. >> "With regards to CoA (Section 3.4.2) this scheme is less than ideal due >> to additional round trips, lack of feedback, lack of ability to >> implement fallback mechanisms and lack of separation of admission from >> session management. We have separate systems (Not RADIUS servers) >> managing aspects of dynamic authorization." > Any fragmentation method has additional round trips over just using > CoA-Request and CoA-Ack. I'm not sure what you mean by "lack of > feedback", or "fallback mechanisms". And again, if you have non-RADIUS lack of feedback = Error-Cause fallback mechanism = Responding to Error-Cause > servers managing dynamic authorization, that is NOT a reason to limit > other peoples implementation of RADIUS. This is backwards. 3.4.2 would limit dynamic authorization client autonomy. Nothing is preventing RADIUS servers from issuing dynamic authorization requests. regards, Peter From aland@deployingradius.com Fri Mar 15 13:20:23 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F59B21F8A2A for ; Fri, 15 Mar 2013 13:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBVd4jfArIQo for ; Fri, 15 Mar 2013 13:20:23 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD16321F8A27 for ; Fri, 15 Mar 2013 13:20:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A22B722410F8; Fri, 15 Mar 2013 21:19:48 +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 Vz60Usn0vj8Q; Fri, 15 Mar 2013 21:19:47 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177737335.dsl.bell.ca [70.50.216.119]) by power.freeradius.org (Postfix) with ESMTPSA id 624FB2240E2B; Fri, 15 Mar 2013 21:19:47 +0100 (CET) Message-ID: <51438261.6040004@deployingradius.com> Date: Fri, 15 Mar 2013 16:19:45 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <5140867E.9020303@deployingradius.com> <5140B834.4050302@deployingradius.com> <5140C7A4.7030509@deployingradius.com> <5140D3E5.6040008@deployingradius.com> <5141D94C.5060709@deployingradius.com> <51432CB3.1010200@deployingradius.com> <51435B6A.4060303@deployingradius.com> <51437116.4040100@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" Subject: Re: [radext] Fragmentation draft(s) X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2013 20:20:23 -0000 Peter Deacon wrote: > With 3.4.2 approach RFC 5176 compliant RADIUS clients would be prevented > from doing CoA containing large packets using RADIUS protocol without > forced synchronization with RADIUS server infrastructure. Yes. > lack of feedback = Error-Cause > fallback mechanism = Responding to Error-Cause That can be signaled in the fragmentation exchange. >> servers managing dynamic authorization, that is NOT a reason to limit >> other peoples implementation of RADIUS. > > This is backwards. 3.4.2 would limit dynamic authorization client > autonomy. Nothing is preventing RADIUS servers from issuing dynamic > authorization requests. Yes. The draft proposes that dynamic authorization clients and RADIUS servers be tightly coupled. If the initial authentication sets up authorization rules on the NAS, how do those get to the dynamic authorization client (DAC)? If the RADIUS server doesn't communicate with the DAC, then it is *impossible* to make any subsequent authorization changes. i.e. The use case you're concerned about is when the DAC *doesn't* have access to the authorization rules, but *can* change them later. That confuses me. I don't see how that works. Alan DeKok. From diego@tid.es Sat Mar 16 00:56:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E91921F89D3 for ; Sat, 16 Mar 2013 00:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoYBSrLgCgfq for ; Sat, 16 Mar 2013 00:56:41 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 333A021F89AF for ; Sat, 16 Mar 2013 00:56:41 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MJQ008UKU2F7I@tid.hi.inet> for radext@ietf.org; Sat, 16 Mar 2013 08:56:39 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 41.1D.05051.7B524415; Sat, 16 Mar 2013 08:56:39 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MJQ008UEU2F7I@tid.hi.inet> for radext@ietf.org; Sat, 16 Mar 2013 08:56:39 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.165]) by EX10-HTCAS5-MAD.hi.inet ([::1]) with mapi id 14.02.0328.009; Sat, 16 Mar 2013 08:56:39 +0100 Date: Sat, 16 Mar 2013 07:56:38 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: "Sanchez, Mauricio (HP Networking)" Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [radext] preliminary minutes Thread-index: AQHOITg3mUnM+tqQnU2qju65joYi5ZinWhsA X-AuditID: 0a5f4e69-b7fbe6d0000013bb-cd-514425b74ab9 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42Lhivcz1N2u6hJoMH2rnkXLq5lsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKeLG6nbngh2DFvEv2DYx7BLsYOTkkBEwkGs68Y4GwxSQu3FvP 1sXIxSEksI1R4suJQ0wQzk9GiZXLV7JCODMZJTp/PmAHaWERUJU4+/cNE4jNBmQ/av4NFhcW 0JSYd+oOK4jNKWAq0fxwGhPECgWJP+ceA63j4BARcJRY8MURJMwsECPxZP92sFZeAW+JeU9u s0DEzSSuLZnPChEXlPgx+R5YK7OAusSUKbkQJeISza03ocoVJaYtamAEsRkFZCXezYdoFRHQ kri+9QzQeHYg20jiQSLELQISS/acZ4awRSVePv4HVi0ECpJH/1kmMErMQnLDLCQ3zEK4YRaS G2YhuWEBI+sqRrHipKLM9IyS3MTMnHQDI72MTL3MvNSSTYyQaMvcwbh8p8ohRgEORiUeXsvd ToFCrIllxZW5hxglOJiVRHjf6TsHCvGmJFZWpRblxxeV5qQWH2Jk4uCUamBUrclnfCLFF/lC RqTKwX/21JUqausbp089arrqsIHtJsvMud1Zh3RuhWnK2tzxNBD5Gcml/d/tSva7LBXDrvVa XhILp5lPTZvw4sTslZfO6ghP2V5SkDx5Tsr+7WZFeXr/ongSuwLLrGfxvPXR+KWywHPuKw2R 6crNRvOvp6ftL9+XyTljSpMSS3FGoqEWc1FxIgDkC+4xlAIAAA== References: Cc: "radext@ietf.org" , "jouni.nospam@gmail.com" Subject: Re: [radext] preliminary minutes X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 16 Mar 2013 07:56:42 -0000 SGkgTWF1cmljaW8sDQoNCkEgbm90ZSByZWxhdGVkIHRvIHRoZSByZXBvcnQgb2YgdGhlIGRpc2N1 c3Npb24gb24gdGhlIGZyYWdtZW50YXRpb24gZHJhZnQuIFRoZSBub3RlcyBzYXk6DQoNCj4NCj4g VGhlIHByb2JsZW0gaXMgaG93IHRvIHByb3ZpZGUgYmlnIFNBTUwgYXNzZXJ0aW9ucw0KPiBlaXRo ZXIgYmVmb3JlIG9yIGFmdGVyIGF1dGhlbnRpY2F0aW9uLiBUaGUgYXV0aG9ycw0KPiBoYWQgdGFs a2VkIGFib3V0IHNlbmRpbmcgYSBVUkwuIFRoZXknbGwgYWRkIHRoaXMNCj4gaWRlYSBiYWNrIHRv IHRoZSBkb2N1bWVudCBmb3IgY29uc2lkZXJhdGlvbi4NCg0KQWN0dWFsbHksIHVzaW5nIGFuIFVS TCBpcyBub3QgYW4gYWNjZXB0YWJsZSBvcHRpb24uIFRoaXMgd2FzIGRpc2N1c3NlZCB3aGVuIHdv cmsgb24gdGhpcyBkcmFmdCBzdGFydGVkLCBidXQgdGhlIHJlYXNvbnMgZm9yIGl0IG5vdCBiZWlu ZyBhY2NlcHRhYmxlIHdlcmUgbmV2ZXIgaW5jbHVkZWQgaW4gdGhlIHRleHQuIE9uZSBvZiB0aGUg Y29tbWVudHMgZnJvbSB0aG9zZSByZXZpZXdpbmcgdGhlIGRyYWZ0IG1hZGUgY2xlYXIgdGhlIG5l ZWQgdG8gaW5jbHVkZSB0aGVzZSByZWFzb25zIGluIHRoZSBkb2N1bWVudC4gV2Ugd2lsbCB1cGRh dGUgdGhlIGRyYWZ0IGFjY29yZGluZ2x5Lg0KDQpCZSBnb29kZSwNCg0KDQoNCk9uIDE1IE1hciAy MDEzLCBhdCAwMDo0NyAsIFNhbmNoZXosIE1hdXJpY2lvIChIUCBOZXR3b3JraW5nKSB3cm90ZToN Cg0KPg0KPiBBdHRhY2hlZCAgYXJlIHByZWxpbWluYXJ5IG5vdGVzLiBBbnkgY29ycmVjdGlvbnMv YWRkaXRpb25zIHdlbGNvbWUuDQo+DQo+IFRoYW5rcyB0byBTdGV2ZSBILiBmb3Igbm90ZSB0YWtp bmcuDQo+DQo+IC1Kb3VuaSBhbmQgTWF1cmljaW8NCj4NCj4NCj4gPG1pbnV0ZXNfaWV0Zjg2LnR4 dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiByYWRl eHQgbWFpbGluZyBsaXN0DQo+IHJhZGV4dEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3JhZGV4dA0KDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1v cywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QN Cmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvQHRpZC5l cw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJpZ2UgZXhjbHVzaXZhbWVu dGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVzdHJhIHBvbMOtdGljYSBk ZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25pY28gZW4gZWwgZW5sYWNl IHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRlbmRlZCBleGNsdXNpdmVs eSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNlaXZlIGVtYWlsIG9uIHRo ZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93d3cudGlkLmVzL0VTL1BB R0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From hartmans@painless-security.com Mon Mar 18 05:23:29 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CDD21F8D11 for ; Mon, 18 Mar 2013 05:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKzJI81dnUs9 for ; Mon, 18 Mar 2013 05:23:28 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id BB60F21F8D10 for ; Mon, 18 Mar 2013 05:23:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id EB6FD20115; Mon, 18 Mar 2013 08:22:52 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 999FA41CF; Mon, 18 Mar 2013 08:23:23 -0400 (EDT) From: Sam Hartman To: Peter Deacon References: Date: Mon, 18 Mar 2013 08:23:23 -0400 In-Reply-To: (Peter Deacon's message of "Thu, 14 Mar 2013 23:59:22 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 12:23:29 -0000 >>>>> "Peter" == Peter Deacon writes: Peter> I don't have a negative opinion of TCP setup time. Peter> Prefer UDP since there are no delays or dependencies on Peter> flight of other requests. No head of line where RTO effects Peter> a queue of requests rather than a single request. Tend to Peter> identify with sentiments of RFC 2865 section 2.4. If you want this behavior, open multiple TCP requests or propose RADIUS over SCTP. With regard to Alex's draft and the MTU issue, I stand behind my claim that it will tend to involve fragmentation at multiple layers. There's no way to learn the MTU that is currently being proposed. In addition, because the protocol is lock-step, there is a significant penalty to limiting the size of transmitted packets. I think both Peter's fragmentation data approach and Alex's draft will require significant transport review because they both propose protocols with complex MTU/congestion/fragmentation/performance characteristics. In the case of Alex's draft I expect the conclusion will be that there's no better option that works with existing proxies. With respect to Peter's fragmentation data, I believe the analysis is that UDP is the wrong option for what he's trying to do and we have multiple better transport options available. --Sam From stefan.winter@restena.lu Mon Mar 18 06:31:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6156021F8DD9 for ; Mon, 18 Mar 2013 06:31:37 -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=-2.599, J_CHICKENPOX_14=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZw-30WNEpkg for ; Mon, 18 Mar 2013 06:31:36 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9B07B21F8D37 for ; Mon, 18 Mar 2013 06:31:34 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 000D210583 for ; Mon, 18 Mar 2013 14:31:31 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:4a1:fbc5:ccd:ef70]) by smtprelay.restena.lu (Postfix) with ESMTPS id E962F10581 for ; Mon, 18 Mar 2013 14:31:31 +0100 (CET) Message-ID: <5147172F.8090100@restena.lu> Date: Mon, 18 Mar 2013 14:31:27 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> In-Reply-To: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2RVNTOICFWISXJDUOOXUA" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:31:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2RVNTOICFWISXJDUOOXUA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, I have one comment about section 2.8 of the document. Imagine * an end-user device which produces valid UTF-8 NAIs; they are not in NFC form though; in particular, the realm portion is interspersed with U+FEFF characters ("zero-width, non-breaking space", i.e "nothing"). * his EAP server knows about this "strange" representation of the identity and configures the corresponding byte sequence as a realm he is willing to authenticate (i.e. terminate EAP for) As per the draft, this will work nicely; both ends of EAP know each other's representation of the username, and act accordingly. In a AAA routing scenario as described in 2.8, forwarding of the authentication will break unless all intermediate proxies are /also/ provided with the knowledge that this one realm can have the non-normalised appearance in question. This requires either signalling of numerous representations of the same realm throughout all concerned proxies (which doesn't scale well), or will lead to a "sorry, use a more sane representation" DoS. I find both alternatives rather unfortunate. How about the following tweak to the routing decision algorithm in 2.8: Old text: "Intermediate nodes MUST use the "utf8-realm" portion of the NAI without modification to perform this lookup. Comparisons between the NAI as given in a AAA packet, and as provisioned in a logical AAA routing table SHOULD be done as a byte-for-byte equality test." New text: "Intermediate nodes MUST use the "utf8-realm" portion of the NAI to perform this lookup. Comparisons between the NAI as given in a AAA packet, and as provisioned in a logical AAA routing table SHOULD be done as a byte-for-byte equality test of the normalized form (NFC) of the NAI and the normalized form (NFC) of the entry in the AAA routing table." Note that this does not manipulate the realm representation in the packet; it merely changes the logical handling of realms in proxies. Greetings, Stefan Winter On 28.01.2013 16:50, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the RADIUS EXTensions Working Group of th= e IETF. >=20 > Title : The Network Access Identifier > Author(s) : Alan DeKok > Filename : draft-ietf-radext-nai-02.txt > Pages : 22 > Date : 2013-01-28 >=20 > Abstract: > In order to provide inter-domain authentication services, it is > necessary to have a standardized method that domains can use to > identify each others users. This document defines the syntax for th= e > Network Access Identifier (NAI), the user identity submitted by the > client prior to accessing network resources. This document is a > revised version of RFC 4282 [RFC4282], which addresses issues with > international character sets, as well as a number of other > corrections to the previous document. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-radext-nai >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-radext-nai-02 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-02 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=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 ------enig2RVNTOICFWISXJDUOOXUA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFHFzMACgkQ+jm90f8eFWYWswCfe7g2U9S99B3XuBlMZxf6w1df qS4An2/J7J9ZU/QPFdl0hll8zlmyb/PS =cGmM -----END PGP SIGNATURE----- ------enig2RVNTOICFWISXJDUOOXUA-- From aland@deployingradius.com Mon Mar 18 06:34:30 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B1F21F8D82 for ; Mon, 18 Mar 2013 06:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.022 X-Spam-Level: X-Spam-Status: No, score=-102.022 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvuo-zQ-vuyg for ; Mon, 18 Mar 2013 06:34:29 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B117C21F8D79 for ; Mon, 18 Mar 2013 06:34:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id BFB2E2240F50; Mon, 18 Mar 2013 14:33: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 48HkvyJmZMTP; Mon, 18 Mar 2013 14:33:55 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id 1960122409C9; Mon, 18 Mar 2013 14:33:54 +0100 (CET) Message-ID: <514717C6.5020909@deployingradius.com> Date: Mon, 18 Mar 2013 09:33:58 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, Peter Deacon Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:34:30 -0000 I agree with SAM here. Re-implementing TCP over UDP is a horrible idea. The only reason to use it is the limitations of existing proxy networks. Alan DeKok. From hartmans@painless-security.com Mon Mar 18 06:46:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181D121F8DE1 for ; Mon, 18 Mar 2013 06:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w57NuZ-iLh5x for ; Mon, 18 Mar 2013 06:46:38 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8A7CB21F8CEF for ; Mon, 18 Mar 2013 06:46:38 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 59AC920115; Mon, 18 Mar 2013 09:46:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 063B941CF; Mon, 18 Mar 2013 09:46:33 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> Date: Mon, 18 Mar 2013 09:46:32 -0400 In-Reply-To: <5147172F.8090100@restena.lu> (Stefan Winter's message of "Mon, 18 Mar 2013 14:31:27 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 13:46:39 -0000 "Intermediate nodes MUST use the "utf8-realm" portion of the NAI without modification to perform this lookup. Comparisons between the NAI as given in a AAA packet, and as provisioned in a logical AAA routing table SHOULD be done as a byte-for-byte equality test." New text: "Intermediate nodes MUST use the "utf8-realm" portion of the NAI to perform this lookup. Comparisons between the NAI as given in a AAA packet, and as provisioned in a logical AAA routing table SHOULD be doneusing a normalization-insensitive comparison function." Rationale: consistent with what the filesystem community and other parts of the apps community (especially outside the IETF) are doing. One obvious normalization-insensitive comparison function is what you propose: normalize both sides. However, the important thing in terms of implementing this is to be normalization insensitive. We want to encourage people to call into their unicode library, not roll their own. --Sam From peterd@iea-software.com Mon Mar 18 08:37:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15D221F84FD for ; Mon, 18 Mar 2013 08:37:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPEJLSJNtXUG for ; Mon, 18 Mar 2013 08:37:53 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 3D4F421F84F7 for ; Mon, 18 Mar 2013 08:37:53 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 18 Mar 2013 08:37:52 -0700 Date: Mon, 18 Mar 2013 08:37:47 -0700 (Pacific Daylight Time) From: Peter Deacon To: Sam Hartman In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 15:37:54 -0000 On Mon, 18 Mar 2013, Sam Hartman wrote: >>>>>> "Peter" == Peter Deacon writes: > Peter> I don't have a negative opinion of TCP setup time. > Peter> Prefer UDP since there are no delays or dependencies on > Peter> flight of other requests. No head of line where RTO effects > Peter> a queue of requests rather than a single request. Tend to > Peter> identify with sentiments of RFC 2865 section 2.4. > If you want this behavior, open multiple TCP requests or propose RADIUS > over SCTP. I agree these are alternatives. > With regard to Alex's draft and the MTU issue, I stand behind my claim > that it will tend to involve fragmentation at multiple layers. There's > no way to learn the MTU that is currently being proposed. In addition, > because the protocol is lock-step, there is a significant penalty to > limiting the size of transmitted packets. > I think both Peter's fragmentation data approach and Alex's draft will > require significant transport review because they both propose protocols > with complex MTU/congestion/fragmentation/performance characteristics. While I understand why this issue is being raised I don't understand what makes Alex's upcoming draft different than EAP and operational experience applicable to its use. > In the case of Alex's draft I expect the conclusion will be that there's > no better option that works with existing proxies. With respect to > Peter's fragmentation data, I believe the analysis is that UDP is the > wrong option for what he's trying to do and we have multiple better > transport options available. UDP is what is actually being used. I don't have the luxury of ignoring it. regards, Peter From ietf@augustcellars.com Mon Mar 18 09:33:41 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E536E21F854F for ; Mon, 18 Mar 2013 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.999 X-Spam-Level: X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u1cAwWkBBGvJ for ; Mon, 18 Mar 2013 09:33:33 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id EB13D21F8994 for ; Mon, 18 Mar 2013 09:30:27 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id F359E38F2E; Mon, 18 Mar 2013 09:30:21 -0700 (PDT) From: "Jim Schaad" To: "'Stefan Winter'" , References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> In-Reply-To: <5147172F.8090100@restena.lu> Date: Mon, 18 Mar 2013 09:29:48 -0700 Message-ID: <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQL6YW4g7f1S+/CPu7v6J0B2nAJo2gLhVSs4ljwdyBA= Content-Language: en-us Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 16:33:42 -0000 I would not support this change. I would suggest that in this case that the AAA client should be the one = that does the required normalization or mapping into the normal form as part = of its "I know where this is supposed to be going" work. I don't see any reason to impose this onto the middle proxies rather = than the injecting system. Jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On = Behalf > Of Stefan Winter > Sent: Monday, March 18, 2013 6:31 AM > To: radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt >=20 > Hi, >=20 > I have one comment about section 2.8 of the document. >=20 > Imagine > * an end-user device which produces valid UTF-8 NAIs; they are not in = NFC > form though; in particular, the realm portion is interspersed with > U+FEFF characters ("zero-width, non-breaking space", i.e "nothing"). > * his EAP server knows about this "strange" representation of the = identity > and configures the corresponding byte sequence as a realm he is = willing to > authenticate (i.e. terminate EAP for) >=20 > As per the draft, this will work nicely; both ends of EAP know each other's > representation of the username, and act accordingly. >=20 > In a AAA routing scenario as described in 2.8, forwarding of the > authentication will break unless all intermediate proxies are /also/ provided > with the knowledge that this one realm can have the non-normalised > appearance in question. >=20 > This requires either signalling of numerous representations of the = same > realm throughout all concerned proxies (which doesn't scale well), or = will > lead to a "sorry, use a more sane representation" DoS. >=20 > I find both alternatives rather unfortunate. >=20 > How about the following tweak to the routing decision algorithm in = 2.8: >=20 > Old text: >=20 > "Intermediate nodes MUST use the "utf8-realm" portion of the NAI > without modification to perform this lookup. Comparisons between = the > NAI as given in a AAA packet, and as provisioned in a logical AAA > routing table SHOULD be done as a byte-for-byte equality test." >=20 > New text: >=20 > "Intermediate nodes MUST use the "utf8-realm" portion of the NAI > to perform this lookup. Comparisons between the NAI as given in a > AAA packet, and as provisioned in a logical AAA routing table = SHOULD > be done as a byte-for-byte equality test of the normalized form = (NFC) > of the NAI and the normalized form (NFC) of the entry in the AAA > routing table." >=20 > Note that this does not manipulate the realm representation in the = packet; it > merely changes the logical handling of realms in proxies. >=20 > Greetings, >=20 > Stefan Winter >=20 > On 28.01.2013 16:50, internet-drafts@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the RADIUS EXTensions Working Group of = the > IETF. > > > > Title : The Network Access Identifier > > Author(s) : Alan DeKok > > Filename : draft-ietf-radext-nai-02.txt > > Pages : 22 > > Date : 2013-01-28 > > > > Abstract: > > In order to provide inter-domain authentication services, it is > > necessary to have a standardized method that domains can use to > > identify each others users. This document defines the syntax for = the > > Network Access Identifier (NAI), the user identity submitted by = the > > client prior to accessing network resources. This document is a > > revised version of RFC 4282 [RFC4282], which addresses issues = with > > international character sets, as well as a number of other > > corrections to the previous document. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-radext-nai > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-radext-nai-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-radext-nai-02 > > > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > > >=20 >=20 > -- > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et de > la Recherche 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 From hartmans@painless-security.com Mon Mar 18 10:22:36 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729BF21F9007 for ; Mon, 18 Mar 2013 10:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qJYMO0NzC7k for ; Mon, 18 Mar 2013 10:22:17 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A3C3621F8A7E for ; Mon, 18 Mar 2013 10:21:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 4F6AB20115; Mon, 18 Mar 2013 13:21:04 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BC3AA41CF; Mon, 18 Mar 2013 13:21:39 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> Date: Mon, 18 Mar 2013 13:21:39 -0400 In-Reply-To: <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> (Jim Schaad's message of "Mon, 18 Mar 2013 09:29:48 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Stefan Winter' , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 17:22:36 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> I would not support this change. I would suggest that in this Jim> case that the AAA client should be the one that does the Jim> required normalization or mapping into the normal form as part Jim> of its "I know where this is supposed to be going" work. Jim> I don't see any reason to impose this onto the middle proxies Jim> rather than the injecting system. We have a lot of experience in the i18n space that suggests you're much better off normalizing as late as possible. When you normalize at injection you can lose information and collapse things together that a later party may wish you had not. The person using the information is in a much better position to know what options they need to distinguish between and thus is in a better position to know what normalization is appropriate. The major exceptions to this rule are when you're forced to normalize before hashing/encrypting or when you have a legacy system like the DNS. --Sam From aland@deployingradius.com Mon Mar 18 11:47:41 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022E421F8B6D for ; Mon, 18 Mar 2013 11:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.957 X-Spam-Level: X-Spam-Status: No, score=-101.957 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc1sYwFQyGPE for ; Mon, 18 Mar 2013 11:47:31 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6094021F8FED for ; Mon, 18 Mar 2013 11:47:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A4BAD2240F53; Mon, 18 Mar 2013 19:46:59 +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 6S2naiuY3ttz; Mon, 18 Mar 2013 19:46:59 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id D73DA2240F50; Mon, 18 Mar 2013 19:46:58 +0100 (CET) Message-ID: <51476121.1090704@deployingradius.com> Date: Mon, 18 Mar 2013 14:46:57 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:47:41 -0000 Peter Deacon wrote: > While I understand why this issue is being raised I don't understand > what makes Alex's upcoming draft different than EAP and operational > experience applicable to its use. Many uses of EAP are EAPoL. EAP over RADIUS is really using RADIUS as a replacement for Ethernet. As such, any expectations about the transport layer are pretty much zero. It gets a packet from A to B. Mostly. Most of the time. The fragmentation proposals are doing transport of bulk data. As such, they're really competing with TCP. RADIUS is a horrible replacement for TCP. It's only being proposed here (IMHO) as a temporary migration path. Once the proxies do RADIUS over TCP, *and* allow for 64K RADIUS packets, the fragmentation proposals become less relevant. Alan DeKok. From ietf@augustcellars.com Mon Mar 18 11:58:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4775521F904B for ; Mon, 18 Mar 2013 11:58:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV7FphglUwEZ for ; Mon, 18 Mar 2013 11:58:08 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 66DEB21F9083 for ; Mon, 18 Mar 2013 11:57:50 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 0293F2CA43; Mon, 18 Mar 2013 11:57:45 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> In-Reply-To: Date: Mon, 18 Mar 2013 11:57:12 -0700 Message-ID: <091f01ce240a$6705a860$3510f920$@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: AQL6YW4g7f1S+/CPu7v6J0B2nAJo2gLhVSs4ARX2zroCZPYREpYgbqdA Content-Language: en-us Cc: 'Stefan Winter' , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 18:58:17 -0000 Sam, In the descriptive text that Stefan provided, he said that the AAA client was configured with the fact that the names were the same. Thus there is no reason for it not to do the mapping on that information rather than normalization. If we are talking about delaying the normalization, then we are looking at what the AAA client as oppose to the AAA server is looking for in the un-normalized name. AAA proxies are always going to want to see the normalized version of the name. There may be other issues in non-AAA systems, but again we are looking at three different entities, the initial client, any proxies in the middle and the final destination server. We are imposing work on the middle proxies in order to get something that is not necessarily a strong benefit for the final server. Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Monday, March 18, 2013 10:22 AM > To: Jim Schaad > Cc: 'Stefan Winter'; radext@ietf.org > Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt > > >>>>> "Jim" == Jim Schaad writes: > > Jim> I would not support this change. I would suggest that in this > Jim> case that the AAA client should be the one that does the > Jim> required normalization or mapping into the normal form as part > Jim> of its "I know where this is supposed to be going" work. > > Jim> I don't see any reason to impose this onto the middle proxies > Jim> rather than the injecting system. > > We have a lot of experience in the i18n space that suggests you're much > better off normalizing as late as possible. When you normalize at injection > you can lose information and collapse things together that a later party may > wish you had not. The person using the information is in a much better > position to know what options they need to distinguish between and thus is in > a better position to know what normalization is appropriate. > > The major exceptions to this rule are when you're forced to normalize before > hashing/encrypting or when you have a legacy system like the DNS. > > --Sam From hartmans@painless-security.com Mon Mar 18 12:18:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6A821F853C for ; Mon, 18 Mar 2013 12:18: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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9D9yQN+M1u4F for ; Mon, 18 Mar 2013 12:18:11 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 8850321F8548 for ; Mon, 18 Mar 2013 12:18:06 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id AE2592010D; Mon, 18 Mar 2013 15:17:25 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C30DC41CF; Mon, 18 Mar 2013 15:17:58 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> Date: Mon, 18 Mar 2013 15:17:58 -0400 In-Reply-To: <091f01ce240a$6705a860$3510f920$@augustcellars.com> (Jim Schaad's message of "Mon, 18 Mar 2013 11:57:12 -0700") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: 'Stefan Winter' , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:18:20 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Sam, In the descriptive text that Stefan provided, he said that Jim> the AAA client was configured with the fact that the names were Jim> the same. Thus there is no reason for it not to do the mapping Jim> on that information rather than normalization. Jim> If we are talking about delaying the normalization, then we are Jim> looking at what the AAA client as oppose to the AAA server is Jim> looking for in the un-normalized name. AAA proxies are always Jim> going to want to see the normalized version of the name. Yeah, I agree his example is not the best. However, I suspect that both aaa-servers and aaa-proxies will perform better if given the un-normalized name. From peterd@iea-software.com Mon Mar 18 12:31:02 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0215E21F9018 for ; Mon, 18 Mar 2013 12:31: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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m1OWZqEVnbC for ; Mon, 18 Mar 2013 12:30:52 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 0B18C21F9011 for ; Mon, 18 Mar 2013 12:30:44 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 18 Mar 2013 12:30:44 -0700 Date: Mon, 18 Mar 2013 12:30:39 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <51476121.1090704@deployingradius.com> Message-ID: References: <51476121.1090704@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Sam Hartman , radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:31:02 -0000 On Mon, 18 Mar 2013, Alan DeKok wrote: > Peter Deacon wrote: >> While I understand why this issue is being raised I don't understand >> what makes Alex's upcoming draft different than EAP and operational >> experience applicable to its use. > Many uses of EAP are EAPoL. EAP over RADIUS is really using RADIUS as > a replacement for Ethernet. As such, any expectations about the > transport layer are pretty much zero. It gets a packet from A to B. > Mostly. Most of the time. > The fragmentation proposals are doing transport of bulk data. As such, > they're really competing with TCP. What is different about the semantics of transporting EAP over RADIUS compared with Alex's draft? On the surface they both appear to me to have the same properties. If I am missing something any hints/clue would be much appreciated. Both are transported blindly thru proxies without regard for intermediate MTU considerations. Both are lock step, both give the sender full control over amount of data to be transmitted at a time. If they are the same I would just expect operational experience (positive or negative) from widely deployed experience with EAP to also be directly applicable to Alex's draft. > RADIUS is a horrible replacement for TCP. It's only being proposed > here (IMHO) as a temporary migration path. Once the proxies do RADIUS > over TCP, *and* allow for 64K RADIUS packets, the fragmentation > proposals become less relevant. Horrible is an opinion not a reason. You still have to deliver to/from clients which far outnumber server implementations. regards, Peter From aland@deployingradius.com Mon Mar 18 12:35:28 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBF121F90AD for ; Mon, 18 Mar 2013 12:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.906 X-Spam-Level: X-Spam-Status: No, score=-101.906 tagged_above=-999 required=5 tests=[AWL=-0.462, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgCAhKMFaXiN for ; Mon, 18 Mar 2013 12:35:19 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B113221F8B37 for ; Mon, 18 Mar 2013 12:34:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A9EAE224037F; Mon, 18 Mar 2013 20:34:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFoTJbk+jb7P; Mon, 18 Mar 2013 20:34:06 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id D1B65224033D; Mon, 18 Mar 2013 20:34:05 +0100 (CET) Message-ID: <51476C2C.5070000@deployingradius.com> Date: Mon, 18 Mar 2013 15:34:04 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> In-Reply-To: <091f01ce240a$6705a860$3510f920$@augustcellars.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Sam Hartman' , radext@ietf.org, 'Stefan Winter' Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:35:28 -0000 I agree with Jim here. As I write RADIUS servers instead of supplicants, I think the normalization work should be pushed off onto supplicants. The document already says that realm names MUST be registrable as names within DNS. DNS requires NFC. Therefore, realms are NFC. Any supplicant injecting non-NFC names is wrong. re: Sam's comments on i18n space, I'm not sure it's relevant to have the home server normalize the realm name. I'm curious to know what information is in the non-NFC form which is needed by the home server. The home server knows who it's users are, and can just use names, without a realm portion. If it gets a realm, it verifies that it owns the realm, but that verification is largely site-specific. e.g. EXAMPLE\foo versus foo@example.com. So the main use for realms is proxies. They don't care about the *content* of the realm. They just want to use it as an opaque token. Realm A goes to RADIUS server for Realm A, etc. Alan DeKok. From aland@deployingradius.com Mon Mar 18 12:38:23 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B38A621F8B48 for ; Mon, 18 Mar 2013 12:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.864 X-Spam-Level: X-Spam-Status: No, score=-101.864 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXlkKhW3qjrP for ; Mon, 18 Mar 2013 12:38:15 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9B37721F8AC2 for ; Mon, 18 Mar 2013 12:38:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 4C7A22240F53; Mon, 18 Mar 2013 20:37:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5VDm+atlzL7; Mon, 18 Mar 2013 20:37:44 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id AAD63224037F; Mon, 18 Mar 2013 20:37:43 +0100 (CET) Message-ID: <51476D06.80202@deployingradius.com> Date: Mon, 18 Mar 2013 15:37:42 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <51476121.1090704@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 19:38:23 -0000 Peter Deacon wrote: > What is different about the semantics of transporting EAP over RADIUS > compared with Alex's draft? I explained that in my previous message. > Horrible is an opinion not a reason. You still have to deliver to/from > clients which far outnumber server implementations. The use-cases for abfab are largely dealing with RADIUS servers. Access points likely won't be sending SAML assertions. If the systems need to send bulk data over RADIUS, they will upgrade. For now, upgrading RADIUS servers is easier than upgrading clients. It's also a first step. There's no point in upgrading clients until the RADIUS servers support TCP. Alan DeKok. From peterd@iea-software.com Mon Mar 18 13:27:56 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D0021F9138 for ; Mon, 18 Mar 2013 13:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+fnrSJT+aSR for ; Mon, 18 Mar 2013 13:27:55 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id A25E021F9135 for ; Mon, 18 Mar 2013 13:27:55 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 18 Mar 2013 13:27:55 -0700 Date: Mon, 18 Mar 2013 13:27:50 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <51476D06.80202@deployingradius.com> Message-ID: References: <51476121.1090704@deployingradius.com> <51476D06.80202@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Sam Hartman , radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 20:27:56 -0000 On Mon, 18 Mar 2013, Alan DeKok wrote: > Peter Deacon wrote: >> What is different about the semantics of transporting EAP over RADIUS >> compared with Alex's draft? > I explained that in my previous message. I reread your message and did not see the relevance. The client retransmits in lock step the same as Alex's. Ethernet properties are irrelevant. What is the average expected size of SAML data to be transported? >From draft-perez-radext-radius-fragmentation-05 Section 5. "It is RECOMMENDED that the limits be set to a few tens of kilobytes" Transporting >=2048 bit public keys and certificate chains over EAP adding all the round trips to negotiate methods and handshake seems to be a pretty good approximation of handling data both in terms of maxing out MTU and dealing with about the same number of round trips. I'm not saying this is good or bad I'm just trying to understand the major differences that prevent EAP being used to reason about the properties of Alex's draft. regards, Peter From hartmans@painless-security.com Mon Mar 18 14:52:17 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC1B21F8994 for ; Mon, 18 Mar 2013 14:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzbaXEjDgzpn for ; Mon, 18 Mar 2013 14:52:05 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id E5E2521F8A04 for ; Mon, 18 Mar 2013 14:52:03 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id C57A52010D; Mon, 18 Mar 2013 17:51:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 91F6341CF; Mon, 18 Mar 2013 17:52:02 -0400 (EDT) From: Sam Hartman To: Pete Resnick , Barry Leiba Date: Mon, 18 Mar 2013 17:52:02 -0400 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: radext@ietf.org Subject: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:52:17 -0000 --=-=-= Dear Pete and Barry: I think radext could use some help on the i18n front; I'm fairly convinced that a decision we seem to be making is the wrong approach, but I don't have quite enough clue or mental bandwidth to argue it. Briefly, we're debating where normalization of network access identifiers should happen. I'm reasonably sure that this is a case where normalization should happen as close to use as possible. The current thinking seems to be that normalization should happen on the client and I think many of the reasons that have made that approach problematic for other architectures apply here. Any chance you could get someone to review this draft and take another look at the issue? --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Mon, 18 Mar 2013 15:33:31 -0400 X-Sieve: CMU Sieve 2.2 Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by mail.painless-security.com (Postfix) with ESMTP id 5E1712010D for ; Mon, 18 Mar 2013 15:33:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A9EAE224037F; Mon, 18 Mar 2013 20:34:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nFoTJbk+jb7P; Mon, 18 Mar 2013 20:34:06 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id D1B65224033D; Mon, 18 Mar 2013 20:34:05 +0100 (CET) Message-ID: <51476C2C.5070000@deployingradius.com> Date: Mon, 18 Mar 2013 15:34:04 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) To: Jim Schaad CC: 'Sam Hartman' , 'Stefan Winter' , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> In-Reply-To: <091f01ce240a$6705a860$3510f920$@augustcellars.com> X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Mar 18 15:33:31 2013 X-DSPAM-Confidence: 0.5420 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,51476c0b222709781317545 X-DSPAM-Factors: 27, From*Alan DeKok , 0.00010, References*mit.edu>, 0.00014, Received*(amavisd, 0.00030, Received*10024), 0.00030, X-Virus-Scanned*at, 0.00030, Received*new, 0.00030, X-Virus-Scanned*amavisd, 0.00030, X-Virus-Scanned*new, 0.00030, Received*Mar, 0.99000, Received*Mar, 0.99000, MUST, 0.99000, Received*2013, 0.99000, Received*2013, 0.99000, owns, 0.99000, Date*2013, 0.99000, versus, 0.99000, Received*security.com>, 0.02338, Received*painless, 0.02338, Received*[127.0.0.1]), 0.02605, Received*[127.0.0.1]), 0.02605, Received*([127.0.0.1]), 0.05082, content, 0.94708, Received*(localhost, 0.05624, Received*port, 0.07037, Date*Mar, 0.92173, Content-Transfer-Encoding*7bit, 0.91717, Subject*Re, 0.09415 MIME-Version: 1.0 I agree with Jim here. As I write RADIUS servers instead of supplicants, I think the normalization work should be pushed off onto supplicants. The document already says that realm names MUST be registrable as names within DNS. DNS requires NFC. Therefore, realms are NFC. Any supplicant injecting non-NFC names is wrong. re: Sam's comments on i18n space, I'm not sure it's relevant to have the home server normalize the realm name. I'm curious to know what information is in the non-NFC form which is needed by the home server. The home server knows who it's users are, and can just use names, without a realm portion. If it gets a realm, it verifies that it owns the realm, but that verification is largely site-specific. e.g. EXAMPLE\foo versus foo@example.com. So the main use for realms is proxies. They don't care about the *content* of the realm. They just want to use it as an opaque token. Realm A goes to RADIUS server for Realm A, etc. Alan DeKok. --=-=-=-- From bernard_aboba@hotmail.com Mon Mar 18 14:58:31 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E8E21F8A7E for ; Mon, 18 Mar 2013 14:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7MJQFMPnSRQ for ; Mon, 18 Mar 2013 14:58:31 -0700 (PDT) Received: from blu0-omc1-s1.blu0.hotmail.com (blu0-omc1-s1.blu0.hotmail.com [65.55.116.12]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1021F8A56 for ; Mon, 18 Mar 2013 14:58:31 -0700 (PDT) Received: from BLU401-EAS273 ([65.55.116.8]) by blu0-omc1-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 14:58:30 -0700 X-EIP: [y3b1WRXWT98+5rbJYcqIjgkP6kIL+r5G] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Mon, 18 Mar 2013 17:58:29 -0400 To: Sam Hartman X-OriginalArrivalTime: 18 Mar 2013 21:58:30.0927 (UTC) FILETIME=[BA5A79F0:01CE2423] Cc: "radext@ietf.org" , Pete Resnick , Barry Leiba Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 21:58:31 -0000 I agree that the NAI draft is broken, if only because "the client" can mean a= nything from a PPP peer to an HTTP client or SIP UA. Attempting to write a s= ingle ABNF covering HTTP and SIP URIs, as well as EAP, PPP, L2TP, IKEv2, etc= . let alone to insist that RADIUS proxies have no role in normalization, see= ms to be contradicted by other RADEXT drafts as well as by experience and co= mmon sense. On Mar 18, 2013, at 17:52, "Sam Hartman" wr= ote: >=20 > Dear Pete and Barry: >=20 > I think radext could use some help on the i18n front; I'm fairly > convinced that a decision we seem to be making is the wrong approach, > but I don't have quite enough clue or mental bandwidth to argue it. > Briefly, we're debating where normalization of network access > identifiers should happen. > I'm reasonably sure that this is a case where normalization should > happen as close to use as possible. > The current thinking seems to be that normalization should happen on the > client and I think many of the reasons that have made that approach > problematic for other architectures apply here. >=20 > Any chance you could get someone to review this draft and take another > look at the issue? >=20 >=20 > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From aland@deployingradius.com Mon Mar 18 15:14:20 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4FB21F86D3 for ; Mon, 18 Mar 2013 15:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.829 X-Spam-Level: X-Spam-Status: No, score=-101.829 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j45wmo60YjKq for ; Mon, 18 Mar 2013 15:14:19 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id D57F021F86CE for ; Mon, 18 Mar 2013 15:14:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id D40812240F53; Mon, 18 Mar 2013 23:13:36 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sk+HKu1ZjJaT; Mon, 18 Mar 2013 23:13:36 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id E9E172240F50; Mon, 18 Mar 2013 23:13:35 +0100 (CET) Message-ID: <5147918E.2000602@deployingradius.com> Date: Mon, 18 Mar 2013 18:13:34 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <51476121.1090704@deployingradius.com> <51476D06.80202@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , radext@ietf.org Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:14:20 -0000 Peter Deacon wrote: > I reread your message and did not see the relevance. The client > retransmits in lock step the same as Alex's. Ethernet properties are > irrelevant. I explained why they're not. > I'm not saying this is good or bad I'm just trying to understand the > major differences that prevent EAP being used to reason about the > properties of Alex's draft. I did *not* say anyone was prevented from using EAP like that. *I* used EAP like that. Can you explain why you keep straw-manning me? Supplicants *can't* do TCP, because they have no net access. So any EAP transport is *allowed* to be horrible, because it's no worse than Ethernet. RADIUS servers *can* do TCP, so horrible transports are use only when there is no alternative. I don't *care* that Alex's draft is no worse (or better) than EAP. A better alternative exists: TCP. Therefore we should use it. The only reason to *not* use TCP is implementation delays. Alan DeKok. From aland@deployingradius.com Mon Mar 18 15:16:39 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9947721F86D3 for ; Mon, 18 Mar 2013 15:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=-0.355, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M85Uo9kGDFvv for ; Mon, 18 Mar 2013 15:16:39 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 098CC21F86CE for ; Mon, 18 Mar 2013 15:16:39 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id B9B672240F53; Mon, 18 Mar 2013 23:16:38 +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 3-QOTAb7N8Do; Mon, 18 Mar 2013 23:16:38 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id E02D7224037F; Mon, 18 Mar 2013 23:16:37 +0100 (CET) Message-ID: <51479244.4040004@deployingradius.com> Date: Mon, 18 Mar 2013 18:16:36 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Pete Resnick , Barry Leiba , "radext@ietf.org" Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:16:39 -0000 Bernard Aboba wrote: > I agree that the NAI draft is broken, if only because "the client" can mean anything from a PPP peer to an HTTP client or SIP UA. Attempting to write a single ABNF covering HTTP and SIP URIs, as well as EAP, PPP, L2TP, IKEv2, etc. let alone to insist that RADIUS proxies have no role in normalization, seems to be contradicted by other RADEXT drafts as well as by experience and common sense. What other drafts require RADIUS proxies to normalize usernames / realms? What else can we do to replace RFC 4282, which is arguably *worse* than the current draft? Alan DeKok. From ietf@augustcellars.com Mon Mar 18 15:18:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 091EC21F86D6 for ; Mon, 18 Mar 2013 15:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EuXKzI7dNJ4i for ; Mon, 18 Mar 2013 15:18:20 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id BF83821F86D3 for ; Mon, 18 Mar 2013 15:18:20 -0700 (PDT) Received: from Philemon (50-39-222-11.bvtn.or.frontiernet.net [50.39.222.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 53B4C38F0F; Mon, 18 Mar 2013 15:18:20 -0700 (PDT) From: "Jim Schaad" To: "'Bernard Aboba'" , "'Sam Hartman'" References: In-Reply-To: Date: Mon, 18 Mar 2013 15:17:46 -0700 Message-ID: <093501ce2426$6bf8aea0$43ea0be0$@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: AQKDqdkZcLEIL1UUu7zAO+HZFkBbfQGYp4ZclzQzzDA= Content-Language: en-us Cc: radext@ietf.org, 'Pete Resnick' , 'Barry Leiba' Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:18:22 -0000 Bernard, Just so I can follow the argument. Which RADEXT drafts are you referring to? Jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Bernard Aboba > Sent: Monday, March 18, 2013 2:58 PM > To: Sam Hartman > Cc: radext@ietf.org; Pete Resnick; Barry Leiba > Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt > > I agree that the NAI draft is broken, if only because "the client" can mean > anything from a PPP peer to an HTTP client or SIP UA. Attempting to write a > single ABNF covering HTTP and SIP URIs, as well as EAP, PPP, L2TP, IKEv2, > etc. let alone to insist that RADIUS proxies have no role in normalization, > seems to be contradicted by other RADEXT drafts as well as by experience > and common sense. > > On Mar 18, 2013, at 17:52, "Sam Hartman" security.com> wrote: > > > > > Dear Pete and Barry: > > > > I think radext could use some help on the i18n front; I'm fairly > > convinced that a decision we seem to be making is the wrong approach, > > but I don't have quite enough clue or mental bandwidth to argue it. > > Briefly, we're debating where normalization of network access > > identifiers should happen. > > I'm reasonably sure that this is a case where normalization should > > happen as close to use as possible. > > The current thinking seems to be that normalization should happen on > > the client and I think many of the reasons that have made that > > approach problematic for other architectures apply here. > > > > Any chance you could get someone to review this draft and take another > > look at the issue? > > > > > > > > _______________________________________________ > > 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 bernard_aboba@hotmail.com Mon Mar 18 15:40:40 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5406421F8A93 for ; Mon, 18 Mar 2013 15:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-QhP1mesI3f for ; Mon, 18 Mar 2013 15:40:39 -0700 (PDT) Received: from blu0-omc1-s25.blu0.hotmail.com (blu0-omc1-s25.blu0.hotmail.com [65.55.116.36]) by ietfa.amsl.com (Postfix) with ESMTP id 92D0921F8A52 for ; Mon, 18 Mar 2013 15:40:39 -0700 (PDT) Received: from BLU404-EAS82 ([65.55.116.9]) by blu0-omc1-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 15:40:39 -0700 X-EIP: [WBhUrwxZBNpHxyC5GuBI5cNt3jb7EeV4] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <51479244.4040004@deployingradius.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <51479244.4040004@deployingradius.com> Date: Mon, 18 Mar 2013 18:40:37 -0400 To: Alan DeKok X-OriginalArrivalTime: 18 Mar 2013 22:40:39.0222 (UTC) FILETIME=[9D55AD60:01CE2429] Cc: Sam Hartman , Pete Resnick , Barry Leiba , "radext@ietf.org" Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:40:40 -0000 On Mar 18, 2013, at 18:16, "Alan DeKok" wrote: >=20 > What other drafts require RADIUS proxies to normalize usernames / realms?= [BA] The Dynamic Discovery draft recognizes that realms won't necessarily ap= pear in the User-Name attribute in normalized form.=20 >=20 > What else can we do to replace RFC 4282, which is arguably *worse* > than the current draft? [BA] Focus only on the scope that the Charter outlines for the document: the= Network Access Identifier, which is a term that applies to Network Access a= lone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc. The NAI draft sh= ould not talk about the contents of the RADIUS User-Name attribute -- that s= hould be handled by a separate document.=20 >=20 > Alan DeKok. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Mon Mar 18 15:44:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C74321F8B3A for ; Mon, 18 Mar 2013 15:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjVSaFec7U9m for ; Mon, 18 Mar 2013 15:44:52 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6D25521F8B37 for ; Mon, 18 Mar 2013 15:44:52 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 8AE512010D; Mon, 18 Mar 2013 18:44:14 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6F62241CF; Mon, 18 Mar 2013 18:44:50 -0400 (EDT) From: Sam Hartman To: Pete Resnick References: <514795BD.10001@qti.qualcomm.com> Date: Mon, 18 Mar 2013 18:44:50 -0400 In-Reply-To: <514795BD.10001@qti.qualcomm.com> (Pete Resnick's message of "Mon, 18 Mar 2013 16:31:25 -0600") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org, Barry Leiba Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:44:53 -0000 >>>>> "Pete" == Pete Resnick writes: Pete> Are these identifiers (usernames, realm names) things that Pete> users actually type in (i.e., user interface elements) or are Pete> they protocol elements? The answer will very much depend on Pete> which sort of thing they are. (And I have a sneaking suspicion Pete> that you're going to tell me that they are both, which is Pete> going to make your job much more difficult.) So, at what layer Pete> are these things used? They're both. Their use is very similar to Kerberos principals or jabber jids. (Their format and the legacy issues are of course unique and special in the worst possible way) They can be typed in by users; for example on Android when you go configure an EAP wireless network you type in a string that acts as a NAI. Or they can be provisioned. For example, you can provision them centrally using Windows group policy. Provisioning is more recommended that typing in but both happen. From hartmans@painless-security.com Mon Mar 18 16:02:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC8221F8B8D for ; Mon, 18 Mar 2013 16:02:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HDR6wJX1LDON for ; Mon, 18 Mar 2013 16:02:18 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 09A1C21F8B6E for ; Mon, 18 Mar 2013 16:02:18 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2C7FC2010D; Mon, 18 Mar 2013 19:01:41 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F299741CF; Mon, 18 Mar 2013 19:02:16 -0400 (EDT) From: Sam Hartman To: Bernard Aboba References: <51479244.4040004@deployingradius.com> Date: Mon, 18 Mar 2013 19:02:16 -0400 In-Reply-To: (Bernard Aboba's message of "Mon, 18 Mar 2013 18:40:37 -0400") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , Pete Resnick , Barry Leiba , Alan DeKok Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:02:18 -0000 >>>>> "Bernard" == Bernard Aboba writes: Bernard> [BA] Focus only on the scope that the Charter outlines for Bernard> the document: the Network Access Identifier, which is a Bernard> term that applies to Network Access alone. This includes Bernard> EAP, PPP, etc. but NOT HTTP, SIP, etc. The NAI draft Bernard> should not talk about the contents of the RADIUS User-Name Bernard> attribute -- that should be handled by a separate document. Bernard, unfortunately, some of us really need to cover non-network-access use cases of EAP and we'd really like to see the same treatment of network access use cases of EAP. I'd prefer to keep all EAP use cases in this draft. From ietf@augustcellars.com Mon Mar 18 16:16:11 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC0221F8C35 for ; Mon, 18 Mar 2013 16:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK-pgh3GRh-W for ; Mon, 18 Mar 2013 16:16:10 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id CD05C21F8C2A for ; Mon, 18 Mar 2013 16:16:10 -0700 (PDT) Received: from Philemon (50-39-222-11.bvtn.or.frontiernet.net [50.39.222.11]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 02C072CA0B; Mon, 18 Mar 2013 16:16:09 -0700 (PDT) From: "Jim Schaad" To: "'Bernard Aboba'" , "'Alan DeKok'" References: <51479244.4040004@deployingradius.com> In-Reply-To: Date: Mon, 18 Mar 2013 16:15:36 -0700 Message-ID: <095301ce242e$801f3ef0$805dbcd0$@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: AQKDqdkZcLEIL1UUu7zAO+HZFkBbfQGYp4ZcAifLyRYBrpNI3JcVkIlQ Content-Language: en-us Cc: 'Sam Hartman' , 'Pete Resnick' , 'Barry Leiba' , radext@ietf.org Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:16:11 -0000 > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf > Of Bernard Aboba > Sent: Monday, March 18, 2013 3:41 PM > To: Alan DeKok > Cc: Sam Hartman; Pete Resnick; Barry Leiba; radext@ietf.org > Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt > > > > On Mar 18, 2013, at 18:16, "Alan DeKok" > wrote: > > > > > What other drafts require RADIUS proxies to normalize usernames / > realms? > > [BA] The Dynamic Discovery draft recognizes that realms won't necessarily > appear in the User-Name attribute in normalized form. The Dynamic Discovery draft recognizes the following: 1. What is in the UserName field may not be an NAI 2. What is in the UserName field realm portion needs to somehow be mapped to a DNS name (much easier if already normalized). Note that it does not talk about the process of normalization in any way. It talks about how to map from a UTF-8 realm name to a DNS name. Jim > > > > > What else can we do to replace RFC 4282, which is arguably *worse* > > than the current draft? > > [BA] Focus only on the scope that the Charter outlines for the document: the > Network Access Identifier, which is a term that applies to Network Access > alone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc. The NAI draft > should not talk about the contents of the RADIUS User-Name attribute -- > that should be handled by a separate document. > > > > > > Alan DeKok. > > _______________________________________________ > > radext mailing list > > radext@ietf.org > > https://www.ietf.org/mailman/listinfo/radext > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From bernard_aboba@hotmail.com Mon Mar 18 16:20:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB04B21F8AD1 for ; Mon, 18 Mar 2013 16:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NvnmFjsoXZM for ; Mon, 18 Mar 2013 16:20:13 -0700 (PDT) Received: from blu0-omc2-s30.blu0.hotmail.com (blu0-omc2-s30.blu0.hotmail.com [65.55.111.105]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFE121F8AD5 for ; Mon, 18 Mar 2013 16:20:13 -0700 (PDT) Received: from BLU403-EAS1 ([65.55.111.72]) by blu0-omc2-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 16:20:13 -0700 X-EIP: [vsS4gV8IIyfaVmsTkAIqK8XchMdjlkZX] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <51479244.4040004@deployingradius.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: Date: Mon, 18 Mar 2013 19:20:11 -0400 To: Sam Hartman X-OriginalArrivalTime: 18 Mar 2013 23:20:13.0051 (UTC) FILETIME=[243F3CB0:01CE242F] Cc: "radext@ietf.org" , Pete Resnick , Barry Leiba , Alan DeKok Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:20:14 -0000 EAP use cases are fine. On Mar 18, 2013, at 7:02 PM, "Sam Hartman" w= rote: >>>>>> "Bernard" =3D=3D Bernard Aboba writes: >=20 >=20 > Bernard> [BA] Focus only on the scope that the Charter outlines for > Bernard> the document: the Network Access Identifier, which is a > Bernard> term that applies to Network Access alone. This includes > Bernard> EAP, PPP, etc. but NOT HTTP, SIP, etc. The NAI draft > Bernard> should not talk about the contents of the RADIUS User-Name > Bernard> attribute -- that should be handled by a separate document. >=20 > Bernard, unfortunately, some of us really need to cover > non-network-access use cases of EAP and we'd really like to see the same > treatment of network access use cases of EAP. > I'd prefer to keep all EAP use cases in this draft. From bernard_aboba@hotmail.com Mon Mar 18 16:22:22 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E5721F8AD5 for ; Mon, 18 Mar 2013 16:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.203 X-Spam-Level: X-Spam-Status: No, score=-101.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxFehZ-DbLJP for ; Mon, 18 Mar 2013 16:22:20 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by ietfa.amsl.com (Postfix) with ESMTP id AEBF821F8AD1 for ; Mon, 18 Mar 2013 16:22:19 -0700 (PDT) Received: from BLU402-EAS118 ([65.55.111.72]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Mar 2013 16:22:19 -0700 X-EIP: [xeak8bMHBEaZ3bbUb8cpffaMuWvRbJdD] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable References: <51479244.4040004@deployingradius.com> <095301ce242e$801f3ef0$805dbcd0$@augustcellars.com> From: Bernard Aboba MIME-Version: 1.0 (1.0) In-Reply-To: <095301ce242e$801f3ef0$805dbcd0$@augustcellars.com> Date: Mon, 18 Mar 2013 19:22:18 -0400 To: Jim Schaad X-OriginalArrivalTime: 18 Mar 2013 23:22:19.0516 (UTC) FILETIME=[6FA043C0:01CE242F] Cc: Sam Hartman , Pete Resnick , Barry Leiba , "radext@ietf.org" , Alan DeKok Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:22:23 -0000 Point #1 is particularly relevant here - which is why handling the NAI and t= he RADIUS User-Name attribute in the same doc (as if they were the same) is d= o problematic. On Mar 18, 2013, at 7:16 PM, "Jim Schaad" wrote: >=20 >=20 >> -----Original Message----- >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf >> Of Bernard Aboba >> Sent: Monday, March 18, 2013 3:41 PM >> To: Alan DeKok >> Cc: Sam Hartman; Pete Resnick; Barry Leiba; radext@ietf.org >> Subject: Re: [radext] I18N help: : I-D Action: > draft-ietf-radext-nai-02.txt >>=20 >>=20 >>=20 >> On Mar 18, 2013, at 18:16, "Alan DeKok" >> wrote: >>=20 >>>=20 >>> What other drafts require RADIUS proxies to normalize usernames / >> realms? >>=20 >> [BA] The Dynamic Discovery draft recognizes that realms won't necessarily= >> appear in the User-Name attribute in normalized form. >=20 > The Dynamic Discovery draft recognizes the following: > 1. What is in the UserName field may not be an NAI > 2. What is in the UserName field realm portion needs to somehow be mapped= > to a DNS name (much easier if already normalized). >=20 > Note that it does not talk about the process of normalization in any way. > It talks about how to map from a UTF-8 realm name to a DNS name. >=20 > Jim >=20 >>=20 >>>=20 >>> What else can we do to replace RFC 4282, which is arguably *worse* >>> than the current draft? >>=20 >> [BA] Focus only on the scope that the Charter outlines for the document: > the >> Network Access Identifier, which is a term that applies to Network Access= >> alone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc. The NAI draf= t >> should not talk about the contents of the RADIUS User-Name attribute -- >> that should be handled by a separate document. >>=20 >>=20 >>>=20 >>> Alan DeKok. >>> _______________________________________________ >>> radext mailing list >>> radext@ietf.org >>> https://www.ietf.org/mailman/listinfo/radext >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >=20 From peterd@iea-software.com Mon Mar 18 16:29:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB2521F8A8F for ; Mon, 18 Mar 2013 16:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKFqggaT3-Rg for ; Mon, 18 Mar 2013 16:29:42 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 61AAD21F8A84 for ; Mon, 18 Mar 2013 16:29:42 -0700 (PDT) Received: from littlesmurf.internal.iea-software.com (unverified [10.0.0.39]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Mon, 18 Mar 2013 16:29:41 -0700 Date: Mon, 18 Mar 2013 16:29:48 -0700 (Pacific Daylight Time) From: Peter Deacon To: Alan DeKok In-Reply-To: <5147918E.2000602@deployingradius.com> Message-ID: References: <51476121.1090704@deployingradius.com> <51476D06.80202@deployingradius.com> <5147918E.2000602@deployingradius.com> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: Sam Hartman , "radext@ietf.org" Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 23:29:43 -0000 On Mon, 18 Mar 2013, Alan DeKok wrote: > Supplicants *can't* do TCP, because they have no net access. So any > EAP transport is *allowed* to be horrible, because it's no worse than > Ethernet. > RADIUS servers *can* do TCP, so horrible transports are use only when > there is no alternative. > I don't *care* that Alex's draft is no worse (or better) than EAP. A > better alternative exists: TCP. Therefore we should use it. The only > reason to *not* use TCP is implementation delays. I think there is a misunderstanding in what has been asked. In the context of my question I am not concerned with: What can or can't do TCP Which protocol is better Why protocol x is better than protocol y Why x implements y while z implements c The only question or observation I wish to make is that Alex's scheme whatever you may think of it looks a lot like EAP over RADIUS in terms of lock step, maximum fragment size, rough number of round trips and presence of proxies forwarding up to maximum fragment size. To the extent comments about the properties of Alex's fragmentation scheme are being discussed specifically the following concerns expressed by Sam: "draft will require significant transport review because they both propose protocols with complex MTU/congestion/fragmentation/performance characteristics." "Alex's draft and the MTU issue, I stand behind my claim that it will tend to involve fragmentation at multiple layers. There's no way to learn the MTU that is currently being proposed." My observation or question is could we look toward current widespread deployment of RADIUS/EAP to help understand these concerns with respect to Alex's fragmentation scheme only? Again I am not making any determinations and I understand EAP is more conversational than bulk transfer and there are different constraints however the MTU issue especially I believe could benefit from operational experience with RADIUS/EAP. regards, Peter From hartmans@painless-security.com Mon Mar 18 17:08:15 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E670B21F8B20 for ; Mon, 18 Mar 2013 17:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9EtYOKap3h-b for ; Mon, 18 Mar 2013 17:08:15 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 4630421F88C7 for ; Mon, 18 Mar 2013 17:08:15 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1FFF12010D; Mon, 18 Mar 2013 20:07:38 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 64EEC41CF; Mon, 18 Mar 2013 20:08:12 -0400 (EDT) From: Sam Hartman To: Peter Deacon References: <51476121.1090704@deployingradius.com> <51476D06.80202@deployingradius.com> <5147918E.2000602@deployingradius.com> Date: Mon, 18 Mar 2013 20:08:12 -0400 In-Reply-To: (Peter Deacon's message of "Mon, 18 Mar 2013 16:29:48 -0700 (Pacific Daylight Time)") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , Alan DeKok Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 00:08:16 -0000 >>>>> "Peter" == Peter Deacon writes: Peter> To the extent comments about the properties of Alex's Peter> fragmentation scheme are being discussed specifically the Peter> following concerns expressed by Sam: Peter> "draft will require significant transport review because they Peter> both propose protocols with complex Peter> MTU/congestion/fragmentation/performance characteristics." Peter> "Alex's draft and the MTU issue, I stand behind my claim that Peter> it will tend to involve fragmentation at multiple layers. Peter> There's no way to learn the MTU that is currently being Peter> proposed." Peter> My observation or question is could we look toward current Peter> widespread deployment of RADIUS/EAP to help understand these Peter> concerns with respect to Alex's fragmentation scheme only? Yes. I think that will help us. From aland@deployingradius.com Mon Mar 18 17:09:04 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F1E21F8507 for ; Mon, 18 Mar 2013 17:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.774 X-Spam-Level: X-Spam-Status: No, score=-101.774 tagged_above=-999 required=5 tests=[AWL=-0.330, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+kx8J2P6Ztj for ; Mon, 18 Mar 2013 17:09:03 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9219621F84F9 for ; Mon, 18 Mar 2013 17:09:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 5CF432240F82; Tue, 19 Mar 2013 01:09:03 +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 Q9bLLdHTMoqs; Tue, 19 Mar 2013 01:09:02 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id 5695D2240842; Tue, 19 Mar 2013 01:09:02 +0100 (CET) Message-ID: <5147AC9C.3070402@deployingradius.com> Date: Mon, 18 Mar 2013 20:09:00 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <51476121.1090704@deployingradius.com> <51476D06.80202@deployingradius.com> <5147918E.2000602@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , "radext@ietf.org" Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 00:09:04 -0000 Peter Deacon wrote: > I think there is a misunderstanding in what has been asked. In the > context of my question I am not concerned with: > > What can or can't do TCP > Which protocol is better > Why protocol x is better than protocol y > Why x implements y while z implements c OK. > The only question or observation I wish to make is that Alex's scheme > whatever you may think of it looks a lot like EAP over RADIUS in terms > of lock step, maximum fragment size, rough number of round trips and > presence of proxies forwarding up to maximum fragment size. Yes, they look very similar. > To the extent comments about the properties of Alex's fragmentation > scheme are being discussed specifically the following concerns expressed > by Sam: > > "draft will require significant transport review because they both > propose protocols with complex MTU/congestion/fragmentation/performance > characteristics." > > "Alex's draft and the MTU issue, I stand behind my claim that it will > tend to involve fragmentation at multiple layers. There's no way to > learn the MTU that is currently being proposed." > > My observation or question is could we look toward current widespread > deployment of RADIUS/EAP to help understand these concerns with respect > to Alex's fragmentation scheme only? No. We can point to EAP over RADIUS and say that fragmentation will *mostly* work. The transport people don't care. They will describe it as a horrible hack, and they will be right. They will point out that we can use TCP instead of fragmentation, and they will be right. The only defense is to say it's a temporary measure meant to work with existing implementations. The transport people will ensure that the fragmentation draft has big warnings saying it's a terrible idea that will destroy the Internet and should be removed ASAP. (I'm only slightly exaggerating) > Again I am not making any determinations and I understand EAP is more > conversational than bulk transfer and there are different constraints > however the MTU issue especially I believe could benefit from > operational experience with RADIUS/EAP. Of course. The traditional RADIUS response to MTU issues is to stick your fingers in your ears and say Alan DeKok. From ietf@augustcellars.com Mon Mar 18 17:25:25 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F37521F8AA6 for ; Mon, 18 Mar 2013 17:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbZXNkhr0P7v for ; Mon, 18 Mar 2013 17:25:24 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A50D621F88C7 for ; Mon, 18 Mar 2013 17:25:24 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 3703C2CA0C; Mon, 18 Mar 2013 17:25:24 -0700 (PDT) From: "Jim Schaad" To: "'Bernard Aboba'" References: <51479244.4040004@deployingradius.com> <095301ce242e$801f3ef0$805dbcd0$@augustcellars.com> In-Reply-To: Date: Mon, 18 Mar 2013 17:24:50 -0700 Message-ID: <096401ce2438$2be8d210$83ba7630$@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: AQKDqdkZcLEIL1UUu7zAO+HZFkBbfQGYp4ZcAifLyRYBrpNI3AHYkklLAbKMtXSW+UqEAA== Content-Language: en-us Cc: 'Sam Hartman' , 'Pete Resnick' , 'Barry Leiba' , radext@ietf.org, 'Alan DeKok' Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 00:25:25 -0000 So I just did search in the document for User-Name just to see how overlapped they are. The document says * NAIs are often transported in the User-Name field of RADIUS and Diameter * Putting localized text into a User-Name field is problematic (because User-Name is not NAI) * Don't do ToAscii on NAI before putting into a User-Name field. Of that list only the last one seems to be an issue from the point of separation. The text seems to be very clear that they are not the same thing. Jim > -----Original Message----- > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com] > Sent: Monday, March 18, 2013 4:22 PM > To: Jim Schaad > Cc: Alan DeKok; Sam Hartman; Pete Resnick; Barry Leiba; radext@ietf.org > Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt > > Point #1 is particularly relevant here - which is why handling the NAI and the > RADIUS User-Name attribute in the same doc (as if they were the same) is do > problematic. > > On Mar 18, 2013, at 7:16 PM, "Jim Schaad" wrote: > > > > > > >> -----Original Message----- > >> From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On > >> Behalf Of Bernard Aboba > >> Sent: Monday, March 18, 2013 3:41 PM > >> To: Alan DeKok > >> Cc: Sam Hartman; Pete Resnick; Barry Leiba; radext@ietf.org > >> Subject: Re: [radext] I18N help: : I-D Action: > > draft-ietf-radext-nai-02.txt > >> > >> > >> > >> On Mar 18, 2013, at 18:16, "Alan DeKok" > >> wrote: > >> > >>> > >>> What other drafts require RADIUS proxies to normalize usernames / > >> realms? > >> > >> [BA] The Dynamic Discovery draft recognizes that realms won't > >> necessarily appear in the User-Name attribute in normalized form. > > > > The Dynamic Discovery draft recognizes the following: > > 1. What is in the UserName field may not be an NAI 2. What is in the > > UserName field realm portion needs to somehow be mapped to a DNS name > > (much easier if already normalized). > > > > Note that it does not talk about the process of normalization in any way. > > It talks about how to map from a UTF-8 realm name to a DNS name. > > > > Jim > > > >> > >>> > >>> What else can we do to replace RFC 4282, which is arguably *worse* > >>> than the current draft? > >> > >> [BA] Focus only on the scope that the Charter outlines for the document: > > the > >> Network Access Identifier, which is a term that applies to Network > >> Access alone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc. > >> The NAI draft should not talk about the contents of the RADIUS > >> User-Name attribute -- that should be handled by a separate document. > >> > >> > >>> > >>> Alan DeKok. > >>> _______________________________________________ > >>> radext mailing list > >>> radext@ietf.org > >>> https://www.ietf.org/mailman/listinfo/radext > >> _______________________________________________ > >> radext mailing list > >> radext@ietf.org > >> https://www.ietf.org/mailman/listinfo/radext > > From ietf@augustcellars.com Mon Mar 18 17:30:52 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF3D21F8B48 for ; Mon, 18 Mar 2013 17:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.524 X-Spam-Level: X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMF+yo-0UmS7 for ; Mon, 18 Mar 2013 17:30:52 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1661F21F8A18 for ; Mon, 18 Mar 2013 17:30:52 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id B7D1F2CA0B; Mon, 18 Mar 2013 17:30:51 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "'Peter Deacon'" References: <51476121.1090704@deployingradius.com> <51476D06.80202@deployingradius.com> <5147918E.2000602@deployingradius.com> In-Reply-To: Date: Mon, 18 Mar 2013 17:30:17 -0700 Message-ID: <096601ce2438$ef1a9bb0$cd4fd310$@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: AQIMOtX7WCI0Ovq1uZSafB7WciplJAHRH06XAigX2jwBkBhasgIwShpuAc/wKKoBkUnUxgI5E+fAAufjvNsBUSIyEgC/iRmHl52Xu+A= Content-Language: en-us Cc: radext@ietf.org, 'Alan DeKok' Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 00:30:52 -0000 It is unclear to me how much looking at this will help. My understand (possibly wrong) is that the EAP fragmentation issue has as much to do with the MTU size on the network between the client and NAS as anything else. This is going to be frequently smaller than the MTU size between the NAS and the server and thus becomes a huge gating factor that has nothing to do with internet congestion itself. The choice of making EAP do the fragmentation rather than having the NAS do it is a trade off in terms of where the complexity lies (i.e. just with the people who talk EAP) rather than having it occur on every protocol that is between clients and NAS boxes. Jim > -----Original Message----- > From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of > Sam Hartman > Sent: Monday, March 18, 2013 5:08 PM > To: Peter Deacon > Cc: radext@ietf.org; Alan DeKok > Subject: Re: [radext] Summary of Where we are with Fragmentation > > >>>>> "Peter" == Peter Deacon writes: > > Peter> To the extent comments about the properties of Alex's > Peter> fragmentation scheme are being discussed specifically the > Peter> following concerns expressed by Sam: > > Peter> "draft will require significant transport review because they > Peter> both propose protocols with complex > Peter> MTU/congestion/fragmentation/performance characteristics." > > Peter> "Alex's draft and the MTU issue, I stand behind my claim that > Peter> it will tend to involve fragmentation at multiple layers. > Peter> There's no way to learn the MTU that is currently being > Peter> proposed." > > Peter> My observation or question is could we look toward current > Peter> widespread deployment of RADIUS/EAP to help understand these > Peter> concerns with respect to Alex's fragmentation scheme only? > > Yes. > I think that will help us. > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From stefan.winter@restena.lu Tue Mar 19 00:52:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8123321F8640 for ; Tue, 19 Mar 2013 00:52:18 -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=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwBnbqlBipVI for ; Tue, 19 Mar 2013 00:52:18 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id ADF7021F8628 for ; Tue, 19 Mar 2013 00:52:17 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id C0F3C1058A for ; Tue, 19 Mar 2013 08:52:15 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:28d9:750b:eb74:2493]) by smtprelay.restena.lu (Postfix) with ESMTPS id B20DC10581 for ; Tue, 19 Mar 2013 08:52:15 +0100 (CET) Message-ID: <5148192B.90507@restena.lu> Date: Tue, 19 Mar 2013 08:52:11 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> In-Reply-To: <51476C2C.5070000@deployingradius.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2QDHTVWNWHKOFJIJUCDQC" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 07:52:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2QDHTVWNWHKOFJIJUCDQC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > As I write RADIUS servers instead of supplicants, I think the > normalization work should be pushed off onto supplicants. >=20 > The document already says that realm names MUST be registrable as > names within DNS. DNS requires NFC. Therefore, realms are NFC. Any > supplicant injecting non-NFC names is wrong. Not quite. Section 2.1 states: See [RFC5198] for a discussion of normalization; the use of Normal Form Composed (NFC) is RECOMMENDED. RECOMMENDED means that some ill-thinking supplicant implementers might decide that they don't have to pay attention to normalisation. If this statement were a MUST; plus a discussion what to do if an incoming string is not in NFC (discard?) would make the whole thing a lot more deterministic. > re: Sam's comments on i18n space, I'm not sure it's relevant to have > the home server normalize the realm name. I'm curious to know what > information is in the non-NFC form which is needed by the home server. It may be that the home server does not "need" the non-normalised junk :-) It may just be that a supplicant thinks it's wise to send it; and since the contents of the attribute can't be altered in-flight, this junk will stay in the packet until it arrives at the home server. My argument was that it may not even reach the home server if proxies aren't allowed to do some sort of "sane" lookup of the packet content vs. their local configuration. > The home server knows who it's users are, and can just use names, > without a realm portion. If it gets a realm, it verifies that it owns > the realm, but that verification is largely site-specific. e.g. > EXAMPLE\foo versus foo@example.com. That verification may ultimately require normalisation by the home server. It's true that this is site-specific; but in the presence of proxies the problematic bit is to reach that home site in the first place= =2E > So the main use for realms is proxies. They don't care about the > *content* of the realm. They just want to use it as an opaque token. > Realm A goes to RADIUS server for Realm A, etc. My issue is: does realm A', which is extremely similar to A in that it differs only in string representation, also go to server A? Or is it discarded by the proxy due to being unknown (i.e. not byte-wise equal to the configured realm A)? Or sent to a "last resort"? If NFC(A') =3D A, an= d if that is looked up in the routing table, a lot good is done in terms of forwardability, IMHO. Greetings, Stefan Winter >=20 > Alan DeKok. > _______________________________________________ > 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 ------enig2QDHTVWNWHKOFJIJUCDQC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFIGS8ACgkQ+jm90f8eFWYPTgCeJxbAET35nYBYtO8rFMi2/Ecz OD0An343wZf0KDKh4srZpptuxYfgz0ES =9S39 -----END PGP SIGNATURE----- ------enig2QDHTVWNWHKOFJIJUCDQC-- From stefan.winter@restena.lu Tue Mar 19 01:25:04 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0215C21F858C for ; Tue, 19 Mar 2013 01:25:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTmFaGDEUsvf for ; Tue, 19 Mar 2013 01:25:02 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id C5DCC21F8589 for ; Tue, 19 Mar 2013 01:24:59 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 99E3E1058A for ; Tue, 19 Mar 2013 09:24:57 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:28d9:750b:eb74:2493]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6DF6D10581 for ; Tue, 19 Mar 2013 09:24:57 +0100 (CET) Message-ID: <514820D5.2030909@restena.lu> Date: Tue, 19 Mar 2013 09:24:53 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <51476121.1090704@deployingradius.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2AVUOIUMQTLDGSKSMKWXC" X-Virus-Scanned: ClamAV Subject: Re: [radext] Summary of Where we are with Fragmentation X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 08:25:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2AVUOIUMQTLDGSKSMKWXC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > What is different about the semantics of transporting EAP over RADIUS > compared with Alex's draft? >=20 > On the surface they both appear to me to have the same properties. If = I > am missing something any hints/clue would be much appreciated. >=20 > Both are transported blindly thru proxies without regard for > intermediate MTU considerations. >=20 > Both are lock step, both give the sender full control over amount of > data to be transmitted at a time. >=20 > If they are the same I would just expect operational experience > (positive or negative) from widely deployed experience with EAP to also= > be directly applicable to Alex's draft. That's just not correct: the maximum size of EAP-Message in EAPoL in a RADIUS packet is not "in full control of the sender" - it is limited by the L2 MTU between supplicant and the pass-through authenticator. In practice, this means: 1500 Bytes for Ethernet; some have been experimenting with 21xx for the wireless medium, but that rarely works. 1500 Bytes of EAP-Message usually do trigger UDP fragmentation; but even with a fair number of attributes added by RADIUS besides the core EAP-Message, they don't exceed 4096 Bytes and thus don't require RADIUS-level packet fragments. I.e. it's a non-issue. BTW, the operational experience with UDP fragmentation in eduroam is far from perfect: EAP types which tend to fill the L2 MTU to the max sometimes won't authenticate because somewhere along the path, UDP fragments are erroneously discarded (well, many instances of that some years ago; meanwhile we test these things and so have found most of the ill firewalls which do that). The problems with UDP frags make many IdPs send their EAP server-to-supplicant with EAP-Message <=3D 1024 Bytes; so that even addin= g RADIUS attributes to the packet will stay below typical UDP fragmentation thresholds. That's "better safe than sorry" but decreases efficiency - more roundtrips. Back in the day (IETF 69!) I argued that working on a RADIUS MTU discovery to prevent UDP fragmentation would be a good thing. I have meanwhile given up on the hope that it will be specified *and* actually work; I believe that human energy is better spent in fixing broken firewalls to make UDP fragmentation work in the first place. So, in short: for EAPoL - UDP fragmentation is a (purely operational) issue - RADIUS total packet size fragmentation is not Greetings, Stefan Winter >> RADIUS is a horrible replacement for TCP. It's only being proposed >> here (IMHO) as a temporary migration path. Once the proxies do RADIUS= >> over TCP, *and* allow for 64K RADIUS packets, the fragmentation >> proposals become less relevant. >=20 > Horrible is an opinion not a reason. You still have to deliver to/from= > clients which far outnumber server implementations. >=20 > regards, > Peter > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2AVUOIUMQTLDGSKSMKWXC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFIINkACgkQ+jm90f8eFWbrsACeOWw2fT0HXqj8cZU8kNifGPoO kKAAn0gmuxRI6iK4kmAuI0N+tHGux7A9 =Hfff -----END PGP SIGNATURE----- ------enig2AVUOIUMQTLDGSKSMKWXC-- From stefan.winter@restena.lu Tue Mar 19 01:42:14 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E33221F8814 for ; Tue, 19 Mar 2013 01:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GFUKShZVSa-N for ; Tue, 19 Mar 2013 01:42:13 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 42FF121F8801 for ; Tue, 19 Mar 2013 01:42:13 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A60F21058A for ; Tue, 19 Mar 2013 09:42:12 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:28d9:750b:eb74:2493]) by smtprelay.restena.lu (Postfix) with ESMTPS id 6A79C10584 for ; Tue, 19 Mar 2013 09:42:12 +0100 (CET) Message-ID: <514824E0.1000506@restena.lu> Date: Tue, 19 Mar 2013 09:42:08 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FEXEJPIXMKBFCLCDMXDX" X-Virus-Scanned: ClamAV Subject: Re: [radext] Meeting laundry list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 08:42:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FEXEJPIXMKBFCLCDMXDX Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > ----- > Stefan - loop detection >=20 > We have had a trivial proxy loop detection system in production in our > implementations for several years. It works on the assumption any > request the same proxy system sees again completes a cycle. >=20 > In our implementation a systems identifier is embedded in the proxy > state attribute. When a request for proxy is received we check for > matching system identifier in the current stack of proxy states and dro= p > the request if one is found. Many of those who implement loop checking in eduroam do similarly: they use their own VSA space to * in incoming packets, check for presence of their VSA like "Processed-By: my.ip.ad.dr" (or other halfways unique ID) * If found, discard and log loop * if not found, add "Processed-By: my.ip.ad.dr" (or other halfways unique ID) and process packet That's simple and straightforward indeed. The problem I have is that such a behaviour is not specified anywhere, and doesn't have its own attribute. You overload Proxy-State; which is fine if you don't need it for anything else. I don't really care if that use of Proxy-State gets standardised, or if a new attribute is chosen. But having one deterministic way of doing things, along with a document which explains the how and why, instead of everyone doing his own variant on its own, is a GoodThing(tm) IMHO. That is after all what Standardisation Organisations are made for :-) Greetings, Stefan Winter >=20 > ----- > ieee802ext >=20 > Had a chance to read thru this draft a bit before and after the meeting= > - looks good here. >=20 > ----- > Datatypes >=20 > I like the general idea of a type registry that can be referenced but > I'm not sure how much utility there is at this point. >=20 > It could see it being more expressive to have a new complex type in the= > registry to map things we don't want to add a separate entry for like > Tunnel-Password rather than collapsing to string. >=20 >=20 > Thanks to chairs and all for a great meeting :) >=20 > regards, > Peter > _______________________________________________ > 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 National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2FEXEJPIXMKBFCLCDMXDX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFIJOQACgkQ+jm90f8eFWY8DgCeJmIGzqjEXn/7w6IErUYIcDWV SnAAmQH5ds1trUO9xYSPKyNo0AdH7yik =xFdG -----END PGP SIGNATURE----- ------enig2FEXEJPIXMKBFCLCDMXDX-- From aland@deployingradius.com Tue Mar 19 06:31:16 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D75C21F8A6F for ; Tue, 19 Mar 2013 06:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.452 X-Spam-Level: X-Spam-Status: No, score=-101.452 tagged_above=-999 required=5 tests=[AWL=-0.608, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l2pENrIcOsIV for ; Tue, 19 Mar 2013 06:31:16 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id B1AE321F8A6E for ; Tue, 19 Mar 2013 06:31:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A23A52240F0E; Tue, 19 Mar 2013 14:31:14 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0bu6G2ooKt0; Tue, 19 Mar 2013 14:31:14 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id C669F2240C5B; Tue, 19 Mar 2013 14:31:13 +0100 (CET) Message-ID: <514868A0.2040207@deployingradius.com> Date: Tue, 19 Mar 2013 09:31:12 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> In-Reply-To: <5148192B.90507@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 13:31:16 -0000 Stefan Winter wrote: >> As I write RADIUS servers instead of supplicants, I think the >> normalization work should be pushed off onto supplicants. >> >> The document already says that realm names MUST be registrable as >> names within DNS. DNS requires NFC. Therefore, realms are NFC. Any >> supplicant injecting non-NFC names is wrong. > > Not quite. Section 2.1 states: > > See [RFC5198] for a discussion of normalization; the use of Normal > Form Composed (NFC) is RECOMMENDED. Yes. Keep reading. It also says that realm names MUST be registrable as names within DNS. Which (eventually) means NFC. The text you quote is left over from an earlier version of the draft, before I worked through the DNS documents. It will be updated in the next rev. > If this statement were a MUST; plus a discussion what to do if an > incoming string is not in NFC (discard?) would make the whole thing a > lot more deterministic. I vote a "hell no" to discarding packets with malformed NAI. For me, a malformed NAI only means that it's not an NAI. EXAMPLE\user is a perfectly valid RADIUS User-Name. It should *not* be forbidden by the NAI document. > It may be that the home server does not "need" the non-normalised junk > :-) It may just be that a supplicant thinks it's wise to send it; and > since the contents of the attribute can't be altered in-flight, this > junk will stay in the packet until it arrives at the home server. That's not what I got from his message, but OK. > My argument was that it may not even reach the home server if proxies > aren't allowed to do some sort of "sane" lookup of the packet content > vs. their local configuration. They are allowed. They do this today. Proxy routing can be done on EXAMPLE\user. The point of the NAI draft is to (a) fix RFC 4282, (b) define the NAI correctly, and (c) encourage people to use it instead of broken alternatives. There are no plans for a RADIUS police force who will shut down non-complaint implementations. They just won't get the benefit of standardization. > That verification may ultimately require normalisation by the home > server. It's true that this is site-specific; but in the presence of > proxies the problematic bit is to reach that home site in the first place. That's blaming the messenger. The problem is really the supplicants that inject multiple versions of the same domain. > My issue is: does realm A', which is extremely similar to A in that it > differs only in string representation, also go to server A? Or is it > discarded by the proxy due to being unknown (i.e. not byte-wise equal to > the configured realm A)? Or sent to a "last resort"? If NFC(A') = A, and > if that is looked up in the routing table, a lot good is done in terms > of forwardability, IMHO. I'm OK with proxies doing deeper inspection or normalization of the NAI. I'm against the *requirement* that they do this. RFC 4282 requires it. Requiring non-NFS from the supplicants means that proxies are required to massage the NAI before they use it. Alan DeKok. From aland@deployingradius.com Tue Mar 19 08:11:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7D0621F8CD7 for ; Tue, 19 Mar 2013 08:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.714 X-Spam-Level: X-Spam-Status: No, score=-101.714 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsNc-OS38E+x for ; Tue, 19 Mar 2013 08:11:13 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E685521F8D1F for ; Tue, 19 Mar 2013 08:11:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id A64AB2240F4B; Tue, 19 Mar 2013 16:11:12 +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 mqC8FZNiliDe; Tue, 19 Mar 2013 16:11:12 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id B9C0B2240F0E; Tue, 19 Mar 2013 16:11:11 +0100 (CET) Message-ID: <5148800E.3040302@deployingradius.com> Date: Tue, 19 Mar 2013 11:11:10 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Bernard Aboba References: <51479244.4040004@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Pete Resnick , Barry Leiba , "radext@ietf.org" Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:11:18 -0000 Bernard Aboba wrote: > [BA] The Dynamic Discovery draft recognizes that realms won't necessarily appear in the User-Name attribute in normalized form. Sure. That's reality. People do all kinds of horrible things with protocols. But the text makes it clear it's about DNS: This document describes server discovery only for well-formed realms mapping to DNS domain names in UTF-8 encoding. And then: The result of all other possible contents of User-Name is unspecified; i.e. other forms are allowed, but "realm == DNS" is what the draft describes. >> What else can we do to replace RFC 4282, which is arguably *worse* >> than the current draft? > > [BA] Focus only on the scope that the Charter outlines for the document: the Network Access Identifier, which is a term that applies to Network Access alone. This includes EAP, PPP, etc. but NOT HTTP, SIP, etc. The NAI draft should not talk about the contents of the RADIUS User-Name attribute -- that should be handled by a separate document. The document discusses how the NAI *may* be used in User-Name, and other protocols. It's meant as a guide for people who want to use the NAI. It's not a requirement on how other protocols (including RADIUS) use the NAI. I'd oppose removing the text about protocols using NAI. Doing that means we're defining an NAI independent of... anything. So we'll have an NAI, but no idea of where or when to use it. Alan DeKok. From peterd@iea-software.com Tue Mar 19 08:14:05 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E21A221F8667 for ; Tue, 19 Mar 2013 08:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpUSOyhrfqLx for ; Tue, 19 Mar 2013 08:14:05 -0700 (PDT) Received: from aspen.internal.iea-software.com (remote.iea-software.com [70.89.142.196]) by ietfa.amsl.com (Postfix) with ESMTP id 280F621F8628 for ; Tue, 19 Mar 2013 08:14:05 -0700 (PDT) Received: from SMURF (unverified [10.0.3.195]) by aspen.internal.iea-software.com (Rockliffe SMTPRA 7.0.6) with ESMTP id ; Tue, 19 Mar 2013 08:14:04 -0700 Date: Tue, 19 Mar 2013 08:13:57 -0700 (Pacific Daylight Time) From: Peter Deacon To: Stefan Winter In-Reply-To: <514824E0.1000506@restena.lu> Message-ID: References: <514824E0.1000506@restena.lu> User-Agent: Alpine 2.00 (WNT 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: radext@ietf.org Subject: Re: [radext] Meeting laundry list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 15:14:06 -0000 On Tue, 19 Mar 2013, Stefan Winter wrote: >> We have had a trivial proxy loop detection system in production in our >> implementations for several years. It works on the assumption any >> request the same proxy system sees again completes a cycle. >> In our implementation a systems identifier is embedded in the proxy >> state attribute. When a request for proxy is received we check for >> matching system identifier in the current stack of proxy states and drop >> the request if one is found. > Many of those who implement loop checking in eduroam do similarly: they > use their own VSA space to > * in incoming packets, check for presence of their VSA like > "Processed-By: my.ip.ad.dr" (or other halfways unique ID) > * If found, discard and log loop > * if not found, add "Processed-By: my.ip.ad.dr" (or other halfways > unique ID) and process packet > That's simple and straightforward indeed. The problem I have is that > such a behaviour is not specified anywhere, and doesn't have its own > attribute. > You overload Proxy-State; which is fine if you don't need it for > anything else. I don't know that "overload" is applicable in this context or why it couldn't be used for multiple purposes concurrently. Proxy-State is defined as an opaque field. Its purpose is left intentionally out of scope RFC2865 5.33 " Usage of the Proxy-State Attribute is implementation dependent. A description of its function is outside the scope of this specification. " > I don't really care if that use of Proxy-State gets standardised, or if > a new attribute is chosen. But having one deterministic way of doing > things, along with a document which explains the how and why, instead of > everyone doing his own variant on its own, is a GoodThing(tm) IMHO. We don't really know generally what constitutes a "loop" or granularity of the system box (Parts of one server or entire groups of servers). Messages may be able to loop back for another round of processing after being sent outside the admin domain. Seems easy enough to create one-off solutions yet very difficult to solve generally. Perhaps some general guidance or blunt tools like TTLs on stack of proxy-states. regards, Peter From stefan.winter@restena.lu Tue Mar 19 08:20:21 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACCB11E80DE for ; Tue, 19 Mar 2013 08:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_31=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTUnJK3zMZF9 for ; Tue, 19 Mar 2013 08:20:20 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 4523D11E80D9 for ; Tue, 19 Mar 2013 08:20:20 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id A139B10584 for ; Tue, 19 Mar 2013 16:20:19 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:28d9:750b:eb74:2493]) by smtprelay.restena.lu (Postfix) with ESMTPS id 9338A1057F for ; Tue, 19 Mar 2013 16:20:19 +0100 (CET) Message-ID: <5148822F.5070708@restena.lu> Date: Tue, 19 Mar 2013 16:20:15 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> In-Reply-To: <514868A0.2040207@deployingradius.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2CRJCFWICVSIIWKRIKPUN" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 15:20:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2CRJCFWICVSIIWKRIKPUN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Yes. Keep reading. It also says that realm names MUST be registrabl= e > as names within DNS. Which (eventually) means NFC. >=20 > The text you quote is left over from an earlier version of the draft,= > before I worked through the DNS documents. It will be updated in the > next rev. Okay. > I vote a "hell no" to discarding packets with malformed NAI. >=20 > For me, a malformed NAI only means that it's not an NAI. EXAMPLE\use= r > is a perfectly valid RADIUS User-Name. It should *not* be forbidden b= y > the NAI document. Then I'd suggest making this very explicit. E.g. replace the previous sentence with "See [RFC5198] and section 2.6 of this specification for a discussion of normalization. Strings which are not in Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such." >> It may be that the home server does not "need" the non-normalised junk= >> :-) It may just be that a supplicant thinks it's wise to send it; and >> since the contents of the attribute can't be altered in-flight, this >> junk will stay in the packet until it arrives at the home server. >=20 > That's not what I got from his message, but OK. You mean my initial mail with the hypothetical example? Well it was about that; I had the assumption in my mind that these multiple representations of the realm are imposed by stubborn supplicants; so if a server wants to authenticate users using this supplicant, it has to negotiate that this is a recognised representation of the string and add it to its server-side config. Not the other way around; sorry if that was unclear. I don't think servers are the main problem when it comes to normalisation (or just valid UTF-8 in the first place). I have much more concerns about ignorant supplicants. >> My argument was that it may not even reach the home server if proxies >> aren't allowed to do some sort of "sane" lookup of the packet content >> vs. their local configuration. >=20 > They are allowed. They do this today. Proxy routing can be done on > EXAMPLE\user. >=20 > The point of the NAI draft is to (a) fix RFC 4282, (b) define the NAI= > correctly, and (c) encourage people to use it instead of broken > alternatives. >=20 > There are no plans for a RADIUS police force who will shut down > non-complaint implementations. They just won't get the benefit of > standardization. Okay; well it's already good that NAI =3D> NFC is indeed hard-wired into the spec. >> That verification may ultimately require normalisation by the home >> server. It's true that this is site-specific; but in the presence of >> proxies the problematic bit is to reach that home site in the first pl= ace. >=20 > That's blaming the messenger. >=20 > The problem is really the supplicants that inject multiple versions o= f > the same domain. With the multitude of end-user computing devices in the wild, and the varying amounts of care firmware writers spend into their supplicant code, I'm sure there'll be a whole zoo of representations of internationalised domain names on the supplicant side :-( >> My issue is: does realm A', which is extremely similar to A in that it= >> differs only in string representation, also go to server A? Or is it >> discarded by the proxy due to being unknown (i.e. not byte-wise equal = to >> the configured realm A)? Or sent to a "last resort"? If NFC(A') =3D A,= and >> if that is looked up in the routing table, a lot good is done in terms= >> of forwardability, IMHO. >=20 > I'm OK with proxies doing deeper inspection or normalization of the > NAI. I'm against the *requirement* that they do this. Well if it's a NAI it does not need to be noramlised any more :-) Would it be okay to *RECOMMEND* that UTF-8 which is not in NFC should be normalised prior to "doing something" in terms of lookup in the config? Greetings, Stefan Winter > RFC 4282 > requires it. Requiring non-NFS from the supplicants means that proxies= > are required to massage the NAI before they use it. >=20 > Alan DeKok. > _______________________________________________ > 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 ------enig2CRJCFWICVSIIWKRIKPUN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFIgjMACgkQ+jm90f8eFWY9YgCeOIU9hlwzSJpDKXBd974c85fG Q3MAnAl8WGrU5MDia6UyZn8blMqTA5ez =2/Og -----END PGP SIGNATURE----- ------enig2CRJCFWICVSIIWKRIKPUN-- From aland@deployingradius.com Tue Mar 19 08:21:53 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7831821F8D5D for ; Tue, 19 Mar 2013 08:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.698 X-Spam-Level: X-Spam-Status: No, score=-101.698 tagged_above=-999 required=5 tests=[AWL=-0.254, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+-YhMXSKUXe for ; Tue, 19 Mar 2013 08:21:53 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CD37C21F8D34 for ; Tue, 19 Mar 2013 08:21:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C9A582240F4B; Tue, 19 Mar 2013 16:21:07 +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 RYfjAmtDJBYl; Tue, 19 Mar 2013 16:21:07 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id 214112240C5B; Tue, 19 Mar 2013 16:21:07 +0100 (CET) Message-ID: <51488260.7080002@deployingradius.com> Date: Tue, 19 Mar 2013 11:21:04 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Peter Deacon References: <514824E0.1000506@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] Meeting laundry list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 19 Mar 2013 15:21:53 -0000 Peter Deacon wrote: > I don't know that "overload" is applicable in this context or why it > couldn't be used for multiple purposes concurrently. Yeah. Fill it with whatever makes you happy. > We don't really know generally what constitutes a "loop" or granularity > of the system box (Parts of one server or entire groups of servers). > Messages may be able to loop back for another round of processing after > being sent outside the admin domain. I agree. I think using an opaque token is a good idea. Using an IP address is more fragile, and prone to disclosing private information. > Perhaps some general guidance or blunt tools like TTLs on stack of > proxy-states. FreeRADIUS just has a config option which says "too many". It's good for blunt checks. Having some guidance for detecting proxy loops would be good. Alan DeKok. From presnick@qti.qualcomm.com Mon Mar 18 15:31:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D277221F8B64 for ; Mon, 18 Mar 2013 15:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqDkqtwK-UW9 for ; Mon, 18 Mar 2013 15:31:35 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB6A21F8ADC for ; Mon, 18 Mar 2013 15:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1363645895; x=1395181895; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=+UpWhlNKI9ztejaQTi7rBOW7ZbsCKOdPt/+QsIhvv6k=; b=Ca0sr4DJF4XAEJHkk3qbkBTnALQO4IWZq/hupy+Q96W4rlsBSco1Cgy4 bR+R8h63R+k3zFugyTla5gBUQpIzHpsHwKHRctBnu7AiFDJ7Vf/gA/FEo NnaSeK1Kg5PqoSDMLK/FeD6cmKFs6MvnfpcNUJZ2N0jFPfnP5qumx1qr0 s=; X-IronPort-AV: E=Sophos;i="4.84,867,1355126400"; d="scan'208,217";a="30523906" Received: from ironmsg04-l.qualcomm.com ([172.30.48.19]) by sabertooth01.qualcomm.com with ESMTP; 18 Mar 2013 15:31:34 -0700 X-IronPort-AV: E=Sophos;i="4.84,867,1355126400"; d="scan'208,217";a="419177799" Received: from nasanexhc08.na.qualcomm.com ([172.30.39.7]) by Ironmsg04-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 18 Mar 2013 15:31:34 -0700 Received: from presnick-mac.local (172.30.39.5) by qcmail1.qualcomm.com (172.30.39.7) with Microsoft SMTP Server (TLS) id 14.2.318.4; Mon, 18 Mar 2013 15:31:33 -0700 Message-ID: <514795BD.10001@qti.qualcomm.com> Date: Mon, 18 Mar 2013 16:31:25 -0600 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------050307040900030606030909" X-Originating-IP: [172.30.39.5] X-Mailman-Approved-At: Tue, 19 Mar 2013 08:30:22 -0700 Cc: radext@ietf.org, Barry Leiba Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Mar 2013 22:31:43 -0000 --------------050307040900030606030909 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit This might be something we want to discuss in the contact of PRECIS, but let's get started just between us: Are these identifiers (usernames, realm names) things that users actually type in (i.e., user interface elements) or are they protocol elements? The answer will very much depend on which sort of thing they are. (And I have a sneaking suspicion that you're going to tell me that they are both, which is going to make your job much more difficult.) So, at what layer are these things used? pr On 3/18/13 3:52 PM, Sam Hartman wrote: > Dear Pete and Barry: > > I think radext could use some help on the i18n front; I'm fairly > convinced that a decision we seem to be making is the wrong approach, > but I don't have quite enough clue or mental bandwidth to argue it. > Briefly, we're debating where normalization of network access > identifiers should happen. > I'm reasonably sure that this is a case where normalization should > happen as close to use as possible. > The current thinking seems to be that normalization should happen on the > client and I think many of the reasons that have made that approach > problematic for other architectures apply here. > > Any chance you could get someone to review this draft and take another > look at the issue? > > > > > Subject: > Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt > From: > Alan DeKok > Date: > Mon, 18 Mar 2013 15:34:04 -0400 > To: > Jim Schaad > > To: > Jim Schaad > CC: > 'Sam Hartman' , 'Stefan Winter' > , > > > I agree with Jim here. > > As I write RADIUS servers instead of supplicants, I think the > normalization work should be pushed off onto supplicants. > > The document already says that realm names MUST be registrable as > names within DNS. DNS requires NFC. Therefore, realms are NFC. Any > supplicant injecting non-NFC names is wrong. > > re: Sam's comments on i18n space, I'm not sure it's relevant to have > the home server normalize the realm name. I'm curious to know what > information is in the non-NFC form which is needed by the home server. > > The home server knows who it's users are, and can just use names, > without a realm portion. If it gets a realm, it verifies that it owns > the realm, but that verification is largely site-specific. e.g. > EXAMPLE\foo versus foo@example.com. > > So the main use for realms is proxies. They don't care about the > *content* of the realm. They just want to use it as an opaque token. > Realm A goes to RADIUS server for Realm A, etc. > > Alan DeKok. > > -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 --------------050307040900030606030909 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit This might be something we want to discuss in the contact of PRECIS, but let's get started just between us:

Are these identifiers (usernames, realm names) things that users actually type in (i.e., user interface elements) or are they protocol elements? The answer will very much depend on which sort of thing they are. (And I have a sneaking suspicion that you're going to tell me that they are both, which is going to make your job much more difficult.) So, at what layer are these things used?

pr

On 3/18/13 3:52 PM, Sam Hartman wrote: 
Dear Pete and Barry:

I think radext  could use some help on the i18n front; I'm fairly
convinced that a decision we seem to be making is the wrong approach,
but I don't have quite enough clue or mental bandwidth to argue it.
Briefly, we're debating where normalization of network access
identifiers should happen.
I'm reasonably sure that this is a case where normalization should
happen as close to use as possible.
The current thinking seems to be that normalization should happen on the
client and I think many of the reasons that have made that approach
problematic for other architectures apply here.

Any chance you could get someone to review this draft and take another
look at the issue?

Subject:
Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt
From:
Alan DeKok <aland@deployingradius.com>
Date:
Mon, 18 Mar 2013 15:34:04 -0400
To:
Jim Schaad <ietf@augustcellars.com>
To:
Jim Schaad <ietf@augustcellars.com>
CC:
'Sam Hartman' <hartmans@painless-security.com>, 'Stefan Winter' <stefan.winter@restena.lu>, <radext@ietf.org>		 

  I agree with Jim here.

  As I write RADIUS servers instead of supplicants, I think the
normalization work should be pushed off onto supplicants.

  The document already says that realm names MUST be registrable as
names within DNS.  DNS requires NFC.  Therefore, realms are NFC.  Any
supplicant injecting non-NFC names is wrong.

  re: Sam's comments on i18n space, I'm not sure it's relevant to have
the home server normalize the realm name.  I'm curious to know what
information is in the non-NFC form which is needed by the home server.

  The home server knows who it's users are, and can just use names,
without a realm portion.  If it gets a realm, it verifies that it owns
the realm, but that verification is largely site-specific.  e.g.
EXAMPLE\foo versus foo@example.com.

  So the main use for realms is proxies.  They don't care about the
*content* of the realm.  They just want to use it as an opaque token.
Realm A goes to RADIUS server for Realm A, etc.

  Alan DeKok.

  

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478
--------------050307040900030606030909-- From aland@deployingradius.com Tue Mar 19 10:46:37 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B583B21F8D8C for ; Tue, 19 Mar 2013 10:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.684 X-Spam-Level: X-Spam-Status: No, score=-101.684 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKmTsU7rbPD3 for ; Tue, 19 Mar 2013 10:46:37 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8549F21F8D1E for ; Tue, 19 Mar 2013 10:46:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id F26012240F4B; Tue, 19 Mar 2013 18:45:59 +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 iCNx3hvVbSgj; Tue, 19 Mar 2013 18:45:58 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id 1E71A2240F0E; Tue, 19 Mar 2013 18:45:58 +0100 (CET) Message-ID: <5148A454.8040102@deployingradius.com> Date: Tue, 19 Mar 2013 13:45:56 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Pete Resnick References: <514795BD.10001@qti.qualcomm.com> In-Reply-To: <514795BD.10001@qti.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Sam Hartman , Barry Leiba , radext@ietf.org Subject: Re: [radext] I18N help: : I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:46:37 -0000 Pete Resnick wrote: > This might be something we want to discuss in the contact of PRECIS, but > let's get started just between us: I've been showing up at Precis for a while. > Are these identifiers (usernames, realm names) things that users > actually type in (i.e., user interface elements) or are they protocol > elements? The answer will very much depend on which sort of thing they > are. (And I have a sneaking suspicion that you're going to tell me that > they are both, which is going to make your job much more difficult.) So, > at what layer are these things used? A large percentage of the identifiers will be entered by users. They will then be used in various protocols to identify the users, and the domains to which the users belong. The traditional practice in RADIUS has been to allow pretty much anything as identifiers. The only requirement is that the user and home system agree on the user identifier. The problem we're trying to solve here is proxies. They connect visited networks to home networks. The proxies need a standard format for the user identifier. This is so that they can route domain A to network A, etc. The format of the user portion is less relevant to proxies. It can be pretty much anything. (and is, in practice) Alan DeKok. From aland@deployingradius.com Tue Mar 19 10:57:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E681D21F8CB5 for ; Tue, 19 Mar 2013 10:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.671 X-Spam-Level: X-Spam-Status: No, score=-101.671 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cOmTpdXGb6K4 for ; Tue, 19 Mar 2013 10:57:18 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF1421F8C84 for ; Tue, 19 Mar 2013 10:57:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 441872240F4B; Tue, 19 Mar 2013 18:57:18 +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 Py2wFjb9jmfO; Tue, 19 Mar 2013 18:57:17 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id 6DC442240F0E; Tue, 19 Mar 2013 18:57:17 +0100 (CET) Message-ID: <5148A6FB.9050807@deployingradius.com> Date: Tue, 19 Mar 2013 13:57:15 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> <5148822F.5070708@restena.lu> In-Reply-To: <5148822F.5070708@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2013 17:57:19 -0000 Stefan Winter wrote: > Then I'd suggest making this very explicit. E.g. replace the previous > sentence with > > "See [RFC5198] and section 2.6 of this specification for a discussion of > normalization. Strings which are not in Normal Form Composed (NFC) are > not valid NAIs and SHOULD NOT be treated as such." Looks good to me. > I don't think servers are the main problem when it comes to > normalisation (or just valid UTF-8 in the first place). I have much more > concerns about ignorant supplicants. I agree. It would be nice to support feedback in one of the EAP methods (e.g. TEAP). A server could say "Thanks for using DOMAIN', but next time please use DOMAIN". > With the multitude of end-user computing devices in the wild, and the > varying amounts of care firmware writers spend into their supplicant > code, I'm sure there'll be a whole zoo of representations of > internationalised domain names on the supplicant side :-( Yes. Which is why I'd like to get the NAI document published. RFC 4282 is distressingly broken. Being able to point to a *good* document would be useful. > Would it be okay to *RECOMMEND* that UTF-8 which is not in NFC should be > normalised prior to "doing something" in terms of lookup in the config? Yes. Alan DeKok. From stefan.winter@restena.lu Wed Mar 20 01:32:43 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3749621F8626 for ; Wed, 20 Mar 2013 01:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rl3zMq1yMJg8 for ; Wed, 20 Mar 2013 01:32:42 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC0321F8615 for ; Wed, 20 Mar 2013 01:32:42 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id AFCFE1058E for ; Wed, 20 Mar 2013 09:32:41 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:2c8d:1153:26f:7c78]) by smtprelay.restena.lu (Postfix) with ESMTPS id 97A971057F for ; Wed, 20 Mar 2013 09:32:41 +0100 (CET) Message-ID: <51497429.9090607@restena.lu> Date: Wed, 20 Mar 2013 09:32:41 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> <5148822F.5070708@restena.lu> <5148A6FB.9050807@deployingradius.com> In-Reply-To: <5148A6FB.9050807@deployingradius.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2LOTWGLPLKBLMSEXMQMKH" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 08:32:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2LOTWGLPLKBLMSEXMQMKH Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > Yes. Which is why I'd like to get the NAI document published. RFC > 4282 is distressingly broken. Being able to point to a *good* document= > would be useful. >=20 >> Would it be okay to *RECOMMEND* that UTF-8 which is not in NFC should = be >> normalised prior to "doing something" in terms of lookup in the config= ? >=20 > Yes. Great. I think an extra sentence in addition to the above should make this fit nicely: "See [RFC5198] and section 2.6 of this specification for a discussion of normalization. Strings which are not in Normal Form Composed (NFC) are not valid NAIs and SHOULD NOT be treated as such. Implementations which expect to receive a NAI, but get non-normalised (but otherwise valid) UTF-8 strings instead SHOULD attempt to normalise the input to NFC for local processing." ? Greetings, Stefan Winter >=20 > Alan DeKok. > _______________________________________________ > 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 ------enig2LOTWGLPLKBLMSEXMQMKH Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFJdCkACgkQ+jm90f8eFWbw+gCeNnqBljpLIWNNBTA76lmC+/ik TMcAni2IXA/Kmdxeha5799Qz8wsWDQi7 =/DC1 -----END PGP SIGNATURE----- ------enig2LOTWGLPLKBLMSEXMQMKH-- From stefan.winter@restena.lu Wed Mar 20 02:12:13 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A144D21F86DC for ; Wed, 20 Mar 2013 02:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yJ7M6Hyll-Ok for ; Wed, 20 Mar 2013 02:12:12 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 86F4221F8667 for ; Wed, 20 Mar 2013 02:12:12 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E80D21058E for ; Wed, 20 Mar 2013 10:12:11 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:2c8d:1153:26f:7c78]) by smtprelay.restena.lu (Postfix) with ESMTPS id D510E1057F for ; Wed, 20 Mar 2013 10:12:11 +0100 (CET) Message-ID: <51497D67.2090604@restena.lu> Date: Wed, 20 Mar 2013 10:12:07 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <514824E0.1000506@restena.lu> <51488260.7080002@deployingradius.com> In-Reply-To: <51488260.7080002@deployingradius.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2UWETPPXFSPQQEREXNXUA" X-Virus-Scanned: ClamAV Subject: Re: [radext] Meeting laundry list X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 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, 20 Mar 2013 09:12:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2UWETPPXFSPQQEREXNXUA Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, >> I don't know that "overload" is applicable in this context or why it >> couldn't be used for multiple purposes concurrently. >=20 > Yeah. Fill it with whatever makes you happy. >=20 >> We don't really know generally what constitutes a "loop" or granularit= y >> of the system box (Parts of one server or entire groups of servers). >> Messages may be able to loop back for another round of processing afte= r >> being sent outside the admin domain. >=20 > I agree. I think using an opaque token is a good idea. Using an IP > address is more fragile, and prone to disclosing private information. Sure; my use of "(or other halfways unique ID)" is basically about cases where one needs to control granularity. E.g. I have two redundant servers in failover: tld1.eduroam.lu and tld2.eduroam.lu - the ID could then be "tld.eduroam.lu" to indicate that the packet went through either of the two already and shouldn't come back later. Of course even loops that ping-pong between multiple hops would eventually be detected, as soon as the packet comes back to one of the servers which used his own mark. So in effect any random value is good enough, doesn't have to be an IP address. It has to be random enough though, so that no two hops accidently use the same ID. >> Perhaps some general guidance or blunt tools like TTLs on stack of >> proxy-states. >=20 > FreeRADIUS just has a config option which says "too many". It's good= > for blunt checks. >=20 > Having some guidance for detecting proxy loops would be good. Yes! It's good to hear that Peter's implementation does some magic with Proxy-State - but it would be even better to write down something like that for every implementation's benefit. E.g. in FreeRADIUS Proxy-State is not under config control and it doesn't do such clever comparisons yet. With a good spec, this could become a config switch "do_loop_checks" which would do all that Proxy-State magic automatically, without any fiddling with VSAs and such. I wonder if Peter feels like putting this into an I-D...? Greetings, Stefan Winter >=20 > Alan DeKok. > _______________________________________________ > 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 ------enig2UWETPPXFSPQQEREXNXUA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFJfWsACgkQ+jm90f8eFWbQGwCfeGI+3bBTRJNIDyWuQ6k4bq32 A3kAnRUTEsA4YwQcG7JRmTTdqB9Iod1f =6L9U -----END PGP SIGNATURE----- ------enig2UWETPPXFSPQQEREXNXUA-- From emile@e-advies.nl Wed Mar 20 01:40:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE0E21F8675 for ; Wed, 20 Mar 2013 01:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.504 X-Spam-Level: X-Spam-Status: No, score=-0.504 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdeHgsU9W5Hv for ; Wed, 20 Mar 2013 01:40:57 -0700 (PDT) Received: from host.e-advies.nl (host.e-advies.nl [93.174.104.94]) by ietfa.amsl.com (Postfix) with SMTP id D7E1621F8A64 for ; Wed, 20 Mar 2013 01:40:56 -0700 (PDT) Received: (qmail 31965 invoked by uid 33); 20 Mar 2013 08:40:53 -0000 To: Stefan Winter X-PHP-Originating-Script: 0:func.inc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: Wed, 20 Mar 2013 09:40:53 +0100 From: Emile van Bergen In-Reply-To: <51497429.9090607@restena.lu> References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> <5148822F.5070708@restena.lu> <5148A6FB.9050807@deployingradius.com> <51497429.9090607@restena.lu> Message-ID: X-Sender: emile@e-advies.nl User-Agent: RoundCube Webmail/0.3.1 X-Mailman-Approved-At: Wed, 20 Mar 2013 05:39:37 -0700 Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 08:41:57 -0000 Hi, On Wed, 20 Mar 2013 09:32:41 +0100, Stefan Winter wrote: > Great. I think an extra sentence in addition to the above should make > this fit nicely: > > "See [RFC5198] and section 2.6 of this specification for a discussion of > normalization. Strings which are not in Normal Form Composed (NFC) are > not valid NAIs and SHOULD NOT be treated as such. > > Implementations which expect to receive a NAI, but get non-normalised > (but otherwise valid) UTF-8 strings instead SHOULD attempt to normalise > the input to NFC for local processing." > > ? I read these as two slightly conflicting clauses, both written from the receiver's viewpoint. I've often found the way that IETF documents dissect 'validity' into separate requirements for senders and receivers. How about: "See [RFC5198] and section 2.6 of this specification for a discussion of normalization. Strings which are not in Normal Form Composed (NFC) are not valid NAIs and MUST NOT be sent by compliant implementations. Implementations which expect to receive a NAI, but get non-normalised (but otherwise valid) UTF-8 strings instead SHOULD attempt to normalise the input to NFC for local processing." Following Jon Postel's "be conservative in what you send, be liberal in what you accept"? Kind regards, Emile van Bergen. From aland@deployingradius.com Wed Mar 20 06:00:46 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDC221F8E38 for ; Wed, 20 Mar 2013 06:00:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.66 X-Spam-Level: X-Spam-Status: No, score=-101.66 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, RCVD_IN_SORBS_HTTP=0.001, RCVD_IN_SORBS_MISC=0.353, RCVD_IN_SORBS_SOCKS=0.801, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RagJCZ7NVixn for ; Wed, 20 Mar 2013 06:00:45 -0700 (PDT) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA50221F8E34 for ; Wed, 20 Mar 2013 06:00:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 859F72240D37; Wed, 20 Mar 2013 14:00:17 +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 KeVw8cwD7nRl; Wed, 20 Mar 2013 14:00:16 +0100 (CET) Received: from Thor-2.local (bas1-ottawa11-1177690350.dsl.bell.ca [70.50.32.238]) by power.freeradius.org (Postfix) with ESMTPSA id 17BDB22409C6; Wed, 20 Mar 2013 14:00:15 +0100 (CET) Message-ID: <5149B2DE.1010106@deployingradius.com> Date: Wed, 20 Mar 2013 09:00:14 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Emile van Bergen References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> <5148822F.5070708@restena.lu> <5148A6FB.9050807@deployingradius.com> <51497429.9090607@restena.lu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Winter , radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:00:46 -0000 Emile van Bergen wrote: > I've often found the way that IETF documents dissect 'validity' into > separate requirements for senders and receivers. How about: > > "See [RFC5198] and section 2.6 of this specification for a discussion of > normalization. Strings which are not in Normal Form Composed (NFC) are > not valid NAIs and MUST NOT be sent by compliant implementations. > > Implementations which expect to receive a NAI, but get non-normalised > (but otherwise valid) UTF-8 strings instead SHOULD attempt to normalise > the input to NFC for local processing." That text is ambiguous about whether or not you re-write the NAI in the packet. People will read it incorrectly. How about this: Implementations which expect to receive a NAI, but get non-normalised (but otherwise valid) UTF-8 strings instead SHOULD attempt to create a local version of the NAI, which is normalized from the input identifier. This local version can then be used for local processing. Alan DeKok. From stefan.winter@restena.lu Wed Mar 20 06:07:45 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FA3821F8F41 for ; Wed, 20 Mar 2013 06:07:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hlo7zF3f42aX for ; Wed, 20 Mar 2013 06:07:45 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6621F851C for ; Wed, 20 Mar 2013 06:07:44 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5CD1210590 for ; Wed, 20 Mar 2013 14:07:44 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:2c8d:1153:26f:7c78]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4F6681058E for ; Wed, 20 Mar 2013 14:07:44 +0100 (CET) Message-ID: <5149B49C.8080909@restena.lu> Date: Wed, 20 Mar 2013 14:07:40 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> <5148822F.5070708@restena.lu> <5148A6FB.9050807@deployingradius.com> <51497429.9090607@restena.lu> <5149B2DE.1010106@deployingradius.com> In-Reply-To: <5149B2DE.1010106@deployingradius.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2LJQXGRFICWGXNRRQSIRK" X-Virus-Scanned: ClamAV Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:07:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2LJQXGRFICWGXNRRQSIRK Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > That text is ambiguous about whether or not you re-write the NAI in > the packet. People will read it incorrectly. How about this: >=20 > Implementations which expect to receive a NAI, but get non-normalised= > (but otherwise valid) UTF-8 strings instead SHOULD attempt to create = a > local version of the NAI, which is normalized from the input > identifier. This local version can then be used for local processing= =2E Sounds good to me. Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2LJQXGRFICWGXNRRQSIRK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFJtKAACgkQ+jm90f8eFWZAmwCeKOVCKrw55IyW+bD8r4l3mbhN yfUAnjbi3WB1SRUYQxuNTPAzDkFNkWni =cq2r -----END PGP SIGNATURE----- ------enig2LJQXGRFICWGXNRRQSIRK-- From hartmans@painless-security.com Wed Mar 20 06:12:18 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8F5C21F89A6 for ; Wed, 20 Mar 2013 06:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjxFC3HYc+HP for ; Wed, 20 Mar 2013 06:12:18 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 5439321F8B9F for ; Wed, 20 Mar 2013 06:12:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id CD398201E2; Wed, 20 Mar 2013 09:11:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B8E07447D; Wed, 20 Mar 2013 09:12:08 -0400 (EDT) From: Sam Hartman To: Stefan Winter References: <20130128155031.8392.45953.idtracker@ietfa.amsl.com> <5147172F.8090100@restena.lu> <08fd01ce23f5$cf8d0b90$6ea722b0$@augustcellars.com> <091f01ce240a$6705a860$3510f920$@augustcellars.com> <51476C2C.5070000@deployingradius.com> <5148192B.90507@restena.lu> <514868A0.2040207@deployingradius.com> <5148822F.5070708@restena.lu> <5148A6FB.9050807@deployingradius.com> <51497429.9090607@restena.lu> Date: Wed, 20 Mar 2013 09:12:08 -0400 In-Reply-To: <51497429.9090607@restena.lu> (Stefan Winter's message of "Wed, 20 Mar 2013 09:32:41 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: radext@ietf.org Subject: Re: [radext] I-D Action: draft-ietf-radext-nai-02.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 13:12:18 -0000 With regard to the i18n issues, having asked others to look at it, I'm withdrawing my objection. I simply don't have time to be a driving force behind confirming that my concerns are real and going through a joint education process here as I learn Alan's side and try and explain my concerns. If people from the apps area look at the document and choose to raise their own concerns, that's fine. However I want to make it clear to the chairs and WG that in terms of judging consensus on the document I'm not objecting. --Sam From xueli@huawei.com Wed Mar 27 19:12:58 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B62F321E8091 for ; Wed, 27 Mar 2013 19:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U0xmt1THOTR for ; Wed, 27 Mar 2013 19:12:58 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A449421E808E for ; Wed, 27 Mar 2013 19:12:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APV86699; Thu, 28 Mar 2013 02:12:47 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 28 Mar 2013 02:12:23 +0000 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 28 Mar 2013 02:12:44 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.01.0323.007; Thu, 28 Mar 2013 10:12:41 +0800 From: Xueli To: "radext@ietf.org" Thread-Topic: New Version Notification for draft-xue-radext-key-management-00.txt Thread-Index: AQHODctrXQqgUW2PJUOZQ4tODkgQZpi6lwXw Date: Thu, 28 Mar 2013 02:12:41 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.95] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 02:12:58 -0000 SGkgYWxsDQoNClRoZXJlIGlzIGEgZHJhZnQgdG8gcmVzb2x2ZSB0aGUgc29tZSBpc3N1ZSByYWlz ZWQgaW4gV0xBTiBuZXR3b3JrLg0KDQpJbiB0aGUgYXV0aGVudGljYXRpb24gYXJjaGl0ZWN0dXJl LCBvbmx5IFNUQSBhbmQgQVMgY2FuIG1hbnVmYWN0dXJlIFBNSywgDQptb3Jlb3ZlciwgQVMgY2Fu IG9ubHkgZGlzdHJpYnV0ZSBQTUsgdG8gQXV0aGVudGljYXRvci5Ib3dldmVyLCBpZiB0aGUgYXV0 aGVudGljYXRvciBmdW5jdGlvbiBpcyBub3QgY29sbG9jYXRlZA0Kd2l0aCB0aGUgZW5jcnlwdGlv bi9kZWNyeXB0aW9uIGZ1bmN0aW9uLCBpdCBpcyBkaWZmaWN1bHQgdG8gYWNoaWV2ZSB0cmFmZmlj IGVuY3J5cHRpb24vZGVjcnlwdGlvbiBpbiBXTEFOIG5ldHdvcmsuDQoNClRoZSBwdXJwb3NlIG9m IHRoaXMgZG9jdW1lbnQgaXMgdG8gYW5hbHl6ZSB0aGUgcmVxdWlyZW1lbnQgYW5kIGlzc3VlIGZv ciBrZXkgbWFuYWdlbWVudCB0aGF0IGhhdmUgYXJpc2VuIHNvIGZhciANCmR1cmluZyBTVEEgYXV0 aGVudGljYXRpb24gcHJvY2VzcyBpbiBXTEFOIG5ldHdvcmsuIE1lYW53aGlsZSwgdGhlIGNvbnRy b2wgbWVzc2FnZXMgZm9yIGtleSBtYW5hZ2VtZW50IGFyZSBkZWZpbmVkLg0KDQpZb3VyIGNvbW1l bnRzIGFyZSBhcHByZWNpYXRlZC4NCg0KQlINCkxpDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmddDQo+U2VudDogTW9uZGF5LCBGZWJydWFyeSAxOCwgMjAxMyA3OjMxIFBNDQo+ VG86IFh1ZWxpDQo+U3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC14 dWUtcmFkZXh0LWtleS1tYW5hZ2VtZW50LTAwLnR4dA0KPg0KPg0KPkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC14dWUtcmFkZXh0LWtleS1tYW5hZ2VtZW50LTAwLnR4dA0KPmhhcyBiZWVuIHN1 Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgTGkgWHVlIGFuZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiBy ZXBvc2l0b3J5Lg0KPg0KPkZpbGVuYW1lOgkgZHJhZnQteHVlLXJhZGV4dC1rZXktbWFuYWdlbWVu dA0KPlJldmlzaW9uOgkgMDANCj5UaXRsZToJCSBSQURJVVMgRXh0ZW5zaW9ucyBmb3IgS2V5IE1h bmFnZW1lbnQgaW4gV0xBTiBuZXR3b3JrDQo+Q3JlYXRpb24gZGF0ZToJIDIwMTMtMDItMTgNCj5H cm91cDoJCSBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5OdW1iZXIgb2YgcGFnZXM6IDE3DQo+VVJM Og0KPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXh1ZS1yYWRleHQt a2V5LW1hbmFnZW1lbnQtMDAudHh0DQo+U3RhdHVzOg0KPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQteHVlLXJhZGV4dC1rZXktbWFuYWdlbWVudA0KPkh0bWxpemVkOg0KPmh0 dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1ZS1yYWRleHQta2V5LW1hbmFnZW1lbnQt MDANCj4NCj4NCj5BYnN0cmFjdDoNCj4gICBJbiBvcmRlciB0byBndWFyYW50ZWUgdGhlIHNlY3Vy aXR5IGFuZCBpbnRlZ3JhdGlvbiBvZiB0aGUgc3Vic2NyaWJlcg0KPiAgIGluIFdMQU4gbmV0d29y aywgUGFpcndpc2UgTWFzdGVyIEtleSAoUE1LKSB3aWxsIGJlIGdlbmVyYXRlZCBhcyBhbg0KPiAg IGFjY2VzcyBhdXRob3JpemF0aW9uIHRva2VuIGR1cmluZyB0aGUgbXV0dWFsIGF1dGhlbnRpY2F0 aW9uIHByb2NlZHVyZQ0KPiAgIGJldHdlZW4gc3RhdGlvbiAoU1RBKSBhbmQgYXV0aGVudGljYXRv ciBzZXJ2ZXIgKEFTKS4gIFRoZW4sIHRoZSBQTUsNCj4gICBhbmQgNC13YXkgaGFuZHNoYWtlIGFy ZSB1c2VkIGJldHdlZW4gU1RBIGFuZCBBdXRoZW50aWNhdG9yIHRvIGRlcml2ZSwNCj4gICBiaW5k IGFuZCB2ZXJpZnkgdGhlIFBhaXJ3aXNlIFRyYW5zaWVudCBLZXkgKFBUSyksIHdoaWNoIGlzIGEN Cj4gICBjb2xsZWN0aW9uIG9mIG9wZXJhdGlvbmFsIGtleXMgZm9yIHNlY3VyaXR5LiAgQWxzbyxH cm91cCBUcmFuc2llbnQNCj4gICBLZXkgKEdUSykgY2FuIGJlIGRlcml2ZWQsIGFuZCBpcyB1c2Vk IHRvIHNlY3VyZSBtdWx0aWNhc3QvYnJvYWRjYXN0DQo+ICAgdHJhZmZpYy4gIEluIHRoZSBhdXRo ZW50aWNhdGlvbiBhcmNoaXRlY3R1cmUsIG9ubHkgU1RBIGFuZCBBUyBjYW4NCj4gICBtYW51ZmFj dHVyZSBQTUssIG1vcmVvdmVyLCBBUyBjYW4gb25seSBkaXN0cmlidXRlIFBNSyB0bw0KPiAgIEF1 dGhlbnRpY2F0b3IuSG93ZXZlciwgaWYgdGhlIGF1dGhlbnRpY2F0b3IgZnVuY3Rpb24gaXMgbm90 DQo+ICAgY29sbG9jYXRlZCB3aXRoIHRoZSBlbmNyeXB0aW9uL2RlY3J5cHRpb24gZnVuY3Rpb24s IGl0IGlzIGRpZmZpY3VsdA0KPiAgIHRvIGFjaGlldmUgdHJhZmZpYyBlbmNyeXB0aW9uL2RlY3J5 cHRpb24gaW4gV0xBTiBuZXR3b3JrLlRoZSBwdXJwb3NlDQo+ICAgb2YgdGhpcyBkb2N1bWVudCBp cyB0byBhbmFseXplIHRoZSByZXF1aXJlbWVudCBhbmQgaXNzdWUgZm9yIGtleQ0KPiAgIG1hbmFn ZW1lbnQgdGhhdCBoYXZlIGFyaXNlbiBzbyBmYXIgZHVyaW5nIFNUQSBhdXRoZW50aWNhdGlvbiBw cm9jZXNzDQo+ICAgaW4gV0xBTiBuZXR3b3JrLiAgTWVhbndoaWxlLCB0aGUgY29udHJvbCBtZXNz YWdlcyBmb3Iga2V5DQo+bWFuYWdlbWVudA0KPiAgIGFyZSBkZWZpbmVkLg0KPg0KPg0KPg0KPg0K PlRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From ietf@augustcellars.com Thu Mar 28 15:43:57 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBD121F8F0D for ; Thu, 28 Mar 2013 15:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7I25tGGHyGbt for ; Thu, 28 Mar 2013 15:43:55 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4E97221F8F0B for ; Thu, 28 Mar 2013 15:43:52 -0700 (PDT) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B77E738EF4; Thu, 28 Mar 2013 15:43:51 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 28 Mar 2013 15:43:15 -0700 Message-ID: <003501ce2c05$a2f4bd90$e8de38b0$@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: Ac4qe+LoC9LeZppTRz2g9935nx0TGA== Content-Language: en-us Cc: radext@ietf.org Subject: [radext] Comments on draft-wierenga-ietf-eduroam-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Mar 2013 22:43:57 -0000 Remember you asked for it. I am CC-ing the radext list for completeness not because I believe this should be a radext working group document. 1. It is not clear to me that the use of RFC 2119 language is appropriate to a document that is describing what the current design is. 2. Introduction: Suggest that the introduction should give a layout of the document as well. Specifically there are two ways to organize the second half of the draft or and it would be good to set expectations of this upfront. 3. Given that RFC 6614 and 6613 are experimental - do you want to say /IETF standardization efforts/? 4. Section 1.3 - Who has to be able to identify users? Just the IdP or the NAS as well? 5. what does it mean to either impersonate someone or to take over their identity? If I give you my name and password it is possible for you to impersonate me. This language should be tightened. 6. Do you really want me to be able to access your network or are you going to provide a public network for me to be able to access and use? It might need to be clearer what is going on. The first implies a greater degree of identification that might actually exist. 7. I can see three different vectors of scalability - it might be useful to tease that out. Users, Orgs providing access, Orgs hosting users. Are the last two a one-to-one or not? 8. For whom does it need to be easy to install and use - just clients or organizations as well? Can it be hard for an org to setup and still be easy for clients? 9. In the paragraph on security, I don't understand the purpose of the first sentence. This would tend to argue that secure is not an absolute design goal. There may be a trade off, but that would be a design goal of usability which is separate. 10. The goal is secure and privacy preserving - however there is nothing in the text about who the privacy is supposed to be protected from. While I guess it could be the third part, that is hardly the limit of who one could wish for privacy to be protected from. Do you care about privacy from the visited SP? Should the IdP be able to know who the client is visiting? 11. It is laid out that organizations should be able to set their own authentication structure. Is there going to be a minimum security that is imposed on organizations by the eduroam federation? 12. Were any other options considered for the architecture? If so why were they not used? 13. Section 2 - If you read the ABFAB architecture document, I think we talk about three different trust relationships. Two of which are "pre-existing" and one of which is established during the protocol. 14. Going from the term type of trust to trust relationship does don't flow well. 15. The term establishment is potentially confusing in this location. Are you talking about for a single event or initial establishment (i.e. introduction ) between the user and the IdP. 16. Section 2.1 - I can understand that authentication uses EAP. However how does it use 802.1X and not use RADIUS for authentication? If 802.1x does anything other than carry EAP this should be covered. Otherwise you should probably include RADIUS here as well. 17. Section 2.1.1 ?? wireless networks MUST support WPA2+AES - What does this mean? It is a requirement that all networks deploy this or merely that the hardware has the capability to use it? If a network deploys both WPA2 and WPA does that require that multiple SSIDs be used? If so is there a naming convention that is documented for this usage type? 18. What are the security implications of not knowing who the SP is - since all SSIDs are "eduroam" it is not possible to distinguish from a user perspective which are not to be used. 19. Discuss the trade of for not always using "eduroam-foo" as the SSID 20. Section 2.1.2 - What guidance is the federation giving on EAP methods - is that of interest to this document? 21. What is the "policy with regards to security properties" 22. I don't understand the purpose of Figure 1 - It does not appear to be reference from the text in any way. The picture would seem to be underspecified in that the specific protocols are not put any place (i.e. X802.1x) and the term EAP tunnel is not introduced in any manner. As with the ABFAB document I did like that it is not clear that the tunneled eap is not traveling directly between the host and the authentication server. 23. Note that mutual authentication does not imply privacy. If I authenticate with EAP-TLS and send both the server and the client certificates in the clear then I have mutual authentication however I have no privacy on identities. 24. The term outer identity is problematic. There is the EAP outer identity - and then there is the RADIUS user-identity attribute. The routing is done on the later and it is generally (but not always) copied from the initial EAP method. However not all methods will have a distinct inner identity. Is there an identity that is transmitted on 802.1x that is used rather than the first eap name? 25. When did you suddenly say than a TLS tunnel was required. If this is true it should be stated someplace explicitly. This is not a requirement on IdPs that was not there before. 26. Do you want to say that outer identities must be NAIs or not? 27.. Section 2.2.1 - You just sprang a national server on me without telling me what it represents. Are you assuming that all routing is two levels deep or is there three and four level deep routing. 28. Do you want to say at this point who is operating the national servers and root servers? On what basis will they setup or remove shared secrets with organizations? 29. What are the trade offs of using anonymous@surfnet.nl vs @surnet.nl for the outer identity? 30. What, if anything needs to be said about the trust needed between the access points and the organization RADIUS server. Is this under some type of protections? 31. Section 3 - Not all of the issues appear to be future problems that are expected. This paragraph should be expanded to say that current operations have identified problems, in addition others are expected with an increase of ... 32. Section 3.1 - I think the word you are looking for is deduced rather than deducted in many of these sentences. 33. I have a slight problem with the fact that you are using down the authentication path since you have just told me that it is a tree and thus has both an up and a down component. 'Along' might be a better choice. 34. I would not use the term proxy chain when looking at the length. I would just say that the radius authentication chain contains more than one hop. If there were no proxies then you have no problems, but in that case the proxy chain is 0 hops? 1 hop? Not clear. 35. I assume that if a server which is believed to be "dead" sends you an authentication request then you would also know that it is now live (step 3) 36. One option that is not discussed here is the option of always flooding and never assuming anything but realms fail. What are the operational problem with this approach. 37. Presumably the use of TCP rather than UDP would also help this situation. Since you seem to be talking about ways that can be used to fix this here. 38. Section 3.2 - ? reactively or retroactively? 39. You don't say how much improvements from section 3.1 would deal with this issue. If you could get reliable - don't fail because I did not get a reply - does this help the situation in the event of no reply? 40. What would be the security implications of being able to inject an error code into the stream by a middle man? Are they any worse than the injection of an access-deny? 41. Do you need to talk about dropped packets in this context as well as dead servers? 42. If 802.1x does not allow for returning errors. Are you suggesting that the RADIUS servers would inject EAP packets in the event of failures or should this be handled by the NAS? 43. Section 3.3 - You need to tell me what a ccTLD and a gTLD are 44. What are the "downsides" to routing based on insertion of new "national" servers that can talk directly to the org servers? These servers would potentially need to be more intelligent - but it would restrict the places where tables need to be routed. Was this considered? 45. I am not sure that I understand why doing an add of a new route would be especially error prone. It seems that this should be easily fixable by a simple tool. Are you ever removing this from the table - it seems that this would be overwhelmed by adds. Are these mappings made at more than just the root level - that is not clear from the discussion although I assume it would be true. 46. Who are you imposing the recommendation on? Is this a new 802.1x requirement for an updated draft? If so is this really what you want - or do you want to be able to negotiate the L2 packet size all the way down? 47. For whom are they hard to diagnose? Are you just talking about users or are you talking about IT departments as well? Are there recommendations on how to do this diagnosis? 48. Section 3.5 - Are EAP MSKs used in this configuration? If so then you have low level encryption on these and it could potentially be stolen and used. 49. It is not clear to me that using a pseudonymous client identifier for the client does much of anything to prevent linking to an actual client. You still can build a large mobility profile. 50. You have not dealt with the issue for TLS of checking that the server certificate is still valid. This is also not currently done. 51. Have you brought up the concept of an EAP configuration meta data format in the EMU group? It is about to close. 52. Is there a reason why you don't reference RADIUS-TLS at this point as this would deal with this issue to a certain extent. I.e. no protection from the proxies but from eavesdroppers. 53. Section 4.1.1 - why is the translation not satisfactorily answered by NASREQ? 54. The last pargraph of 4.1.1. should be the first paragraph of 4.1.2 55. Section 5 - It would seem that placing the policy enforcement with Chargeable User Identity at the RADIUS server nearest the NAS - or at the edge of the organization, would make as much sense as placing it on the NAS itself. This would allow for correlation between different access points and given a better idea of abuse on the network as a whole. Thus using the servers that do this would solve the problem better. 56. Section 5.1 - It may be also taken as evidence that you have no idea of what is going on as you have not identified the serious incident as being serious. 57. Section 5.2 - How does the fact that the home site is now going have the ability to block reflect back on the question of differences of opinion on if the action was abuse or not? What type of protocol is setup for dealing with this type of request- is it automated, done by hand or through the infrastructure? 58. Section 5.3 - Given that home servers are required to regularly churn CUIs, how does this affect the local accounting problems in terms of tracking and preventing people from abusing the system. Can the home IdP simply deal with this issue by changing the CUI of an individual every time an abuse is reported? Random changes s/Abfab/ABFAB/ s/in all continents/on all continents/ s/like for example/like/ s/alternative use/alternative uses/ s/foresaw/?????? - I am not sure what this sentence is supposed to say/ Update reference to privacy terminology draft - it is now draft-iab-private-considerations From stefan.winter@restena.lu Fri Mar 29 06:27:59 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6019D21F9410 for ; Fri, 29 Mar 2013 06:27: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=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5gViT3A2s5F for ; Fri, 29 Mar 2013 06:27:58 -0700 (PDT) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8CE8321F9405 for ; Fri, 29 Mar 2013 06:27:58 -0700 (PDT) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 5A6D810589; Fri, 29 Mar 2013 14:27:57 +0100 (CET) Received: from aragorn.restena.lu (aragorn.restena.lu [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 4359A10581; Fri, 29 Mar 2013 14:27:57 +0100 (CET) Message-ID: <515596D8.1000209@restena.lu> Date: Fri, 29 Mar 2013 14:27:52 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: radext@ietf.org, xueli@huawei.com References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> In-Reply-To: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2GVSTHOAOIHPIXOLHEJDN" X-Virus-Scanned: ClamAV Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 13:27:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2GVSTHOAOIHPIXOLHEJDN Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello, On 28.03.2013 03:12, Xueli wrote: > Hi all >=20 > There is a draft to resolve the some issue raised in WLAN network. >=20 > In the authentication architecture, only STA and AS can manufacture PMK= ,=20 > moreover, AS can only distribute PMK to Authenticator.However, if the a= uthenticator function is not collocated > with the encryption/decryption function, it is difficult to achieve tra= ffic encryption/decryption in WLAN network. >=20 > The purpose of this document is to analyze the requirement and issue fo= r key management that have arisen so far=20 > during STA authentication process in WLAN network. Meanwhile, the contr= ol messages for key management are defined. >=20 > Your comments are appreciated. You attempt to split the role of the Access Point into several sub-entities. This is admirable, but by no means a novelty. There are many proprietary approaches to this, but there's also already a set of RFCs describing a standard way: If you are interested in offloading functions of an AP into separate sub-entities, you should also first take a look at the results of the CAPWAP working group, whose target is to do just that. The advantage of CAPWAP is that it has a much broader scope than "just" the keys for a session. RFC5415 is a good read. Section 10.1 has a "Station Configuration Request" which transmits user session specific data from the controller to the lightweight AP (which you call "FIT" AP in your document - did you mean "thin" as the opposite to "fat"?). The media-specific binding in RFC5416 goes into detail and describes how exactly session keys are transmitted in WLAN (Sections 5.10, 6.15). Greetings, Stefan Winter >=20 > BR > Li >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, February 18, 2013 7:31 PM >> To: Xueli >> Subject: New Version Notification for draft-xue-radext-key-management-= 00.txt >> >> >> A new version of I-D, draft-xue-radext-key-management-00.txt >> has been successfully submitted by Li Xue and posted to the >> IETF repository. >> >> Filename: draft-xue-radext-key-management >> Revision: 00 >> Title: RADIUS Extensions for Key Management in WLAN network >> Creation date: 2013-02-18 >> Group: Individual Submission >> Number of pages: 17 >> URL: >> http://www.ietf.org/internet-drafts/draft-xue-radext-key-management-00= =2Etxt >> Status: >> http://datatracker.ietf.org/doc/draft-xue-radext-key-management >> Htmlized: >> http://tools.ietf.org/html/draft-xue-radext-key-management-00 >> >> >> Abstract: >> In order to guarantee the security and integration of the subscriber= >> in WLAN network, Pairwise Master Key (PMK) will be generated as an >> access authorization token during the mutual authentication procedur= e >> between station (STA) and authenticator server (AS). Then, the PMK >> and 4-way handshake are used between STA and Authenticator to derive= , >> bind and verify the Pairwise Transient Key (PTK), which is a >> collection of operational keys for security. Also,Group Transient >> Key (GTK) can be derived, and is used to secure multicast/broadcast >> traffic. In the authentication architecture, only STA and AS can >> manufacture PMK, moreover, AS can only distribute PMK to >> Authenticator.However, if the authenticator function is not >> collocated with the encryption/decryption function, it is difficult >> to achieve traffic encryption/decryption in WLAN network.The purpose= >> of this document is to analyze the requirement and issue for key >> management that have arisen so far during STA authentication process= >> in WLAN network. Meanwhile, the control messages for key >> management >> are defined. >> >> >> >> >> The IETF Secretariat >=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 ------enig2GVSTHOAOIHPIXOLHEJDN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlFVlt0ACgkQ+jm90f8eFWayVgCgizH32G0v/zDVqTE71YYrv7S5 aj8Ani6n+hjh9AAkHf75aAtHw6TpXVnC =ecLI -----END PGP SIGNATURE----- ------enig2GVSTHOAOIHPIXOLHEJDN-- From kwiereng@cisco.com Fri Mar 29 02:55:12 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC5821F9317 for ; Fri, 29 Mar 2013 02:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G1sDy4X7Ju+p for ; Fri, 29 Mar 2013 02:55:11 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AE11921F9318 for ; Fri, 29 Mar 2013 02:55:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13310; q=dns/txt; s=iport; t=1364550910; x=1365760510; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g32WrpFRj1CtYPhzSD/XRuQW1zLr6BJFy38pBb43a/0=; b=BEVYpFq9vKNkEMQZARCIA4Mu+zCFoB6l2i1KsiOcsYJGXwbaY0IWxjCV ORGSiVuhal5X7t0D8fuWqbnK3OMZV0Wj7BVkmCgdzUESPVETZILrx1EYn ZMVOA707kEFam8oK5WTIy1Njb7FeSgTVuHh8aFDEoYaJeqMgg/PGdkoB3 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqILAFhkVVGtJXG//2dsb2JhbAA5AQmDOoETvg6BBxZ0gh8BAQEDATo4BwULAgEIDgQeBhAyFw4BAQQOAwIbh3MGv2mNXAEEgQQzBxiCR2EDlmiBH49pgwtAgSs X-IronPort-AV: E=Sophos;i="4.87,373,1363132800"; d="scan'208";a="192854568" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 29 Mar 2013 09:55:09 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r2T9t9tZ005661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 29 Mar 2013 09:55:09 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.138]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Fri, 29 Mar 2013 04:55:09 -0500 From: "Klaas Wierenga (kwiereng)" To: Jim Schaad Thread-Topic: Comments on draft-wierenga-ietf-eduroam-00 Thread-Index: Ac4qe+LoC9LeZppTRz2g9935nx0TGAB55vkp Date: Fri, 29 Mar 2013 09:55:08 +0000 Message-ID: References: <003501ce2c05$a2f4bd90$e8de38b0$@augustcellars.com> In-Reply-To: <003501ce2c05$a2f4bd90$e8de38b0$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 29 Mar 2013 10:05:54 -0700 Cc: "radext@ietf.org" , "draft-wierenga-ietf-eduroam@tools.ietf.org" Subject: Re: [radext] Comments on draft-wierenga-ietf-eduroam-00 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 09:55:12 -0000 Hi Jim, On 28 mrt. 2013, at 23:44, "Jim Schaad" wrote: > Remember you asked for it. Be careful what you wish for, you may get it.... But seriously, thanks a lot for your careful review, many of the points you= bring up stem from the fact that we are too familiar with the architecture= and thus assume knowledge, so your review is very helpful in pointing thos= e out. Some other comments need some more careful consideration, we'll work= on addressing those. Thanks again! Klaas >=20 > I am CC-ing the radext list for completeness not because I believe this > should be a radext working group document. >=20 > 1. It is not clear to me that the use of RFC 2119 language is appropriat= e > to a document that is describing what the current design is. >=20 > 2. Introduction: Suggest that the introduction should give a layout of t= he > document as well. Specifically there are two ways to organize the secon= d > half of the draft or and it wou= ld > be good to set expectations of this upfront. >=20 > 3. Given that RFC 6614 and 6613 are experimental - do you want to say /I= ETF > standardization efforts/? >=20 > 4. Section 1.3 - Who has to be able to identify users? Just the IdP or t= he > NAS as well? =20 >=20 > 5. what does it mean to either impersonate someone or to take over their > identity? If I give you my name and password it is possible for you to > impersonate me. This language should be tightened. >=20 > 6. Do you really want me to be able to access your network or are you go= ing > to provide a public network for me to be able to access and use? It migh= t > need to be clearer what is going on. The first implies a greater degree = of > identification that might actually exist. >=20 > 7. I can see three different vectors of scalability - it might be useful= to > tease that out. Users, Orgs providing access, Orgs hosting users. Are t= he > last two a one-to-one or not? =20 >=20 > 8. For whom does it need to be easy to install and use - just clients or > organizations as well? Can it be hard for an org to setup and still be e= asy > for clients? >=20 > 9. In the paragraph on security, I don't understand the purpose of the > first sentence. This would tend to argue that secure is not an absolute > design goal. There may be a trade off, but that would be a design goal o= f > usability which is separate. >=20 > 10. The goal is secure and privacy preserving - however there is nothing= in > the text about who the privacy is supposed to be protected from. While I > guess it could be the third part, that is hardly the limit of who one cou= ld > wish for privacy to be protected from. Do you care about privacy from th= e > visited SP? Should the IdP be able to know who the client is visiting? >=20 > 11. It is laid out that organizations should be able to set their own > authentication structure. Is there going to be a minimum security that i= s > imposed on organizations by the eduroam federation? >=20 > 12. Were any other options considered for the architecture? If so why w= ere > they not used?=20 >=20 > 13. Section 2 - If you read the ABFAB architecture document, I think we > talk about three different trust relationships. Two of which are > "pre-existing" and one of which is established during the protocol. =20 >=20 > 14. Going from the term type of trust to trust relationship does don't f= low > well. >=20 > 15. The term establishment is potentially confusing in this location. A= re > you talking about for a single event or initial establishment (i.e. > introduction ) between the user and the IdP. >=20 > 16. Section 2.1 - I can understand that authentication uses EAP. Howeve= r > how does it use 802.1X and not use RADIUS for authentication? If 802.1x > does anything other than carry EAP this should be covered. Otherwise yo= u > should probably include RADIUS here as well. >=20 > 17. Section 2.1.1 ?? wireless networks MUST support WPA2+AES - What does > this mean? It is a requirement that all networks deploy this or merely t= hat > the hardware has the capability to use it? If a network deploys both WPA= 2 > and WPA does that require that multiple SSIDs be used? If so is there a > naming convention that is documented for this usage type? >=20 > 18. What are the security implications of not knowing who the SP is - sin= ce > all SSIDs are "eduroam" it is not possible to distinguish from a user > perspective which are not to be used. >=20 > 19. Discuss the trade of for not always using "eduroam-foo" as the SSID >=20 > 20. Section 2.1.2 - What guidance is the federation giving on EAP method= s - > is that of interest to this document? >=20 > 21. What is the "policy with regards to security properties" >=20 > 22. I don't understand the purpose of Figure 1 - It does not appear to b= e > reference from the text in any way. The picture would seem to be > underspecified in that the specific protocols are not put any place (i.e. > X802.1x) and the term EAP tunnel is not introduced in any manner. As wi= th > the ABFAB document I did like that it is not clear that the tunneled eap = is > not traveling directly between the host and the authentication server. >=20 > 23. Note that mutual authentication does not imply privacy. If I > authenticate with EAP-TLS and send both the server and the client > certificates in the clear then I have mutual authentication however I hav= e > no privacy on identities. >=20 > 24. The term outer identity is problematic. There is the EAP outer > identity - and then there is the RADIUS user-identity attribute. The > routing is done on the later and it is generally (but not always) copied > from the initial EAP method. However not all methods will have a distinc= t > inner identity. Is there an identity that is transmitted on 802.1x that = is > used rather than the first eap name? >=20 > 25. When did you suddenly say than a TLS tunnel was required. If this i= s > true it should be stated someplace explicitly. This is not a requirement= on > IdPs that was not there before. =20 >=20 > 26. Do you want to say that outer identities must be NAIs or not? >=20 > 27.. Section 2.2.1 - You just sprang a national server on me without > telling me what it represents. Are you assuming that all routing is two > levels deep or is there three and four level deep routing. =20 >=20 > 28. Do you want to say at this point who is operating the national serve= rs > and root servers? On what basis will they setup or remove shared secret= s > with organizations? >=20 > 29. What are the trade offs of using anonymous@surfnet.nl vs @surnet.nl = for > the outer identity? >=20 > 30. What, if anything needs to be said about the trust needed between th= e > access points and the organization RADIUS server. Is this under some typ= e > of protections? >=20 > 31. Section 3 - Not all of the issues appear to be future problems that a= re > expected. This paragraph should be expanded to say that current operatio= ns > have identified problems, in addition others are expected with an increas= e > of ... >=20 > 32. Section 3.1 - I think the word you are looking for is deduced rather > than deducted in many of these sentences. >=20 > 33. I have a slight problem with the fact that you are using down the > authentication path since you have just told me that it is a tree and thu= s > has both an up and a down component. 'Along' might be a better choice. >=20 > 34. I would not use the term proxy chain when looking at the length. I > would just say that the radius authentication chain contains more than on= e > hop. If there were no proxies then you have no problems, but in that ca= se > the proxy chain is 0 hops? 1 hop? Not clear. >=20 > 35. I assume that if a server which is believed to be "dead" sends you a= n > authentication request then you would also know that it is now live (step= 3) >=20 > 36. One option that is not discussed here is the option of always floodi= ng > and never assuming anything but realms fail. What are the operational > problem with this approach. >=20 > 37. Presumably the use of TCP rather than UDP would also help this > situation. Since you seem to be talking about ways that can be used to f= ix > this here. >=20 > 38. Section 3.2 - ? reactively or retroactively? >=20 > 39. You don't say how much improvements from section 3.1 would deal with > this issue. If you could get reliable - don't fail because I did not get= a > reply - does this help the situation in the event of no reply? >=20 > 40. What would be the security implications of being able to inject an > error code into the stream by a middle man? Are they any worse than the > injection of an access-deny? >=20 > 41. Do you need to talk about dropped packets in this context as well as > dead servers? >=20 > 42. If 802.1x does not allow for returning errors. Are you suggesting t= hat > the RADIUS servers would inject EAP packets in the event of failures or > should this be handled by the NAS? >=20 > 43. Section 3.3 - You need to tell me what a ccTLD and a gTLD are >=20 > 44. What are the "downsides" to routing based on insertion of new > "national" servers that can talk directly to the org servers? These > servers would potentially need to be more intelligent - but it would > restrict the places where tables need to be routed. Was this considered? >=20 > 45. I am not sure that I understand why doing an add of a new route woul= d > be especially error prone. It seems that this should be easily fixable b= y a > simple tool. Are you ever removing this from the table - it seems that t= his > would be overwhelmed by adds. Are these mappings made at more than just = the > root level - that is not clear from the discussion although I assume it > would be true. =20 >=20 > 46. Who are you imposing the recommendation on? Is this a new 802.1x > requirement for an updated draft? If so is this really what you want - o= r > do you want to be able to negotiate the L2 packet size all the way down? >=20 > 47. For whom are they hard to diagnose? Are you just talking about users= or > are you talking about IT departments as well? Are there recommendations = on > how to do this diagnosis? >=20 > 48. Section 3.5 - Are EAP MSKs used in this configuration? If so then y= ou > have low level encryption on these and it could potentially be stolen and > used. >=20 > 49. It is not clear to me that using a pseudonymous client identifier fo= r > the client does much of anything to prevent linking to an actual client. > You still can build a large mobility profile. >=20 > 50. You have not dealt with the issue for TLS of checking that the serve= r > certificate is still valid. This is also not currently done. >=20 > 51. Have you brought up the concept of an EAP configuration meta data > format in the EMU group? It is about to close. >=20 > 52. Is there a reason why you don't reference RADIUS-TLS at this point a= s > this would deal with this issue to a certain extent. I.e. no protection > from the proxies but from eavesdroppers. >=20 > 53. Section 4.1.1 - why is the translation not satisfactorily answered b= y > NASREQ? >=20 > 54. The last pargraph of 4.1.1. should be the first paragraph of 4.1.2 >=20 > 55. Section 5 - It would seem that placing the policy enforcement with > Chargeable User Identity at the RADIUS server nearest the NAS - or at the > edge of the organization, would make as much sense as placing it on the N= AS > itself. This would allow for correlation between different access points > and given a better idea of abuse on the network as a whole. Thus using t= he > servers that do this would solve the problem better. >=20 > 56. Section 5.1 - It may be also taken as evidence that you have no idea= of > what is going on as you have not identified the serious incident as being > serious. >=20 > 57. Section 5.2 - How does the fact that the home site is now going have > the ability to block reflect back on the question of differences of opini= on > on if the action was abuse or not? What type of protocol is setup for > dealing with this type of request- is it automated, done by hand or throu= gh > the infrastructure? >=20 > 58. Section 5.3 - Given that home servers are required to regularly chur= n > CUIs, how does this affect the local accounting problems in terms of > tracking and preventing people from abusing the system. Can the home IdP > simply deal with this issue by changing the CUI of an individual every ti= me > an abuse is reported? >=20 >=20 >=20 > Random changes >=20 > s/Abfab/ABFAB/ > s/in all continents/on all continents/ > s/like for example/like/ > s/alternative use/alternative uses/ > s/foresaw/?????? - I am not sure what this sentence is supposed to say/ >=20 > Update reference to privacy terminology draft - it is now > draft-iab-private-considerations >=20 >=20 >=20 >=20 From bernard_aboba@hotmail.com Fri Mar 29 14:35:38 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF6721E808C for ; Fri, 29 Mar 2013 14:35:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wzU+bqrnwgwc for ; Fri, 29 Mar 2013 14:35:37 -0700 (PDT) Received: from blu0-omc3-s15.blu0.hotmail.com (blu0-omc3-s15.blu0.hotmail.com [65.55.116.90]) by ietfa.amsl.com (Postfix) with ESMTP id EA92921E808B for ; Fri, 29 Mar 2013 14:35:33 -0700 (PDT) Received: from BLU169-W85 ([65.55.116.73]) by blu0-omc3-s15.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Mar 2013 14:35:33 -0700 X-EIP: [NmRqUVqx/mXzeZMygj1TA5xT7JzZiFlAFND9CxpuxBU=] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: Content-Type: multipart/alternative; boundary="_968c4e6a-6594-4f07-938e-718d868e03d5_" From: Bernard Aboba To: Stefan Winter , "radext@ietf.org" , "xueli@huawei.com" Date: Fri, 29 Mar 2013 14:35:33 -0700 Importance: Normal In-Reply-To: <515596D8.1000209@restena.lu> References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com>, <515596D8.1000209@restena.lu> MIME-Version: 1.0 X-OriginalArrivalTime: 29 Mar 2013 21:35:33.0792 (UTC) FILETIME=[580F9A00:01CE2CC5] Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 21:35:38 -0000 --_968c4e6a-6594-4f07-938e-718d868e03d5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [BA] Also=2C RFC 5247 desribes the security issues that can arise when spli= tting the AP function.=20 Stefan Winter said:=20 =20 "You attempt to split the role of the Access Point into several sub-entities. This is admirable=2C but by no means a novelty. There are many proprietary approaches to this=2C but there's also already a set of RFCs describing a standard way:" =20 = --_968c4e6a-6594-4f07-938e-718d868e03d5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
[BA] Also=2C RFC 5247 desribes t= he security issues =3Bthat can arise when splitting the AP function.  =3B
Stefan Winter said:
=  =3B
"You attempt to split the role of the Access Point into several=
sub-entities. This is admirable=2C but by no means a novelty. There are=
many proprietary approaches to this=2C but there's also already a set o= f
RFCs describing a standard way:"
 =3B
=
= --_968c4e6a-6594-4f07-938e-718d868e03d5_-- From sarikaya2012@gmail.com Fri Mar 29 16:13:42 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420C921F8ED4 for ; Fri, 29 Mar 2013 16:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.348 X-Spam-Level: X-Spam-Status: No, score=-3.348 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bSWosb4rpST5 for ; Fri, 29 Mar 2013 16:13:41 -0700 (PDT) Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0DA21F859D for ; Fri, 29 Mar 2013 16:13:41 -0700 (PDT) Received: by mail-lb0-f176.google.com with SMTP id y8so612029lbh.7 for ; Fri, 29 Mar 2013 16:13:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=bAsMnzF9Pam0XwjbyRVGbBCNccdidH3GPyKvd8aqRXw=; b=EQMZEJ4KVGc187UrCAnnzx5SF7cyGmyQWa/xz/tI335UnBuZ+spmTov0bu7xvd45L0 XZ8IvFFv8GttUzQIZYfkStD0ArK0fNokZ75cWruV6x+CpqWRaycAw4R4a6NAGC1UA+62 rRV6j0pPzRfrm8v0N/lj1R8Z2Y2lSZPwnxEGxabGJ0Vq2ETWPz0Q/INEMGU32+1iYIa+ nhMV7MlGyeFxB7yEGLk9G+KBYqcIgFZ50kfSqiBwDgtxR1nHO4vfeeTZEJ4kBthvg3fE d4CID2KLb2A2o9fEKOJE4HCqcZeHcqz1Hqnq9t8nqsG1bwRgVOLrMLzT1cbTU3JyJHAu Yzkg== MIME-Version: 1.0 X-Received: by 10.152.123.194 with SMTP id mc2mr1909555lab.7.1364598820106; Fri, 29 Mar 2013 16:13:40 -0700 (PDT) Received: by 10.114.93.41 with HTTP; Fri, 29 Mar 2013 16:13:40 -0700 (PDT) In-Reply-To: References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> <515596D8.1000209@restena.lu> Date: Fri, 29 Mar 2013 18:13:40 -0500 Message-ID: From: Behcet Sarikaya To: Bernard Aboba Content-Type: multipart/alternative; boundary=f46d04426edaeef73504d9186b01 Cc: Stefan Winter , "xueli@huawei.com" , "radext@ietf.org" Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sarikaya@ieee.org List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2013 23:13:42 -0000 --f46d04426edaeef73504d9186b01 Content-Type: text/plain; charset=ISO-8859-1 Hi Stefan, Bernard, This draft is not about split MAC, local MAC of CAPWAP protocol (in the draft those are called Fit AP, Fat AP, quite strangely). This draft is about the case where IEEE 802.11i authenticator is moved from the AC of CAPWAP to the access router which is not at the same time the AC. In that case the keys, e.g. PMK has to be transferred to the AC. The solution is described in Section 5 which uses CoA type of signaling (as in RFC3576). This requires some RADIUS extensions Hope this helps. Regards, Behcet On Fri, Mar 29, 2013 at 4:35 PM, Bernard Aboba wrote: > [BA] Also, RFC 5247 desribes the security issues that can arise when > splitting the AP function. > > Stefan Winter said: > > "You attempt to split the role of the Access Point into several > sub-entities. This is admirable, but by no means a novelty. There are > many proprietary approaches to this, but there's also already a set of > RFCs describing a standard way:" > > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext > > --f46d04426edaeef73504d9186b01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Stefan, Bernard,

<= /div>This draft is not about split MAC, local MAC of CAPWAP protocol (in th= e draft those are called Fit AP, Fat AP, quite strangely).

Thi= s draft is about the case where IEEE 802.11i authenticator is moved from th= e AC of CAPWAP to the access router which is not at the same time the AC. <= br>
In that case the keys, e.g. PMK has to be transferred to the AC. = The solution is described in Section 5 which uses CoA type of signaling (as= in RFC3576).=A0 This requires some RADIUS extensions

Hope thi= s helps.

Regards,

Behcet
=

On Fri, Mar 29, 2013 at 4:35 PM, Bernard= Aboba <bernard_aboba@hotmail.com> wrote:
[BA] Also, RFC 5247 desribes the security issues=A0th= at can arise when splitting the AP function.
=A0
<= div>
Stefan Winter said:
=A0
"You attempt to split the role= of the Access Point into several
sub-entities. This is admirable, but by no means a novelty. There are
ma= ny proprietary approaches to this, but there's also already a set ofRFCs describing a standard way:"
=A0

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


--f46d04426edaeef73504d9186b01-- From xueli@huawei.com Fri Mar 29 23:33:27 2013 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89021F8BBB for ; Fri, 29 Mar 2013 23:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.498 X-Spam-Level: X-Spam-Status: No, score=-5.498 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 321eegb5nDcA for ; Fri, 29 Mar 2013 23:33:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E0AB021F8F07 for ; Fri, 29 Mar 2013 23:33:24 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARG23952; Sat, 30 Mar 2013 06:33:22 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 06:33:21 +0000 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 30 Mar 2013 06:32:58 +0000 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Sat, 30 Mar 2013 14:32:53 +0800 From: Xueli To: Stefan Winter , "radext@ietf.org" Thread-Topic: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt Thread-Index: AQHOLIFAOTSG7yr9c0iZOcBFFpnzXJi9xSjQ Date: Sat, 30 Mar 2013 06:32:52 +0000 Message-ID: <01FE63842C181246BBE4CF183BD159B4482A1FAE@NKGEML512-MBS.china.huawei.com> References: <01FE63842C181246BBE4CF183BD159B4482A1371@NKGEML512-MBS.china.huawei.com> <515596D8.1000209@restena.lu> In-Reply-To: <515596D8.1000209@restena.lu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.95] Content-Type: multipart/related; boundary="_004_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [radext] FW: New Version Notification for draft-xue-radext-key-management-00.txt X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2013 06:33:27 -0000 --_004_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_ Content-Type: multipart/alternative; boundary="_000_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_" --_000_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stefan Thanks a lot for your comments. Actually, the issue is when the authenticator is in access router instead o= f AC, the PMK should be announced to AC. Please see the procedure shown as follow [cid:image003.jpg@01CE2D53.74DAE0C0] Unfortunately, in exiting authentication procedure, authenticator is the on= ly node which can obtain the derived PMK, except of STA and AS. In addition, authenticator is not always deployed col= located on ecryption/decryption node, as AC. That is to say, WTP/AC cannot implement STA's traffic encryption/decryption= because of lacking the PMK information. In this case, mechanism is needed to inform the PMK to ecryption/decryption= node, WTP or AC in WLAN. The Radius extension is defined in this draft for key announcement from aut= henticator(GW) to AC. I hope this clarification is helpful. BR Li >-----Original Message----- >From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf O= f >Stefan Winter >Sent: Friday, March 29, 2013 9:28 PM >To: radext@ietf.org; Xueli >Subject: Re: [radext] FW: New Version Notification for >draft-xue-radext-key-management-00.txt > >Hello, > > >On 28.03.2013 03:12, Xueli wrote: >> Hi all >> >> There is a draft to resolve the some issue raised in WLAN network. >> >> In the authentication architecture, only STA and AS can manufacture >> PMK, moreover, AS can only distribute PMK to Authenticator.However, if >> the authenticator function is not collocated with the encryption/decrypt= ion >function, it is difficult to achieve traffic encryption/decryption in WLAN >network. >> >> The purpose of this document is to analyze the requirement and issue >> for key management that have arisen so far during STA authentication >process in WLAN network. Meanwhile, the control messages for key >management are defined. >> >> Your comments are appreciated. > >You attempt to split the role of the Access Point into several sub-entitie= s. This >is admirable, but by no means a novelty. There are many proprietary >approaches to this, but there's also already a set of RFCs describing a st= andard >way: > >If you are interested in offloading functions of an AP into separate sub-e= ntities, >you should also first take a look at the results of the CAPWAP working gro= up, >whose target is to do just that. The advantage of CAPWAP is that it has a >much broader scope than "just" the keys for a session. > >RFC5415 is a good read. Section 10.1 has a "Station Configuration Request" >which transmits user session specific data from the controller to the >lightweight AP (which you call "FIT" AP in your document - did you mean >"thin" as the opposite to "fat"?). > >The media-specific binding in RFC5416 goes into detail and describes how >exactly session keys are transmitted in WLAN (Sections 5.10, 6.15). > >Greetings, > >Stefan Winter > > >> >> BR >> Li >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, February 18, 2013 7:31 PM >>> To: Xueli >>> Subject: New Version Notification for >>> draft-xue-radext-key-management-00.txt >>> >>> >>> A new version of I-D, draft-xue-radext-key-management-00.txt >>> has been successfully submitted by Li Xue and posted to the IETF >>> repository. >>> >>> Filename: draft-xue-radext-key-management >>> Revision: 00 >>> Title: RADIUS Extensions for Key Management in WLAN network >>> Creation date: 2013-02-18 >>> Group: Individual Submission >>> Number of pages: 17 >>> URL: >>> http://www.ietf.org/internet-drafts/draft-xue-radext-key-management-0 >>> 0.txt >>> Status: >>> http://datatracker.ietf.org/doc/draft-xue-radext-key-management >>> Htmlized: >>> http://tools.ietf.org/html/draft-xue-radext-key-management-00 >>> >>> >>> Abstract: >>> In order to guarantee the security and integration of the subscriber >>> in WLAN network, Pairwise Master Key (PMK) will be generated as an >>> access authorization token during the mutual authentication procedure >>> between station (STA) and authenticator server (AS). Then, the PMK >>> and 4-way handshake are used between STA and Authenticator to >derive, >>> bind and verify the Pairwise Transient Key (PTK), which is a >>> collection of operational keys for security. Also,Group Transient >>> Key (GTK) can be derived, and is used to secure multicast/broadcast >>> traffic. In the authentication architecture, only STA and AS can >>> manufacture PMK, moreover, AS can only distribute PMK to >>> Authenticator.However, if the authenticator function is not >>> collocated with the encryption/decryption function, it is difficult >>> to achieve traffic encryption/decryption in WLAN network.The purpose >>> of this document is to analyze the requirement and issue for key >>> management that have arisen so far during STA authentication process >>> in WLAN network. Meanwhile, the control messages for key >>> management >>> are defined. >>> >>> >>> >>> >>> The IETF Secretariat >> >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext >> > > >-- >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 --_000_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stefan<= /p>

 

Thanks a lot for your commen= ts.

 

Actually, the issue is when = the authenticator is in access router instead of AC, the PMK should be anno= unced to AC.

Please see the procedure sho= wn as follow

 

Unfortunately, in exiting au= thentication procedure, authenticator is the only node which can obtain the= derived PMK,

except of STA and AS. In add= ition, authenticator is not always deployed collocated on ecryption/decrypt= ion node, as AC.

That is to say, WTP/AC canno= t implement STA's traffic encryption/decryption because of lacking the PMK = information.

In this case, mechanism is n= eeded to inform the PMK to ecryption/decryption node, WTP or AC in WLAN.

 

The Radius extension is defi= ned in this draft for key announcement from authenticator(GW) to AC.

 

I hope this clarification is= helpful.

 

BR

Li

 

>-----Original Message---= --

>From: radext-bounces@iet= f.org [mailto:radext-bounces@ietf.org] On Behalf Of

>Stefan Winter=

>Sent: Friday, March 29, = 2013 9:28 PM

>To: radext@ietf.org; Xue= li

>Subject: Re: [radext] FW= : New Version Notification for

>draft-xue-radext-key-man= agement-00.txt

> =

>Hello,=

> =

> =

>On 28.03.2013 03:12, Xue= li wrote:

>> Hi all

>> 

>> There is a draft to= resolve the some issue raised in WLAN network.

>> 

>> In the authenticati= on architecture, only STA and AS can manufacture

>> PMK, moreover, AS c= an only distribute PMK to Authenticator.However, if

>> the authenticator f= unction is not collocated with the encryption/decryption<= /p>

>function, it is difficul= t to achieve traffic encryption/decryption in WLAN

>network.

>> 

>> The purpose of this= document is to analyze the requirement and issue

>> for key management = that have arisen so far during STA authentication

>process in WLAN network.= Meanwhile, the control messages for key

>management are defined.<= o:p>

>> 

>> Your comments are a= ppreciated.

> =

>You attempt to split the= role of the Access Point into several sub-entities. This=

>is admirable, but by no = means a novelty. There are many proprietary

>approaches to this, but = there's also already a set of RFCs describing a standard<= /p>

>way:

> =

>If you are interested in= offloading functions of an AP into separate sub-entities,

>you should also first ta= ke a look at the results of the CAPWAP working group,

>whose target is to do ju= st that. The advantage of CAPWAP is that it has a

>much broader scope than = "just" the keys for a session.

> =

>RFC5415 is a good read. = Section 10.1 has a "Station Configuration Request"

>which transmits user ses= sion specific data from the controller to the

>lightweight AP (which yo= u call "FIT" AP in your document - did you mean=

>"thin" as the = opposite to "fat"?).

> =

>The media-specific bindi= ng in RFC5416 goes into detail and describes how

>exactly session keys are= transmitted in WLAN (Sections 5.10, 6.15).

> =

>Greetings,

> =

>Stefan Winter=

> =

> =

>> 

>> BR

>> Li

>>> -----Original M= essage-----

>>> From: internet-= drafts@ietf.org [mailto:internet-drafts@ietf.org]

>>> Sent: Monday, F= ebruary 18, 2013 7:31 PM

>>> To: Xueli<= /o:p>

>>> Subject: New Ve= rsion Notification for

>>> draft-xue-radex= t-key-management-00.txt

>>> 

>>> 

>>> A new version o= f I-D, draft-xue-radext-key-management-00.txt

>>> has been succes= sfully submitted by Li Xue and posted to the IETF

>>> repository.

>>> 

>>> Filename: = draft-xue-radext-key-management

>>> Revision: =   00

>>> Title: &nb= sp;        RADIUS Extensions for Key Man= agement in WLAN network

>>> Creation date:&= nbsp; 2013-02-18

>>> Group: &nb= sp;            =   Individual Submission

>>> Number of pages= : 17

>>> URL:=

>>> http://www.ietf= .org/internet-drafts/draft-xue-radext-key-management-0

>>> 0.txt

>>> Status:

>>> http://datatrac= ker.ietf.org/doc/draft-xue-radext-key-management

>>> Htmlized:<= /o:p>

>>> http://tools.ie= tf.org/html/draft-xue-radext-key-management-00

>>> 

>>> 

>>> Abstract:<= /o:p>

>>>   In = order to guarantee the security and integration of the subscriber

>>>   in = WLAN network, Pairwise Master Key (PMK) will be generated as an<= /span>

>>>   acc= ess authorization token during the mutual authentication procedure

>>>   bet= ween station (STA) and authenticator server (AS).  Then, the PMK<= /o:p>

>>>   and= 4-way handshake are used between STA and Authenticator to

>derive,

>>>   bin= d and verify the Pairwise Transient Key (PTK), which is a=

>>>   col= lection of operational keys for security.  Also,Group Transient

>>>   Key= (GTK) can be derived, and is used to secure multicast/broadcast=

>>>   tra= ffic.  In the authentication architecture, only STA and AS can

>>>   man= ufacture PMK, moreover, AS can only distribute PMK to

>>>   Aut= henticator.However, if the authenticator function is not<= /p>

>>>   col= located with the encryption/decryption function, it is difficult=

>>>   to = achieve traffic encryption/decryption in WLAN network.The purpose

>>>   of = this document is to analyze the requirement and issue for key

>>>   man= agement that have arisen so far during STA authentication process

>>>   in = WLAN network.  Meanwhile, the control messages for key

>>> management=

>>>   are= defined.

>>> 

>>> 

>>> 

>>> 

>>> The IETF Secret= ariat

>> 

>> ___________________= ____________________________

>> radext mailing list=

>> radext@ietf.org

>> https://www.ietf.or= g/mailman/listinfo/radext

>> 

> =

> =

>--

>Stefan WINTER=

>Ingenieur de Recherche

>Fondation RESTENA - R=E9<= /span>seau T=E9l=E9informatique de l'Education Nationale et de

>la Recherche 6, rue Rich= ard Coudenhove-Kalergi

>L-1359 Luxembourg

> =

>Tel: +352 424409 1

>Fax: +352 422473

 

--_000_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_-- --_004_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_ Content-Type: image/jpeg; name="image003.jpg" Content-Description: image003.jpg Content-Disposition: inline; filename="image003.jpg"; size=15360; creation-date="Sat, 30 Mar 2013 06:32:52 GMT"; modification-date="Sat, 30 Mar 2013 06:32:52 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCAD9AaIDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD2aisn xNrqeG9BuNUeBpxDtAQNtBLEAZPYc8nsKi0vxHHc29qNRWG0u7pZJIoopxOkiJglldRgjBB7UAbd Fc/ceO/C9qIDPq8MYuI0lj3K3KPna3TgcdT071MfGHh8auNJOqRC9aUwiIhvv4ztzjGfTnntQBtU Vx+geO1vrOKfVfslohs5LqVxKRsCymP7pHTjrnrxir7+O/DEdrb3T6qghuSRG/lPjg4Ofl+Xn1xQ D0OhorDbxn4dTVDpbapELwOUMW1shgM4zjGcdPXtTvDHinTvFdjLd6eZAsUrRurqQQQeD+I5/GgD aooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoopKAForldJ8dWt/JqbXlubG2sk 8+Kd23CeDcy+YABwMqeOe1T67450TQIXe4naR42iDxxoSwEn3T0xjAJ/CgDo6K5Kz8faa/iS80q9 uoIAJIUsjtYNMJIw3PYcnAzitWLxXoU2oXNhHqMbXNqrNKgB4C/ewcYOO4GcUAbFFcrc/EjwxFpd 5f2+oC8Fmiu8cKtuYMcDGQM89+g71Yj8aaWzzzy3EMVhFaRXInZ2DEOSACm3I6cckn0oA6KisE+N /Da/ZM6ogF4AYWMb4OW28nGF545xVex+IHh+8g1Kdrs28WmzeVK0qEZ5wCvHOTkAdeOlAHTUVgHx z4ZFnb3h1aLybl2SIhGyzLjcuMZBGRwR3reoAWiiigAooooArajfQ6Zp1zfXBxFbxNI30AzWZoni qy1bS4budTp8stybU29ww3rMM/J7kgZpfFWiT+ItKTTI7gQQSzxm6IJDNEDkqpHQnArnJPh/qNlN M2kakjot7Bf24v3eVjMoKvvbqQQR75FC8xnQ3HjPQLbVLPTX1GIz3kjxx7WBAdTggnsd3A96h8L+ MtP8Q2g8y4tre+HmNJaCYMyKrldx6dgD+NZdn4N1eym0u6Fzp8tza31zPPvjYKyTHJ29ww7Z4qtF 8N5/7PsLR7q3jMMV9HPLEh3P5/3SPXHfNHQP6/M6uHxRoNxZS3sOsWb20LiOSVZl2ox4AJ7ZzVO6 8d+GrSKylbVbeSK9mMMUkUgZQw6knPAHH5iuX0/4a6hBot7Y3NxaPLcSW2H86WQNHE+4gh+nGcAc c1pXPgnUBc3F1ZS2AkOsLqEKTI2zZ5YQqcd+/FHX+vIXQ208WaXHbT3Go3VtYRxXb2qtLcIQ7L9D wfY8jvUk/izw/bz3NvJq9p59rG0k0QlG5VAyeK5p/A2rwXo1CzudOluFvbuYRXcbNEY58dhzuG36 c0xPAOsSeLhqt5qcE1ojyGOP5wQrRlAoj+4MZ7daWth6XOit/G3hyfRbfWG1W3t7S5O1GnkCHdjJ UjPUdxV4a/o5v4rAanam6nUNFCJQWcEEggdwQCa46PwRr9vY6YYbjR3u7C1ksts0LmJomxh/UP8A Lz2Oa1vC/g1vD2ptcPPFcIthb2sTFfnBj3bj7A5HA9KrS5Otjq6KKKQyjrFreXmnPBYXUdtOxGHl hEqEd1ZSRkEe9cnbfDy8sYbR7HV4be7imuHkItP3O2YAMqR7vlxtGOT3ruqKLDueZt4D1l72TSIb 5YLD+x7eymuntg/nhWbcF+b5WwR69as2HgzVLrW777RcfZNLj1hLtIWhDST+Wi7WD54BIweM8e9e h0Uef9b3F/X4WOAHwxdrD7NJqq5Wxa3V1h6P9o85WwTyAcAjvTvEPgDWfEkEIvvEMe8I6yqluyRk kjDKquOcDB3bq72igd+px6+BpBIX+3pk6zFqX+q7IgXZ19uv6Vr+GtFutCtrm1mvUuYGuJJYAItj IrsWIY5O45PXitmij+v6+4X9f194UUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQA VU1S2uLzSrq1tZxbzzRMiSld2wkYzjvirdFJq+gJ2OE/4VbYWsSRaXdSWqy2MlneF2eQzKyjBAZs LhhnA45NPPgTVJ7TUDd63DJeXi2oSVLTakZgYlfl3cg8Z5ruKKdwOPuPBNzdtqMs2oxGa/urS4dl gIAMIXIxnuV49M96pWHw0/s/Wrq8S+ikhlFx5QeOQyRmUEHnft43H+EZH513tFA7nEn4eu1ktt/a Krt0MaXuWH+INu39enHT9ade+Bb7UJZLu41aIXrQ2wSRLb5FlhcsGKluVOcYz+NdpRR1v/X9ai/r +vuOB1z4e6tr1xbz3niBGZEXzEEDLHuDlsoquAM8A7t3Srt34Jvp2vvK1aONZNSTUrTNtuMUw6hv m+ZTjpxXY0UAchpngiez1iy1W51FLi5jubi5udsG1ZHlQL8oz8oAX3zXX0UUAFFFFABRRRQAUUUU AFcfpfjWa88Q6naXcdjZ2entIsiyzlblVQZ8woRgoQCQQT2rsK5G78B/2pqcl1q+sT3sIimit4vJ RGiWQYILgZbAPGaQy1H4/wDD0mmXGo/aZkgtmjEvmW7qwDnCMFIyVJ7ipYvGuiy28sxknjMMsULR S27pJuk+4NpGef6GsXTvhjb6fpV1YC/QieWB/Mjs0jYCJ9wBwfmzjqa177wfa33i218QPcOvkKu+ 2CjZK67tjH3XccUxCweOdAuZLxIrqQ/ZIpJWYwsFkSP75Q4w+PbNaWjazZ69YC+sfNMDNhWkiaPd 7gMBkc9a5PT/AIW2WmyagIL1fKvLaa3TNqnmRCQEZ8wctjPeuz0+0Fhp1tZhy4t4liDEY3bQBn9K FsDLFFFFABRRRQAVi+M3eLwTrkkbMjrp85VlOCDsNbVYfjb/AJEbXf8AsHT/APos0AZGl/DnwlPp NnNLo6NJJAjMxmk5JUEn71Wv+FaeDv8AoCp/3+k/+Krc0X/kB2H/AF7R/wDoIrP1DXLi18RQaWv2 W3SWNXSS6LD7QS2CiEcBgMdc53DijyAp/wDCtPB3/QFT/v8ASf8AxVH/AArTwd/0BU/7/Sf/ABVW Bq2qwarfRXj2ItLGFZ5GSNw7Kd3Ay2ARt/Wrfh7VbnVLSX7dAlvdwSbZYkJIAIDKefVWH45oA5Lx j4D8MaX4P1W/sdLENzb2zvFIs0mUYDg/ervrUk2kJJySi/yrC+IP/Iga5/15v/Kty1/49If+ua/y oAmooooAK4a48P6V4j+ImrRava/aktrG1MKtIyhNxkzjBHXA/Ku5rmNM/wCSk69/14Wf85aAG/8A CtPB3/QFT/v9J/8AFUf8K08Hf9AVP+/0n/xVWtX8Q3Gl3Gow/ZkkeGzW4tBk/vWLFdp/4Ft/76qO 31+/1NbZbCK3jd7EXUxmDMI2JxswCO4f8qPP+v60Ah/4Vp4O/wCgKn/f6T/4qj/hWng7/oCp/wB/ pP8A4qmReINaey0uV20yJ9RVpAzq4SNQm7B+bk+9b2i6g2q6Pa37Q+S08YcpnOPoe4p2Fc5/wFaQ adL4isLRDHbW2qskUe4sEHlRnAyT3Jrrq5fwf/yFfFP/AGGG/wDRMVdRSGcDB4a0jxJ468TtrFp9 rNtLbJDukcBFMKkgAEd+a1f+FaeDv+gKn/f6T/4qjw5/yPHi/wD672v/AKIWupoA5b/hWng7/oCp /wB/pP8A4qj/AIVp4O/6Aqf9/pP/AIqruoa9LZ6/bWSQo9qSqXMpJzG0mRGB25KnP1FPtdR1HUb6 drOO1WytrgwN5pbzJCvDEY4GDwMg5x2oWoPQz/8AhWng7/oCp/3+k/8AiqxfEvg/QPD40i+0qw+y 3P8Aa9onmJK5O1pACOW7ivQ65bx7/wAg/SP+w1Zf+jRQB1NFFFABRRRQAV554a8H6D4gGrX+rWH2 q5Or3aeY8rg7VkIA4bsK9DrlvAX/ACD9W/7DV7/6NNAB/wAK08Hf9AVP+/0n/wAVR/wrTwd/0BU/ 7/Sf/FVo6rq89vfrYWht43WA3E1xdEiOKPOB0xkk57jGKrHxI9vJAbg2s0EtnNMJ7VyyM8ZGQD6E HP1BoAr/APCtPB3/AEBU/wC/0n/xVNk+Gvg9YnYaKmQpP+uk/wDiqsaL4lutUj0pZLNIbi6Exu49 xPkeXwcevzFfzroJv9RJ/un+VAHPfDx3k8AaK7sWY2q5LHJNdJXNfDn/AJJ7on/Xqv8AWuloAKKK KACiiigAooooAKKKKAMLxw7x+BtbeNijLYykMpwR8prMsvhv4QlsbeR9GQs8Ssx86Tkkf71aPjv/ AJEPXf8Arwl/9BNa2nf8g21/64p/IUAc/wD8K08Hf9AVP+/0n/xVH/CtPB3/AEBU/wC/0n/xVXrf XpJvEsmnNCgtMMkMwJ3PKgBdfTGGGP8Adb0pNO16W9125spIUS2wxtJQTmXY22TP0YjGO1AFL/hW ng7/AKAqf9/pP/iqwvG3gXw1pHg3VNQ0/TBb3VvDvilWaTKNkcj5q6rRdek1PUbu3lhSOMDzLR1J zLEGKFj77lP4EVU+JH/JPNa/69j/ADFAHSx/6tfoKdTY/wDVr9BTqACiiigArD8bf8iNrv8A2Dp/ /RZrcrN8R2E2q+GdT063Kia6tJYY9xwNzKQM/nQBLov/ACA7D/r2j/8AQRVXWdFm1kfZ5b7ZZOUM kPkgtlWzlXz8vQdj7YrIs7zxtaWUFsPDenN5Max7v7TIzgYz/q6m/tTxv/0LGm/+DQ//ABugC9qf huLU3vPNuHWO9SGOVAvVEYkrn/azg1Jp3h600nU57yxzFHcRKkkOSQzKThsk5zg4/Ks3+1PG/wD0 LGm/+DQ//G6P7U8b/wDQsab/AODQ/wDxugCb4g/8iBrn/Xm/8q3LX/j0h/65r/KuN19fG2u6De6U 3h/ToBdwtEZP7SLbc98eWM12kCGOCNG6qoB/KgCSiiigArmNM/5KTr3/AF4Wf85a6euSvbPxHp/i ++1XSdMtL6C8toYj512YShQv/snOd1AGtq+gRatqOnXrTvE1jJvKqARKvB2n23Kp/Ck0fw9FpEmo sk7yfbZi4DDHlLzhB7Alj+NZ/wDanjf/AKFjTf8AwaH/AON0f2p43/6FjTf/AAaH/wCN0AXV8L2h g0qC4K3MemoVCSxKwkyu3JB6YraAAAAGAOgFcx/anjf/AKFjTf8AwaH/AON0f2p43/6FjTf/AAaH /wCN0AHg/wD5Cvin/sMN/wCiYq6iud8I6bqll/a11q1vBbz6hfG4EUMvmBV2Iv3sDup7V0VAHLeH P+R48X/9d7X/ANELXU1xzWfifSfFOtX+maVZX1tqTwuplvDEybIwhGNh7g1Z/tTxv/0LGm/+DQ// ABugCW88F2F+b+a5d3u7uXzEuOQYSANmBnB24BGauW2jXNleSyWuo+XbTy+dNAYQxLn7xVs/KCRn GD3xWd/anjf/AKFjTf8AwaH/AON0f2p43/6FjTf/AAaH/wCN0bAdRXLePf8AkH6R/wBhqy/9Gil/ tTxv/wBCxpv/AIND/wDG6o6pbeL9ffT7e70Wws4IL+C5klS/MhCxuGIC7BngetAHbUUUUAFFFFAB XLeAv+Qfq3/Yavf/AEaa6muJ0u28X6A2oW9potheQT389zHK9+YyVkcsAV2HHX1oA6PUNIkuL+LU LO7NrdxxmIsYxIkkZOdrLkdDyCCO9Z914OhutHtNPe8kVre5M7TKgBfcSXXHZW3EVF/anjf/AKFj Tf8AwaH/AON0f2p43/6FjTf/AAaH/wCN0AaOn+H4tP12/wBVWd3N4F2xEfLF/ex/vHBP0rUm/wBR J/un+Vc1/anjf/oWNN/8Gh/+N0j6l43ZGX/hGdN5GP8AkKH/AON0ASfDn/knuif9eq/1rpaxvCGl 3OieE9N0y72efbQBJNhyM+xrZoAKKKKACiiigAooooAKKKKAMDx3/wAiHrv/AF4S/wDoJrW0/wD5 Blrj/nin/oIqn4n06fV/C+p6da7fPurWSKPecDcVIGTWRb33jaC2ih/4RrTW8tAuf7UPOBj/AJ50 ATxeCbK3jtpYJ3TUIJzP9sIyzuSd2VzjkMRTU8D2VrBaGwnktry2VgboZZn3KQ+QTgZJ3cdwKT+1 PG//AELGm/8Ag0P/AMbo/tTxv/0LGm/+DQ//ABugCzYeENO0q8sbrT90ElpGYnOSfOQjGDk8cgNx 3FV/iR/yTzWv+vY/zFJ/anjf/oWNN/8ABof/AI3Wb4ii8a+IfD95pDaBp1uLuPyzKNSLbPfHljNA HcR/6tfoKdTUG1FB7CnUAFFFFABRRRQAUUUUAFFVmvUXVI7DYd8kLzBuwCsox/49VmgAooooAKKK KACiiigAorOHiDSCLki/hIteZufu84/HkY478Up17Sg1spvos3YBh54YE4HPbJ4570AaFFVpNQs4 b6GxkuY1uZwTHET8zADJ4qd3VELswCqMknsKAHUVlWniPTbySCFZWSedFdYXQ7gGGVzjIGRzyanO s6aLe6uPtsXlWbmO4YNxGw6g+/NAF6iq9lf2mo2/2i0nWaPJUlexHUEdjUOn61puqM62N5HOUGWC 56dM89Rx1oAvUVl+IZXi0nfFIUY3EABU4ODMgI/LNadAC0UmRzyOOtRrcwPcPbrKrSxqGZAeQDnB /Q0AS0UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRUN3cLaWc9y yllhjaQgdSAM0ATUVFbzC4top1BAlQOAe2RmpaACiiigAooooAKKKKACiiigDKl/5G61/wCvCb/0 ZFWrXK+KbnWrTVYpdAsoby9FhNtjmk2jG+Pkep9sitC0ufEr2cLzadpwlaNS4N44IbHPHlnH50Ab VFZfneIP+fDTf/A2T/41R53iD/nw03/wNk/+NUAalFZfneIP+fDTf/A2T/41R53iD/nw03/wNk/+ NUAalFZfneIP+fDTf/A2T/41R53iD/nw03/wNk/+NUAc3beGNYhknmaOEskkcip5vyyFZjJhOP3a kE8c881bTSdXitrCwksoprRZDcXOycKfMMhcJyOVUkH3I7Vs+d4g/wCfDTf/AANk/wDjVHneIP8A nw03/wADZP8A41QD1Kd7Dq9xqek3P9mw/wCjSO05W5HAIZRjK88EH8xWZFoGpWcF7blMpqUixoY3 LfZIixLxjP8ACBk59Wx6Vv8AneIP+fDTf/A2T/41R53iD/nw03/wNk/+NUAZsmmapaeIrq9soGeG SNBEoutkYKoV+dMc84qgPCmtw2Nxai8tpvtdsiyOiGMrMrht5yW3Egtzx0HFdD53iD/nw03/AMDZ P/jVHneIP+fDTf8AwNk/+NUAFpoz2RLRahOzyzGa5LIn79iAOfl+UAKB8uK5tfCGqw6X5CTrJI9q iN5kgYqVkDNGpK42MvGCDyB2rpPO8Qf8+Gm/+Bsn/wAao87xB/z4ab/4Gyf/ABqgDivFWg3lr4QV vs/mJFvBhkkXMLvKhVk2KBxgjAAI3cVr22j6tJJbNHHGLaSa2umlaUhkCwqhXbjrkZ61b8Qza7/Z P7yx09V+0QcreOTnzkx/yzHetPzvEH/Phpv/AIGyf/GqAOcsfCt9b6XeQXMMks0iRqfLmiVZ2Vs7 yNnJ9d+cg4Na2jaNcWOrC8uLKzEktlFHJNAoXY65yoGOhBHT0q753iD/AJ8NN/8AA2T/AONUed4g /wCfDTf/AANk/wDjVAGpRWX53iD/AJ8NN/8AA2T/AONUed4g/wCfDTf/AANk/wDjVAGpRWX53iD/ AJ8NN/8AA2T/AONUed4g/wCfDTf/AANk/wDjVAGpRWX53iD/AJ8NN/8AA2T/AONUed4g/wCfDTf/ AANk/wDjVAGpRWX53iD/AJ8NN/8AA2T/AONVE2oaxb31jFdWdkkN1OYmaK5d2H7t24BRf7vrQBs0 UUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFUda/wCQFqH/AF7Sf+gmr1Uda/5AWof9e0n/AKCa AJNM/wCQVaf9cE/9BFWqq6Z/yCrT/rgn/oIq1QAUUUUAFFFFABRRRQAUUUUAZUv/ACN1r/14Tf8A oyKtWsqX/kbrX/rwm/8ARkVatABRRRQAUUUUAFFFFABRXC23iTVppZ4zdgC4kjW3k8pcBWnKF4+O VAwMNzn2q9BquqXVrpskN8GupJjGbdYV2zIkpV5GPVRtGeMc+ucUIHodZRWNfXt1HrmlLb3UZtLp 5I3jVAdxCMc7vqO3vVGHxZLcWeqP9kVJdPPk4V93mTEkLt45U8c+uR2oA6eiuU06e/tNak0+a6u2 tLCGLzJAsbISULMZGb5+T6Vnw+Mrm40nVZY7xGmWNbm2KRZaKJ327SMfMy8ev3hQB3dFYmj6jeCF k1BLqQyTsttK9qys0YAwZABhOcjkDIANc/pnizU4bOS5vTJcFoImSOWJVJd5NgKeWCSnPOct045o A6bxL/yB/wDt5t//AEclatcdq+tX9xpFn5+mvbpLeRpNK6OFTbOm0gFQQGHOWAHGPSp28X3EMJnn sofLlSUwCObLZSQJ8/GACWHPOOc0AdVRXNnxDqYnNgtlatfJM0THz28riMSA5256HGMdajk8YPDE t3PZeVbNZfaY8li0x2biqkDbkY6E57gYoA6iisvQtTu9Sgla7smtmjcBW2OqyAgHI3qDx06dq1KA CiiigAooooAKy9X/AOP7Rv8Ar+P/AKJlrUrL1f8A4/tG/wCv4/8AomWgDUooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKo61/yAtQ/wCvaT/0E1eqjrX/ACAtQ/69pP8A0E0ASaZ/yCrT/rgn/oIq 1VXTP+QVaf8AXBP/AEEVaoAKKKKACiiigAooooAKKKKAMqX/AJG61/68Jv8A0ZFWrWRO6p4ttSzB R9gm6nH/AC0irT8+H/nqn/fQoAkoqPz4f+eqf99Cjz4f+eqf99CgCSio/Ph/56p/30KPPh/56p/3 0KAJKKj8+H/nqn/fQo8+H/nqn/fQoAoGx0KOO5Bt7FUnbbcZVQHbrhvfnNOfRdGmlhdtPtGkhjCx Hy1yqA8AewNcfJby3Nnp0gi85oL27+0lbZbnaxZgMoT345q75eqN4lj1hNPRYo5lt1zMFk+zYwf3 eMY3Hd16DpQgZ0Q0jQ7iWNhY2Uj2p+QiNSYjknj05yakfSNPlMDrbxr5LKyGMBc7SSAcdQCc49a5 7wxoUlopurxoLaQwyw+XCNjsGfduds8sMDBHTJqhaC/0y20jToZruH7Zm1lSWbLQlTvMikk8FQwy PahAzsLjRdLu7o3Vxp9tLORtMjxgsRjGCfpU0tjaT7fOtYZNi7F3IDheDge3A/IVxaXWtXIupNMm u2mH2tC88oMJwxEYTnGRj6+taFoNQ/4Rq9SS+u0mdwYf3UhljHGQNzF2B55ByMnHShbXDqdXVZtL sHhELWUBjEZiCGMYCHqv04HFcc15qk11HAgvorpLe3ZIkuC0cTF23GQk5OVH8WfzqSE+Iw2pubiU XBjlEceG2Od/yFGLbAQvQADrz0oA0/EdhpFjo0Un2a1hFncQSRkqB5QMyZI9Kv6boek2ltKIYIJv ODCaUopMgJJIY9xzXLazatcwRP8A8TCO1WW2wbmYrID9oXOTnd0ORnp19K0IxfR6yftAvPshmkaI 2zgDd5gwZMHldvrx170lqx9DorOx02K3iNlbWywjLRGJBj5hyRj1FCaTp0c3nJY26yeX5W4RjOzG Nv0x2qj4ZuIToqlZkMRml8r5v4PMbFa3nw/89U/76FMRFZafZ6dEYrK1it0Y5KxqFBP4VZqPz4f+ eqf99Cjz4f8Anqn/AH0KAJKKj8+H/nqn/fQo8+H/AJ6p/wB9CgCSio/Ph/56p/30KPPh/wCeqf8A fQoAkrL1f/j+0b/r+P8A6JlrQ8+H/nqn/fQrFvdTsb3VNNgtbyGaW31ArLGjgsh8iXqO1AG9RRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVR1r/kBah/17Sf+gmr1Uda/5AWof9e0n/oJoAk0z/kF Wn/XBP8A0EVaqrpn/IKtP+uCf+girVABRRRQAUUUUAFFFFABRRRQBh6hY2l/4qs47y1huUWxmKrN GHAO+LnBq3/wjuh/9AbT/wDwFT/Co5f+Rutf+vCb/wBGRVq0AZ3/AAjuh/8AQG0//wABU/wo/wCE d0P/AKA2n/8AgKn+FaNFAGd/wjuh/wDQG0//AMBU/wAKP+Ed0P8A6A2n/wDgKn+FaNFAGd/wjuh/ 9AbT/wDwFT/Cj/hHdD/6A2n/APgKn+FaNFAGb/wjuh/9AbT/APwFT/Cl/wCEd0P/AKA2n/8AgKn+ FaNFAGd/wjuh/wDQG0//AMBU/wAKT/hHdD/6A2n/APgKn+FaVFAGb/wjuh/9AbT/APwFT/Cl/wCE d0P/AKA2n/8AgKn+FaNFAGb/AMI7of8A0BtP/wDAVP8ACl/4R3Q/+gNp/wD4Cp/hWjRQBzXiHQdG j0ndHpFirfaLcZW2QHBmQHt6Vp/8I7of/QG0/wD8BU/wpniX/kD/APbzb/8Ao5K1aAM3/hHdDH/M G0//AMBU/wAKX/hHdD/6A2n/APgKn+FaNFAGd/wjuh/9AbT/APwFT/Cj/hHdD/6A2n/+Aqf4Vo0U AZ3/AAjuh/8AQG0//wABU/wo/wCEd0P/AKA2n/8AgKn+FaNFAGd/wjuh/wDQG0//AMBU/wAKP+Ed 0P8A6A2n/wDgKn+FaNFAGd/wjuh/9AbT/wDwFT/CsV/CuiaLr2n6hp+nxQXN1fnzJFHODDJ8o7Ac dBXV1l6v/wAf2jf9fx/9Ey0AalFU9YvH07Rry9iVWe3geRQ3QkAnnFc9H4qvTo91ORaNcCeO3tnd XhR5GUHDKx3LjJ78jpQB1tFc3Hr1/qj2C6UbRPtNm9wxnRnG5WClRtYY5J556VFa+LLi7aJltokW Sa1jwSSR5gO7nvgjg0AdTRXO6hr1/AbnyII/LtrsRSTeU8vlJ5YbcUU5PJxx0zml1zxN/ZllZTW7 WszTr5z7pPlMKgF2Q9zyMfWhAdDRWLc+JYbeS5ZbaWW1tEDTXCFcKSu4AAnJyCOfcVWvfGEWmzw2 99YyQTuoeSIyoSqFtoI5+fvwOeDQHmdHRWBceKooGvwbRz9ikVCDIoY5ONxBOVTvuPGKra94nutO Fm1sLdVntZJzvRpQSu3C7kOADu+8eKAOoornk8X2f9rf2dJEUdPkkYSK2xwm8jb1wB/FjGaIfFsb siy6dcQ+aIXjLMpDpK+1TwePUjtQB0NFc1feNrGxba8DlxJKrKXVTtjYKxGTycngDk07UvFUlumo rZ2PmzWSBgssqoXBxyFJzt56+2KAOjqjrX/IC1D/AK9pP/QTVuJneJGkj8tyAWQkHafTIqprX/IC 1D/r2k/9BNAEmmf8gq0/64J/6CKtVV0z/kFWn/XBP/QRVqgAooooAKKKKACiiigAooooAypf+Rut f+vCb/0ZFWrWVL/yN1r/ANeE3/oyKtWgAooooAKKKKACiiigAooooAKKKKACiiigAooooAyvEv8A yB/+3m3/APRyVq1leJf+QP8A9vNv/wCjkrVoAKKKKACiiigAooooAKKKKACsfX7mC0n0ie5njgiW ++Z5GCqP3Mvc1sVmauhe80jCFgt6S3GQB5MvJ/SgCO51rw7eWsttPq+nvFKhR1+1oMg8Edapyv4O nuhczXumSSDHD3SspIXaCVLYJwcZxXQeVH/cX8qPKj/uL+VAHNNF4MJXZqdnCF34EGo+WMOcsMKw 4JHTpUrv4PeGWH7fpypKIwQl4q7dn3NuG+UjsRiug8qP+4v5UeVH/cX8qAOeL+Eza/ZxrFsqly7O upbZHJGCWcPubI45PYU5pfBsjo8l1pEnlwiBA88bKiDsATgVv+VH/cX8qPKj/uL+VAHNiPwYBt/t Gx2GIQtH9v8AkZQNoyN2CQOATzTlbwmjxyJrUKyxjHmjVDvYZzhm35YexzXReVH/AHF/Kjyo/wC4 v5UAYEk3haWeadtbg86YbWkGpkMq5ztUh/lGewwKd9p8IiOKMahpuyKBrdF+1rgRtjK43d8Ct3yo /wC4v5UeVH/cX8qAMCGfwpbz+bDq9qmVCsg1D5Hwu3LLuwTgAZIzxVGOz8Jx3czDWbI2ssEcQiN9 lkKOWUq2/KgZGAMYxXW+VH/cX8qPKj/uL+VAHNovg+JI1h1a1haNnYSRakVcljlssHyckZIPepZ5 vCd1LPLcatZzNPGYm36gCFU4yFG75c4HTHSt/wAqP+4v5UeVH/cX8qAM6LXtBiiWNdbsSEAAL3is T9STk1ma94w8ORWU9i2s2hnubWXygsoYEhemRwDz3610nlR/3F/KsnxDpOnXOn3N7PZQS3FvazCG R0BKZXnHp0FAF/TP+QVaf9cE/wDQRVqqumf8gq0/64J/6CKtUAFFFFABRRRQAUUUUAFFFFAGVL/y N1r/ANeE3/oyKtWsqX/kbrX/AK8Jv/RkVatABRRRQAUUUUAFFFFABRRRQBR1LVI9MEG6Ced7iTy4 44FDMTgnuQOgNMOt2qalaadKssdzdxmRFZOFx2YjgHg4Hsag8RaI2tQ2qobcm3m83ZcRl0f5SuCA Qe+fwqjL4TuJ52vG1R4rkSQvEkSAQoI8bV2nLEfe/iH3qF5gzQtPEdld3xtAk8RJkEckiYSUxnD7 Tnt74p9h4h0nUrZri2voiiB2bcwBVVOCT7e/vUek+HrbTJ5Llmaa4eWV1dmYiMOxYhVJIXtnGM4r JvvDl4Y9PtVkEqreOJJETH+iuS7o2T1JCjI/KhdA7nQx6tp0t0bWO+t2nCljGJAWAHXilt9V066t ZLq3vYJYIs+ZIsgKrgZ5PbiueXw1eahNeR3cyW9o11cSRqkeJSXQoDuzjGGJ6Z6VcsPDj22lXlrP 9mnluUVCzmV1cKMDducn8iKOg+o3xFrGmSaPFsv7cme4tzEPMHzgTJyPbg/lWwup2L3klmt5CbmJ dzxBxuUepH4j864nxF4e1JrM21xdebBLBFbz3DqWbDXIO1GJzkAj72cjrzWwPB/+lXm+53wXAn2M Wk8yIyjDYG7Z3P8ADnpR0EXNQ8XaTY2D3i3EdxGFJUxyLhjkDbnPXJFW012xWMNczxWxLiMCSVcF yoOAQeetZ0vhy9u0U3d7biVYfKzDAVGNyEHlj/c/Wnv4fuo9Xk1G0u4Q8rOHSaEsoRgmcYI+b5Pp zQBp3Wr6bZTLDdX9vBK3RJJAp/WiPVtOlhE0d9btGY2lDCQY2KcM30B61Sv9AF7c3MxlQef9n4Me ceU5b9c/hWfdeErp/tJtr+KNroXKOXhLbUmYNx8w5GPoc0gNe28QaVd3c9rFeRmWCRYnBYDLMMgD 1zUz6vpsbxI99bq0zlIwZB8zA4IHvnj61k3Hhy7d3aG8hGJ4LiIPETh41CkHnlSB2wRVOfwdfTW0 FudVXYrmSUCNlBYzeZkAMM+mGyO/WqF0Ogt9WtpdOa/lYW8KO6s0pAxtYr/MU9dV054vNW+tzH5Y l3CQY2E4DfTIIqjJotyNDawt70RymYyiTaRkGQvt4II64yCD6VkDwVeR2P2aLU4h50LRXDPCzEgy tICuWzn5iDnPrSXmNmq3i3SA7AXKlY7k20rlgBGwUnJz24xV86vpqyW8ZvrcNdAGAeYP3gPQj1qg mhTDUDM9xG0K3xu418v5gShUgnOOpyDis+PwY0NxbuLlJYkSNJYnMiqdjs6kBXA/i/iBHAoXn/Wg M2bjxBpNslyz38BNrG0kqK4LKBwePrxSJ4h0trc3LXcccGxHEruApD5x368VTfwxvUD7SqnN0Swj 5PnZ9+364qL/AIRy/W5t79L23+2QLGAGhYxttRkORuz0bI54xR0DqaN34i0izhuJJb+E/Zo/MkVX BYL64/EfnS/2/pYhaeS8iigUIRK7gK24ZGOfSseTwjeXF/NPPqgZXgmiQBGG3zAB93dtAGOwBPc1 O/h2/wDt0epx3luLxNvDQsYj+72Hjdn3HNAdTXbV9NWeKBr+3Es+DGnmjL56Y9c9quVzkHhJYLQ2 63Qb5bZQ5j5/dPu9e+ePSujoAKKKKACiiigAooooAKKKKACqOtf8gLUP+vaT/wBBNXqo61/yAtQ/ 69pP/QTQBJpn/IKtP+uCf+girVVdM/5BVp/1wT/0EVaoAKKKKACiiigAooooAKKKKAOV8U2utXeq xQ6BfQ2V6bCbbJLHuGN8fA9D74NX7Ww8RpaQrNrVsZRGocmyzzjnnfzU0v8AyN1r/wBeE3/oyKtW gDJ+xa9/0GbX/wAAD/8AHKPsWvf9Bm1/8AD/APHK1qKAMn7Fr3/QZtf/AAAP/wAco+xa9/0GbX/w AP8A8crWooAyfsWvf9Bm1/8AAA//AByj7Fr3/QZtf/AA/wDxytaigDJ+xa9/0GbX/wAAD/8AHKPs Wvf9Bm1/8AD/APHK1qKAMn7Fr3/QZtf/AAAP/wAco+xa9/0GbX/wAP8A8crWooAyfsWvf9Bm1/8A AA//AByj7Fr3/QZtf/AA/wDxytaigDJ+xa9/0GbX/wAAD/8AHKPsWvf9Bm1/8AD/APHK1qKAOX8Q WmtrpWZNXtmX7RBwLHHPnJj+P1rS+xa9/wBBm1/8AD/8cpfEv/IH/wC3m3/9HJWrQBk/Yte/6DNr /wCAB/8AjlH2LXv+gza/+AB/+OVrUUAZP2LXv+gza/8AgAf/AI5R9i17/oM2v/gAf/jla1FAGT9i 17/oM2v/AIAH/wCOUfYte/6DNr/4AH/45WtRQBk/Yte/6DNr/wCAB/8AjlH2LXv+gza/+AB/+OVr UUAZP2LXv+gza/8AgAf/AI5VO+XxBbXNhGus22Lm5MTYsO3lu39/1UV0VZer/wDH9o3/AF/H/wBE y0AN+xa9/wBBm1/8AD/8co+xa9/0GbX/AMAD/wDHK1qybzxFaWOoGzlhuDs8vzJlQGOPzG2pk5zy fQGgA+xa9/0GbX/wAP8A8co+xa9/0GbX/wAAD/8AHKkGvWJvr6zzJ5tjH5kvycEYydp7kcZ+oqrF 4ssWh8ya3u7bMaSos0QBkRmChlwSDywz3GelAE32LXv+gza/+AB/+OUfYte/6DNr/wCAB/8AjlTD WrQxmQeZgXf2T7v/AC03bfyz3pdM1eDVhI9vFOIlYqsrphZMEqdpz6g9cGgCD7Fr3/QZtf8AwAP/ AMco+xa9/wBBm1/8AD/8cqSz1/Tr23u7hZvKis5GSV5RsAx/Fz/Cex71ImtaXI8SLqFuWmQvGPMH zLzz+h/KgCv9i17/AKDNr/4AH/45R9i17/oM2v8A4AH/AOOVOuu6S9mbxdRtjbhtnmeYMbsZx9cc 4pkOv6ZcalHp8N2kk8sHnoFOQyeoNAEf2LXv+gza/wDgAf8A45R9i17/AKDNr/4AH/45UUvim0ih jlFtdTLK02zyUDEpGcM/Ucfr7VNaeI9Nvb+ezhlbfBAk5dlwjIwyCCevBGfTIoAT7Fr3/QZtf/AA /wDxyj7Fr3/QZtf/AAAP/wAcqCLxfpU1pBcjz1W4R2iVo8M+1gu0D1JIwO9aVnqCXdxcweW0cluV 3K2M4ZQQf5j8KAKn2LXv+gza/wDgAf8A45WD4l0zxe6+dba9arZx2032pDaY3jbwMbjk9ecjHvXa VR1r/kBah/17Sf8AoJoAk0z/AJBVpj/ngn/oIq1VXTP+QVaf9cE/9BFWqACiiigAooooAKKKKACi iigDKl/5G61/68Jv/RkVatZUv/I3Wv8A14Tf+jIq1aACiiigAorD8W3UtpoytDO0LPcRpuEnlggt yGf+AEfxdq5yz1e/kl0zfqFx5223WONmA88M7iViP4wFAw3oAe9CA7+iua8OaxbGK+jm1dbrbqLQ xO8yux3Y2jj1OcdqoReIJ7Ox1Z7K+XVbi21ELHA0gd5lKr8i7enJbHGBg0AdmSB1IGaWuTubyXVY reQSxyfY7F715IhhRKykR4B54+c8+grMh1aZ/DdtbW95cve37KGktbtryWNQoZm6fLzgY/2qAO/o rhJNR1bXJrMWBu4rlrDcVSURpDOsm1jIpPIBBGMH6VseIru5+xLmU6eIpxnzrlYBdKAchZFJKdjz jOMUPQDo6K5GPxZL5scGVRpZbRYIrhcTPHIBuJGeSDnnoDTI/E93LDbM2p2EH2qQiRnj4ssBjsf5 hljtxzjnPHSgDsaK5Cz8S6pdapdQqLRY4llAWV0TaVHyv9/eVbr90YBHJpLbxPdyDTmkuIiksxim KxoXZ9wACqHOU5++pb6DmgDb8S/8gf8A7ebf/wBHJWrWV4l/5A//AG82/wD6OStWgAooooAKKKKA CiiigAooooAKy9X/AOP7Rv8Ar+P/AKJlrUrC8URXky6ZHp9zHbXTXhEUskfmKp8mXkrkZoA3awb/ AMMpe6tJqizKl0BD5DlMmMoSSDzyGBwRUOjaZ4rt9Khi1HXreS6Xd5jfZN+fmOOdw7Y7Cr32LXv+ g1b/APgD/wDZ0AZ0fg+WORZzq87zP5/nB1HlsJQd2B1HO0jJP3aU+Fry5tYYr3UIWa2hSGDyYSqg BkJY5Ykk7AOuBWh9i17/AKDVv/4A/wD2dH2LXv8AoNW//gD/APZ0AVx4fuBeMv2xPsLXn2zy/K/e B8527s42556Z7UlvoF5BdX90l5BBNdQmNfs8BRd2TiR13YL+4x3qz9i17/oNW/8A4A//AGdH2LXv +g1b/wDgD/8AZ0rAZieDHtYylrqszDyoVAuVDgNE4aM8Y46gjqc9eKmm8N3tyb1Zr6AR6lEEutkB BVgpAKHdx1756e9XfsWvf9Bq3/8AAH/7Oj7Fr3/Qat//AAB/+zpgtDJbw9qFpFamBoJLr7akrzES SLhY2UFg7k98cEYrR0vQZ9MubaVbtJAsLxzgx43Mzl8rzwMk8HPGKl+xa9/0Grf/AMAf/s6PsWvf 9Bq3/wDAH/7Oj+v0AzbLwuJ7WwhvzIqWH2iIxq7L5ys3BypHBA5B65qW98JLdXMssV39nEkyEqkf /LEIEeLr0YKPpirv2LXv+g1b/wDgD/8AZ0fYte/6DVv/AOAP/wBnQBQuPB6zS28y3YjmtGnktnWP /VO7hgRzyAAQR3BPStDTbe6Gr6hdXMYUOIo0I4D7VyWA7DLED6Un2LXv+g1b/wDgD/8AZ0fYte/6 DVv/AOAP/wBnQtANaqOtf8gLUP8Ar2k/9BNV/sWvf9Bq3/8AAH/7Oqer2euDRr4vrNuyi3kyBY4y Np/26ANjTP8AkFWn/XBP/QRVqqumf8gq0/64J/6CKtUAFFFFABRRRQAUUUUAFFFFAHM+Ide03w5r lvqGq3It4FsZgCQSWO+LgAdTVyHxfoE0KSrqcIDqGAY4IyO9F7bQXfiaC3uYUmhk0+YPHIoZWHmR dQa2I40ijWKNQqIAqqOgA6CgDK/4SrQf+gpB/wB9Uf8ACVaD/wBBSD/vqteigDHbxRoDqVbUrdge oJo/4Sfw/kH+0bbKjA56VsUUAYy+JfDqfd1C1X6cUL4l8OocrqFqp9uP6Vs0UAYcfiDw1DLLLHf2 yvMQZGB+9gYFPTxL4dj+5qFquf7vFbNFAGQPFOgA5Gp2+frSP4n8PyLtfUrZh6E5rYooAxz4n8Pl gx1K2LDgHPNIfEvh0hgdQtSGOT7mtmigDGPiXw6WLHULUsRgnvigeJfDoKkahajb932+lbNFAHLe IPEuiTaVsj1KBm+0QHAPYTIT+grS/wCEq0H/AKCkH/fVO8SHGj5H/Pzb/wDo5K1aAMj/AISrQf8A oKQf99Uf8JVoP/QUg/76rXooAyP+Eq0H/oKQf99Uf8JVoP8A0FIP++q16KAMj/hKtB/6CkH/AH1R /wAJVoP/AEFIP++q16KAMj/hKtB/6CkH/fVH/CVaD/0FIP8AvqteigDI/wCEq0H/AKCkH/fVVLrW 9M1HVNHgs72KaQXhbah5x5MvNdFWXq//AB/aN/1/H/0TLQBqUUUUAFFFFABRRRQAUUUUAFFFFABR RRQAUUUUAFUda/5AWof9e0n/AKCavVR1r/kBah/17Sf+gmgCTTP+QVaf9cE/9BFWqq6Z/wAgq0/6 4J/6CKtUAFFFFABRRRQAUUUUAFFFFAGVL/yN1r/14Tf+jIq1aypf+Rutf+vCb/0ZFWrQAUUUUAFF FFABRRRQAUUUUAFFFFABRRRQAUUUUAZXiX/kD/8Abzb/APo5K1ayvEv/ACB/+3m3/wDRyVleLfGE vh+WKztdOmmuLggJKyHygT7/AMR9uPrUykoq7NaNGdafJBanVUVzsXixxEgl0HW2kCjcy2JAJ7kD NO/4S0f9C/rv/gF/9elzxL+rVex0FFc//wAJaP8AoX9d/wDAL/69H/CWj/oX9d/8Av8A69HPEPq1 XsdBRXP/APCWj/oX9d/8Av8A69H/AAlo/wChf13/AMAv/r0c8Q+rVex0FFc//wAJaP8AoX9d/wDA L/69H/CWj/oX9d/8Av8A69HPEPq1XsdBXPeMWK2Noykgid8EHB/1EtL/AMJaP+hf13/wC/8Ar1na r4kS5uNND6DrAVLosUks/vjypBgDPJ5zj0BpSlFpq5UKFWMlLl2JbrT5zp0kYE1lDdTQJFH52WQ5 5bgnGcjjPamvqM+p3mmyl2jFpcxwzqpwGmOd6n1wB/49VxvFMbgBvDmtsFIIBsc4I6d6aPEluOnh nWfv+Z/yD/4v73Xr71nZX0Z3xqVLe9DX17q35CaNM82rPHeSOoSSY2i7/lk+chifVh0x2HNdLXN/ 8JLACp/4RnWcoxZf9A6E9SOevJqT/hLR/wBC/rv/AIBf/Xq4NRVrnLXp1KsuZRt939f8E6Ciuf8A +EtH/Qv67/4Bf/Xo/wCEtH/Qv67/AOAX/wBeq54mH1ar2Ogorn/+EtH/AEL+u/8AgF/9ej/hLR/0 L+u/+AX/ANejniH1ar2Ogorn/wDhLR/0L+u/+AX/ANej/hLR/wBC/rv/AIBf/Xo54h9Wq9joKK5/ /hLR/wBC/rv/AIBf/Xo/4S0f9C/rv/gF/wDXo54h9Wq9joKK5/8A4S0f9C/rv/gF/wDXo/4S0f8A Qv67/wCAX/16OeIfVqvY6CqOtf8AIC1D/r2k/wDQTXO6141urOwNzaaLqMRiYM/2u0Koy9xuz8p9 +a0ItaXXvB15fLaXFqGtpPkmTGflPIPce9CnFuyCeGqwh7SS0NbTP+QVaf8AXBP/AEEVaqrpn/IK tP8Argn/AKCKtVZzhRRRQAUUUUAFFFFABRRRQBlS/wDI3Wv/AF4Tf+jIq1artZxNqEd8S3mxxNEO eNrFSfxyoqxQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAZPiZlGkAFgC1zb4BPX98laF1aW 97bvb3UCTQuMMki5BrD8bpbt4ffz4PMLuqIwOCh3A5Bx6gfX1rdt4zFbRRs5cogUserYHWpTu2jd 03GnGonu3+A6KNIYkijUKiKFVR2A6U+iiqMAooooAKKKKACiiigArL1f/j+0b/r+P/omWtSq9zZx 3UttI5YG2l81MdztZefwY0AWKKKKACiiigAooooAKKKKACiiigAooooAKKKKAK93Y2l+sa3dvHOs biRFkXIDDocVDrQxoV+B/wA+sn/oJq9UVzbpd2sttJnZMjI2DzgjBoHd2sRaZ/yCrT/rgn/oIq1U cEK28EcKZ2xqFGeuAMVJQIKKKKACiiigD//Z --_004_01FE63842C181246BBE4CF183BD159B4482A1FAENKGEML512MBSchi_--