From ietf@augustcellars.com Sat Mar 3 13:48:24 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9AC21F876D; Sat, 3 Mar 2012 13:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, 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 kEwVzByg6Rff; Sat, 3 Mar 2012 13:48:24 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1658921F876C; Sat, 3 Mar 2012 13:48:23 -0800 (PST) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id D625738F38; Sat, 3 Mar 2012 13:47:53 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , , References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> In-Reply-To: <4F4E03E3.8070006@um.es> Date: Sat, 3 Mar 2012 13:47:06 -0800 Message-ID: <010601ccf987$409e0220$c1da0660$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt1L0qLKvc32/xJBUkpNNaNsw/wgHbB2m1lwhje2A= Content-Language: en-us Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Mar 2012 21:48:24 -0000 I have some comments on the draft. However first let me say that I know = next to nothing about RADIX having only briefly read it a couple of = times and having not yet worked with it to any extent. 1. I think a discussion is in order about the issues of packing a = radius message full in the presence of proxy intermediaries which might = need room for adding and removing routing materials. I don't know how = many proxies are keep local state as oppose to just filling up the = message with Proxy-State items and thus need space on the way back. = Also a discussion of removal and re-insertion of the T flag might be = needed if the proxy fully assembles the message and then relays it in = pieces. 2. The Overview in section 2 does not discuss the fact that a new set = of state items might also added to the message. This changes the limit = of how many bytes can be placed into the fragmented packets. 3. nit - in para #3 of overview you use the word truncated and = truncation. I think a better word set might be partitioned and = partitioning. Also ensure that fragmentation is used strictly for the = process in radius-extensions. I have not found any cases yet were it is = not but will try and remember to look. 4. I am not sure if positioning of the more-data-pending packet is = significant. The introduction says it comes last but nothing to that = effect is said in section 3. =20 5. Section 6 implies that the order of items in a set of fragmented = packets might need to be changed based on the ability of items to be in = the packet. For example if the Access-Accept packet had been =3D = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], = Framed-IP-Address the order would need to be changed in the original = partitioning. This should be mentioned someplace other than just in the = "examples" section. It implies that a general use piece of code to do = this will need to have the table built in, and potentially extended as = new items are added, rather than just being coded correctly in the = specific packet type code. 6. What if any indications does a server have that the client will be = able to deal with the partitioned message other than it will either fail = or get confused depending on what set of attributes are in the first = packet and what it needs and feels it can ignore. From aland@deployingradius.com Sat Mar 3 23:10:34 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 155B721F85A3; Sat, 3 Mar 2012 23:10:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 pYWHoNrabFah; Sat, 3 Mar 2012 23:10:33 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 372BA21F8516; Sat, 3 Mar 2012 23:10:33 -0800 (PST) Message-ID: <4F53154C.9060604@deployingradius.com> Date: Sun, 04 Mar 2012 08:10:04 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> In-Reply-To: <010601ccf987$409e0220$c1da0660$@augustcellars.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 07:10:34 -0000 Jim Schaad wrote: > I have some comments on the draft. However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent. Reviews are always welcome. > 1. I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials. I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back. Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces. The simplest way to address that is to artificially lower the RADIUS maximum packet size, as seen by the client. > 2. The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message. This changes the limit of how many bytes can be placed into the fragmented packets. Yes. > 3. nit - in para #3 of overview you use the word truncated and truncation. I think a better word set might be partitioned and partitioning. Also ensure that fragmentation is used strictly for the process in radius-extensions. I have not found any cases yet were it is not but will try and remember to look. > > 4. I am not sure if positioning of the more-data-pending packet is significant. The introduction says it comes last but nothing to that effect is said in section 3. > > 5. Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet. For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning. This should be mentioned someplace other than just in the "examples" section. It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code. Attribute ordering is explicitly *not* required in RADIUS. > 6. What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore. That's an open area for discussion. RADIUS doesn't have capability negotiation, so it's hard to do. Alan DeKok. From klaas@cisco.com Sun Mar 4 04:27:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F108121F85C6 for ; Sun, 4 Mar 2012 04:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.996 X-Spam-Level: X-Spam-Status: No, score=-0.996 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_40=-0.185, MIME_QP_LONG_LINE=1.396, 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 md5ICw9gLng4 for ; Sun, 4 Mar 2012 04:27:29 -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 4B9BF21F85C5 for ; Sun, 4 Mar 2012 04:27:29 -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 q24CRPcB030668; Sun, 4 Mar 2012 13:27:25 +0100 Received: from 535512e3.cm-6-6a.dynamic.ziggo.nl ([83.85.18.227] helo=[192.168.1.43]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1S4AW2-0003oM-G6; Sun, 04 Mar 2012 13:26:18 +0100 From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (9A405) Message-Id: <0A6B790B-010E-4409-A098-2376AA7FDDBA@cisco.com> Date: Sun, 4 Mar 2012 13:27:25 +0100 To: abfab@ietf.org Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) 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: 0vGForp3O - 58b61e200230 - 20120304 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) on 145.0.1.45 Subject: [abfab] Call for presentations abfab X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Mar 2012 12:27:30 -0000 Hi, I know we have asked for this before, but now that the IETF is getting close= r.... Please let Leif and me know if you would like to present (and have not= indicated so before).=20 Klaas & Leif From alex@um.es Mon Mar 5 00:02:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9C121F8542; Mon, 5 Mar 2012 00:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.057 X-Spam-Level: X-Spam-Status: No, score=-5.057 tagged_above=-999 required=5 tests=[AWL=-1.458, 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 y-1Dh4vhrU1r; Mon, 5 Mar 2012 00:02:36 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 6F90521F8559; Mon, 5 Mar 2012 00:02:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 16D9C5D4E4; Mon, 5 Mar 2012 09:02:35 +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 hu9MhqGaPLs9; Mon, 5 Mar 2012 09:02:34 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id 8D3A95D497; Mon, 5 Mar 2012 09:02:32 +0100 (CET) Message-ID: <4F547319.5040001@um.es> Date: Mon, 05 Mar 2012 09:02:33 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan DeKok References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> In-Reply-To: <4F53154C.9060604@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org, Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 08:02:38 -0000 El 04/03/12 08:10, Alan DeKok escribió: > Jim Schaad wrote: >> I have some comments on the draft. However first let me say that I know next to nothing about RADIX having only briefly read it a couple of times and having not yet worked with it to any extent. > Reviews are always welcome. > >> 1. I think a discussion is in order about the issues of packing a radius message full in the presence of proxy intermediaries which might need room for adding and removing routing materials. I don't know how many proxies are keep local state as oppose to just filling up the message with Proxy-State items and thus need space on the way back. Also a discussion of removal and re-insertion of the T flag might be needed if the proxy fully assembles the message and then relays it in pieces. > The simplest way to address that is to artificially lower the RADIUS > maximum packet size, as seen by the client. Additionally, regarding the T flag removal/re-insertion comment, proxies are not allowed to perform RADIUS fragmentation on forwarded packets. It is a process performed end-to-end the RADIUS client and server. > >> 2. The Overview in section 2 does not discuss the fact that a new set of state items might also added to the message. This changes the limit of how many bytes can be placed into the fragmented packets. > Yes. > >> 3. nit - in para #3 of overview you use the word truncated and truncation. I think a better word set might be partitioned and partitioning. Also ensure that fragmentation is used strictly for the process in radius-extensions. I have not found any cases yet were it is not but will try and remember to look. >> >> 4. I am not sure if positioning of the more-data-pending packet is significant. The introduction says it comes last but nothing to that effect is said in section 3. >> >> 5. Section 6 implies that the order of items in a set of fragmented packets might need to be changed based on the ability of items to be in the packet. For example if the Access-Accept packet had been = Data1[M], Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the order would need to be changed in the original partitioning. This should be mentioned someplace other than just in the "examples" section. It implies that a general use piece of code to do this will need to have the table built in, and potentially extended as new items are added, rather than just being coded correctly in the specific packet type code. > Attribute ordering is explicitly *not* required in RADIUS. > >> 6. What if any indications does a server have that the client will be able to deal with the partitioned message other than it will either fail or get confused depending on what set of attributes are in the first packet and what it needs and feels it can ignore. > That's an open area for discussion. RADIUS doesn't have capability > negotiation, so it's hard to do. > > Alan DeKok. From hartmans@mit.edu Mon Mar 5 15:39:45 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E2621F8688 for ; Mon, 5 Mar 2012 15:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.655 X-Spam-Level: X-Spam-Status: No, score=-102.655 tagged_above=-999 required=5 tests=[AWL=-2.249, BAYES_20=-0.74, IP_NOT_FRIENDLY=0.334, 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 uxwLdqkM8Vip for ; Mon, 5 Mar 2012 15:39:44 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0C321F8664 for ; Mon, 5 Mar 2012 15:39:44 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EF040204E3; Mon, 5 Mar 2012 18:39:24 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EB15A4350; Mon, 5 Mar 2012 18:39:26 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Mon, 05 Mar 2012 18:39:26 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: draft-hartman-emu-mutual-crypto-bind@tools.ietf.org Subject: [abfab] Heads Up: Significant Attack Against Deployments of EAP Channel Binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Mar 2012 23:39:45 -0000 Hi. While working on the Moonshot Implementation of EAP Channel Bindings, Margaret Wasserman discovered some attacks. We've been working on refining these attacks and put together a draft with our analysis. Please see draft-hartman-emu-mutual-crypto-bind This is not a protocol flaw in EAP Channel Bindings or the ABFAb core specs. However, it is a serious concern in adding EAP Channel Binding to existing EAP methods. so, it's something that we should cover in describing how EAP should be used for application authentication. This isn't a show stopper for Moonshot. The Moonshot Project can work around this for its implementation. Similarly, I believe that enough certificate validation will avoid this issue for people using ABFAB with PLASMA. However, this is a fairly serious issue for the EAP community as a whole. It's very easy to deploy things in a manner where channel bindings don't provide security. We think the ABFAB community should track this issue. we'd ask that discussion take place on the emu@ietf.org list. Thanks for your consideration, --Sam From leifj@sunet.se Mon Mar 5 23:45:06 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 378FF21F8573 for ; Mon, 5 Mar 2012 23:45:06 -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 kNicCXxJ5ur0 for ; Mon, 5 Mar 2012 23:45:05 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id B1A8B21F854B for ; Mon, 5 Mar 2012 23:45:00 -0800 (PST) Received: from [192.36.125.239] (dhcp.pilsnet.sunet.se [192.36.125.239] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q267isnx022605 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 6 Mar 2012 08:44:57 +0100 (CET) Message-ID: <4F55C076.6070106@sunet.se> Date: Tue, 06 Mar 2012 08:44:54 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Heads Up: Significant Attack Against Deployments of EAP Channel Binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 07:45:06 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/2012 12:39 AM, Sam Hartman wrote: > > Hi. While working on the Moonshot Implementation of EAP Channel > Bindings, Margaret Wasserman discovered some attacks. We've been > working on refining these attacks and put together a draft with > our analysis. Please see draft-hartman-emu-mutual-crypto-bind > Do you want a slot to give an overview of the issue at the ABFAB WG meeting? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9VwHYACgkQ8Jx8FtbMZnczmwCgre1AhlApkvXyBbzR/V9jdbBV ug0AoMTlq1hn88w/tBVzPvPThWyoufUK =Enjz -----END PGP SIGNATURE----- From hartmans@painless-security.com Tue Mar 6 05:20:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F73621F86FA for ; Tue, 6 Mar 2012 05:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.062, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 6kQjViozYh6Q for ; Tue, 6 Mar 2012 05:20:03 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 173F521F86C9 for ; Tue, 6 Mar 2012 05:20:00 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C9543204BE; Tue, 6 Mar 2012 08:19:42 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2BDCF4350; Tue, 6 Mar 2012 08:19:53 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4F55C076.6070106@sunet.se> Date: Tue, 06 Mar 2012 08:19:53 -0500 In-Reply-To: <4F55C076.6070106@sunet.se> (Leif Johansson's message of "Tue, 06 Mar 2012 08:44: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: abfab@ietf.org Subject: Re: [abfab] Heads Up: Significant Attack Against Deployments of EAP Channel Binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:20:04 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> On 03/06/2012 12:39 AM, Sam Hartman wrote: >> > Hi. While working on the Moonshot Implementation of EAP Channel >> Bindings, Margaret Wasserman discovered some attacks. We've been >> working on refining these attacks and put together a draft with >> our analysis. Please see draft-hartman-emu-mutual-crypto-bind >> Do you want a slot to give an overview of the issue at the ABFAB Leif> WG meeting? I'm not sure that's necessary. I think we'll be discussing at EMU. I'm happy to take some open mic time if we have any. If you want me to spend more I'm happy to do it, I just hope we'll be busy with other things. From hartmans@painless-security.com Tue Mar 6 05:22:33 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B2B21F86C9 for ; Tue, 6 Mar 2012 05:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.324 X-Spam-Level: X-Spam-Status: No, score=-2.324 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jH9Mz-t4SAKE for ; Tue, 6 Mar 2012 05:22:29 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 05BFB21F86EC for ; Tue, 6 Mar 2012 05:22:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3A0A12023F; Tue, 6 Mar 2012 08:22:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 998D44350; Tue, 6 Mar 2012 08:22:18 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4F55C076.6070106@sunet.se> Date: Tue, 06 Mar 2012 08:22:18 -0500 In-Reply-To: <4F55C076.6070106@sunet.se> (Leif Johansson's message of "Tue, 06 Mar 2012 08:44: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: abfab@ietf.org Subject: Re: [abfab] Heads Up: Significant Attack Against Deployments of EAP Channel Binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:22:33 -0000 Hmm. Thinking more. We'll obviously eventually have to discuss what we want to recommend for abfab-like uses in response to that. I think that will take time on the list and possibly in-person. I'm definitely not ready for that now and am not sure I'll be ready by Paris with my own thoughts. So, yes there are ABFAb aspects we'll have to consider. Right now though I'm not ready to do more than give people a heads up. Your call about whether to spend time. --Sam From leifj@sunet.se Tue Mar 6 05:38:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7A521F8848 for ; Tue, 6 Mar 2012 05:38:53 -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 iuVhNSxzmN6K for ; Tue, 6 Mar 2012 05:38:53 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF8F21F871E for ; Tue, 6 Mar 2012 05:38:46 -0800 (PST) Received: from [192.36.125.239] (dhcp.pilsnet.sunet.se [192.36.125.239] (may be forged)) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q26DcekI019686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 6 Mar 2012 14:38:43 +0100 (CET) Message-ID: <4F561360.2080109@sunet.se> Date: Tue, 06 Mar 2012 14:38:40 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: <4F55C076.6070106@sunet.se> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Heads Up: Significant Attack Against Deployments of EAP Channel Binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 13:38:54 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/06/2012 02:19 PM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > > Leif> On 03/06/2012 12:39 AM, Sam Hartman wrote: >>> >> Hi. While working on the Moonshot Implementation of EAP Channel >>> Bindings, Margaret Wasserman discovered some attacks. We've >>> been working on refining these attacks and put together a draft >>> with our analysis. Please see >>> draft-hartman-emu-mutual-crypto-bind >>> > > Do you want a slot to give an overview of the issue at the ABFAB > Leif> WG meeting? > > I'm not sure that's necessary. I think we'll be discussing at EMU. > I'm happy to take some open mic time if we have any. > > If you want me to spend more I'm happy to do it, I just hope we'll > be busy with other things. Very good. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9WE2AACgkQ8Jx8FtbMZnciGQCfU8ZZRaq5nAo43ZhFMSWznqOB EDkAn3PnOW642v7fYrVjk6Q0iI3yKYdp =wRUj -----END PGP SIGNATURE----- From hartmans@painless-security.com Tue Mar 6 06:55:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0133621F87F4 for ; Tue, 6 Mar 2012 06:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.321 X-Spam-Level: X-Spam-Status: No, score=-2.321 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 TydK1kozePV1 for ; Tue, 6 Mar 2012 06:55:34 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 88AC021F87ED for ; Tue, 6 Mar 2012 06:55:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6A634204BE; Tue, 6 Mar 2012 09:55:16 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5E1D94350; Tue, 6 Mar 2012 09:55:26 -0500 (EST) From: Sam Hartman To: Rhys Smith References: <0375B6F5-EC9C-4DB3-9F6E-8B99F75A5B72@cardiff.ac.uk> Date: Tue, 06 Mar 2012 09:55:26 -0500 In-Reply-To: <0375B6F5-EC9C-4DB3-9F6E-8B99F75A5B72@cardiff.ac.uk> (Rhys Smith's message of "Wed, 22 Feb 2012 11:49:46 +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: abfab@ietf.org Subject: Re: [abfab] New Version Notification for draft-ietf-abfab-usecases-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 14:55:35 -0000 >>>>> "Rhys" == Rhys Smith writes: Rhys> So the way I've done it in this document is that I'm listed as Rhys> the editor (as I'm pulling the document together), and the Rhys> contributors are listed in Sections 5 and 6 of the document. This is very standard ietf practice. From hartmans@mit.edu Tue Mar 6 11:55:32 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5789D21F87C1 for ; Tue, 6 Mar 2012 11:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.548 X-Spam-Level: X-Spam-Status: No, score=-103.548 tagged_above=-999 required=5 tests=[AWL=-1.283, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 aU7iUuHc2-pr for ; Tue, 6 Mar 2012 11:55:32 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id DD21121F8778 for ; Tue, 6 Mar 2012 11:55:31 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4C21520580 for ; Tue, 6 Mar 2012 14:55:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EA0774366; Tue, 6 Mar 2012 14:55:22 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Tue, 06 Mar 2012 14:55:22 -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: [abfab] Removed dangling name form from draft-ietf-abfab-gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 19:55:32 -0000 I removed the following section from draft-ietf-abfab-gss-eap: Sometimes, the client may know what AAA realm a particular host should belong to. In this case it would be desirable to use a name form that included a service, host and realm. Syntactically, this appears the same as the domain-based name discussed in , but the semantics are not similar enough semantics to use the same name form. Rationale: we describe the syntax for a name, but we don't actually give the oid to use to import that name. We haven't needed such a name in testing so far and you can always just import the gss-eap mechanism name if you really need it. So it's needless complexity and if it turns out it is needed later it can be added in a future document. From hartmans@painless-security.com Tue Mar 6 12:53:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E962421E8053 for ; Tue, 6 Mar 2012 12:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.318 X-Spam-Level: X-Spam-Status: No, score=-2.318 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 J1u0Jttz1l0H for ; Tue, 6 Mar 2012 12:53:34 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6D4FE21E80BF for ; Tue, 6 Mar 2012 12:53:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EE31B20118; Tue, 6 Mar 2012 15:53:15 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8BC0C4366; Tue, 6 Mar 2012 15:53:25 -0500 (EST) From: Sam Hartman To: Alejandro Perez Mendez References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <011a01cc9833$3a006440$ae012cc0$@augustcellars.com> <4EB140CF.1040206@um.es> Date: Tue, 06 Mar 2012 15:53:25 -0500 In-Reply-To: <4EB140CF.1040206@um.es> (Alejandro Perez Mendez's message of "Wed, 02 Nov 2011 14:08:31 +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: abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:53:35 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Sorry for the delay and thanks for all the great comments. I believe most of these will be fixed in 05; please let me know if I missed anything. Alejandro> * It is stated that "The subtoken type MUST be unique Alejandro> within a given token". Is there any requirement or Alejandro> motivation for this? Won't this limit us in the future Alejandro> for extensions? Just asking, cause I don't really know. I don't think this is a problem. If we define a subtoken type that you might want more than one of we can have internal structure within it. Alejandro> Section 5.7 Alejandro> * I have a question here, not an issue, I'm just Alejandro> curious. If the PROT_READY is never available and Alejandro> per-message security services cannot be used before Alejandro> context establishment, how do you call to GSS_Wrap and Alejandro> GSS_GetMIC to generate the Channel Bindings and MIC Alejandro> subtokens? The mechanism implementation can produce the token without calling gss_wrap. However this sort of layering violation is one of the things that caused me to support using RFC 3961 tokens in 5.6 rather than 4121 tokens. So this issue gues away in the next version anyway. --Sam From hartmans@painless-security.com Tue Mar 6 12:59:57 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B014421F8634 for ; Tue, 6 Mar 2012 12:59:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3] 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 3zpQLhhIghEl for ; Tue, 6 Mar 2012 12:59:57 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 294A421F8675 for ; Tue, 6 Mar 2012 12:59:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id EC67B204BE; Tue, 6 Mar 2012 15:59:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A47C24366; Tue, 6 Mar 2012 15:59:48 -0500 (EST) From: Sam Hartman To: zhou.sujing@zte.com.cn References: Date: Tue, 06 Mar 2012 15:59:48 -0500 In-Reply-To: (zhou sujing's message of "Sat, 17 Dec 2011 10:12:28 +0800") 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: abfab@ietf.org Subject: Re: [abfab] =?iso-8859-1?q?=F0=B4=3A_Re=3A__a_review_on_draft-ietf-ab?= =?iso-8859-1?q?fab-gss-eap-04?= X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 20:59:57 -0000 >>>>> "zhou" == zhou sujing writes: zhou> While, I think 1. it better have a reference (I guess it is zhou> RFC6066) after " This is similar to TLS Server Name zhou> Indication", and have a brief explaintation about the use of zhou> Server name indication there, since it is not inlcuded in TLS zhou> but an extension, and may be not known by most people (like me zhou> :) ). 2. and better change the "Acceptor Name Request" to zhou> "Acceptor Name Indication" since it is REALLY easy to take zhou> "Acceptor Name Request" and "Acceptor Name Response" as a pair zhou> of requesting and answering the name of acceptor. 3. put some zhou> more explaining words in the beginning of Section 5.4.2 I'd prefer not to change the name of the subtoken at this late date, but I did take your other suggestions. From hartmans@painless-security.com Tue Mar 6 13:24:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFE821F87C8 for ; Tue, 6 Mar 2012 13:24:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.307 X-Spam-Level: X-Spam-Status: No, score=-2.307 tagged_above=-999 required=5 tests=[AWL=-0.042, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 TNuVppSDYevt for ; Tue, 6 Mar 2012 13:24:11 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id B653421F8587 for ; Tue, 6 Mar 2012 13:24:11 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 80E4F204BE for ; Tue, 6 Mar 2012 16:23:53 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 746604366; Tue, 6 Mar 2012 16:24:03 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Tue, 06 Mar 2012 16:24:03 -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: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:24:12 -0000 Hi. we had a long discussion on the list and in the meeting about whether we want to continue wasting a round trip on eap request/identity or whether we want to introduce a new subtoken type to carry the identity from the initiator to the acceptor. If I were making a consensus call I'd say we were going to drop the round trip and add the subtoken. However it was not entirely clear and I'd sure appreciate any comments from the chairs or others. From Josh.Howlett@ja.net Tue Mar 6 13:53:06 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFD421E8053 for ; Tue, 6 Mar 2012 13:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.144 X-Spam-Level: X-Spam-Status: No, score=-101.144 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185, 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 1DTMk4WdNNaV for ; Tue, 6 Mar 2012 13:53:06 -0800 (PST) Received: from har003676.ukerna.ac.uk (har003676.ukerna.ac.uk [194.82.140.75]) by ietfa.amsl.com (Postfix) with ESMTP id DBE7A21E8013 for ; Tue, 6 Mar 2012 13:53:05 -0800 (PST) Received: from har003676.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 5A1DA4A6B64_F568740B; Tue, 6 Mar 2012 21:53:04 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by har003676.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 3039C4A6B60_F568740F; Tue, 6 Mar 2012 21:53:04 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Tue, 6 Mar 2012 21:53:04 +0000 From: Josh Howlett To: Sam Hartman , "abfab@ietf.org" Thread-Topic: [abfab] gss-eap: eap identity? Thread-Index: AQHM+9+BmFJJDoIvd0qRYknMqiGHCZZdzz8A Date: Tue, 6 Mar 2012 21:53:03 +0000 Message-ID: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <04FC0FD92049604A9E8207D7B0EEDFDB@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Mar 2012 21:53:06 -0000 > >If I were making a consensus call I'd say we were going to drop the >round trip and add the subtoken. However it was not entirely clear and >I'd sure appreciate any comments from the chairs or others. My recollection is that there was a fair amount of ambivalence around this point, myself included. If I had to come off the fence I would prefer to avoid a special-case for the sake of a single trip, but that's basically an argument from aesthetics that I admit isn't hugely compelling. Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From lukeh@padl.com Tue Mar 6 17:09:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A746821E8028 for ; Tue, 6 Mar 2012 17:09:03 -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.700, 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 mRBd5WxQ24-S for ; Tue, 6 Mar 2012 17:09:03 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id 26E6321E8011 for ; Tue, 6 Mar 2012 17:09:03 -0800 (PST) Received: by us.padl.com with ESMTP id q2718nKj021734; Tue, 6 Mar 2012 20:08:54 -0500 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Luke Howard In-Reply-To: Date: Wed, 7 Mar 2012 12:08:52 +1100 Content-Transfer-Encoding: 7bit Message-Id: References: To: Josh Howlett X-Mailer: Apple Mail (2.1257) X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL,BAYES_00,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.5 Cc: "abfab@ietf.org" Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 01:09:03 -0000 On 07/03/2012, at 8:53 AM, Josh Howlett wrote: > My recollection is that there was a fair amount of ambivalence around this > point, myself included. If I had to come off the fence I would prefer to > avoid a special-case for the sake of a single trip, but that's basically > an argument from aesthetics that I admit isn't hugely compelling. Right, I had the same feeling as Josh. -- Luke From alex@um.es Tue Mar 6 23:35:33 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6336321F85B7 for ; Tue, 6 Mar 2012 23:35:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.445 X-Spam-Level: X-Spam-Status: No, score=-6.445 tagged_above=-999 required=5 tests=[AWL=0.154, 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 o9hMechkU4bf for ; Tue, 6 Mar 2012 23:35:32 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB4421F85B5 for ; Tue, 6 Mar 2012 23:35:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 16BAD5D4BF; Wed, 7 Mar 2012 08:35:31 +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 phuqk7e9u-q7; Wed, 7 Mar 2012 08:35:30 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id C2DBC5D4B8; Wed, 7 Mar 2012 08:35:30 +0100 (CET) Message-ID: <4F570FC1.2070102@um.es> Date: Wed, 07 Mar 2012 08:35:29 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: <013901cc95b9$7ef055f0$7cd101d0$@augustcellars.com> <011a01cc9833$3a006440$ae012cc0$@augustcellars.com> <4EB140CF.1040206@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Review on gss-eap-03 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 07:35:33 -0000 El 06/03/12 21:53, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > > Sorry for the delay and thanks for all the great comments. > I believe most of these will be fixed in 05; please let me know if I > missed anything. > > > Alejandro> * It is stated that "The subtoken type MUST be unique > Alejandro> within a given token". Is there any requirement or > Alejandro> motivation for this? Won't this limit us in the future > Alejandro> for extensions? Just asking, cause I don't really know. > I don't think this is a problem. > > If we define a subtoken type that you might want more than one of we can > have internal structure within it. Right, we could do that. > Alejandro> Section 5.7 > > Alejandro> * I have a question here, not an issue, I'm just > Alejandro> curious. If the PROT_READY is never available and > Alejandro> per-message security services cannot be used before > Alejandro> context establishment, how do you call to GSS_Wrap and > Alejandro> GSS_GetMIC to generate the Channel Bindings and MIC > Alejandro> subtokens? > > > The mechanism implementation can produce the token without calling > gss_wrap. > However this sort of layering violation is one of the things that caused > me to support using RFC 3961 tokens in 5.6 rather than 4121 tokens. > So this issue gues away in the next version anyway. Ok, it's clear now. Regards, Alejandro > > --Sam From klaas@cisco.com Wed Mar 7 00:45:48 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FB221F864E for ; Wed, 7 Mar 2012 00:45:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.294 X-Spam-Level: X-Spam-Status: No, score=-9.294 tagged_above=-999 required=5 tests=[AWL=1.305, 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 mrfVZ+57g3aH for ; Wed, 7 Mar 2012 00:45:48 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F2BAD21F864B for ; Wed, 7 Mar 2012 00:45:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=klaas@cisco.com; l=1465; q=dns/txt; s=iport; t=1331109948; x=1332319548; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=A48WEgTpqdP2f2quVPyDMgUTtGtIuv/QRnYw+iyA618=; b=f22RED9pmf7MHGitvxkn1xyBckA4JdHVwVmEBbtjcaQLPO9yiG+FAf3k jo9p5dARmFZCaNfY3foDRFMNh/by6EakUaDu/LcSMEkvoxFvakfPrNqqY vjYvosAQ4bQAB7+mbwJLcQNdeui2wkfZdm0qiEOND/ERxGOwvVJ3pF/XO o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAD4fV0+tJXG8/2dsb2JhbAA5CbUagQeBfQEBAQMBEgFlBgsLIRYPCQMCAQIBRRMIAQEeh2AFoFYBlzCKIoMsgyIElT+QFoJk X-IronPort-AV: E=Sophos;i="4.73,545,1325462400"; d="scan'208";a="64421517" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 07 Mar 2012 08:45:47 +0000 Received: from macmini.wierenga.net (rtp-kwiereng-8714.cisco.com [10.116.7.37]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id q278jk98026187 for ; Wed, 7 Mar 2012 08:45:47 GMT Message-ID: <4F57203A.6080502@cisco.com> Date: Wed, 07 Mar 2012 09:45:46 +0100 From: Klaas Wierenga User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 08:45:48 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 3/6/12 10:24 PM, Sam Hartman wrote: Hi Sam, > we had a long discussion on the list and in the meeting about > whether we want to continue wasting a round trip on eap > request/identity or whether we want to introduce a new subtoken > type to carry the identity from the initiator to the acceptor. > > If I were making a consensus call I'd say we were going to drop > the round trip and add the subtoken. However it was not entirely > clear and I'd sure appreciate any comments from the chairs or > others. As an individual: If I had to make a judgment call I would argue that this extra round trip is not such a big deal compared to introducing a new special case. It is my understanding that this exchange happens once, when the application is accessed. Compared to using EAP for network access where potentially a high frequency of reauthentications need to take place I don't think this is a big deal. So I'd be happy to sacrifice this one extra round trip for generality. As a chair: Perhaps we need to make a formal consensus call, don't you think? Klaas -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9XIDoACgkQH2Wy/p4XeFKLfgCfZx7JfslxPrKW0U8v6VEARde2 7gIAnRxkPwLvAPchvNGENL/tkJBHYLE8 =cNwV -----END PGP SIGNATURE----- From hartmans@painless-security.com Wed Mar 7 06:46:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE61221F862F for ; Wed, 7 Mar 2012 06:46:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.306 X-Spam-Level: X-Spam-Status: No, score=-2.306 tagged_above=-999 required=5 tests=[AWL=-0.040, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 unko0EUYUEnC for ; Wed, 7 Mar 2012 06:46:55 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 17BC221F86A0 for ; Wed, 7 Mar 2012 06:46:53 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B8AFD20118; Wed, 7 Mar 2012 09:46:33 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BE36A4352; Wed, 7 Mar 2012 09:46:42 -0500 (EST) From: Sam Hartman To: Klaas Wierenga References: <4F57203A.6080502@cisco.com> Date: Wed, 07 Mar 2012 09:46:42 -0500 In-Reply-To: <4F57203A.6080502@cisco.com> (Klaas Wierenga's message of "Wed, 07 Mar 2012 09:45:46 +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: abfab@ietf.org Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 14:46:56 -0000 Speaking as an individual. I don't look forward to making changes to EAP identity handling now and I definitely don't look forward to implementing the code for it. I think this is a change we can make later. I do think we'll have to make it later. This saves a round trip and throughout the IETF we've generally found that saving round trips in authentication is important. This is only a round trip when you access an application but for some important classes of application you access them very very frequently. For example for Kerberos used with HTTP we'd seen thousands of authentications a second for a single web page. (Without fast reauthentication of some kind, GSS-EAP will not be suitable for that deployment. It stretches Kerberos a lot.) So I think we'll end up supporting this long-term. I think we can add support later. I think the spec and implementation would be cleaner if we added support now. Currently the EAP identity is more of a special case than I think it will end up. Currently, we have EAP traffic both in the initial state and in the authenticate state. Also, a passthrough authenticator needs to synthesize an identity request. We could get rid of both of those if we had an identity subtoken. However we clearly don't have consensus to make the change (I'm really glad I asked). Building that consensus would take time, getting the change right and implemented would take time. I'd rather just do this in a future extension document if I'm right that we end up needing it. I think the result will be slightly more ugly, but it would be nice to get done and last call our core specs. From rafa@um.es Wed Mar 7 07:41:30 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB2521E80C1 for ; Wed, 7 Mar 2012 07:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.200, 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 TM1KwG6LAiuA for ; Wed, 7 Mar 2012 07:41:29 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id DACC321E8082 for ; Wed, 7 Mar 2012 07:41:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 8724F5D51A; Wed, 7 Mar 2012 16:41:25 +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 KGUGfvXK6OQf; Wed, 7 Mar 2012 16:41:25 +0100 (CET) Received: from inf-205-205.inf.um.es (inf-205-205.inf.um.es [155.54.205.205]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPSA id D81B75D4DC; Wed, 7 Mar 2012 16:41:24 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Wed, 7 Mar 2012 16:41:24 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7A8C5795-2904-4136-A0C7-B0451348ADB6@um.es> References: To: Sam Hartman X-Mailer: Apple Mail (2.1257) Cc: abfab@ietf.org Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 15:41:30 -0000 Hi Sam: =46rom what I recall, I suggested to move to the subtoken option because = synthesizing an EAP response/id was not a good idea.=20 The reasons were explained here = http://www.ietf.org/mail-archive/web/abfab/current/msg00947.html Nevertheless I am still wondering what is the benefit. Let me explain. = Fast re-authentication is generally important but we are just saving a = round trip between initiator and acceptor, which are not too much in = comparison with the number of messages involved during a whole EAP = authentication and the travel the messages have to do all the way to the = home AAA/EAP server. So basically I believe reducing that part does not = help too much if we do not reduce the real critic parts as the number of = EAP messages or the fact they have to reach the home AAA/EAP server. Not only that. I also made some additional comments about some situation = that may happen, but I believe there were not any comments after my = e-mail. My last e-mail was in http://www.ietf.org/mail-archive/web/abfab/current/msg00950.html But let me paste what I wrote: "Definitely, designing a subtoken seems the most standard way of = defining this optimization. Nevertheless, we may need to think about = something I just realized. It may happen that when the acceptor sends = the EAP-Start in the RADIUS Access-Request that the RADIUS EAP/AAA = server decides to start the EAP request/identity instead the first EAP = request of the chosen EAP method. The reason is the text about that RFC = 3579 I pasted in my previous e-mail where it is said: "The RADIUS server will typically respond with an Access-Challenge containing EAP-Message attribute(s) encapsulating an EAP-Request/Identity (Type 1). However, an EAP-Request for an authentication method (Type 4 or greater) can also be sent by the server." It means that RADIUS EAP/AAA server implementation is not obligated = (there is no MUST in the text) to start an EAP method instead of sending = an EAP request/identity. This means that RADIUS EAP/AAA should be = correctly configured to allow this optimization. Otherwise, the RADIUS = EAP/AAA server will send the EAP request/identity that has to travel all = the way to the authenticator.=20 Although the solution does not violate any standard, in certain cases it = may not help to achieve the optimization if the home EAP/AAA is not = configured to select directly the EAP method for that peer. Even I would = say that it is more problematic than sending the EAP request/identity = from the authenticator (The EAP request/identity sent from the home = EAP/AAA will add more latency and the same number of messages than the = current not optimized case). So the question would be : can we be sure that all home EAP/AAA servers = will act to allow the optimization?" NOTE: If the subtoken carries the same identity as it should be included = in the EAP response/id, it may work. However, I am not completely sure = what will be the default behavior of existing RADIUS servers when they = receive a User-Name without any EAP packet or with the "EAP-Start" = packet. Potentially, it seems they may initiate EAP Request/Id in some = cases. It is for sure that RADIUS experts may provide some good insight = about it. Best regards. El 06/03/2012, a las 22:24, Sam Hartman escribi=F3: >=20 > Hi. >=20 > we had a long discussion on the list and in the meeting about whether = we > want to continue wasting a round trip on eap request/identity or > whether we want to introduce a new subtoken type to carry the identity > from the initiator to the acceptor. >=20 > If I were making a consensus call I'd say we were going to drop the > round trip and add the subtoken. However it was not entirely clear = and > I'd sure appreciate any comments from the chairs or others. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Wed Mar 7 08:53:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC9CD21F8762 for ; Wed, 7 Mar 2012 08:53:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=-0.039, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 GEUMEFssNa2F for ; Wed, 7 Mar 2012 08:53:07 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7EFDB21F8757 for ; Wed, 7 Mar 2012 08:53:06 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3496E203BA; Wed, 7 Mar 2012 11:52:43 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 620CB4352; Wed, 7 Mar 2012 11:52:52 -0500 (EST) From: Sam Hartman To: Rafa Marin Lopez References: <7A8C5795-2904-4136-A0C7-B0451348ADB6@um.es> Date: Wed, 07 Mar 2012 11:52:52 -0500 In-Reply-To: <7A8C5795-2904-4136-A0C7-B0451348ADB6@um.es> (Rafa Marin Lopez's message of "Wed, 7 Mar 2012 16:41:24 +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: abfab@ietf.org Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 16:53:10 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: From what I recall, I suggested to move to the Rafa> subtoken option because synthesizing an EAP response/id was Rafa> not a good idea. Rafa> The reasons were explained here Rafa> http://www.ietf.org/mail-archive/web/abfab/current/msg00947.html Right. I think we all agree with you and appreciate that input. Rafa> Nevertheless I am still wondering what is the benefit. Let me Rafa> explain. Fast re-authentication is generally important but we Rafa> are just saving a round trip between initiator and acceptor, Rafa> which are not too much in comparison with the number of Rafa> messages involved during a whole EAP authentication and the Rafa> travel the messages have to do all the way to the home AAA/EAP Rafa> server. So basically I believe reducing that part does not Rafa> help too much if we do not reduce the real critic parts as the Rafa> number of EAP messages or the fact they have to reach the home Rafa> AAA/EAP server. You may well be right. I had not fully thought this through. It sounds like you'd be happy holding off on this change if we ever make it. When we are next in person I'd like to discuss this sort of optimization with you in more detail. From hartmans@painless-security.com Wed Mar 7 12:10:43 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FEBE21E808F for ; Wed, 7 Mar 2012 12:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 8N6TOLH4ac3t for ; Wed, 7 Mar 2012 12:10:35 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9DECF21E805E for ; Wed, 7 Mar 2012 12:10:35 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id D720B203BA for ; Wed, 7 Mar 2012 15:10:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E595643F3; Wed, 7 Mar 2012 15:10:22 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Wed, 07 Mar 2012 15:10:22 -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: [abfab] eap-aes128 or eap-aes128-cts-hmac-sha1-96 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 20:10:43 -0000 hi. The draft currently proposes the longer SASL name, but the Moonshot implementation mostly (except in one comment) uses the shorter name. Changing either the draft or the Moonshot code would not be a big deal. I bring this up because I seem to remember some discussion of the shorter name. Advantages of the shorter name: shorter and easier to remember for configuration and debugging. Disadvantages: There have been other proposals for aes128 Kerberos enctypes. Please let me know what we want. would we be OK with eap-aes128 meaning eap-aes128-cts-hmac-sha1-96 and eap-aes128-gcm meaning the obvious thing? From lukeh@padl.com Wed Mar 7 14:52:32 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C6D411E808F for ; Wed, 7 Mar 2012 14:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.251 X-Spam-Level: X-Spam-Status: No, score=-2.251 tagged_above=-999 required=5 tests=[AWL=-1.048, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] 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 tCIneLraeBsq for ; Wed, 7 Mar 2012 14:52:31 -0800 (PST) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id AB86311E80AE for ; Wed, 7 Mar 2012 14:52:31 -0800 (PST) Received: by us.padl.com with ESMTP id q27MqPb9017932; Wed, 7 Mar 2012 17:52:30 -0500 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <69A20EEF-B03E-4400-ACC5-F3DFC3A855D3@padl.com> X-Mailer: iPhone Mail (9A405) From: Luke Howard Date: Thu, 8 Mar 2012 09:52:22 +1100 To: Sam Hartman X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: ALL_TRUSTED,AWL,BAYES_00,MIME_QP_LONG_LINE,USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.6 Cc: "abfab@ietf.org" Subject: Re: [abfab] eap-aes128 or eap-aes128-cts-hmac-sha1-96 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 22:52:32 -0000 On 08/03/2012, at 7:10 AM, Sam Hartman wrot= e: > would we be OK with eap-aes128 meaning eap-aes128-cts-hmac-sha1-96 and > eap-aes128-gcm meaning the obvious thing? I think this is a sensible compromise.= From hartmans@painless-security.com Wed Mar 7 15:57:07 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0797411E8094 for ; Wed, 7 Mar 2012 15:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[AWL=-0.036, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 FUR6JSZX23JN for ; Wed, 7 Mar 2012 15:57:06 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9370711E808C for ; Wed, 7 Mar 2012 15:57:06 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id BBBC1203BA for ; Wed, 7 Mar 2012 18:56:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4F4D844EB; Wed, 7 Mar 2012 18:56:56 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Wed, 07 Mar 2012 18:56:56 -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: [abfab] Oops: changes potentially lost in my working copy of gss-eap X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Mar 2012 23:57:07 -0000 folks, today has not been the most productive. I had an editor oops and managed to lose all changes to section 5 of draft-ietf-abfab-gss-eap since October 30. The good news is that isn't too many changes as I have been mostly working on other sections of the documents. I think I've gone back and reconstructed section 5 changes from the reviews, but I'd appreciate people looking at 05 when it is published and if their requested changes failed to make it let me know. If I said I fixed issues you brought up and the changes are absent please let me know. I'm not trying to drop changes it was an honest mistake. --sam From ietf@augustcellars.com Thu Mar 8 20:55:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1861421F855D; Thu, 8 Mar 2012 20:55:01 -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 z3RZasEeYLVj; Thu, 8 Mar 2012 20:55:00 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 0A54121F855B; Thu, 8 Mar 2012 20:54:50 -0800 (PST) Received: from Tobias (50-39-221-206.bvtn.or.frontiernet.net [50.39.221.206]) (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 7790C2CA17; Thu, 8 Mar 2012 20:54:49 -0800 (PST) From: "Jim Schaad" To: "'Alan DeKok'" References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> In-Reply-To: <4F53154C.9060604@deployingradius.com> Date: Thu, 8 Mar 2012 20:54:03 -0800 Message-ID: <002701ccfdb0$a6b67ab0$f4237010$@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: AQFt1L0qLKvc32/xJBUkpNNaNsw/wgHbB2m1AfCQXZUCbseylpbt5J8g Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:55:01 -0000 > > > 1. I think a discussion is in order about the issues of packing a radius > message full in the presence of proxy intermediaries which might need room > for adding and removing routing materials. I don't know how many proxies > are keep local state as oppose to just filling up the message with Proxy-State > items and thus need space on the way back. Also a discussion of removal > and re-insertion of the T flag might be needed if the proxy fully assembles > the message and then relays it in pieces. > > The simplest way to address that is to artificially lower the RADIUS maximum > packet size, as seen by the client. > Would this also be a way to deal with restrictions on the size seen by the server? I.e. you also need to make the server deal with smaller packets as well. Jim From ietf@augustcellars.com Thu Mar 8 20:56:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD7221F855B; Thu, 8 Mar 2012 20:56:21 -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 w2eCUkBM+CWF; Thu, 8 Mar 2012 20:56:20 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9A30C21F855A; Thu, 8 Mar 2012 20:56:19 -0800 (PST) Received: from Tobias (50-39-221-206.bvtn.or.frontiernet.net [50.39.221.206]) (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 18BD038EA6; Thu, 8 Mar 2012 20:56:19 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , "'Alan DeKok'" References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <4F547319.5040001@um.es> In-Reply-To: <4F547319.5040001@um.es> Date: Thu, 8 Mar 2012 20:55:32 -0800 Message-ID: <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt1L0qLKvc32/xJBUkpNNaNsw/wgHbB2m1AfCQXZUCbseylgGK6EbSluGNtJA= Content-Language: en-us Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 04:56:21 -0000 > -----Original Message----- > From: Alejandro Perez Mendez [mailto:alex@um.es] > Sent: Monday, March 05, 2012 12:03 AM > To: Alan DeKok > Cc: Jim Schaad; radext@ietf.org; abfab@ietf.org > Subject: Re: [abfab] FYI: New Version Notification for = draft-perez-radext- > radius-fragmentation-01.txt >=20 >=20 >=20 > El 04/03/12 08:10, Alan DeKok escribi=C3=B3: > > Jim Schaad wrote: > >> I have some comments on the draft. However first let me say that I = know > next to nothing about RADIX having only briefly read it a couple of = times and > having not yet worked with it to any extent. > > Reviews are always welcome. > > > >> 1. I think a discussion is in order about the issues of packing a = radius > message full in the presence of proxy intermediaries which might need = room > for adding and removing routing materials. I don't know how many = proxies > are keep local state as oppose to just filling up the message with = Proxy-State > items and thus need space on the way back. Also a discussion of = removal > and re-insertion of the T flag might be needed if the proxy fully = assembles > the message and then relays it in pieces. > > The simplest way to address that is to artificially lower the > > RADIUS maximum packet size, as seen by the client. >=20 > Additionally, regarding the T flag removal/re-insertion comment, = proxies are > not allowed to perform RADIUS fragmentation on forwarded packets. It = is a > process performed end-to-end the RADIUS client and server. >=20 What happens for proxies that, for some reason - want to re-write the = contents of packets. For ABFAB I am specifically thinking of changing = or mapping attributes in SAML assertions. > > > >> 2. The Overview in section 2 does not discuss the fact that a new = set of > state items might also added to the message. This changes the limit = of how > many bytes can be placed into the fragmented packets. > > Yes. > > > >> 3. nit - in para #3 of overview you use the word truncated and = truncation. > I think a better word set might be partitioned and partitioning. Also = ensure > that fragmentation is used strictly for the process in = radius-extensions. I > have not found any cases yet were it is not but will try and remember = to > look. > >> > >> 4. I am not sure if positioning of the more-data-pending packet is > significant. The introduction says it comes last but nothing to that = effect is > said in section 3. > >> > >> 5. Section 6 implies that the order of items in a set of = fragmented packets > might need to be changed based on the ability of items to be in the = packet. > For example if the Access-Accept packet had been =3D Data1[M], > Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the > order would need to be changed in the original partitioning. This = should be > mentioned someplace other than just in the "examples" section. It = implies > that a general use piece of code to do this will need to have the = table built in, > and potentially extended as new items are added, rather than just = being > coded correctly in the specific packet type code. > > Attribute ordering is explicitly *not* required in RADIUS. > > > >> 6. What if any indications does a server have that the client will = be able to > deal with the partitioned message other than it will either fail or = get confused > depending on what set of attributes are in the first packet and what = it needs > and feels it can ignore. > > That's an open area for discussion. RADIUS doesn't have = capability > > negotiation, so it's hard to do. > > > > Alan DeKok. From aland@deployingradius.com Fri Mar 9 00:15:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E4321F85A1; Fri, 9 Mar 2012 00:15:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.392 X-Spam-Level: X-Spam-Status: No, score=-102.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 K6c1aj4c4mhh; Fri, 9 Mar 2012 00:15:54 -0800 (PST) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEF521F860B; Fri, 9 Mar 2012 00:15:54 -0800 (PST) Message-ID: <4F59BC22.5070800@deployingradius.com> Date: Fri, 09 Mar 2012 09:15:30 +0100 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <002701ccfdb0$a6b67ab0$f4237010$@augustcellars.com> In-Reply-To: <002701ccfdb0$a6b67ab0$f4237010$@augustcellars.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 08:15:55 -0000 Jim Schaad wrote: > Would this also be a way to deal with restrictions on the size seen by the > server? I.e. you also need to make the server deal with smaller packets as > well. Yes. Servers already do this for EAP authentication. If they see a Framed-MTU, they ensure that the EAP packet will fit into that MTU. This gives a secondary result that the size of the RADIUS packet is limited. Alan DeKok. From alex@um.es Fri Mar 9 03:56:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9123B21F85F1; Fri, 9 Mar 2012 03:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SsgGk9MmKXwC; Fri, 9 Mar 2012 03:56:10 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 879F821F85E6; Fri, 9 Mar 2012 03:56:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 217D5535FE; Fri, 9 Mar 2012 12:56:09 +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 GcOWQNCxJLyW; Fri, 9 Mar 2012 12:56:08 +0100 (CET) Received: from [192.168.1.131] (238.226.14.37.dynamic.jazztel.es [37.14.226.238]) (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 6B184535E7; Fri, 9 Mar 2012 12:56:03 +0100 (CET) Message-ID: <4F59EFD1.8030400@um.es> Date: Fri, 09 Mar 2012 12:56:01 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <4F547319.5040001@um.es> <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> In-Reply-To: <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: radext@ietf.org, abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 11:56:11 -0000 El 09/03/12 05:55, Jim Schaad escribió: > >> -----Original Message----- >> From: Alejandro Perez Mendez [mailto:alex@um.es] >> Sent: Monday, March 05, 2012 12:03 AM >> To: Alan DeKok >> Cc: Jim Schaad; radext@ietf.org; abfab@ietf.org >> Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext- >> radius-fragmentation-01.txt >> >> >> >> El 04/03/12 08:10, Alan DeKok escribió: >>> Jim Schaad wrote: >>>> I have some comments on the draft. However first let me say that I know >> next to nothing about RADIX having only briefly read it a couple of times and >> having not yet worked with it to any extent. >>> Reviews are always welcome. >>> >>>> 1. I think a discussion is in order about the issues of packing a radius >> message full in the presence of proxy intermediaries which might need room >> for adding and removing routing materials. I don't know how many proxies >> are keep local state as oppose to just filling up the message with Proxy-State >> items and thus need space on the way back. Also a discussion of removal >> and re-insertion of the T flag might be needed if the proxy fully assembles >> the message and then relays it in pieces. >>> The simplest way to address that is to artificially lower the >>> RADIUS maximum packet size, as seen by the client. >> Additionally, regarding the T flag removal/re-insertion comment, proxies are >> not allowed to perform RADIUS fragmentation on forwarded packets. It is a >> process performed end-to-end the RADIUS client and server. >> > What happens for proxies that, for some reason - want to re-write the contents of packets. For ABFAB I am specifically thinking of changing or mapping attributes in SAML assertions. I don't think a RADIUS proxy should change anything at a SAML level, but I may be wrong. Specially, if the assertion is singed by the IdP, that would be impossible at it would invalidate the signature. Anyway, other alternatives to deliver large authorization data, like providing a URL where the RP can download the assertion later, have exactly the same issue: proxies cannot modify the contents of the assertion. Regards, Alejandro > >>>> 2. The Overview in section 2 does not discuss the fact that a new set of >> state items might also added to the message. This changes the limit of how >> many bytes can be placed into the fragmented packets. >>> Yes. >>> >>>> 3. nit - in para #3 of overview you use the word truncated and truncation. >> I think a better word set might be partitioned and partitioning. Also ensure >> that fragmentation is used strictly for the process in radius-extensions. I >> have not found any cases yet were it is not but will try and remember to >> look. >>>> 4. I am not sure if positioning of the more-data-pending packet is >> significant. The introduction says it comes last but nothing to that effect is >> said in section 3. >>>> 5. Section 6 implies that the order of items in a set of fragmented packets >> might need to be changed based on the ability of items to be in the packet. >> For example if the Access-Accept packet had been = Data1[M], >> Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the >> order would need to be changed in the original partitioning. This should be >> mentioned someplace other than just in the "examples" section. It implies >> that a general use piece of code to do this will need to have the table built in, >> and potentially extended as new items are added, rather than just being >> coded correctly in the specific packet type code. >>> Attribute ordering is explicitly *not* required in RADIUS. >>> >>>> 6. What if any indications does a server have that the client will be able to >> deal with the partitioned message other than it will either fail or get confused >> depending on what set of attributes are in the first packet and what it needs >> and feels it can ignore. >>> That's an open area for discussion. RADIUS doesn't have capability >>> negotiation, so it's hard to do. >>> >>> Alan DeKok. From ietf@augustcellars.com Fri Mar 9 09:26:51 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20421F867F for ; Fri, 9 Mar 2012 09:26:51 -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 r6WRVc-22e2u for ; Fri, 9 Mar 2012 09:26:50 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 590DE21E8059 for ; Fri, 9 Mar 2012 09:26:48 -0800 (PST) Received: from Tobias (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 ED03D2CA2F; Fri, 9 Mar 2012 09:26:47 -0800 (PST) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <4F547319.5040001@um.es> <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> <4F59EFD1.8030400@um.es> In-Reply-To: <4F59EFD1.8030400@um.es> Date: Fri, 9 Mar 2012 09:26:01 -0800 Message-ID: <006801ccfe19$b34ff120$19efd360$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFt1L0qLKvc32/xJBUkpNNaNsw/wgHbB2m1AfCQXZUCbseylgGK6EbSAbOf44oCLYfWaJbDVbMQ Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 17:26:51 -0000 > -----Original Message----- > From: Alejandro Perez Mendez [mailto:alex@um.es] > Sent: Friday, March 09, 2012 3:56 AM > To: Jim Schaad > Cc: 'Alan DeKok'; radext@ietf.org; abfab@ietf.org > Subject: Re: [abfab] FYI: New Version Notification for = draft-perez-radext- > radius-fragmentation-01.txt >=20 >=20 >=20 > El 09/03/12 05:55, Jim Schaad escribi : > > > >> -----Original Message----- > >> From: Alejandro Perez Mendez [mailto:alex@um.es] > >> Sent: Monday, March 05, 2012 12:03 AM > >> To: Alan DeKok > >> Cc: Jim Schaad; radext@ietf.org; abfab@ietf.org > >> Subject: Re: [abfab] FYI: New Version Notification for > >> draft-perez-radext- radius-fragmentation-01.txt > >> > >> > >> > >> El 04/03/12 08:10, Alan DeKok escribi : > >>> Jim Schaad wrote: > >>>> I have some comments on the draft. However first let me say that = I > >>>> know > >> next to nothing about RADIX having only briefly read it a couple of > >> times and having not yet worked with it to any extent. > >>> Reviews are always welcome. > >>> > >>>> 1. I think a discussion is in order about the issues of packing = a > >>>> radius > >> message full in the presence of proxy intermediaries which might = need > >> room for adding and removing routing materials. I don't know how > >> many proxies are keep local state as oppose to just filling up the > >> message with Proxy-State items and thus need space on the way back. > >> Also a discussion of removal and re-insertion of the T flag might = be > >> needed if the proxy fully assembles the message and then relays it = in > pieces. > >>> The simplest way to address that is to artificially lower the > >>> RADIUS maximum packet size, as seen by the client. > >> Additionally, regarding the T flag removal/re-insertion comment, > >> proxies are not allowed to perform RADIUS fragmentation on = forwarded > >> packets. It is a process performed end-to-end the RADIUS client and > server. > >> > > What happens for proxies that, for some reason - want to re-write = the > contents of packets. For ABFAB I am specifically thinking of changing = or > mapping attributes in SAML assertions. >=20 > I don't think a RADIUS proxy should change anything at a SAML level, = but I > may be wrong. Specially, if the assertion is singed by the IdP, that = would be > impossible at it would invalidate the signature. If you look at draft-ietf-abfab-aaa-saml - this is exactly the case that = is imagined. The attributes need to be re-written as they change = domains. The signature is assumed to be checked by the IdP system and = RADIUS is then responsible for keeping the integrity in transit. There = is no reason to suppose that the relying party is going to know who the = signer of the SAML statement would be and therefore would not be able to = establish the trust without the AAA infrastructure. Jim >=20 > Anyway, other alternatives to deliver large authorization data, like = providing > a URL where the RP can download the assertion later, have exactly the = same > issue: proxies cannot modify the contents of the assertion. >=20 > Regards, > Alejandro >=20 > > > >>>> 2. The Overview in section 2 does not discuss the fact that a = new set of > >> state items might also added to the message. This changes the = limit > >> of how many bytes can be placed into the fragmented packets. > >>> Yes. > >>> > >>>> 3. nit - in para #3 of overview you use the word truncated and > truncation. > >> I think a better word set might be partitioned and partitioning. > >> Also ensure that fragmentation is used strictly for the process in > >> radius-extensions. I have not found any cases yet were it is not = but > >> will try and remember to look. > >>>> 4. I am not sure if positioning of the more-data-pending packet = is > >> significant. The introduction says it comes last but nothing to = that > >> effect is said in section 3. > >>>> 5. Section 6 implies that the order of items in a set of = fragmented > packets > >> might need to be changed based on the ability of items to be in the > packet. > >> For example if the Access-Accept packet had been =3D Data1[M], > >> Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address = the > >> order would need to be changed in the original partitioning. This > >> should be mentioned someplace other than just in the "examples" > >> section. It implies that a general use piece of code to do this = will > >> need to have the table built in, and potentially extended as new > >> items are added, rather than just being coded correctly in the = specific > packet type code. > >>> Attribute ordering is explicitly *not* required in RADIUS. > >>> > >>>> 6. What if any indications does a server have that the client = will > >>>> be able to > >> deal with the partitioned message other than it will either fail or > >> get confused depending on what set of attributes are in the first > >> packet and what it needs and feels it can ignore. > >>> That's an open area for discussion. RADIUS doesn't have > >>> capability negotiation, so it's hard to do. > >>> > >>> Alan DeKok. From hartmans@painless-security.com Fri Mar 9 10:55:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C25721E8098 for ; Fri, 9 Mar 2012 10:55:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 8dF4leZn31am for ; Fri, 9 Mar 2012 10:55:29 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 17C4921E8095 for ; Fri, 9 Mar 2012 10:55:27 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B931820244 for ; Fri, 9 Mar 2012 13:55:05 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 8E5074768; Fri, 9 Mar 2012 13:55:25 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Fri, 09 Mar 2012 13:55: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: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 18:55:29 -0000 So, I'm looking at registration procedures for error codes for the GSSEAP registry. Our implementation uses a library called com_err to handle error codes for GSSEAP. This is commonly used in Kerberos implementations as well. It has the kind of undesirable side effect that it splits error codes into 255-entry tables. If you use that library you can easily get into a situation where you have difficulty dealing with errors greater than 255. Kerberos made things worse and actually got into a situation where two of the major implementations have trouble with errors greater than 127. I recommend we do not make that mistake. I was thinking of addressing com_err concerns in the following way: 1) Add a note that implementations need to be able to deal with the entire range of error codes. In practice all this means is that you should design your APIs for mapping from protocol errors to whatever errors your implementation uses so that they will work if you're trying to map say more than 255 errors that you might encounter. 2) Reserve the lower 127 values for standards action. 3) Say 128-255 specification required. 4) Reserve the rest of the range noting that future registration policies may permit assignment from the greater range. Thoughts? From nico@cryptonector.com Fri Mar 9 12:24:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E324C21F8647 for ; Fri, 9 Mar 2012 12:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.321 X-Spam-Level: X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[AWL=-1.203, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622] 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 i4rBqv1bBWzO for ; Fri, 9 Mar 2012 12:24:02 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 6E95621F849B for ; Fri, 9 Mar 2012 12:24:02 -0800 (PST) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id B03F643807C for ; Fri, 9 Mar 2012 12:24:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=JCW79u9pqjwFwAB284gL4 me4+giYcRvLnFXvXBKBoY3yn20cvvTxHCky5f4nZP9KGGqVemyUepdCg7p5OffG5 Af7Lz7ZjRYSaKqJZaj7lbHMUCwf4Dp+qXgD+4WK5cWcGLT+2dtpqAcjHVC4G126i TtBX065pSfM0rtkJKf/Dpg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=IZj0EIUnjv/MpeWdWcx1 0Qg/nfo=; b=E+3g8eSVD2RxCpT3N/0VBmD1EgpY8ARA80skK0Jzm38M8dZSD6m4 KKK+A9lH7Mp468U+psAhAoL2VHhXp15ZQwqcsFt6bqqEkrGnB7KNIzu3790JmHlt lZJvwFCFMmBPOEVEFsObAKn0BiTBhgza/SJ2yeqgNOGlIfUNquUnWNs= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id 89FAD438072 for ; Fri, 9 Mar 2012 12:24:01 -0800 (PST) Received: by dakl33 with SMTP id l33so1985688dak.31 for ; Fri, 09 Mar 2012 12:24:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.221.73 with SMTP id qc9mr6133571pbc.139.1331324641217; Fri, 09 Mar 2012 12:24:01 -0800 (PST) Received: by 10.68.28.6 with HTTP; Fri, 9 Mar 2012 12:24:01 -0800 (PST) In-Reply-To: References: Date: Fri, 9 Mar 2012 14:24:01 -0600 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 20:24:03 -0000 The idea of leaking implementation details into the registry and/or its registration rules makes me gag. From hartmans@painless-security.com Fri Mar 9 13:04:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A918521F84B6 for ; Fri, 9 Mar 2012 13:04:38 -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.034, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 wFhypL6tEUN9 for ; Fri, 9 Mar 2012 13:04:38 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 436C621F8483 for ; Fri, 9 Mar 2012 13:04:38 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E0A6720244; Fri, 9 Mar 2012 16:04:11 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 205D34768; Fri, 9 Mar 2012 16:04:32 -0500 (EST) From: Sam Hartman To: Nico Williams References: Date: Fri, 09 Mar 2012 16:04:32 -0500 In-Reply-To: (Nico Williams's message of "Fri, 9 Mar 2012 14:24:01 -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: abfab@ietf.org Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:04:38 -0000 >>>>> "Nico" == Nico Williams writes: Nico> The idea of leaking implementation details into the registry Nico> and/or its registration rules makes me gag. I hear your frustration because you'd like to keep a clean orderly registration. I feel happy about the registration I proposed because I think it avoids leaking com_err details. I chose to reserve codes above 255 because I'm concerned we may need/want an IETF review range or may decide that specification required is too loose for the future. My intent was to provide a registration process that was flexible while acknoowledging that we don't understand what policy we may want years from now. How do you feel about this registration process? --Sam From internet-drafts@ietf.org Fri Mar 9 13:17:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE5A21E8044; Fri, 9 Mar 2012 13:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.543 X-Spam-Level: X-Spam-Status: No, score=-102.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 k6iTSJQgLcs5; Fri, 9 Mar 2012 13:17:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B0921F85C9; Fri, 9 Mar 2012 13:17:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120309211723.14833.65453.idtracker@ietfa.amsl.com> Date: Fri, 09 Mar 2012 13:17:23 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-05.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:17:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Ac= cess Beyond web Working Group of the IETF. Title : A GSS-API Mechanism for the Extensible Authentication Pr= otocol Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-05.txt Pages : 39 Date : 2012-03-09 This document defines protocols, procedures, and conventions to be employed by peers implementing the Generic Security Service Application Program Interface (GSS-API) when using the EAP mechanism. Through the GS2 family of mechanisms, these protocols also define how Simple Authentication and Security Layer (SASL, RFC 4422) applications use the Extensible Authentication Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-05.txt From trac+abfab@trac.tools.ietf.org Fri Mar 9 13:23:18 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35EF021E8044 for ; Fri, 9 Mar 2012 13:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 NwWInlSZ90zl for ; Fri, 9 Mar 2012 13:23:17 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BB9BB21E8040 for ; Fri, 9 Mar 2012 13:23:17 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S67HM-0000Nn-6y; Fri, 09 Mar 2012 16:23:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartmans-ietf@mit.edu X-Trac-Project: abfab Date: Fri, 09 Mar 2012 21:23:12 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/31#comment:1 Message-ID: <076.78e68019057f32a0e4b18e91a9c56fb8@trac.tools.ietf.org> References: <061.0ded2f3783acc385a44c725f6c136b79@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 In-Reply-To: <061.0ded2f3783acc385a44c725f6c136b79@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: abfab@ietf.org Subject: Re: [abfab] #31: Error text is a placeholder X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:23:18 -0000 #31: Error text is a placeholder Changes (by hartmans-ietf@…): * status: new => closed * resolution: => fixed -- -----------------------------+--------------------- Reporter: hartmans-ietf@… | Owner: Type: defect | Status: closed Priority: major | Milestone: Component: gss-eap | Version: Severity: - | Resolution: fixed Keywords: | -----------------------------+--------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Fri Mar 9 13:47:27 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C793A21E80B2 for ; Fri, 9 Mar 2012 13:47:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSiO3ClXER-D for ; Fri, 9 Mar 2012 13:47:27 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A006221E809F for ; Fri, 9 Mar 2012 13:47:26 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S67Iv-0004ah-Fm; Fri, 09 Mar 2012 16:24:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hartmans-ietf@mit.edu X-Trac-Project: abfab Date: Fri, 09 Mar 2012 21:24:49 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://wiki.tools.ietf.org/wg/abfab/trac/ticket/32 Message-ID: <061.68e7f7707b99594dc7bd5e3b4f7c83f1@trac.tools.ietf.org> X-Trac-Ticket-ID: 32 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hartmans-ietf@mit.edu, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: abfab@ietf.org Subject: [abfab] #32: RADIUS AVP registrations are a placeholder X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Mar 2012 21:47:27 -0000 #32: RADIUS AVP registrations are a placeholder The RADIUS registrations need to be correctly handled. -- -----------------------------+----------------------------- Reporter: hartmans-ietf@… | Owner: hartmans-ietf@… Type: defect | Status: new Priority: major | Milestone: Component: gss-eap | Version: Severity: - | Keywords: -----------------------------+----------------------------- Ticket URL: abfab From leifj@sunet.se Fri Mar 9 22:42:42 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E6321F852C for ; Fri, 9 Mar 2012 22:42:42 -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 oVGEQniLltj3 for ; Fri, 9 Mar 2012 22:42:41 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id E583221F8517 for ; Fri, 9 Mar 2012 22:42:39 -0800 (PST) Received: from [10.130.0.167] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2A6gYvm011816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 10 Mar 2012 07:42:38 +0100 (CET) Message-ID: <4F5AF7DA.4090908@sunet.se> Date: Sat, 10 Mar 2012 07:42:34 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 06:42:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/09/2012 10:04 PM, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > Nico> The idea of leaking implementation details into the registry > Nico> and/or its registration rules makes me gag. > > I hear your frustration because you'd like to keep a clean orderly > registration. I feel happy about the registration I proposed > because I think it avoids leaking com_err details. > > I chose to reserve codes above 255 because I'm concerned we may > need/want an IETF review range or may decide that specification > required is too loose for the future. My intent was to provide a > registration process that was flexible while acknoowledging that > we don't understand what policy we may want years from now. > > How do you feel about this registration process? The only question I have is that since this is a pretty scarce resource we might want specification required + expert review and give the expert pool explicit review instructions that we are only looking for a "is not crazy"-check. I'm guessing that you don't want to introduce a high bar of entry so as to encourage innovation. If so, I concur but we might want to raise the bar just a little bit so that nobody eats up the 127 error codes with a cleverly crafted cronjob+xml2rfc. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9a99oACgkQ8Jx8FtbMZndzIACfenFIdNau69svFTjcKOEZLtwY VpQAn2pzgCcSeppMQwA1zh3XoSo+gB2v =Tdsz -----END PGP SIGNATURE----- From nico@cryptonector.com Fri Mar 9 23:15:37 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D727E21F84FA for ; Fri, 9 Mar 2012 23:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=-0.241, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qMStWNX3BKkc for ; Fri, 9 Mar 2012 23:15:37 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 57A5721F84F9 for ; Fri, 9 Mar 2012 23:15:37 -0800 (PST) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id E357726405D for ; Fri, 9 Mar 2012 23:15:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=WtLYpV221Lx06R7fIKAEOQKg+2SW7fIILFlQ0LmcOgvl 2gkQCdYPcjk4MB6j+2xOWwcwFWk3MX4tKFxxckraU+94cPxAWNkIjVZ2qEB/UU3e ZX4xdGT30hTHJvbtWqX0hIa2lTSeZlFNRSM6RYA2FI7Legqq5xMm/cYj4EgUGig= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=y6kVVt0vaVsEb9Ueh2iqljcjNnY=; b=SJVGsI3v7Bj cEdfBONZvBqzV26nkOZUpu0ieahkBT1asY2cAYICHhSBZrPSkRkJvO+F/AU9+XwF JXi2op8KNgwkUoZMdLDHEGOTl3Xul8ezzvk5ssAfdgHNNCc5ML4+1WaI0SbYYzzN jx49BNfoRsz5avjNP4dtAQpMrzoRZygo= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id C879C264058 for ; Fri, 9 Mar 2012 23:15:36 -0800 (PST) Received: by dakl33 with SMTP id l33so2596666dak.31 for ; Fri, 09 Mar 2012 23:15:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.129.129 with SMTP id nw1mr8588959pbb.13.1331363736360; Fri, 09 Mar 2012 23:15:36 -0800 (PST) Received: by 10.68.28.6 with HTTP; Fri, 9 Mar 2012 23:15:36 -0800 (PST) In-Reply-To: <4F5AF7DA.4090908@sunet.se> References: <4F5AF7DA.4090908@sunet.se> Date: Sat, 10 Mar 2012 01:15:36 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: abfab@ietf.org Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 07:15:38 -0000 On Sat, Mar 10, 2012 at 12:42 AM, Leif Johansson wrote: > On 03/09/2012 10:04 PM, Sam Hartman wrote: >>>>>>> "Nico" =3D=3D Nico Williams writes: >> >> Nico> The idea of leaking implementation details into the registry >> Nico> and/or its registration rules makes me gag. >> >> I hear your frustration because you'd like to keep a clean orderly >> registration. I feel happy about the registration =C2=A0I proposed >> because I think it avoids leaking =C2=A0com_err details. This is the problem I have with letting an implementation detail like this leak into the IANA process. I won't go along with expert review for error codes because of com_err. Nico -- From nico@cryptonector.com Sat Mar 10 00:44:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2743F21F85A4 for ; Sat, 10 Mar 2012 00:44:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.215 X-Spam-Level: X-Spam-Status: No, score=-2.215 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 wSMF3RGxqxFc for ; Sat, 10 Mar 2012 00:44:41 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id E27C121F85A3 for ; Sat, 10 Mar 2012 00:44:41 -0800 (PST) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 138C23B805C for ; Sat, 10 Mar 2012 00:44:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=bVC5uPPdD5eBeXP0B9eEn YVzTXWH2//dCgse7IiHxtM3K6NvNOmxIpFTIGktEYiGdxbLHi6JW0htW8bzJU97B ixO6wqKVc28ZsX0nsF4UHzmCkam9o+f9CyFaG9f+EANGHg3s8rOcw/26D5C6ppLm HaPBCy37haORUQ3hlzr4EM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=w2+CSF5/qw3Ms35MelZT XFHhdSk=; b=melC3MFzt0HTNC3PrRSew6t7XGMBm0oXBhDohFRJRktqpuXuz377 zK1web5ro8LztxVI/h+xdLpWko3Glv8qzwSh3W0lYd0tkauy/iKezg76o6ufbKwh zoZt+94l8enXp/7FD2NXuuvUUhqv+HNu0ar3fGDb56VPlsLriAZa2mw= Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 0277B3B805B for ; Sat, 10 Mar 2012 00:44:40 -0800 (PST) Received: by dakl33 with SMTP id l33so2683376dak.31 for ; Sat, 10 Mar 2012 00:44:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.129.129 with SMTP id nw1mr8848687pbb.13.1331369080640; Sat, 10 Mar 2012 00:44:40 -0800 (PST) Received: by 10.68.28.6 with HTTP; Sat, 10 Mar 2012 00:44:40 -0800 (PST) In-Reply-To: References: <4F5AF7DA.4090908@sunet.se> Date: Sat, 10 Mar 2012 02:44:40 -0600 Message-ID: From: Nico Williams To: Leif Johansson Content-Type: text/plain; charset=UTF-8 Cc: abfab@ietf.org Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 08:44:46 -0000 Actually, can you clarify something? Are we talkign about protocol errors or API (minor_status) errors? If the former, then sure, I think expert review is fine. If the latter then I don't. From leifj@sunet.se Sat Mar 10 01:05:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BD721F8678 for ; Sat, 10 Mar 2012 01:05:28 -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 jbkcJ2CS3jTr for ; Sat, 10 Mar 2012 01:05:28 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 062E721F8677 for ; Sat, 10 Mar 2012 01:05:27 -0800 (PST) Received: from [10.130.3.183] (4.234.241.83.in-addr.dgcsystems.net [83.241.234.4]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2A958ri012668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 10 Mar 2012 10:05:21 +0100 (CET) Message-ID: <4F5B1944.6090402@sunet.se> Date: Sat, 10 Mar 2012 10:05:08 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Nico Williams References: <4F5AF7DA.4090908@sunet.se> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 09:05:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/10/2012 09:44 AM, Nico Williams wrote: > Actually, can you clarify something? Are we talkign about > protocol errors or API (minor_status) errors? > > If the former, then sure, I think expert review is fine. If the > latter then I don't. I'd like to understand this: are you objecting because you think expert review would produce poor results or some other reason? Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9bGUQACgkQ8Jx8FtbMZneGogCfXxYAKl3/0zaq+OY0cKtDjKSw tdQAoI1g14qpnlBi1jnC3IwOUTLdVLjh =Bb7T -----END PGP SIGNATURE----- From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:21:24 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEBBB21F864A for ; Sat, 10 Mar 2012 02:21:24 -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 4-cRGfjVOSmT for ; Sat, 10 Mar 2012 02:21:24 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 8304C21F8627 for ; Sat, 10 Mar 2012 02:21:16 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6JPy-00026N-FJ; Sat, 10 Mar 2012 05:20:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:20:53 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/24#comment:1 Message-ID: <077.1a61226466e54c3cee308c0b41b5fe8d@trac.tools.ietf.org> References: <062.43fe269e2b549bf525737a130e8baf4c@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <062.43fe269e2b549bf525737a130e8baf4c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310102116.8304C21F8627@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:21:16 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #24: Section 2.3 - typeo X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:21:24 -0000 #24: Section 2.3 - typeo Changes (by hannes.tschofenig@…): * status: new => closed * resolution: => fixed Comment: Addressed in -01. -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:22:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C37121F864C for ; Sat, 10 Mar 2012 02:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WETBmOi3zs4G for ; Sat, 10 Mar 2012 02:22:22 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 3206E21F8601 for ; Sat, 10 Mar 2012 02:22:22 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6JRM-00044M-9s; Sat, 10 Mar 2012 05:22:20 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:22:20 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/22#comment:1 Message-ID: <077.6ed9f21bcee30fff8a81ddd8639ad692@trac.tools.ietf.org> References: <062.cb320f023c7eba19e248bf6039db1613@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 In-Reply-To: <062.cb320f023c7eba19e248bf6039db1613@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310102222.3206E21F8601@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:22:22 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #22: Section 2.1 -- typo X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:22:22 -0000 #22: Section 2.1 -- typo Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01 -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:26:24 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1281B21F85B5 for ; Sat, 10 Mar 2012 02:26:24 -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 gip7qUAjzDTS for ; Sat, 10 Mar 2012 02:26:23 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 283F921F8572 for ; Sat, 10 Mar 2012 02:26:22 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6JVC-0007Qp-Mm; Sat, 10 Mar 2012 05:26:18 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:26:18 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/20#comment:1 Message-ID: <077.4d6145df4d72f851d1aa1443c5aaaa81@trac.tools.ietf.org> References: <062.cfa02a9afc09132a4c9e05582acc5b72@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <062.cfa02a9afc09132a4c9e05582acc5b72@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310102623.283F921F8572@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:26:22 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #20: Section 1.4 - digaram correction X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:26:24 -0000 #20: Section 1.4 - digaram correction Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01 -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:27:18 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E98A521F85B5 for ; Sat, 10 Mar 2012 02:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zzmoFAi52fYm for ; Sat, 10 Mar 2012 02:27:18 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6FB7021F8572 for ; Sat, 10 Mar 2012 02:27:18 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6JW7-0002OM-81; Sat, 10 Mar 2012 05:27:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:27:15 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/14#comment:1 Message-ID: <077.46c114d7cda123ce53cff00a3f2473df@trac.tools.ietf.org> References: <062.50d8e84635cdbf8ba1e83740028d22f4@trac.tools.ietf.org> X-Trac-Ticket-ID: 14 In-Reply-To: <062.50d8e84635cdbf8ba1e83740028d22f4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310102718.6FB7021F8572@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:27:18 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #14: Section 1.2 -- spelling erro X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:27:19 -0000 #14: Section 1.2 -- spelling erro Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01 -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:28:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A5D21F846F for ; Sat, 10 Mar 2012 02:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa9+5csHeKmv for ; Sat, 10 Mar 2012 02:28:38 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id BF4BE21F843F for ; Sat, 10 Mar 2012 02:28:38 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6JXQ-0008Sd-6l; Sat, 10 Mar 2012 05:28:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:28:36 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/11#comment:1 Message-ID: <077.17f2bbed1aaba4cbfd5de60858a3ec13@trac.tools.ietf.org> References: <062.3d51fe0bb3fc047d6a8b3a0f65c89a5f@trac.tools.ietf.org> X-Trac-Ticket-ID: 11 In-Reply-To: <062.3d51fe0bb3fc047d6a8b3a0f65c89a5f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310102838.BF4BE21F843F@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:28:38 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #11: Section 1.1 - para 'Provisioning' spelling errors X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:28:39 -0000 #11: Section 1.1 - para 'Provisioning' spelling errors Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01 -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:33:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5809A21F865B for ; Sat, 10 Mar 2012 02:33:04 -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 oI8cY1T2I-qV for ; Sat, 10 Mar 2012 02:33:03 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id CD2E321F8650 for ; Sat, 10 Mar 2012 02:33:03 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Jbc-0006z6-LP; Sat, 10 Mar 2012 05:32:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:32:56 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/25#comment:1 Message-ID: <077.97901d95d0070b023139d3da9cbcbcac@trac.tools.ietf.org> References: <062.a452be6f2a3ca8d1b2eaa8a7e3088d4f@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 In-Reply-To: <062.a452be6f2a3ca8d1b2eaa8a7e3088d4f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310103303.CD2E321F8650@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:33:03 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #25: Section 2.4 - Section title is confusing X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:33:04 -0000 #25: Section 2.4 - Section title is confusing Comment (by hannes.tschofenig@…): I agree with the comment. The title and the content of the section is confusing. For version -01 I omit this section since I don't understand it either. I suggest to re-introduce this section once we know what to say. Who wrote this section? -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:35:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8775421F864B for ; Sat, 10 Mar 2012 02:35:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 694bxUfyG9Pn for ; Sat, 10 Mar 2012 02:35:21 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9969621F8633 for ; Sat, 10 Mar 2012 02:35:20 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Jds-0003rj-Tw; Sat, 10 Mar 2012 05:35:16 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:35:16 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/17#comment:1 Message-ID: <077.67139f6df509070beebb095314c79bd9@trac.tools.ietf.org> References: <062.27fbd4596011813885f23634b6db806a@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <062.27fbd4596011813885f23634b6db806a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310103520.9969621F8633@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:35:20 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #17: Section 1.3 - Clarifications X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:35:21 -0000 #17: Section 1.3 - Clarifications Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:37:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7858521F8668 for ; Sat, 10 Mar 2012 02:37:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBt-fN4InIX2 for ; Sat, 10 Mar 2012 02:37:12 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 058B321F8653 for ; Sat, 10 Mar 2012 02:37:12 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Jfh-0000ry-EL; Sat, 10 Mar 2012 05:37:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:37:09 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/16#comment:1 Message-ID: <077.8dc0f4a9d79cf0615c8a39b8fdc9480d@trac.tools.ietf.org> References: <062.d0e290ab8ab36ed3a610453de359878f@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <062.d0e290ab8ab36ed3a610453de359878f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310103712.058B321F8653@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:37:12 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #16: Section 1.3 - Clarifications and grammer X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:37:12 -0000 #16: Section 1.3 - Clarifications and grammer Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:38:34 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB0221F8661 for ; Sat, 10 Mar 2012 02:38:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6GP0sM74c6k for ; Sat, 10 Mar 2012 02:38:33 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B8E5D21F8653 for ; Sat, 10 Mar 2012 02:38:33 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Jh0-0003s7-N1; Sat, 10 Mar 2012 05:38:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:38:30 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/15#comment:1 Message-ID: <077.31bc4d633d6c4e200391f178ecfe184d@trac.tools.ietf.org> References: <062.1c585890bc404658a4dcf3794c9f428b@trac.tools.ietf.org> X-Trac-Ticket-ID: 15 In-Reply-To: <062.1c585890bc404658a4dcf3794c9f428b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310103833.B8E5D21F8653@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:38:33 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #15: Section 1.2 - Suggested new wording X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:38:34 -0000 #15: Section 1.2 - Suggested new wording Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:41:40 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9614321F8653 for ; Sat, 10 Mar 2012 02:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTZmRnu4pwk0 for ; Sat, 10 Mar 2012 02:41:40 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 235AC21F864C for ; Sat, 10 Mar 2012 02:41:40 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Jk0-0002Iw-9h; Sat, 10 Mar 2012 05:41:36 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:41:36 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/13#comment:1 Message-ID: <077.cb109e0d4eaeb7dff656ea7d131cc31d@trac.tools.ietf.org> References: <062.865878ccb5d78069c4e708463a02f431@trac.tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <062.865878ccb5d78069c4e708463a02f431@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310104140.235AC21F864C@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:41:40 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #13: Section 1.2 - language clarity X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:41:40 -0000 #13: Section 1.2 - language clarity Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 02:47:58 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABAE621F8607 for ; Sat, 10 Mar 2012 02:47:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TK1q41thvIIu for ; Sat, 10 Mar 2012 02:47:57 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DB06821F85B7 for ; Sat, 10 Mar 2012 02:47:55 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Jq0-0006Hm-MM; Sat, 10 Mar 2012 05:47:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 10:47:48 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/21#comment:1 Message-ID: <077.238ab4cb96fe4fcfba37a6327bf4485d@trac.tools.ietf.org> References: <062.8e8ef92949e597f22e96182810416b6c@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 In-Reply-To: <062.8e8ef92949e597f22e96182810416b6c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310104756.DB06821F85B7@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 02:47:55 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #21: Section 2 - clarification needed for 'end party' X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 10:47:58 -0000 #21: Section 2 - clarification needed for 'end party' Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: In this specific context we are talking about the client. I replaced end host with client in the text and modified Figure 1 to include the client next to the (data) subject. The data subject is a human and the client is the software that is used by the human. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 03:02:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448AC21F85BB for ; Sat, 10 Mar 2012 03:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYx9VmK3SHXP for ; Sat, 10 Mar 2012 03:02:03 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 987AA21F847E for ; Sat, 10 Mar 2012 03:02:03 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6K3g-0003lU-4o; Sat, 10 Mar 2012 06:01:56 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 11:01:56 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/8#comment:1 Message-ID: <077.3157ace78ea06ec2ca80c3b7a330b1b8@trac.tools.ietf.org> References: <062.8c6495cd1dde547981dfb2772cac7faa@trac.tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <062.8c6495cd1dde547981dfb2772cac7faa@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310110203.987AA21F847E@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 03:02:03 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #8: Issues about using a AA rather than an IdP at one end X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 11:02:04 -0000 #8: Issues about using a AA rather than an IdP at one end Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) Comment: The problem here is that we do not use good identity management terminology. Consequently, we have some problems as we have a certain understanding of what identity means and how the identity provider / attribute provider relates to all this. To make it worse there is also a relationship with the privacy terminology. I believe we will have to get together and talk about the basic terminology. We have put some new terms into the privacy terminology document, see https://github.com/hannestschofenig/tschofenig- ids/blob/master/privacy-terminology/draft-iab-privacy-terminology-01.txt. There are, unfortunately, still some loose ends. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 03:06:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BAC321F85B5 for ; Sat, 10 Mar 2012 03:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 BF8NeJT9nwJv for ; Sat, 10 Mar 2012 03:06:38 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id B549821F8585 for ; Sat, 10 Mar 2012 03:06:38 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6K8A-0004hS-Gg; Sat, 10 Mar 2012 06:06:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 11:06:34 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/4#comment:1 Message-ID: <077.71a9510a2f36f6c7e2c71c479499069a@trac.tools.ietf.org> References: <062.46ef602c330d7f6bf2ef0077b9408fdc@trac.tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <062.46ef602c330d7f6bf2ef0077b9408fdc@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310110638.B549821F8585@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 03:06:38 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #4: Section 1.4 - Step 7 - explain endpoints X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 11:06:39 -0000 #4: Section 1.4 - Step 7 - explain endpoints Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: The EAP exchange happens between the EAP peer and the EAP server. In our terminology this would be between the client and the IdP. At some point in time we, unfortunately, introduce the term "principal". We either have to define it or replace it with subject. In any case, I made changes to version -01 to address the raised concern. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 03:09:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3B3A21F8475 for ; Sat, 10 Mar 2012 03:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6HTEYUJgPHD for ; Sat, 10 Mar 2012 03:09:16 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id CCB5521F8559 for ; Sat, 10 Mar 2012 03:09:15 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6KAi-0004ii-0O; Sat, 10 Mar 2012 06:09:12 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 11:09:11 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/3#comment:1 Message-ID: <077.7edfaa169f36a02a123fa812befe63bf@trac.tools.ietf.org> References: <062.b8cd88f598aae5e077dbe8665d81b7a3@trac.tools.ietf.org> X-Trac-Ticket-ID: 3 In-Reply-To: <062.b8cd88f598aae5e077dbe8665d81b7a3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310110915.CCB5521F8559@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 03:09:15 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #3: Section 1.4 Step 5- GSS/EAP X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 11:09:16 -0000 #3: Section 1.4 Step 5- GSS/EAP Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: Fixed in version -01. The GSS payloads are indeed not encapsulated in the RADIUS messages from the RP to the IdP. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 03:17:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9564921F863E for ; Sat, 10 Mar 2012 03:17: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 Dzkt+8OGodBU for ; Sat, 10 Mar 2012 03:17:02 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 20EC621F8637 for ; Sat, 10 Mar 2012 03:17:01 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6KI9-00081G-V4; Sat, 10 Mar 2012 06:16:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 11:16:53 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/1#comment:1 Message-ID: <077.3c0eb45c33cc15e1230bded2d53511f7@trac.tools.ietf.org> References: <062.431a4b0baac443ac856e3b95893fa03c@trac.tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <062.431a4b0baac443ac856e3b95893fa03c@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310111702.20EC621F8637@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 03:17:01 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #1: NAI needs to be expanded at first instance of use X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 11:17:02 -0000 #1: NAI needs to be expanded at first instance of use Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: There are indeed various terms that need to be expanded the first they time are used. I added the NAI to the terminology section since this is an important concept for this document. I also expanded the terms in the introduction. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: minor | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 04:10:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DC421F8622 for ; Sat, 10 Mar 2012 04:10:04 -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 phJCyDsIayDg for ; Sat, 10 Mar 2012 04:10:04 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFC921F861C for ; Sat, 10 Mar 2012 04:10:04 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6L7Q-0000u7-9g; Sat, 10 Mar 2012 07:09:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 12:09:51 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/28#comment:1 Message-ID: <077.408c429cd9063a9fde57bb488fa0c967@trac.tools.ietf.org> References: <062.6d0caaa3bde28c503e5a4879aaaf29db@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <062.6d0caaa3bde28c503e5a4879aaaf29db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310121004.5BFC921F861C@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 04:10:04 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #28: Missing Security Consideration - AAA protection of the MSK X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 12:10:05 -0000 #28: Missing Security Consideration - AAA protection of the MSK Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: RADIUS and Diameter currently provide the same level of security when it comes to the protection of the protocol exchanges between neighboring RADIUS/Diameter nodes. There is no end-to-end security mechanism (i.e., RADIUS client <-> RADIUS server; Diameter client <-> Diameter server) standardized although there are discussions in the DIME working group to add functionality. An example contribution can be found with http://tools.ietf.org/html/draft-korhonen- dime-e2e-security-00 and with http://tools.ietf.org/html/draft-zorn-dime- n2n-sec-lite-02. I would suggest to raise the issue of MSK security in the security consideration section. I put a placeholder there. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 04:48:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D39BE21F8610 for ; Sat, 10 Mar 2012 04:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQS9AWPbekpW for ; Sat, 10 Mar 2012 04:48:12 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 85EE921F860E for ; Sat, 10 Mar 2012 04:47:50 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Li8-0006mm-Fh; Sat, 10 Mar 2012 07:47:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 12:47:48 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/29#comment:1 Message-ID: <077.0c01fb7dba6066ab34ab71d5a51d8795@trac.tools.ietf.org> References: <062.02e3ffc16252077000a0c1c061478ccd@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <062.02e3ffc16252077000a0c1c061478ccd@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: abfab@ietf.org Subject: Re: [abfab] #29: More explicity discussions of the communication channels with the end-points, cryptography and channel binding X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 12:48:12 -0000 #29: More explicity discussions of the communication channels with the end- points, cryptography and channel binding Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * owner: draft-ietf-abfab-arch@… => hannes.tschofenig@… Comment: I think that this comment can be addressed in the security consideration section. Here is a proposal what I plan to put into the -01 version of the draft: Security Considerations This document describes the architecture for Application Bridging for Federated Access Beyond Web (ABFAB) and security is therefore the main focus. This section highlights the main communication channels and their security properties: Client-to-RP Channel: This communication channel is secured by TLS executed between the client and the RP. The channel binding material is provided by any certificates and the final message (i.e., a cryptographic token for the channel). Authentication may be provided by the RP to the client but a deployment without authentication at the TLS layer is possible as well. In addition, there is a channel between the GSS requestor and the GSS acceptor, but the keying material is provided by a "third party" to both entities. The client can derive keying material locally, but the RP gets the material from the IdP. There is no cryptographic binding on this channel until the EAP processing has finished and the MSK is transferred from the IdP to the RP. RP-to-IdP Channel: The security of this communication channel is mainly provided by the functionality offered via RADIUS and Diameter. At the time of writing there are no end-to-end security mechanisms standardized and thereby the architecture has to rely on hop-by-hop security with trusted AAA entities or, as an alternative but possible deployment variant, direct communication between the AAA client to the AAA server. Note that the authorization result the IdP provides to the RP in the form of a SAML assertion may, however, be protected such that the SAML related components are secured end-to-end. Client-to-IdP Channel: This communication interaction is accomplished with the help of EAP and EAP methods. The offered security protection will depend on the EAP method that is chosen but a minimum requirement fis to offer mutual authentication, and key derivation. The IdP is responsible during this process to determine that the RP that is communication to the client over the RP-to-IdP channel is the same one talking to the IdP. This is accomplished via the EAP channel binding. -- --------------------+---------------------------------- Reporter: ietf@… | Owner: hannes.tschofenig@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | --------------------+---------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 05:04:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4E221F8596 for ; Sat, 10 Mar 2012 05:04:28 -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 GKFMGahXQA5W for ; Sat, 10 Mar 2012 05:04:28 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id EC28721F855D for ; Sat, 10 Mar 2012 05:04:27 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6Ly7-0004Ih-HB; Sat, 10 Mar 2012 08:04:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 13:04:19 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/27#comment:1 Message-ID: <077.265dc31dc215cc75b23b7676110c44f9@trac.tools.ietf.org> References: <062.66220d434bcbf9a46583666c519b6576@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <062.66220d434bcbf9a46583666c519b6576@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310130427.EC28721F855D@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 05:04:27 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #27: Setion 3.1 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:04:28 -0000 #27: Setion 3.1 Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) Comment: I changed the title of the section but I am currently not able to address your second comment regarding the correctness and completely of bullet 1 and 2 of the following text: " RFC 2743 does not explicitly talk about what mutual authentication means. Within the GSS-API community successful mutual authentication has come to mean: o If a target name is supplied by the initiator, then the initiator trusts that the supplied target name describes the acceptor. This implies both that appropriate cryptographic exchanges took place for the initiator to make such a trust decision, and that after evaluating the results of these exchanges, the initiator's policy trusts that the target name is accurate. o The initiator trusts that its idea of the acceptor name correctly names the entity it is communicating with. o Both the initiator and acceptor have the same key material for per-message keys and both parties have confirmed they actually have the key material. In EAP terms, there is a protected indication of success. " A problem with the text above is that it uses the fuzzy term "trust". I would at least expect to have an indication " trusts to do ". I prefer to have the issue assigned to someone who is very familiar with the GSS-API and to re-work the text. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 05:23:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5351521F860F for ; Sat, 10 Mar 2012 05:23:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dbO++epAmkjG for ; Sat, 10 Mar 2012 05:23:11 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AF53A21F855D for ; Sat, 10 Mar 2012 05:23:11 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6MG7-0001ty-8b; Sat, 10 Mar 2012 08:22:55 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 13:22:54 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/26#comment:1 Message-ID: <077.8e8bb7cd506959e21cdd74796decd7b8@trac.tools.ietf.org> References: <062.86c3874cfd3d79c73e5f5811bb37ce1a@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 In-Reply-To: <062.86c3874cfd3d79c73e5f5811bb37ce1a@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310132311.AF53A21F855D@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 05:23:11 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #26: Section 2.5 - Setion contains a picture but no discriptive text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:23:12 -0000 #26: Section 2.5 - Setion contains a picture but no discriptive text Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: You are unfortunately right that Figure 2 is loosely hanging around. For some reason the various draft versions have not been aligned with the figure. To address your comment I have moved Figure 2 to Section 2. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 05:28:42 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1AC21F852A for ; Sat, 10 Mar 2012 05:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUEWI0Yp0v-N for ; Sat, 10 Mar 2012 05:28:41 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 91D1921F84AF for ; Sat, 10 Mar 2012 05:28:41 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6MLb-0003y4-58; Sat, 10 Mar 2012 08:28:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 13:28:35 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/23#comment:1 Message-ID: <077.782f30d2d7044cadd5fa58999ae60c8b@trac.tools.ietf.org> References: <062.f26fe2a37815bb2e2190faaf5be74b08@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 In-Reply-To: <062.f26fe2a37815bb2e2190faaf5be74b08@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310132841.91D1921F84AF@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 05:28:41 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #23: Section 2.1.1 - Clarifications and typos X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:28:42 -0000 #23: Section 2.1.1 - Clarifications and typos Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) Comment: Sam responded: Begin forwarded message: From: Sam Hartman Date: December 19, 2011 7:08:07 PM GMT+02:00 To: "Jim Schaad" Cc: abfab@ietf.org Subject: Re: [abfab] Issue 23 - Clarifications and typos "Jim" == Jim Schaad writes: Jim> I have to admit this is interesting is that the trust router Jim> would provide the ability for an RP to do this. I had managed Jim> to insert a different entity into the picture and wonder if I Jim> am wrong or of the document is just written odd. Jim> I have an RP code that is written on top of GSS-API. At this Jim> point I need to be able to do a couple of different things. Jim> 1. Is the RP that is my service provider going to talk Jim> directly to the AAA proxy that is hosted with the IdP, or is it Jim> going to go through some local AAA proxy at my side of the Jim> conversation. In our deployment we're assuming that this is a local proxy. Jim> 2. Since as an RP I am doing all of my talking to the AAA side Jim> of the world via GSS-API, I assume that we need to have some Jim> set of items for controlling how the routing is going to be Jim> done in the GSS-API interface. We currently have a way of Jim> getting answers from IdP such as the SAML returned (either in Jim> its entirety or in parts.) And I assume we are going to have Jim> some way of setting the SAML request. However, is the GSS-API Jim> or the RP code itself going to deal with the routing issues? I'm not aware of any proposals for controlling the routing through GSS. I'm not aware of any proposals other than trust router for standardizing controlling the routing. Today that's done through proxy or RP-side config files. Nico responded: Begin forwarded message: From: Nico Williams Date: December 19, 2011 12:01:08 AM GMT+02:00 To: Jim Schaad Cc: abfab@ietf.org Subject: Re: [abfab] Issue 23 - Clarifications and typos On Sat, Dec 17, 2011 at 9:59 PM, Jim Schaad wrote: I have an RP code that is written on top of GSS-API. At this point I need to be able to do a couple of different things. 1. Is the RP that is my service provider going to talk directly to the AAA proxy that is hosted with the IdP, or is it going to go through some local AAA proxy at my side of the conversation. A local proxy. 2. Since as an RP I am doing all of my talking to the AAA side of the world via GSS-API, I assume that we need to have some set of items for controlling how the routing is going to be done in the GSS-API interface. Well, the RP application is just calling GSS_Accept_sec_context(). The mechanism invoked by GSS_Accept_sec_context() (GSS-EAP) will do all the work of talking AAA under the covers, invisibly to the application. More likely than not the application only really needs to indicate to the GSS-API that for any particular instance of the application it wants to use one or another configuration/profile. In practice there will often be a single configuration/profile anyways, so that nothing is needed here. If the application really does need direct, fine-grained control how trust routing is done we'd likely end up using a GSS extension such as naming extensions (applied to the acceptor NAME object), credential options (applied to the acceptor's CREDENTIAL HANDLE), or security context options. We currently have a way of getting answers from IdP such as the SAML returned (either in its entirety or in parts.) And I assume we are going to have some way of setting the SAML request. However, is the GSS-API or the RP code itself going to deal with the routing issues? For the sake of simplicity the GSS mechanism should deal with trust routing. The application should limit itself to inspecting the initiator (client) name returned by the GSS-API, or perhaps the application should ask for specific kinds of attributes that it wants to see, or perhaps it should simply select a profile that tells the mechanism the application's requirements. Nico Jim responded: From: "Jim Schaad" Date: December 18, 2011 5:59:11 AM GMT+02:00 To: Subject: Re: [abfab] Issue 23 - Clarifications and typos I have to admit this is interesting is that the trust router would provide the ability for an RP to do this. I had managed to insert a different entity into the picture and wonder if I am wrong or of the document is just written odd. I have an RP code that is written on top of GSS-API. At this point I need to be able to do a couple of different things. 1. Is the RP that is my service provider going to talk directly to the AAA proxy that is hosted with the IdP, or is it going to go through some local AAA proxy at my side of the conversation. 2. Since as an RP I am doing all of my talking to the AAA side of the world via GSS-API, I assume that we need to have some set of items for controlling how the routing is going to be done in the GSS-API interface. We currently have a way of getting answers from IdP such as the SAML returned (either in its entirety or in parts.) And I assume we are going to have some way of setting the SAML request. However, is the GSS-API or the RP code itself going to deal with the routing issues? Jim ---- Hannes posted to the list: Hi Jim, In issue #23 http://trac.tools.ietf.org/wg/abfab/trac/ticket/23 you write: “ 1. The rules determinaion in pagraph #2 might want to refer to levels of assurence which is one of th4e ways in figuring out some of these issues. Note that this may need to change how the realm of the NAI is going to be determined if you are looking ath the routing issues in paragraph #1 2. Paragraph #3 is ambigious in at least one respect. I am not clear if the question is one of the RP relying on the IdP in roder to get a decision, or if the text is saying if the IdP is going to agree to talk to the RP. This should be clarified. I believe that both sides of this question need to be covered - but in separate locations. “ The current version of the document uses the term “Rules determination†as a way to indicate that the RP has to make a decision of where to route the AAA mechanism. This term is confusing. I agree with you that the writeup is a bit short with regard to what are the decision criteria. In fact, there is a separate document (which is not yet a working group item) that discusses these aspects in much more detail, see http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02 I suggest to reference that document. I agree that the LoA may have an impact on the routing, particularly when it comes to the broader question of assessing the operational security of some of the providers. Here is paragraph #3: Rules determination covers a broad range of decisions about the exchange. One of these is whether the given RP is permitted to talk to the IDP using a given federation at all, so rules determination encompasses the basic authorization decision. Other factors are included, such as what policies govern release of information about the principal to the RP and what policies govern the RP's use of this information. While rules determination is ultimately a business function, it has significant impact on the technical exchanges. The protocols need to communicate the result of authorization. When multiple sets of rules are possible, the protocol must disambiguate which set of rules are in play. Some rules have technical enforcement mechanisms; for example in some federations intermediates validate information that is being communicated within the federation. I agree with you that the writeup is confusing. I believe it needs to take some of the work we did afterwards, such as with the document I mentioned above, into consideration. Ciao Hannes -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: new Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 05:30:36 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5299021F860B for ; Sat, 10 Mar 2012 05:30:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 Cyi6-NgLYX6m for ; Sat, 10 Mar 2012 05:30:35 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id C2E1321F8621 for ; Sat, 10 Mar 2012 05:30:35 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6MNV-0001Lf-MD; Sat, 10 Mar 2012 08:30:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 13:30:33 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/18#comment:1 Message-ID: <077.29f221603f96512a65d2dc2df3147a07@trac.tools.ietf.org> References: <062.e99dde29b852641f69ab022d6955f026@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <062.e99dde29b852641f69ab022d6955f026@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310133035.C2E1321F8621@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 05:30:35 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #18: Section 1.3 - Missing issue? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:30:36 -0000 #18: Section 1.3 - Missing issue? Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => wontfix Comment: -- I had responded to Jim about this issue in an earlier mail. I believe it is closed but I would like to hear what others have to say. Hi Jim, in issue #18 http://trac.tools.ietf.org/wg/abfab/trac/ticket/18 you wrote: " Should the following issue be addressed as well? In the presence of multiple federations, the naming of individuals can become murky especially if one is trying to associate a single individual from different federations. Asking a question such as does John Doe belong to an IdP (in the absence of authentication) may get an answer for the wrong John Doe. " In the way we define the architecture this is actually not an issue. All entities are uniquely identified using a NAI and there is no mechanism to query IdPs in the style of "Do you happen to know John Doe?" What is an issue, which is outside the scope of our IETF work - I believe, is the ability to associate user accounts from different IdPs/federations. For example, I know known by one IdP as hannes.tschofenig and another one as user12345 and maybe these two have to be linked together. I would say that we don't worry about these issues since I don't see the implications for our protocol work. I do, however, know that SAML tried to solve some of these account linking use cases and others may have more insight into how useful they had been. Ciao Hannes -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: wontfix Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From trac+abfab@trac.tools.ietf.org Sat Mar 10 05:37:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6155321F8601 for ; Sat, 10 Mar 2012 05:37:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.586 X-Spam-Level: X-Spam-Status: No, score=-102.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 KMssiXh1MMPJ for ; Sat, 10 Mar 2012 05:37:30 -0800 (PST) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DB5C421F85EF for ; Sat, 10 Mar 2012 05:37:30 -0800 (PST) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S6MUA-0006jY-Oy; Sat, 10 Mar 2012 08:37:26 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net X-Trac-Project: abfab Date: Sat, 10 Mar 2012 13:37:26 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/12#comment:1 Message-ID: <077.f5691950313229a866060e63ff7d0f93@trac.tools.ietf.org> References: <062.5422dec07d3b886db616f56b37f560ee@trac.tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <062.5422dec07d3b886db616f56b37f560ee@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120310133730.DB5C421F85EF@ietfa.amsl.com> Resent-Date: Sat, 10 Mar 2012 05:37:30 -0800 (PST) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #12: Section 1.1. - AAA vs RADIUS vs DIAMETER terms X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:37:31 -0000 #12: Section 1.1. - AAA vs RADIUS vs DIAMETER terms Changes (by hannes.tschofenig@…): * cc: hannes.tschofenig@… (added) * status: new => closed * resolution: => fixed Comment: I fixed the editorial issue with version -01 -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: closed Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: fixed Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From internet-drafts@ietf.org Sat Mar 10 05:49:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6959B21F85A3; Sat, 10 Mar 2012 05:49:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COWww+A+MkMC; Sat, 10 Mar 2012 05:49:53 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A6421F858D; Sat, 10 Mar 2012 05:49:53 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120310134952.3882.72741.idtracker@ietfa.amsl.com> Date: Sat, 10 Mar 2012 05:49:52 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-arch-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:49:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Ac= cess Beyond web Working Group of the IETF. Title : Application Bridging for Federated Access Beyond Web (AB= FAB) Architecture Author(s) : Josh Howlett Sam Hartman Hannes Tschofenig Eliot Lear Filename : draft-ietf-abfab-arch-01.txt Pages : 37 Date : 2012-03-10 Over the last decade a substantial amount of work has occurred in the space of federated access management. Most of this effort has focused on two use-cases: network and web-based access. However, the solutions to these use-cases that have been proposed and deployed tend to have few common building blocks in common. This memo describes an architecture that makes use of extensions to the commonly used security mechanisms for both federated and non- federated access management, including the Remote Authentication Dial In User Service (RADIUS) and the Diameter protocol, the Generic Security Service (GSS), the GS2 family, the Extensible Authentication Protocol (EAP) and the Security Assertion Markup Language (SAML). The architecture addresses the problem of federated access management to primarily non-web-based services, in a manner that will scale to large numbers of identity providers, relying parties, and federations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-arch-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-arch-01.txt From Hannes.Tschofenig@gmx.net Sat Mar 10 05:54:33 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4387F21F8610 for ; Sat, 10 Mar 2012 05:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, 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 g-eUjcXnqjAK for ; Sat, 10 Mar 2012 05:54:32 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5432721F851C for ; Sat, 10 Mar 2012 05:54:32 -0800 (PST) Received: (qmail invoked by alias); 10 Mar 2012 13:54:30 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.107]) [88.115.216.191] by mail.gmx.net (mp069) with SMTP; 10 Mar 2012 14:54:30 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+3AnlUbSC3TgoYB4E9H7zN/8sxJJJ1cLNnf4KEaf aX4hZ8wEjK/iTB From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 10 Mar 2012 15:54:29 +0200 Message-Id: To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [abfab] draft-ietf-abfab-arch-01 posted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 13:54:33 -0000 Hi all,=20 as you have seen from the issue tracker generated messages I have been = trying to close a few of the open issues.=20 Here is the draft:=20 http://tools.ietf.org/html/draft-ietf-abfab-arch-01 There are, unfortunately, still more issues left. We may want to pick a = few of them for discussion at the upcoming IETF meeting.=20 Additional reviews with a focus on consistency and readability are = highly appreciated.=20 Ciao Hannes From hartmans@painless-security.com Sat Mar 10 07:05:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A92D21F85DA for ; Sat, 10 Mar 2012 07:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=-0.032, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 EfW4tcadt03H for ; Sat, 10 Mar 2012 07:05:15 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2410021F85B6 for ; Sat, 10 Mar 2012 07:05:15 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 05AE020424; Sat, 10 Mar 2012 10:04:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9D5934766; Sat, 10 Mar 2012 10:05:10 -0500 (EST) From: Sam Hartman To: Nico Williams References: <4F5AF7DA.4090908@sunet.se> Date: Sat, 10 Mar 2012 10:05:10 -0500 In-Reply-To: (Nico Williams's message of "Sat, 10 Mar 2012 02:44:40 -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: abfab@ietf.org Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 15:05:15 -0000 >>>>> "Nico" == Nico Williams writes: Nico> Actually, can you clarify something? Are we talkign about Nico> protocol errors or API (minor_status) errors? Protocol errors over the wire. From hartmans@painless-security.com Sat Mar 10 07:10:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602C221F8596 for ; Sat, 10 Mar 2012 07:10:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ZePR3+JpS8us for ; Sat, 10 Mar 2012 07:10:01 -0800 (PST) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F26F621F8572 for ; Sat, 10 Mar 2012 07:10:00 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 1C2C920384; Sat, 10 Mar 2012 10:09:38 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 726134766; Sat, 10 Mar 2012 10:09:57 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <4F5AF7DA.4090908@sunet.se> Date: Sat, 10 Mar 2012 10:09:57 -0500 In-Reply-To: <4F5AF7DA.4090908@sunet.se> (Leif Johansson's message of "Sat, 10 Mar 2012 07:42:34 +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: abfab@ietf.org Subject: Re: [abfab] com_err and error codes X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 15:10:01 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> The only question I have is that since this is a pretty scarce Leif> resource we might want specification required + expert review Leif> and give the expert pool explicit review instructions that we Leif> are only looking for a "is not crazy"-check. I don't think it is particularly scarce actually. By requiring implementations to deal with error codes greater than 255, here's what I'd do if I were using com_err: 1) have all mapping from protocol error to com_err code in one function 2) have the inverse in another function 3) Until we use up the first 3255 you can just add or subtract the error table base. 4) If we get beyond tht then have a set of bases based on what IANA has currently assigned. So, I don't think it is particularly scarce and thus I think specification required is good enough. However I'd be equally happy with expert review. From alex@um.es Sat Mar 10 10:25:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AE321F856C for ; Sat, 10 Mar 2012 10:25:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yuoLVKaG6MWy for ; Sat, 10 Mar 2012 10:25:40 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3469921F8549 for ; Sat, 10 Mar 2012 10:25:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id E1C445360E; Sat, 10 Mar 2012 19:25:38 +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 lFMMv-QcoSXb; Sat, 10 Mar 2012 19:25:38 +0100 (CET) Received: from [192.168.1.131] (64.227.14.37.dynamic.jazztel.es [37.14.227.64]) (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 ACD44535DE; Sat, 10 Mar 2012 19:25:35 +0100 (CET) Message-ID: <4F5B9C9E.8070109@um.es> Date: Sat, 10 Mar 2012 19:25:34 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Schaad References: <20120229104634.26066.95888.idtracker@ietfa.amsl.com> <4F4E03E3.8070006@um.es> <010601ccf987$409e0220$c1da0660$@augustcellars.com> <4F53154C.9060604@deployingradius.com> <4F547319.5040001@um.es> <002801ccfdb0$dc0d6ac0$94284040$@augustcellars.com> <4F59EFD1.8030400@um.es> <006801ccfe19$b34ff120$19efd360$@augustcellars.com> In-Reply-To: <006801ccfe19$b34ff120$19efd360$@augustcellars.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 18:25:41 -0000 > If you look at draft-ietf-abfab-aaa-saml - this is exactly the case that is imagined. The attributes need to be re-written as they change domains. I don't see any part of the draft where it is stated the attributes *need* to be re-written. Indeed, it says nothing about proxies (or I couldn't find it). Nevertheless, some parts of draft-ietf-abfab-aaa-saml need to be modified as the fragmentation draft moves forward. > The signature is assumed to be checked by the IdP system and RADIUS is then responsible for keeping the integrity in transit. There is no reason to suppose that the relying party is going to know who the signer of the SAML statement would be and therefore would not be able to establish the trust without the AAA infrastructure. Although as you say, trust can be leveraged on the AAA infrastructure, and the use of signatures can be avoided (using a single trust model), IMO nothing should preclude using them if desired by the parties. If intermediate proxies modify assertions, this would be impossible. Regards, Alejandro > > Jim > >> Anyway, other alternatives to deliver large authorization data, like providing >> a URL where the RP can download the assertion later, have exactly the same >> issue: proxies cannot modify the contents of the assertion. >> >> Regards, >> Alejandro >> >>>>>> 2. The Overview in section 2 does not discuss the fact that a new set of >>>> state items might also added to the message. This changes the limit >>>> of how many bytes can be placed into the fragmented packets. >>>>> Yes. >>>>> >>>>>> 3. nit - in para #3 of overview you use the word truncated and >> truncation. >>>> I think a better word set might be partitioned and partitioning. >>>> Also ensure that fragmentation is used strictly for the process in >>>> radius-extensions. I have not found any cases yet were it is not but >>>> will try and remember to look. >>>>>> 4. I am not sure if positioning of the more-data-pending packet is >>>> significant. The introduction says it comes last but nothing to that >>>> effect is said in section 3. >>>>>> 5. Section 6 implies that the order of items in a set of fragmented >> packets >>>> might need to be changed based on the ability of items to be in the >> packet. >>>> For example if the Access-Accept packet had been = Data1[M], >>>> Data2[M]...Data 10, User-Name, Service-Type[X], Framed-IP-Address the >>>> order would need to be changed in the original partitioning. This >>>> should be mentioned someplace other than just in the "examples" >>>> section. It implies that a general use piece of code to do this will >>>> need to have the table built in, and potentially extended as new >>>> items are added, rather than just being coded correctly in the specific >> packet type code. >>>>> Attribute ordering is explicitly *not* required in RADIUS. >>>>> >>>>>> 6. What if any indications does a server have that the client will >>>>>> be able to >>>> deal with the partitioned message other than it will either fail or >>>> get confused depending on what set of attributes are in the first >>>> packet and what it needs and feels it can ignore. >>>>> That's an open area for discussion. RADIUS doesn't have >>>>> capability negotiation, so it's hard to do. >>>>> >>>>> Alan DeKok. From Josh.Howlett@ja.net Sat Mar 10 11:55:11 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D8321F8531 for ; Sat, 10 Mar 2012 11:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.111 X-Spam-Level: X-Spam-Status: No, score=-102.111 tagged_above=-999 required=5 tests=[AWL=0.488, 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 58dvO+n1j0WL for ; Sat, 10 Mar 2012 11:55:10 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id EC7EA21F84C2 for ; Sat, 10 Mar 2012 11:55:09 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 305141A9BD36_F5BB19CB; Sat, 10 Mar 2012 19:55:08 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw001.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id BEC381A9BD0F_F5BB19BF; Sat, 10 Mar 2012 19:55:07 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Sat, 10 Mar 2012 19:55:00 +0000 From: Josh Howlett To: Alejandro Perez Mendez , Jim Schaad Thread-Topic: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt Thread-Index: AQHM/vet7bwnAWX0d0W3sGoCGcs7SA== Date: Sat, 10 Mar 2012 19:55:00 +0000 Message-ID: In-Reply-To: <4F5B9C9E.8070109@um.es> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E0276842350D346920BF20646EC0C6B@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Mar 2012 19:55:11 -0000 On 10/03/2012 18:25, "Alejandro Perez Mendez" wrote: >> If you look at draft-ietf-abfab-aaa-saml - this is exactly the case >>that is imagined. The attributes need to be re-written as they change >>domains. > >I don't see any part of the draft where it is stated the attributes >*need* to be re-written. Yes, the draft is silent in this respect. This is a deployment question. >Indeed, it says nothing about proxies (or I >couldn't find it). It doesn't (nor should it). > Nevertheless, some parts of draft-ietf-abfab-aaa-saml >need to be modified as the fragmentation draft moves forward. I'll be doing that on Monday :-/ Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From hartmans@painless-security.com Sun Mar 11 11:50:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3829B21F864F for ; Sun, 11 Mar 2012 11:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.295 X-Spam-Level: X-Spam-Status: No, score=-2.295 tagged_above=-999 required=5 tests=[AWL=-0.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 3QNGxmIpgiiO for ; Sun, 11 Mar 2012 11:50:37 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5926B21F8644 for ; Sun, 11 Mar 2012 11:50:37 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5274A2023F; Sun, 11 Mar 2012 14:50:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C687A4766; Sun, 11 Mar 2012 14:50:24 -0400 (EDT) From: Sam Hartman To: Josh Howlett References: Date: Sun, 11 Mar 2012 14:50:24 -0400 In-Reply-To: (Josh Howlett's message of "Sat, 10 Mar 2012 19:55:00 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 18:50:38 -0000 I do think we want to deal with a case where it's a proxy rather than the home AAA server adding an assertion. The case of a proxy modifying an assertion can be simplified to a proxy choosing to read an assertion and then isse a new assertion based in input from the data. From alex@um.es Sun Mar 11 13:16:57 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A367021F86D0 for ; Sun, 11 Mar 2012 13:16:57 -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 9Muen79VcJt4 for ; Sun, 11 Mar 2012 13:16:56 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id A831D21F86C6 for ; Sun, 11 Mar 2012 13:16:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 04D4653610; Sun, 11 Mar 2012 21:16:55 +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 mM9vWWoSZW43; Sun, 11 Mar 2012 21:16:54 +0100 (CET) Received: from [192.168.1.131] (64.227.14.37.dynamic.jazztel.es [37.14.227.64]) (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 F1474535C1; Sun, 11 Mar 2012 21:16:53 +0100 (CET) Message-ID: <4F5D0834.2050501@um.es> Date: Sun, 11 Mar 2012 21:16:52 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 20:16:57 -0000 > I do think we want to deal with a case where it's a proxy rather than > the home AAA server adding an assertion. Assuming the original packet has not fragmentation, I think this case is straightforward. > The case of a proxy modifying an assertion can be simplified to a proxy > choosing to read an assertion and then isse a new assertion based in > input from the data. The problem with this case is that the intermediate proxy will need to perform a conversation with the RADIUS client (i.e. sending Acess-Challenge packets) to obtain all the fragments of the packet. Then, the proxy have to reconstruct the assertion, modify it and then start a new conversation with the RADIUS server sending the new fragments. I think it is possible, but that may be a lot of state to hold for a proxy. Anyway, what's the idea behind having a proxy modifying an assertion? Wouldn't be the assertion losing its meaning as the originator of the assertion (i.e. the IdP) has no control over the asserted information along the path? IMO, one thing is assuming integrity is assured by the trust on the AAA infrastructure and thus, digital signature is not required, and another is abusing of that fact by introducing intermediary elements that can modify the asserted data out of the control of the IdP. Regards, Alejandro From hartmans@painless-security.com Sun Mar 11 13:55:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473C621F85C2 for ; Sun, 11 Mar 2012 13:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 eotdQg4h47z8 for ; Sun, 11 Mar 2012 13:55:28 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 6A41121F85AA for ; Sun, 11 Mar 2012 13:55:28 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 111B420384; Sun, 11 Mar 2012 16:55:02 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0C5944766; Sun, 11 Mar 2012 16:55:20 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <4F5D0834.2050501@um.es> Date: Sun, 11 Mar 2012 16:55:20 -0400 In-Reply-To: <4F5D0834.2050501@um.es> (Alejandro Perez Mendez's message of "Sun, 11 Mar 2012 21:16:52 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 20:55:29 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: Alejandro> The problem with this case is that the intermediate proxy Alejandro> will need to perform a conversation with the RADIUS Alejandro> client (i.e. sending Acess-Challenge packets) to obtain Alejandro> all the fragments of the packet. Then, the proxy have to Alejandro> reconstruct the assertion, modify it and then start a new Alejandro> conversation with the RADIUS server sending the new Alejandro> fragments. Alejandro> I think it is possible, but that may be a lot of state to Alejandro> hold for a proxy. I'm confused because I thought the proxy would end up having to first have a conversation with the RADIUS server. Do you have server and client reversed? If not, would you help me better understand what's going on? Is the proxy's state required any more than the state a server needs to retain for its outstanding fragmented requests? --Sam From alex@um.es Sun Mar 11 16:10:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F87621F86E4 for ; Sun, 11 Mar 2012 16:10:53 -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 mfEWTDAJgGHS for ; Sun, 11 Mar 2012 16:10:47 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC8021F8476 for ; Sun, 11 Mar 2012 16:10:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id D913353610; Mon, 12 Mar 2012 00:10:46 +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 rPc85sqR+-ct; Mon, 12 Mar 2012 00:10:46 +0100 (CET) Received: from [192.168.1.131] (64.227.14.37.dynamic.jazztel.es [37.14.227.64]) (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 D01D753616; Mon, 12 Mar 2012 00:10:43 +0100 (CET) Message-ID: <4F5D30F1.4040808@um.es> Date: Mon, 12 Mar 2012 00:10:41 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: <4F5D0834.2050501@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Mar 2012 23:10:53 -0000 >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > Alejandro> The problem with this case is that the intermediate proxy > Alejandro> will need to perform a conversation with the RADIUS > Alejandro> client (i.e. sending Acess-Challenge packets) to obtain > Alejandro> all the fragments of the packet. Then, the proxy have to > Alejandro> reconstruct the assertion, modify it and then start a new > Alejandro> conversation with the RADIUS server sending the new > Alejandro> fragments. > > Alejandro> I think it is possible, but that may be a lot of state to > Alejandro> hold for a proxy. > > I'm confused because I thought the proxy would end up having to first > have a conversation with the RADIUS server. > Do you have server and client reversed? > If not, would you help me better understand what's going on? My mistake, sorry. I was initially thinking on a client-initiated conversation (e.g. SAML Authn Request). It would be as you say. > Is the proxy's state required any more than the state a server needs to > retain for its outstanding fragmented requests? No, it should be the same. But it would be more than usually required for a proxy (they usually receive, send and forget). Anyway, I'm not sure that is actually a big issue. I was just asking if it was. Regards, Alejandro > > --Sam From wei.yinxing@zte.com.cn Mon Mar 12 02:23:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B064721F8754 for ; Mon, 12 Mar 2012 02:23:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.727 X-Spam-Level: X-Spam-Status: No, score=-99.727 tagged_above=-999 required=5 tests=[AWL=2.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 q9jnwphV9p1f for ; Mon, 12 Mar 2012 02:23:14 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A74DB21F8750 for ; Mon, 12 Mar 2012 02:23:13 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 12280967931198; Mon, 12 Mar 2012 16:50:25 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 65905.967931198; Mon, 12 Mar 2012 17:23:01 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2C9MffZ008766 for ; Mon, 12 Mar 2012 17:22:42 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) To: abfab@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Mon, 12 Mar 2012 17:18:59 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-12 17:22:43, Serialize complete at 2012-03-12 17:22:43 Content-Type: multipart/alternative; boundary="=_alternative 0033DD53482579BF_=" X-MAIL: mse01.zte.com.cn q2C9MffZ008766 Subject: [abfab] draft-wei-abfab-fcla-02 is posted X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 09:23:14 -0000 This is a multipart message in MIME format. --=_alternative 0033DD53482579BF_= Content-Type: text/plain; charset="US-ASCII" Hi, all An updated version of Federated Cross-Layer Access (draft-wei-abfab-fcla-02) is posted. The major changes is in claust 4 : - 4. message flow - 4.1 fast re-authentication - 4.2 secure data sharing here is the draft: http://www.ietf.org/id/draft-wei-abfab-fcla-02.txt Any comments are appreciated! ------------- Yinxing Wei -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0033DD53482579BF_= Content-Type: text/html; charset="US-ASCII"
Hi, all

  An updated version of Federated Cross-Layer Access (draft-wei-abfab-fcla-02) is posted.
  The major changes is in claust 4 :
 - 4. message flow
 - 4.1 fast re-authentication
 - 4.2 secure data sharing

here is the draft:
  http://www.ietf.org/id/draft-wei-abfab-fcla-02.txt

Any comments are appreciated!

-------------
Yinxing Wei

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0033DD53482579BF_=-- From rafa@um.es Mon Mar 12 02:39:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B6F21F8669 for ; Mon, 12 Mar 2012 02:39:47 -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 MtuKQWxEs7rF for ; Mon, 12 Mar 2012 02:39:46 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 735D621F8585 for ; Mon, 12 Mar 2012 02:39:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id EED7F5360A; Mon, 12 Mar 2012 10:39:44 +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 Qpt2Jp41xHHU; Mon, 12 Mar 2012 10:39:44 +0100 (CET) Received: from [192.168.1.67] (28.Red-83-38-59.dynamicIP.rima-tde.net [83.38.59.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id CB44F535D4; Mon, 12 Mar 2012 10:39:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Rafa Marin Lopez In-Reply-To: Date: Mon, 12 Mar 2012 10:39:42 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <35A82FAB-7E16-4A9A-B7A1-0C01F34F39A7@um.es> References: <7A8C5795-2904-4136-A0C7-B0451348ADB6@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1257) Cc: abfab@ietf.org Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 09:39:47 -0000 Hi Sam:=20 > Rafa> Nevertheless I am still wondering what is the benefit. Let me > Rafa> explain. Fast re-authentication is generally important but we > Rafa> are just saving a round trip between initiator and acceptor, > Rafa> which are not too much in comparison with the number of > Rafa> messages involved during a whole EAP authentication and the > Rafa> travel the messages have to do all the way to the home = AAA/EAP > Rafa> server. So basically I believe reducing that part does not > Rafa> help too much if we do not reduce the real critic parts as = the > Rafa> number of EAP messages or the fact they have to reach the = home > Rafa> AAA/EAP server. >=20 >=20 > You may well be right. I had not fully thought this through. > It sounds like you'd be happy holding off on this change if we ever = make > it. >=20 I believe it would be interesting to further analyze the general = problem, perhaps defining a problem statement and the requirements for a = fast re-authentication procedure in ABFAB. Then, we could move to the = solution space. I think this is an interesting topic. > When we are next in person I'd like to discuss this sort of = optimization > with you in more detail. Sure. Many thanks. >=20 ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From internet-drafts@ietf.org Mon Mar 12 04:59:36 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53BD521F86F8; Mon, 12 Mar 2012 04:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 3A4TydqZ1DpJ; Mon, 12 Mar 2012 04:59:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC4E21F8702; Mon, 12 Mar 2012 04:59:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 04:59:35 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 11:59:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Ac= cess Beyond web Working Group of the IETF. Title : A RADIUS Attribute, Binding and Profiles for SAML Author(s) : Josh Howlett Sam Hartman Filename : draft-ietf-abfab-aaa-saml-03.txt Pages : 15 Date : 2012-03-12 This document specifies a RADIUS attribute, a binding and two profiles for the Security Assertion Mark-up Language (SAML). The attribute provides RADIUS encapsulation of SAML protocol messages, while the binding describes the transport of this attribute, and the SAML protocol messages within, using RADIUS. The profiles describe the application of this binding for Abfab authentication and assertion query/request. The SAML RADIUS attribute and binding are defined generically to permit application in other scenarios, such as network access. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-aaa-saml-03.txt From hartmans@painless-security.com Mon Mar 12 05:00:36 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76F2621F878B for ; Mon, 12 Mar 2012 05:00:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.294 X-Spam-Level: X-Spam-Status: No, score=-2.294 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 usfIEwJ1fFal for ; Mon, 12 Mar 2012 05:00:36 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E89BF21F8744 for ; Mon, 12 Mar 2012 05:00:35 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 6C5272024B; Mon, 12 Mar 2012 08:00:08 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B32204766; Mon, 12 Mar 2012 08:00:25 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> Date: Mon, 12 Mar 2012 08:00:25 -0400 In-Reply-To: <4F5D30F1.4040808@um.es> (Alejandro Perez Mendez's message of "Mon, 12 Mar 2012 00:10: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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:00:36 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: >> Is the proxy's state required any more than the state a server >> needs to retain for its outstanding fragmented requests? Alejandro> No, it should be the same. But it would be more than Alejandro> usually required for a proxy (they usually receive, send Alejandro> and forget). Anyway, I'm not sure that is actually a big Alejandro> issue. I was just asking if it was. I'm greatful that you're trying to explore this issue because I think it gets at the core of Jim's question. I don't know if the state required is too much. Here are my thoughts: 1) It makes rewriting SAML requests significantly more effort than rewriting RADIUS attributes. That said, there are a number of ways (needing a SAML library, possibly needing to resign or strip signatures) where a SAML rewrite is harder for a RADIUS server than a RADIUS rewrite. However this increases state not just adding new libraries. 2) It wouldn't surprise me if proxies near an RP handled similar volumes of requests as home servers or proxies near an IDP. 3) In a proxy fabric deployment it wouldn't surprise me if proxies in the middle of a federation handle significantly more volume than proxies near the edges. 4) In the Moonshot deployment we're hoping to avoid proxy fabric and use trust router, so we're hoping that any proxy-like entities in the middle will not see individual requests. I think implicit in that is an assumption that attributes of individual requests will not need to be rewritten in the middle. 5) The effort required for this sort of rewrite is very similar to the effort required to map from SAML and other authorization languages to Kerberos in the gss-preauth/eap-preauth cases on the RP's KDC. In conclusion, I'd be happy if we had more data on use cases and performance requirements for proxy rewriting. From rafa@um.es Mon Mar 12 05:17:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F0C21F8754 for ; Mon, 12 Mar 2012 05:17:01 -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.501, 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 y5ce9bzN-lBj for ; Mon, 12 Mar 2012 05:17:00 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 30F7021F854A for ; Mon, 12 Mar 2012 05:17:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id CCE845D503; Mon, 12 Mar 2012 13:16:58 +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 glCkRicJQoMQ; Mon, 12 Mar 2012 13:16:58 +0100 (CET) Received: from [192.168.1.67] (28.Red-83-38-59.dynamicIP.rima-tde.net [83.38.59.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon13.um.es (Postfix) with ESMTPSA id 49BB35D498; Mon, 12 Mar 2012 13:16:52 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_FAA038B3-6E5F-40B2-887F-AE1224A36863" From: Rafa Marin Lopez In-Reply-To: Date: Mon, 12 Mar 2012 13:16:50 +0100 Message-Id: References: To: wei.yinxing@zte.com.cn X-Mailer: Apple Mail (2.1257) Cc: abfab@ietf.org Subject: Re: [abfab] draft-wei-abfab-fcla-02 is posted (fast re-auth) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:17:01 -0000 --Apple-Mail=_FAA038B3-6E5F-40B2-887F-AE1224A36863 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Yinxing: I have seen that you have also mentioned and described the problem of = fast re-authentication in your I-D. We have been just discussing as you = may have noticed. Although I am still in favor to define a general problem statement for = this in ABFAB before going to solution space, I must say that here in = UMU we have been thinking about a possible solution for providing this = fast re-authentication procedure, which may have some similarities with = yours. Basically, since GSS-EAP is used in ABFAB to provide authentication, our = idea is to use ERP (RFC 5296) (and the associated infrastructure) to = provide fast re-authentication in ABFAB. After all, ERP is the standard = to reduce the authentication time in EAP-based authentications. In this way, we could extend GSS-EAP or create a GSS-ERP mechanism to = transport ERP messages within GSS tokens. Something like: 1. Initiator --> Acceptor: GSS-EAP (EAP Initiate/Re-auth(SEQ, = keyName-NAI, cryptosuite,Auth-tag*))=20 1a. Acceptor --> ER-Server: AAA-Request{Authenticator-Id, EAP Initiate/Re-auth(SEQ,keyName-NAI, cryptosuite,Auth-tag*) 2. ER-Server --> Acceptor: AAA-Response{rMSK, EAP-Finish/Re-auth(SEQ,keyName-NAI, cryptosuite,[CB-Info],Auth-tag*) 2b. Acceptor --> Initiator: GSS-EAP = (EAP-Finish/Re-auth(SEQ,keyName-NAI, cryptosuite,[CB-Info],Auth-tag*)) Even the ER-Server could be placed near the server (local ER server) = reducing the travel time of the messages.=20 Obviously this is just an idea, which needs to be elaborated and = discussed. In fact, as I said, I think it would be better to start = defining a problem statement, requirements etc... for fast = re-authentication in ABFAB. UMU would be willing to work on that. Best regards. El 12/03/2012, a las 10:18, wei.yinxing@zte.com.cn escribi=F3: >=20 > Hi, all=20 >=20 > An updated version of Federated Cross-Layer Access = (draft-wei-abfab-fcla-02) is posted.=20 > The major changes is in claust 4 :=20 > - 4. message flow=20 > - 4.1 fast re-authentication=20 > - 4.2 secure data sharing=20 >=20 > here is the draft:=20 > http://www.ietf.org/id/draft-wei-abfab-fcla-02.txt=20 >=20 > Any comments are appreciated!=20 >=20 > -------------=20 > Yinxing Wei >=20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. > This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_FAA038B3-6E5F-40B2-887F-AE1224A36863 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Yinxing:

I have seen that you have also mentioned and = described the problem of fast re-authentication in your I-D. We have = been just discussing as you may have = noticed.

Although I am still in favor to define = a general problem statement for this in ABFAB before going to solution = space, I must say that here in UMU we have been thinking about a = possible solution for providing this fast re-authentication procedure, = which may have some similarities with = yours.

Basically, since GSS-EAP is used in = ABFAB to provide authentication, our idea is to use ERP (RFC 5296) (and = the associated infrastructure) to provide fast re-authentication in = ABFAB. After all, ERP is the standard to reduce the authentication time = in EAP-based authentications.

In this way, we = could extend GSS-EAP or create a GSS-ERP mechanism to transport ERP = messages within GSS tokens. Something = like:


1. Initiator --> = Acceptor: GSS-EAP (EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,Auth-tag*)) 
   1a. Acceptor --> ER-Server: AAA-Request{Authenticator-Id,
                                EAP Initiate/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,Auth-tag*)

   2. ER-Server --> Acceptor: AAA-Response{rMSK,
                                EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,[CB-Info],Auth-tag*)

   2b. Acceptor --> Initiator: GSS-EAP =
(EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                =
cryptosuite,[CB-Info],Auth-tag*))

Even the ER-Server could be placed near the server (local = ER server) reducing the travel time of the = messages. 

Obviously this is just an idea, = which needs to be elaborated and discussed. In fact, as I said, I think = it would be better to start defining a problem statement, requirements = etc... for fast re-authentication in ABFAB. UMU would be willing to work = on that.

Best = regards.

El 12/03/2012, a las 10:18, wei.yinxing@zte.com.cn = escribi=F3:


Hi, all

  An updated version of Federated = Cross-Layer Access (draft-wei-abfab-fcla-02) is posted.
  The major changes is in claust 4 = :
 - 4. message flow
 - 4.1 fast re-authentication
 - 4.2 secure data sharing

here is the draft:
  http://www.iet= f.org/id/draft-wei-abfab-fcla-02.txt

Any comments are appreciated!

-------------
Yinxing Wei
= 
-----------------------------------------------------=
---
=
ZTE Information Security Notice: The information&=
nbsp;contained in this mail is solely proper=
ty of the sender's organization. This mail&n=
bsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy a=
nd are not permitted to disclose the co=
ntents of this communication to others.
=
This email and any files transmitted with&nb=
sp;it are confidential and intended solely f=
or the use of the individual or entity&=
nbsp;to whom they are addressed. If you =
;have received this email in error please&nb=
sp;notify the originator of the message. Any=
 views expressed in this message are th=
ose of the individual sender.
=
This message has been scanned for viruses&nb=
sp;and Spam by ZTE Anti-Spam system.
_______________________________________________
abfab mailing = list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab

-------------------------------------------------------
<= div>Rafael Marin Lopez, PhD
Dept. Information and = Communications Engineering (DIIC)
Faculty of Computer = Science-University of Murcia
30100 Murcia - = Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
----------------------= ---------------------------------




= --Apple-Mail=_FAA038B3-6E5F-40B2-887F-AE1224A36863-- From lukeh@padl.com Mon Mar 12 05:21:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39A921F8754 for ; Mon, 12 Mar 2012 05:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 d2fyoLKpefEu for ; Mon, 12 Mar 2012 05:21:09 -0700 (PDT) Received: from us.padl.com (us.padl.com [216.154.215.154]) by ietfa.amsl.com (Postfix) with ESMTP id BAA1721F86F0 for ; Mon, 12 Mar 2012 05:21:08 -0700 (PDT) Received: by us.padl.com with ESMTP id q2CCL0ah011468; Mon, 12 Mar 2012 08:21:04 -0400 References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-4A5CF00D-F8C6-4C5B-B825-C45850E24602 Message-Id: <54A04086-BAAD-4B75-B6D0-4877DD415346@padl.com> X-Mailer: iPhone Mail (9B176) From: Luke Howard Date: Mon, 12 Mar 2012 23:18:41 +1100 To: Rafa Marin Lopez X-SMTP-Vilter-Version: 1.3.6 X-Spamd-Symbols: AWL, BAYES_00, HTML_MESSAGE, MIME_QP_LONG_LINE, USER_IN_WHITELIST X-SMTP-Vilter-Spam-Backend: spamd X-Spam-Threshold: 5.0 X-Spam-Probability: -20.4 Cc: "abfab@ietf.org" Subject: Re: [abfab] draft-wei-abfab-fcla-02 is posted (fast re-auth) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:21:09 -0000 --Apple-Mail-4A5CF00D-F8C6-4C5B-B825-C45850E24602 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I haven't read the draft, but note that the Moonshot implementation provides= fast reauth based on Kerberos tickets. Sent from my iPhone On 12/03/2012, at 11:16 PM, Rafa Marin Lopez wrote: > Hi Yinxing: >=20 > I have seen that you have also mentioned and described the problem of fast= re-authentication in your I-D. We have been just discussing as you may have= noticed. >=20 > Although I am still in favor to define a general problem statement for thi= s in ABFAB before going to solution space, I must say that here in UMU we ha= ve been thinking about a possible solution for providing this fast re-authen= tication procedure, which may have some similarities with yours. >=20 > Basically, since GSS-EAP is used in ABFAB to provide authentication, our i= dea is to use ERP (RFC 5296) (and the associated infrastructure) to provide f= ast re-authentication in ABFAB. After all, ERP is the standard to reduce the= authentication time in EAP-based authentications. >=20 > In this way, we could extend GSS-EAP or create a GSS-ERP mechanism to tran= sport ERP messages within GSS tokens. Something like: >=20 >=20 > 1. Initiator --> Acceptor: GSS-EAP (EAP Initiate/Re-auth(SEQ, keyName-NA= I, > cryptosuite,Auth-tag*))=20 > 1a. Acceptor --> ER-Server: AAA-Request{Authenticator-Id, > EAP Initiate/Re-auth(SEQ,keyName-NAI, > cryptosuite,Auth-tag*) >=20 > 2. ER-Server --> Acceptor: AAA-Response{rMSK, > EAP-Finish/Re-auth(SEQ,keyName-NAI, > cryptosuite,[CB-Info],Auth-tag*) >=20 > 2b. Acceptor --> Initiator: GSS-EAP (EAP-Finish/Re-auth(SEQ,keyName-NAI= , > cryptosuite,[CB-Info],Auth-tag*)) >=20 >=20 > Even the ER-Server could be placed near the server (local ER server) reduc= ing the travel time of the messages.=20 >=20 > Obviously this is just an idea, which needs to be elaborated and discussed= . In fact, as I said, I think it would be better to start defining a problem= statement, requirements etc... for fast re-authentication in ABFAB. UMU wou= ld be willing to work on that. >=20 > Best regards. >=20 > El 12/03/2012, a las 10:18, wei.yinxing@zte.com.cn escribi=C3=B3: >=20 >>=20 >> Hi, all=20 >>=20 >> An updated version of Federated Cross-Layer Access (draft-wei-abfab-fcl= a-02) is posted.=20 >> The major changes is in claust 4 :=20 >> - 4. message flow=20 >> - 4.1 fast re-authentication=20 >> - 4.2 secure data sharing=20 >>=20 >> here is the draft:=20 >> http://www.ietf.org/id/draft-wei-abfab-fcla-02.txt=20 >>=20 >> Any comments are appreciated!=20 >>=20 >> -------------=20 >> Yinxing Wei >>=20 >> -------------------------------------------------------- >> ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is c= onfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. >> This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed.= If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual s= ender. >> This message has been scanned for viruses and Spam by ZTE Anti-Spam syste= m. >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- >=20 >=20 >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --Apple-Mail-4A5CF00D-F8C6-4C5B-B825-C45850E24602 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I haven't read the draft, b= ut note that the Moonshot implementation provides fast reauth based on Kerbe= ros tickets.

Sent from my iPhone

On 12/03/2012, at 11:1= 6 PM, Rafa Marin Lopez <rafa@um.es> w= rote:

Hi Yinxing:
I have seen that you have also mentioned and described the p= roblem of fast re-authentication in your I-D. We have been just discussing a= s you may have noticed.

Although I am still in favo= r to define a general problem statement for this in ABFAB before going to so= lution space, I must say that here in UMU we have been thinking about a poss= ible solution for providing this fast re-authentication procedure, which may= have some similarities with yours.

Basically, sinc= e GSS-EAP is used in ABFAB to provide authentication, our idea is to use ERP= (RFC 5296) (and the associated infrastructure) to provide fast re-authentic= ation in ABFAB. After all, ERP is the standard to reduce the authentication t= ime in EAP-based authentications.

In this way, we c= ould extend GSS-EAP or create a GSS-ERP mechanism to transport ERP messages w= ithin GSS tokens. Something like:


1. Initiator --> Acceptor: GSS= -EAP (EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,Auth-tag*)) 
   1a. Acceptor --> ER-Server: AAA-Request{Au=
thenticator-Id,
                                EAP Initiate/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,Auth-tag*)

   2. ER-Server --> Acceptor: AAA-Response{rMSK,
                                EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,[CB-Info],Auth-tag*)

   2b. Acceptor --> Initiator: GSS-EAP (EAP-Finish/Re-auth(SEQ,keyName-NA=
I,
                                cryptosuite,[CB-Info],Auth-tag*))


Even the ER-Server could be place= d near the server (local ER server) reducing the travel time of the messages= . 

Obviously this is just an idea, which needs= to be elaborated and discussed. In fact, as I said, I think it would be bet= ter to start defining a problem statement, requirements etc... for fast re-a= uthentication in ABFAB. UMU would be willing to work on that.

=
Best regards.

El 12/03/2012, a las 10:18,= wei.yinxing@zte.com.cn escrib= i=C3=B3:


Hi, all

  An updated version of Federated Cross-Layer Access (draft-wei-abfab-fcla-02) is posted.
  The major changes is in claust 4 :
 - 4. message flow
 - 4.1 fast re-authentication
 - 4.2 secure data sharing

here is the draft:
  http://www.ietf.org/id/draft-wei-abfab-fcla-02.txt

Any comments are appreciated!

-------------
Yinxing Wei

-------------------------------------------------------=
-
ZTE Information Security Notice: The information&nb=
sp;contained in this mail is solely property&n=
bsp;of the sender's organization. This mail co=
mmunication is confidential. Recipients named above=
 are obligated to maintain secrecy and ar=
e not permitted to disclose the contents =
of this communication to others.
This email and any files transmitted with =
;it are confidential and intended solely for&n=
bsp;the use of the individual or entity t=
o whom they are addressed. If you have&nb=
sp;received this email in error please notify&=
nbsp;the originator of the message. Any views&=
nbsp;expressed in this message are those of&nb=
sp;the individual sender.
This message has been scanned for viruses =
;and Spam by ZTE Anti-Spam system.
_______________________________________________
abfab mailing list<= br>abfab@ietf.org
https://www.ietf.org/mailman/listinfo= /abfab

--------------------= -----------------------------------
Rafael Marin Lopez, PhD
<= div>Dept. Information and Communications Engineering (DIIC)
Facult= y of Computer Science-University of Murcia
30100 Murcia - Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
--------------------------------------------= -----------




__________= _____________________________________
abfab mailing list
abfab@ietf.org
= https://www.ie= tf.org/mailman/listinfo/abfab
= --Apple-Mail-4A5CF00D-F8C6-4C5B-B825-C45850E24602-- From hartmans@painless-security.com Mon Mar 12 05:33:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5B921F8597 for ; Mon, 12 Mar 2012 05:33:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.293 X-Spam-Level: X-Spam-Status: No, score=-2.293 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 svdoUZraKhpE for ; Mon, 12 Mar 2012 05:33:46 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A247221F8585 for ; Mon, 12 Mar 2012 05:33:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5749D2024B; Mon, 12 Mar 2012 08:33:07 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id C76D04766; Mon, 12 Mar 2012 08:33:24 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <7A8C5795-2904-4136-A0C7-B0451348ADB6@um.es> <35A82FAB-7E16-4A9A-B7A1-0C01F34F39A7@um.es> Date: Mon, 12 Mar 2012 08:33:24 -0400 In-Reply-To: <35A82FAB-7E16-4A9A-B7A1-0C01F34F39A7@um.es> (Rafa Marin Lopez's message of "Mon, 12 Mar 2012 10:39:42 +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: abfab@ietf.org Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:33:47 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: >I believe it would be interesting to further analyze the general problem, perhaps defining a problem statement and the requirements for a fast re-authentication procedure in ABFAB. Then, we could move to the solution space. I think this is an interesting topic. I'm delighted to hear you're interested the fast reauth problem; I think it would be great to get more input into that process. I am frustrated when people propose a formal problem statement/requirements draft. My experience has been that these document take around a year to work through. How about we have a couple of brainstorming sessions and possibly a call or two to collect input on requirements from interested parties? I think that will capture as much value as a requirement document with much less frustration and delay. --Sam From diego@tid.es Mon Mar 12 05:38:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47F1421F87A0 for ; Mon, 12 Mar 2012 05:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.194 X-Spam-Level: X-Spam-Status: No, score=-3.194 tagged_above=-999 required=5 tests=[AWL=-0.595, 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 wGsBrjkSlEH3 for ; Mon, 12 Mar 2012 05:38:24 -0700 (PDT) Received: from tidos.tid.es (tidos.tid.es [195.235.93.44]) by ietfa.amsl.com (Postfix) with ESMTP id B3B8921F8789 for ; Mon, 12 Mar 2012 05:38:23 -0700 (PDT) Received: from sbrightmailg01.hi.inet (sbrightmailg01.hi.inet [10.95.64.104]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0M0R00LY0V3Y4S@tid.hi.inet> for abfab@ietf.org; Mon, 12 Mar 2012 13:38:22 +0100 (MET) Received: from tid (tid.hi.inet [10.95.64.10]) by sbrightmailg01.hi.inet (Symantec Messaging Gateway) with SMTP id F7.80.02893.E3EED5F4; Mon, 12 Mar 2012 13:38:22 +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 <0M0R00LXVV3Y4S@tid.hi.inet> for abfab@ietf.org; Mon, 12 Mar 2012 13:38:22 +0100 (MET) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Mon, 12 Mar 2012 13:38:22 +0100 Date: Mon, 12 Mar 2012 13:38:21 +0100 From: DIEGO LOPEZ GARCIA In-reply-to: To: Sam Hartman Message-id: <5C280F78-768A-44E6-B050-1EBA7277EF39@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] gss-eap: eap identity? Thread-index: Ac0ATQJ265SIacmaTeSjUSygri65mw== acceptlanguage: en-US X-AuditID: 0a5f4068-b7f2d6d000000b4d-fb-4f5dee3ef7c6 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsXCFe/ApWv3Ltbf4OxfAYuP198wOjB6LFny kymAMYrLJiU1J7MstUjfLoEr48rPo2wFqwQqFiw8zd7A+IW/i5GTQ0LAROJi109GCFtM4sK9 9WxdjFwcQgIbGCU+vrzDCOH8YJSYdfUTO4TTyCix+vJOsBYWAVWJTavfM4PYbALqEi1Hv7GA 2MIC2hINzxtYQWxOATWJ3uc9bCC2iICBxLxXx8BsZgEXiQ0TfzCB2LwClhItR75B2YISPybf A5rDAVSjLjFlSi5EubhEc+tNFghbUWLaogawExiBrv5+ag0TxHgdibYnG6FsPYmJ89ezQtSI StxpXw/1pYDEkj3nmSFsUYmXj/+xQvy1nVFi8YMtLBMYxWchOWMWwhmzkJwxC8kZCxhZVjGK FScVZaZnlOQmZuakGxjqZWTqZeallmxihMRRxg7G5TtVDjEKcDAq8fBmWEb5C7EmlhVX5h5i lORgUhLlTX8V6y/El5SfUpmRWJwRX1Sak1p8iFGCg1lJhPfYc6Acb0piZVVqUT5MSoaDQ0mC t+YtUEqwKDU9tSItMweYLGDSTBycIO08QO39r0HaiwsSc4sz0yHypxglpcR5W0CaBUASGaV5 cL2vGMWBjhTmLQPJ8gDTGlzXK6CBTEADP3NFgwwsSURISTUwGoh5FEtW/Fqw7Y7A/9Y/u46o fVwea3dL+thJg7c5D9MSVjlfEmHNn6TftvVqlfH8+HeBLdOqb2930v/S81V7a0Z7fcg2tlm8 Dw5YMLJdeJlzWHr72u26a8OKQsUW2ec6WD3gqpHkdOQxunDObct0lb2zwhv5LuUm/V2wt3D6 5QCb5ZV/LuzeqsRSnJFoqMVcVJwIAMUILBsoAwAA References: <7A8C5795-2904-4136-A0C7-B0451348ADB6@um.es> <35A82FAB-7E16-4A9A-B7A1-0C01F34F39A7@um.es> Cc: "abfab@ietf.org" Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:38:26 -0000 DQpPbiAxMiBNYXIgMjAxMiwgYXQgMTM6MzMgLCBTYW0gSGFydG1hbiB3cm90ZToNCj4+Pj4+PiAi UmFmYSIgPT0gUmFmYSBNYXJpbiBMb3BleiA8cmFmYUB1bS5lcz4gd3JpdGVzOg0KPg0KPj4gSSBi ZWxpZXZlIGl0IHdvdWxkIGJlIGludGVyZXN0aW5nIHRvIGZ1cnRoZXIgYW5hbHl6ZSB0aGUgZ2Vu ZXJhbCBwcm9ibGVtLCBwZXJoYXBzIGRlZmluaW5nIGEgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHRo ZSByZXF1aXJlbWVudHMgZm9yIGEgZmFzdCByZS1hdXRoZW50aWNhdGlvbiBwcm9jZWR1cmUgaW4g QUJGQUIuIFRoZW4sIHdlIGNvdWxkIG1vdmUgdG8gdGhlIHNvbHV0aW9uIHNwYWNlLiBJIHRoaW5r IHRoaXMgaXMgYW4gaW50ZXJlc3RpbmcgdG9waWMuDQo+DQo+DQo+IEknbSBkZWxpZ2h0ZWQgdG8g aGVhciB5b3UncmUgaW50ZXJlc3RlZCB0aGUgZmFzdCByZWF1dGggcHJvYmxlbTsgSSB0aGluaw0K PiBpdCB3b3VsZCBiZSBncmVhdCB0byBnZXQgbW9yZSBpbnB1dCBpbnRvIHRoYXQgcHJvY2Vzcy4g SSBhbSBmcnVzdHJhdGVkDQo+IHdoZW4gcGVvcGxlIHByb3Bvc2UgYSBmb3JtYWwgcHJvYmxlbSBz dGF0ZW1lbnQvcmVxdWlyZW1lbnRzIGRyYWZ0LiBNeQ0KPiBleHBlcmllbmNlIGhhcyBiZWVuIHRo YXQgdGhlc2UgZG9jdW1lbnQgdGFrZSBhcm91bmQgYSB5ZWFyIHRvIHdvcmsNCj4gdGhyb3VnaC4g IEhvdyBhYm91dCB3ZSBoYXZlIGEgY291cGxlIG9mIGJyYWluc3Rvcm1pbmcgc2Vzc2lvbnMgYW5k DQo+IHBvc3NpYmx5IGEgY2FsbCBvciB0d28gdG8gY29sbGVjdCBpbnB1dCBvbiByZXF1aXJlbWVu dHMgZnJvbSBpbnRlcmVzdGVkDQo+IHBhcnRpZXM/IEkgdGhpbmsgdGhhdCB3aWxsIGNhcHR1cmUg YXMgbXVjaCB2YWx1ZSBhcyBhIHJlcXVpcmVtZW50DQo+IGRvY3VtZW50IHdpdGggbXVjaCBsZXNz IGZydXN0cmF0aW9uIGFuZCBkZWxheS4NCg0KDQorMQ0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJl bW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRyIERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkr RA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlk LmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg0KRXN0ZSBtZW5zYWpl IHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBhIHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3Vs dGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVudsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVs ZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdl IGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQg YW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJhc2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0DQpo dHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFTL2Rpc2NsYWltZXIuYXNweA0K From rafa@um.es Mon Mar 12 05:48:32 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE75C21F87B9 for ; Mon, 12 Mar 2012 05:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fbd47b5vQiBQ for ; Mon, 12 Mar 2012 05:48:32 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4C321F87B6 for ; Mon, 12 Mar 2012 05:48:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 5F11C53615; Mon, 12 Mar 2012 13:48:30 +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 QyZbu6iPTjn3; Mon, 12 Mar 2012 13:48:29 +0100 (CET) Received: from [192.168.1.67] (28.Red-83-38-59.dynamicIP.rima-tde.net [83.38.59.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 6D5F853610; Mon, 12 Mar 2012 13:48:20 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_FF57D444-87A1-4CA1-BB5B-E424E27E82D8" From: Rafa Marin Lopez In-Reply-To: <54A04086-BAAD-4B75-B6D0-4877DD415346@padl.com> Date: Mon, 12 Mar 2012 13:44:04 +0100 Message-Id: References: <54A04086-BAAD-4B75-B6D0-4877DD415346@padl.com> To: Luke Howard X-Mailer: Apple Mail (2.1257) Cc: "abfab@ietf.org" Subject: Re: [abfab] draft-wei-abfab-fcla-02 is posted (fast re-auth) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 12:48:33 -0000 --Apple-Mail=_FF57D444-87A1-4CA1-BB5B-E424E27E82D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Luke: That kind of fast re-auth based on Kerberos is also intrinsic to = draft-perez-abfab-eap-gss-preauth-01 Best regards. El 12/03/2012, a las 13:18, Luke Howard escribi=F3: > I haven't read the draft, but note that the Moonshot implementation = provides fast reauth based on Kerberos tickets. >=20 > Sent from my iPhone >=20 > On 12/03/2012, at 11:16 PM, Rafa Marin Lopez wrote: >=20 >> Hi Yinxing: >>=20 >> I have seen that you have also mentioned and described the problem of = fast re-authentication in your I-D. We have been just discussing as you = may have noticed. >>=20 >> Although I am still in favor to define a general problem statement = for this in ABFAB before going to solution space, I must say that here = in UMU we have been thinking about a possible solution for providing = this fast re-authentication procedure, which may have some similarities = with yours. >>=20 >> Basically, since GSS-EAP is used in ABFAB to provide authentication, = our idea is to use ERP (RFC 5296) (and the associated infrastructure) to = provide fast re-authentication in ABFAB. After all, ERP is the standard = to reduce the authentication time in EAP-based authentications. >>=20 >> In this way, we could extend GSS-EAP or create a GSS-ERP mechanism to = transport ERP messages within GSS tokens. Something like: >>=20 >>=20 >> 1. Initiator --> Acceptor: GSS-EAP (EAP Initiate/Re-auth(SEQ, = keyName-NAI, >> cryptosuite,Auth-tag*))=20 >> 1a. Acceptor --> ER-Server: AAA-Request{Authenticator-Id, >> EAP Initiate/Re-auth(SEQ,keyName-NAI, >> cryptosuite,Auth-tag*) >>=20 >> 2. ER-Server --> Acceptor: AAA-Response{rMSK, >> EAP-Finish/Re-auth(SEQ,keyName-NAI, >> cryptosuite,[CB-Info],Auth-tag*) >>=20 >> 2b. Acceptor --> Initiator: GSS-EAP = (EAP-Finish/Re-auth(SEQ,keyName-NAI, >> cryptosuite,[CB-Info],Auth-tag*)) >>=20 >>=20 >> Even the ER-Server could be placed near the server (local ER server) = reducing the travel time of the messages.=20 >>=20 >> Obviously this is just an idea, which needs to be elaborated and = discussed. In fact, as I said, I think it would be better to start = defining a problem statement, requirements etc... for fast = re-authentication in ABFAB. UMU would be willing to work on that. >>=20 >> Best regards. >>=20 >> El 12/03/2012, a las 10:18, wei.yinxing@zte.com.cn escribi=F3: >>=20 >>>=20 >>> Hi, all=20 >>>=20 >>> An updated version of Federated Cross-Layer Access = (draft-wei-abfab-fcla-02) is posted.=20 >>> The major changes is in claust 4 :=20 >>> - 4. message flow=20 >>> - 4.1 fast re-authentication=20 >>> - 4.2 secure data sharing=20 >>>=20 >>> here is the draft:=20 >>> http://www.ietf.org/id/draft-wei-abfab-fcla-02.txt=20 >>>=20 >>> Any comments are appreciated!=20 >>>=20 >>> -------------=20 >>> Yinxing Wei >>>=20 >>> -------------------------------------------------------- >>> ZTE Information Security Notice: The information contained in this = mail is solely property of the sender's organization. This mail = communication is confidential. Recipients named above are obligated to = maintain secrecy and are not permitted to disclose the contents of this = communication to others. >>> This email and any files transmitted with it are confidential and = intended solely for the use of the individual or entity to whom they are = addressed. If you have received this email in error please notify the = originator of the message. Any views expressed in this message are those = of the individual sender. >>> This message has been scanned for viruses and Spam by ZTE Anti-Spam = system. >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>=20 >> ------------------------------------------------------- >> Rafael Marin Lopez, PhD >> Dept. Information and Communications Engineering (DIIC) >> Faculty of Computer Science-University of Murcia >> 30100 Murcia - Spain >> Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es >> ------------------------------------------------------- >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- --Apple-Mail=_FF57D444-87A1-4CA1-BB5B-E424E27E82D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Luke:

That kind of fast re-auth based on Kerberos is = also intrinsic to = draft-perez-abfab-eap-gss-preauth-01

Best = regards.

El 12/03/2012, a las 13:18, Luke Howard = escribi=F3:

I haven't read the draft, = but note that the Moonshot implementation provides fast reauth based on = Kerberos tickets.

Sent from my iPhone

On = 12/03/2012, at 11:16 PM, Rafa Marin Lopez <rafa@um.es> = wrote:

Hi = Yinxing:

I have seen that you have also mentioned and = described the problem of fast re-authentication in your I-D. We have = been just discussing as you may have = noticed.

Although I am still in favor to define = a general problem statement for this in ABFAB before going to solution = space, I must say that here in UMU we have been thinking about a = possible solution for providing this fast re-authentication procedure, = which may have some similarities with = yours.

Basically, since GSS-EAP is used in = ABFAB to provide authentication, our idea is to use ERP (RFC 5296) (and = the associated infrastructure) to provide fast re-authentication in = ABFAB. After all, ERP is the standard to reduce the authentication time = in EAP-based authentications.

In this way, we = could extend GSS-EAP or create a GSS-ERP mechanism to transport ERP = messages within GSS tokens. Something = like:


1. Initiator --> = Acceptor: GSS-EAP (EAP Initiate/Re-auth(SEQ, keyName-NAI, cryptosuite,Auth-tag*)) 
   1a. Acceptor --> =
ER-Server: AAA-Request{Authenticator-Id,
                                EAP Initiate/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,Auth-tag*)

   2. ER-Server --> Acceptor: AAA-Response{rMSK,
                                EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                cryptosuite,[CB-Info],Auth-tag*)

   2b. Acceptor --> Initiator: GSS-EAP =
(EAP-Finish/Re-auth(SEQ,keyName-NAI,
                                =
cryptosuite,[CB-Info],Auth-tag*))

Even the ER-Server could be placed near the server (local = ER server) reducing the travel time of the = messages. 

Obviously this is just an idea, = which needs to be elaborated and discussed. In fact, as I said, I think = it would be better to start defining a problem statement, requirements = etc... for fast re-authentication in ABFAB. UMU would be willing to work = on that.

Best = regards.

El 12/03/2012, a las 10:18, wei.yinxing@zte.com.cn = escribi=F3:


Hi, all

  An updated version of Federated = Cross-Layer Access (draft-wei-abfab-fcla-02) is posted.
  The major changes is in claust 4 = :
 - 4. message flow
 - 4.1 fast re-authentication
 - 4.2 secure data sharing

here is the draft:
  http://www.iet= f.org/id/draft-wei-abfab-fcla-02.txt

Any comments are appreciated!

-------------
Yinxing Wei
= 
-----------------------------------------------------=
---
=
ZTE Information Security Notice: The information&=
nbsp;contained in this mail is solely proper=
ty of the sender's organization. This mail&n=
bsp;communication is confidential. Recipients named&nb=
sp;above are obligated to maintain secrecy a=
nd are not permitted to disclose the co=
ntents of this communication to others.
=
This email and any files transmitted with&nb=
sp;it are confidential and intended solely f=
or the use of the individual or entity&=
nbsp;to whom they are addressed. If you =
;have received this email in error please&nb=
sp;notify the originator of the message. Any=
 views expressed in this message are th=
ose of the individual sender.
=
This message has been scanned for viruses&nb=
sp;and Spam by ZTE Anti-Spam system.
_______________________________________________
abfab mailing = list
abfab@ietf.org
https://www.ietf.org/= mailman/listinfo/abfab

-------------------------------------------------------
<= div>Rafael Marin Lopez, PhD
Dept. Information and = Communications Engineering (DIIC)
Faculty of Computer = Science-University of Murcia
30100 Murcia - = Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
----------------------= ---------------------------------




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

-------------------------------------------------------
<= div>Rafael Marin Lopez, PhD
Dept. Information and = Communications Engineering (DIIC)
Faculty of Computer = Science-University of Murcia
30100 Murcia - = Spain
Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es
----------------------= ---------------------------------




= --Apple-Mail=_FF57D444-87A1-4CA1-BB5B-E424E27E82D8-- From rafa@um.es Mon Mar 12 06:17:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968F921F86A8 for ; Mon, 12 Mar 2012 06:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=0.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 I3GohfsklVkU for ; Mon, 12 Mar 2012 06:17:46 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6B421F8600 for ; Mon, 12 Mar 2012 06:17:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 20C4D5D498; Mon, 12 Mar 2012 14:17:45 +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 vwHNXOnRvw0S; Mon, 12 Mar 2012 14:17:44 +0100 (CET) Received: from [192.168.1.67] (28.Red-83-38-59.dynamicIP.rima-tde.net [83.38.59.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id AF97C5D499; Mon, 12 Mar 2012 14:17:43 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Mon, 12 Mar 2012 14:17:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <7E665AAF-3790-46B5-B8B0-5815DB0DD7C3@um.es> References: <7A8C5795-2904-4136-A0C7-B0451348ADB6@um.es> <35A82FAB-7E16-4A9A-B7A1-0C01F34F39A7@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1257) Cc: abfab@ietf.org Subject: Re: [abfab] gss-eap: eap identity? X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 13:17:47 -0000 Yeah, that is also fine with me. El 12/03/2012, a las 13:33, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 >> I believe it would be interesting to further analyze the general = problem, perhaps defining a problem statement and the requirements for a = fast re-authentication procedure in ABFAB. Then, we could move to the = solution space. I think this is an interesting topic. >=20 >=20 > I'm delighted to hear you're interested the fast reauth problem; I = think > it would be great to get more input into that process. I am frustrated > when people propose a formal problem statement/requirements draft. My > experience has been that these document take around a year to work > through. How about we have a couple of brainstorming sessions and > possibly a call or two to collect input on requirements from = interested > parties? I think that will capture as much value as a requirement > document with much less frustration and delay. >=20 > --Sam ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Mon Mar 12 06:40:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBD721F873D for ; Mon, 12 Mar 2012 06:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.292 X-Spam-Level: X-Spam-Status: No, score=-2.292 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 MuIopZM-r8VF for ; Mon, 12 Mar 2012 06:40:53 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D86F921F8735 for ; Mon, 12 Mar 2012 06:40:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A1F082021E; Mon, 12 Mar 2012 09:40:24 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id DCB8A4766; Mon, 12 Mar 2012 09:40:41 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <54A04086-BAAD-4B75-B6D0-4877DD415346@padl.com> Date: Mon, 12 Mar 2012 09:40:41 -0400 In-Reply-To: (Rafa Marin Lopez's message of "Mon, 12 Mar 2012 13:44:04 +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: "abfab@ietf.org" Subject: Re: [abfab] draft-wei-abfab-fcla-02 is posted (fast re-auth) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 13:40:54 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Luke: That kind of fast re-auth based on Kerberos is also Rafa> intrinsic to draft-perez-abfab-eap-gss-preauth-01 Rafa> Best regards. Rafa> El 12/03/2012, a las 13:18, Luke Howard escribi : Right. I'd prefer to focus on the Kerberos-based approaches because we have a lot of experience with them (the Moonshot implementation and your implementation) and because they seem to be rather simple. I think for the sorts of services that use ABFAB, ERP would require more infrastructure and might be more complex. Nothing precludes using ERP--it's just another EAP method after all. However for application bridging it seems like there are environments where the two directions we're already working on (gss-preauth and the reauth within Moonshot) are far more attractive. --Sam From leifj@sunet.se Mon Mar 12 08:32:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7F421F8853 for ; Mon, 12 Mar 2012 08:32:38 -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 pzwuEUdj4IZV for ; Mon, 12 Mar 2012 08:32:10 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E0CC21F8852 for ; Mon, 12 Mar 2012 08:32:10 -0700 (PDT) Received: from [10.0.1.91] (70-91-87-57-BusName-metrodr.md.hfc.comcastbusiness.net [70.91.87.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2CFW3W3017615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 12 Mar 2012 16:32:08 +0100 (CET) Message-ID: <4F5E16F3.8020101@sunet.se> Date: Mon, 12 Mar 2012 16:32:03 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] agenda for Paris X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:32:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is the agenda I'll post presently: - - Agenda Bashing and Note Well (5min) - - Document status * AAA-SAML (Josh) 20min * GSS-EAP (Sam) 20min * Use Cases and User Interface (Rhys) 15min * Fragmentation (Alejandro) 15min - - Open Mic and Technical Discussion 15min -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9eFvMACgkQ8Jx8FtbMZneV6ACgmYjvaYcmK2VM/voQNJKSwz3p n+QAoKzuRHNhdipdrdvyxp7KD3JNOdw3 =EJNw -----END PGP SIGNATURE----- From alex@um.es Mon Mar 12 08:46:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBCCC21E802A for ; Mon, 12 Mar 2012 08:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[AWL=-1.357, 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 gt4aWJ7JlYK0 for ; Mon, 12 Mar 2012 08:46:38 -0700 (PDT) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 2A34221E801E for ; Mon, 12 Mar 2012 08:46:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 315CB5D4C5; Mon, 12 Mar 2012 16:46:37 +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 9YJi7JVZRT2v; Mon, 12 Mar 2012 16:46:36 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon13.um.es (Postfix) with ESMTPSA id B756B5D471; Mon, 12 Mar 2012 16:46:36 +0100 (CET) Message-ID: <4F5E1A5C.3080209@um.es> Date: Mon, 12 Mar 2012 16:46:36 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:46:38 -0000 >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > >> Is the proxy's state required any more than the state a server > >> needs to retain for its outstanding fragmented requests? > > Alejandro> No, it should be the same. But it would be more than > Alejandro> usually required for a proxy (they usually receive, send > Alejandro> and forget). Anyway, I'm not sure that is actually a big > Alejandro> issue. I was just asking if it was. > > I'm greatful that you're trying to explore this issue because I think it > gets at the core of Jim's question. > I don't know if the state required is too much. Here are my thoughts: > > 1) It makes rewriting SAML requests significantly more effort than > rewriting RADIUS attributes. That said, there are a number of ways > (needing a SAML library, possibly needing to resign or strip signatures) > where a SAML rewrite is harder for a RADIUS server than a RADIUS > rewrite. > However this increases state not just adding new libraries. > > 2) It wouldn't surprise me if proxies near an RP handled similar volumes > of requests as home servers or proxies near an IDP. > > 3) In a proxy fabric deployment it wouldn't surprise me if proxies in > the middle of a federation handle significantly more volume than proxies > near the edges. > > > 4) In the Moonshot deployment we're hoping to avoid proxy fabric and use > trust router, so we're hoping that any proxy-like entities in the middle > will not see individual requests. I think implicit in that is an > assumption that attributes of individual requests will not need to be > rewritten in the middle. That's exactly my point. The more important question is: do we really need SAML rewrite at AAA proxies? I don't see the point, specially if that can happen in any point of the path. Regards, Alejandro > > 5) The effort required for this sort of rewrite is very similar to the > effort required to map from SAML and other authorization languages to > Kerberos in the gss-preauth/eap-preauth cases on the RP's KDC. > > In conclusion, I'd be happy if we had more data on use cases and > performance requirements for proxy rewriting. From hartmans@painless-security.com Mon Mar 12 08:55:50 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8B421E8048 for ; Mon, 12 Mar 2012 08:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ShLrFpUFrCzY for ; Mon, 12 Mar 2012 08:55:49 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E0E9A21F871C for ; Mon, 12 Mar 2012 08:55:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 0742D2024B; Mon, 12 Mar 2012 11:55:21 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7A8464766; Mon, 12 Mar 2012 11:55:37 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> Date: Mon, 12 Mar 2012 11:55:37 -0400 In-Reply-To: <4F5E1A5C.3080209@um.es> (Alejandro Perez Mendez's message of "Mon, 12 Mar 2012 16:46:36 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 15:55:50 -0000 Well, I think you may well need SAML rewrite at AAA proxies if you don't have something like Kerberos. Attribute remapping at organizational boundaries seems like something people will want. From alex@um.es Mon Mar 12 09:07:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E65EA21F87D1 for ; Mon, 12 Mar 2012 09:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.366 X-Spam-Level: X-Spam-Status: No, score=-6.366 tagged_above=-999 required=5 tests=[AWL=0.233, 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 QA3OguTYApt6 for ; Mon, 12 Mar 2012 09:07:27 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 0D64E21F87D0 for ; Mon, 12 Mar 2012 09:07:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 4747053623; Mon, 12 Mar 2012 17:07:26 +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 7xubiftLqytF; Mon, 12 Mar 2012 17:07:26 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id ED7B9535FE; Mon, 12 Mar 2012 17:07:25 +0100 (CET) Message-ID: <4F5E1F3D.5090909@um.es> Date: Mon, 12 Mar 2012 17:07:25 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:07:29 -0000 > Well, I think you may well need SAML rewrite at AAA proxies if you don't > have something like Kerberos. > > Attribute remapping at organizational boundaries seems like something > people will want. But that does not happen at the intermediary AAA proxies, as they are not interested on the information being transmitted. It should happend at both ends of the communication, or at a close point. And likely it will happend once at much for each assertion. Am I wrong? Regards, Alejandro From hartmans@painless-security.com Mon Mar 12 09:42:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE9021E8048 for ; Mon, 12 Mar 2012 09:42:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 dEPIGP2mUBhH for ; Mon, 12 Mar 2012 09:42:53 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 96D0D21E8045 for ; Mon, 12 Mar 2012 09:42:53 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4E0E02024B; Mon, 12 Mar 2012 12:42:28 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 92E284766; Mon, 12 Mar 2012 12:42:45 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> Date: Mon, 12 Mar 2012 12:42:45 -0400 In-Reply-To: <4F5E1F3D.5090909@um.es> (Alejandro Perez Mendez's message of "Mon, 12 Mar 2012 17:07:25 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 16:42:54 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: >> Well, I think you may well need SAML rewrite at AAA proxies if >> you don't have something like Kerberos. >> >> Attribute remapping at organizational boundaries seems like >> something people will want. Alejandro> But that does not happen at the intermediary AAA proxies, Alejandro> as they are not interested on the information being Alejandro> transmitted. It should happend at both ends of the Alejandro> communication, or at a close point. And likely it will Alejandro> happend once at much for each assertion. Am I wrong? Right. I don't think that core proxies need to be involved in rewrite. From hartmans@mit.edu Mon Mar 12 15:00:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E62321E8106 for ; Mon, 12 Mar 2012 15:00:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 aIyzWZ-jJ755 for ; Mon, 12 Mar 2012 15:00:26 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D900A21E804D for ; Mon, 12 Mar 2012 15:00:25 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 39C4A2021E; Mon, 12 Mar 2012 18:00:00 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 50F704769; Mon, 12 Mar 2012 18:00:17 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Mon, 12 Mar 2012 18:00:17 -0400 In-Reply-To: (Scott Cantor's message of "Mon, 28 Nov 2011 20:58:39 +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: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 22:00:29 -0000 Scott, thanks for the proposed text regarding name attributes. In your original text you proposed to mandate that the display form of SAML attributes should be UTF-8 encoded. I agree that's reasonable for the raw form but I'm not actually sure that we should standardize that for the display form. I'd appreciate comments from the WG, especially from Nico, Leif and others who have worked on the base naming extensions spec. I'm wondering for example whether implementations will want to present display names in the local character set of the current system locale for hosted environments that have such. From cantor.2@osu.edu Mon Mar 12 16:18:37 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F164421F8B33 for ; Mon, 12 Mar 2012 16:18: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 3wOowCUk3vSu for ; Mon, 12 Mar 2012 16:18:36 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0F421F8B32 for ; Mon, 12 Mar 2012 16:18:36 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2CNIYMo004659; Mon, 12 Mar 2012 19:18:34 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.01.0355.002; Mon, 12 Mar 2012 19:18:34 -0400 From: "Cantor, Scott" To: Sam Hartman Thread-Topic: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 Thread-Index: AQHMreeEDu2VuDvkVUuL1dXPCIhnW5XCdmWAgABbXYD//7AAgIAAVjeA///tOYCApRYVi4AAFhwA Date: Mon, 12 Mar 2012 23:18:33 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [71.74.80.179] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Columbus; postalcode=43201; latitude=39.9930; longitude=-82.9985; metrocode=535; areacode=614; http://maps.google.com/maps?q=39.9930,-82.9985&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:18:37 -0000 On 3/12/12 6:00 PM, "Sam Hartman" wrote: >Scott, thanks for the proposed text regarding name attributes. >In your original text you proposed to mandate that the display form of >SAML attributes should be UTF-8 encoded. I agree that's reasonable for >the raw form but I'm not actually sure that we should standardize that >for the display form. I'm working with an absence of understanding of exactly how the display form would be used, but my experience with XML data in general is that sticking with UTF-8 where possible tends to keep things simpler, since an application can always do whatever converting it wants to from that baseline. But in a related question, wouldn't it be bad to have different name attributes expressing themselves in either raw or display form with different encodings? How would the application know what the encoding was meant to be in each case? -- Scott From ietf@augustcellars.com Mon Mar 12 16:29:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 525AF21F8A06 for ; Mon, 12 Mar 2012 16:29:02 -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 FDu2jGI9PcpD for ; Mon, 12 Mar 2012 16:29:01 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 4262221E81B0 for ; Mon, 12 Mar 2012 16:28:59 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 944482CA2C; Mon, 12 Mar 2012 16:28:57 -0700 (PDT) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , "'Sam Hartman'" References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> In-Reply-To: <4F5E1F3D.5090909@um.es> Date: Mon, 12 Mar 2012 16:28:08 -0700 Message-ID: <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDNHPJXnRNudUwKAHwUV1skxOAxCwHX+tEvAeRn0gABnLtYsgIyq6+zAeE7zx8CneIZzQHwW0QiAfg1o/mX53i3cA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:29:02 -0000 Remapping of attributes is something that Plasma is going to want. =20 I don't know that this is restricted to just on at either end. I think = that it may possibly happen any time you cross any type of federation = boundary. How attributes are portrayed and represented and if they have = any significance is going to depend on the federation agreement. I = think that on will generally be uninterested in the proxies that occur = inside of a federation. =20 When looking at what Moonshot is doing, I think that the trust router = will skip right to the cross-boundary federation proxies that will need = to potentially do the re-writing and thus it is an issue for all such = proxy agents. Also I think that the re-writes will be done in both directions. If you = do a query from the RP to the IdP, then the attributes you are asking = for change as you cross the federation boundaries. And the response of = the query needs to be modified as it comes back so that the RP can = understand what is happening. While it would be ideal if this only = happens at the end points, I fully expect in any type of complex = federation it would happen in the middle as well. Jim > -----Original Message----- > From: Alejandro Perez Mendez [mailto:alex@um.es] > Sent: Monday, March 12, 2012 9:07 AM > To: Sam Hartman > Cc: Josh Howlett; Jim Schaad; abfab@ietf.org > Subject: Re: [abfab] FYI: New Version Notification for = draft-perez-radext- > radius-fragmentation-01.txt >=20 >=20 > > Well, I think you may well need SAML rewrite at AAA proxies if you > > don't have something like Kerberos. > > > > Attribute remapping at organizational boundaries seems like = something > > people will want. >=20 > But that does not happen at the intermediary AAA proxies, as they are = not > interested on the information being transmitted. It should happend at = both > ends of the communication, or at a close point. And likely it will = happend > once at much for each assertion. Am I wrong? >=20 > Regards, > Alejandro From internet-drafts@ietf.org Mon Mar 12 16:29:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB29921E81E8; Mon, 12 Mar 2012 16:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 a7TBZwD9Ux0P; Mon, 12 Mar 2012 16:29:12 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3618021E81B0; Mon, 12 Mar 2012 16:29:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.00 Message-ID: <20120312232912.18646.9087.idtracker@ietfa.amsl.com> Date: Mon, 12 Mar 2012 16:29:12 -0700 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-02.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:29:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Application Bridging for Federated Ac= cess Beyond web Working Group of the IETF. Title : Name Attributes for the GSS-API EAP mechanism Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-naming-02.txt Pages : 14 Date : 2012-03-12 The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-naming-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-abfab-gss-eap-naming-02.txt From hartmans@painless-security.com Mon Mar 12 16:35:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4F421E8219 for ; Mon, 12 Mar 2012 16:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 yEAT9yu8FhLp for ; Mon, 12 Mar 2012 16:35:46 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id AA86121E8210 for ; Mon, 12 Mar 2012 16:35:46 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id F1C2E2021E for ; Mon, 12 Mar 2012 19:35:18 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3DE6A4767; Mon, 12 Mar 2012 19:35:35 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Mon, 12 Mar 2012 19:35:35 -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: [abfab] Defeated by IANA X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:35:47 -0000 Hi folks. I've submitted version of gss-eap-naming and gss-eap. To my knowledge the following open issues exist: #32 (gss-eap): radius iana considerations are placeholders xx (not submitted gss-eap-naming): URN IANA considerations are a placeholder. I've bitten off somewhat more than I choose to chew in terms of IETF draft load. And I don't particularly like IANA considerations sections, and it shows from the above. However, I'd really love to see these last called. So, chairs permitting I'll submit new versions with the IANA considerations filled in correctly as soon as the draft window opens up. Now, I'd really appreciate reviews and people commenting on the changes. I think I've done the things we agreed at the last meeting and I'm quite happy with the overall quality of these drafts. I'd really like to thank Scott, Diego, Jim, Alexey, Josh, Alex, the chairs and anyone I've forgotten who has contributed. Your help has been important to getting where we are. I'm excited because I think we've made a lot of progress and I want to see us send some documents to the IESG. I realize we need to get done with the IANA considerations, chairs need to decide we're done, we need to last call before that can happen. However I'm happy that we are making significant steady progress! I'm also happy we're making significant progress on our external dependencies. Naming extensions is moving along in kitten and channel bindings is moving along in EMU. --Sam From hartmans@painless-security.com Mon Mar 12 16:38:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE55321E8224; Mon, 12 Mar 2012 16:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 1IyPKOXqqhYg; Mon, 12 Mar 2012 16:38:15 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D244021E8222; Mon, 12 Mar 2012 16:38:14 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 3162C2024B; Mon, 12 Mar 2012 19:37:49 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6C6FF4767; Mon, 12 Mar 2012 19:38:05 -0400 (EDT) From: Sam Hartman To: kitten@ietf.org,abfab@ietf.org Date: Mon, 12 Mar 2012 19:38:05 -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: [abfab] URN prefixes for draft-ietf-abfab-gss-eap-naming X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:38:16 -0000 So last time around I said I'd put together a straw man for the name attribute prefixes for the GSS EAP mechanism in ABFAB and things like SAML EC in KITTEN. I asked for input and got suggestions like "use OIDs instead," after we spent months deciding to use URIs. I'm proposing things like urn:ietf:params:gss:fed-saml-assertion (for a saml assertion in the federated context) Please see section 5 and 6 of the most recent draft-ietf-abfab-gss-eap-naming. Comments welcome. From hartmans@painless-security.com Mon Mar 12 16:41:29 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8259321E8237 for ; Mon, 12 Mar 2012 16:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 39PERPWcqbvG for ; Mon, 12 Mar 2012 16:41:29 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0518321E823D for ; Mon, 12 Mar 2012 16:41:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 55ECF2021E; Mon, 12 Mar 2012 19:41:03 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7621F4767; Mon, 12 Mar 2012 19:41:19 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: Date: Mon, 12 Mar 2012 19:41:19 -0400 In-Reply-To: (Scott Cantor's message of "Mon, 12 Mar 2012 23:18:33 +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: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:41:29 -0000 >>>>> "Cantor," == Cantor, Scott writes: Cantor,> I'm working with an absence of understanding of exactly how Cantor,> the display form would be used, but my experience with XML Cantor,> data in general is that sticking with UTF-8 where possible Cantor,> tends to keep things simpler, since an application can Cantor,> always do whatever converting it wants to from that Cantor,> baseline. Me too. I'm not really sure what you'd do with the display form other than dump into a debug log. I was hoping to get input from those who added the display form to the API. Cantor,> But in a related question, wouldn't it be bad to have Cantor,> different name attributes expressing themselves in either Cantor,> raw or display form with different encodings? How would the Cantor,> application know what the encoding was meant to be in each Cantor,> case? That's part of my concern. I'm wondering whether the display form is expected to have encoding under the implementation's control rather than under the attribute's control? I really don't know what the right answer is. I've left it unspecified in the current version and will be happy to change that if we figure out what should be done there. From hartmans@painless-security.com Mon Mar 12 16:46:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBECA21E8257 for ; Mon, 12 Mar 2012 16:46:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 zauaYhzz8KP8 for ; Mon, 12 Mar 2012 16:46:22 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4A80F21E8255 for ; Mon, 12 Mar 2012 16:46:22 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A1FCF2021E; Mon, 12 Mar 2012 19:45:56 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2CD874767; Mon, 12 Mar 2012 19:46:12 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> Date: Mon, 12 Mar 2012 19:46:12 -0400 In-Reply-To: <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> (Jim Schaad's message of "Mon, 12 Mar 2012 16:28:08 -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: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2012 23:46:22 -0000 >>>>> "Jim" == Jim Schaad writes: OK. So, I think we need to figure out what the performance characteristics are and whether your proxies can afford to hold the sort of state we're talking about. In the trust router model you definitely can skip to boundary proxies that "need" to be men-in-the-middle. From nico@cryptonector.com Mon Mar 12 23:34:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC621F87F7 for ; Mon, 12 Mar 2012 23:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.204 X-Spam-Level: X-Spam-Status: No, score=-2.204 tagged_above=-999 required=5 tests=[AWL=-0.227, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 1SOywfQMero9 for ; Mon, 12 Mar 2012 23:34:55 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcagg.dreamhost.com [208.97.132.66]) by ietfa.amsl.com (Postfix) with ESMTP id 18C2C21F87F2 for ; Mon, 12 Mar 2012 23:34:55 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id BA0111F007C for ; Mon, 12 Mar 2012 23:34:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=LvdJ7/WmOpC4Fz+wpaJks0SA7vt1YF7cZdFLRf1euLFO TCFTyG3b838e13z18x+PsRiA+p+IXlq2WndDAsJ7Ej8HV4hYTVi2mvnzh190teWD uMU15fO5J3ONA8sqh+ByxtTHYq0ivmphlPlstgD+Qn0PJxip8axkaQRv3XNlb48= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=7bwVjuYakZ+AUISNJY6V/6Cb1Ns=; b=umpy3d56hQH PR/ZowpTllMF1eLOJyZzbBtnICc98bKnoMqw+HVKGN6W3fUS1FV+xbX7CUxAk56g cP/Juq2+5IFFRcfm3eAqeVFvyvtQsp+sftBvjqo/MeJq24032emGZr1aNZR2PPBd 0U3kPs8dIhMvh/4IBu+LtW6gGJwQfPuA= Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id 96BC31F001E for ; Mon, 12 Mar 2012 23:34:54 -0700 (PDT) Received: by iazz13 with SMTP id z13so405454iaz.31 for ; Mon, 12 Mar 2012 23:34:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.192.100 with SMTP id hf4mr5017613pbc.118.1331620493885; Mon, 12 Mar 2012 23:34:53 -0700 (PDT) Received: by 10.68.28.6 with HTTP; Mon, 12 Mar 2012 23:34:53 -0700 (PDT) In-Reply-To: References: Date: Tue, 13 Mar 2012 01:34:53 -0500 Message-ID: From: Nico Williams To: Sam Hartman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on draft-ietf-abfab-gss-eap-naming-01 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 06:34:56 -0000 On Mon, Mar 12, 2012 at 6:41 PM, Sam Hartman wrote: >>>>>> "Cantor," =3D=3D Cantor, Scott writes: > > =C2=A0 =C2=A0Cantor,> I'm working with an absence of understanding of exa= ctly how > =C2=A0 =C2=A0Cantor,> the display form would be used, but my experience w= ith XML > =C2=A0 =C2=A0Cantor,> data in general is that sticking with UTF-8 where p= ossible > =C2=A0 =C2=A0Cantor,> tends to keep things simpler, since an application = can > =C2=A0 =C2=A0Cantor,> always do whatever converting it wants to from that > =C2=A0 =C2=A0Cantor,> baseline. > > > Me too. > I'm not really sure what you'd do with the display form other than dump > into a debug log. > > I was hoping to get input from those who added the display form to the > API. I did that. It was in the original. It was intended for tools like, say, a GSS version of klist (hand waiving). Now, the GSS-API specifies somewhere that it deals in Latin-1. Clearly we're NOT going to have consensus on using Latin-1 as that's just ridiculous. UTF-8 would certainly be a lot better than "unspecified" or "Latin-1", but I think in practice applications that care for display forms of attribute values will want something that is in the current locale's codeset. I'd be OK with saying these must be UTF-8, and I'd be OK with saying these must be in the application's locale's codeset. Applications that need to send these display forms over the wire (e.g., in log messages) will want UTF-8. Applications displaying these in UIs will want the current locale's codeset. In the interest of speeding a consensus I'll go with UTF-8. Nico -- From leifj@mnt.se Tue Mar 13 13:21:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 142D521F8611 for ; Tue, 13 Mar 2012 13:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.212 X-Spam-Level: X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=-1.388, BAYES_00=-2.599, FRT_XANAX1=2.775] 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 HtroSqZlQa9I for ; Tue, 13 Mar 2012 13:21:33 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id DD4B921F860F for ; Tue, 13 Mar 2012 13:21:32 -0700 (PDT) Received: from [129.6.252.156] ([129.6.252.156]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2DKLQvM008781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 13 Mar 2012 21:21:31 +0100 (CET) Message-ID: <4F5FAC45.1020801@mnt.se> Date: Tue, 13 Mar 2012 21:21:25 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Defeated by IANA X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Mar 2012 20:21:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > However, I'd really love to see these last called. So, chairs > permitting I'll submit new versions with the IANA considerations > filled in correctly as soon as the draft window opens up. The chairs will certainly not hold IANA (or much of anything else for that matter) against you. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9frEUACgkQ8Jx8FtbMZneFnQCeIyqTn0mRq78Sy15MAJ3O65PV xJYAoJ8vHkFn9vDUZfYm+xGgnjgCx+KL =YEn1 -----END PGP SIGNATURE----- From ietf@augustcellars.com Wed Mar 14 20:21:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157D221F8698 for ; Wed, 14 Mar 2012 20:21:34 -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 AmNuLZuPoipy for ; Wed, 14 Mar 2012 20:21:34 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6209E21F869C for ; Wed, 14 Mar 2012 20:21:34 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 8403438F00; Wed, 14 Mar 2012 20:21:27 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" , "Alan DeKok" References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> In-Reply-To: Date: Wed, 14 Mar 2012 20:20:31 -0700 Message-ID: <000701cd025a$9cfb9ce0$d6f2d6a0$@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: AQDNHPJXnRNudUwKAHwUV1skxOAxCwHX+tEvAeRn0gABnLtYsgIyq6+zAeE7zx8CneIZzQHwW0QiAfg1o/kCicRlngIy0JQel8T4THA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 03:21:35 -0000 Alan, Do you have any data which we could start getting some data about how proxies are currently used. 1. How many places are there were we see transitions from Diameter to RADIUS or vice versa? These would be places where we already have a situation where messages might need to be fragmented because of the different sizes of packets. 2. Are you aware of any places where information needs to be translated as they go past proxies in the manner we are talking about where things cross federation boundaries and the data needs to be either validated or modified to fit how the federation thinks about the data? 3. How much routing data is placed into packets today in semi-complex arrangements by proxies? How many of them cache the data locally for the return trip rather than just append data to the message? Jim > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Monday, March 12, 2012 4:46 PM > To: Jim Schaad > Cc: 'Alejandro Perez Mendez'; 'Josh Howlett'; abfab@ietf.org > Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext- > radius-fragmentation-01.txt > > >>>>> "Jim" == Jim Schaad writes: > > > > OK. So, I think we need to figure out what the performance characteristics > are and whether your proxies can afford to hold the sort of state we're > talking about. > > In the trust router model you definitely can skip to boundary proxies that > "need" to be men-in-the-middle. From ietf@augustcellars.com Wed Mar 14 22:41:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA16321F86FC for ; Wed, 14 Mar 2012 22:41: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=[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 lxKCBpnE5Pa0 for ; Wed, 14 Mar 2012 22:41:11 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1655721F86F7 for ; Wed, 14 Mar 2012 22:41:11 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 D57E438EF0; Wed, 14 Mar 2012 22:40:47 -0700 (PDT) From: "Jim Schaad" To: "Sam Hartman" , References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> In-Reply-To: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> Date: Wed, 14 Mar 2012 22:39:23 -0700 Message-ID: <000801cd026e$19e4b710$4dae2530$@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: AQLr+32EzPhx8XDlot9yxh/WPNQDppQsvtqg Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 05:41:12 -0000 Comments on the current version of the document. First let me say that overall I am very happy with the state of this document. It is slightly repetitive, but is very clear about what happens when and where. I believe that I now have a clear understanding of how I would go about using SAML statements in Plasma by starting with using the Authentication Profile and then following it up with generic queries using the identity that was returned in the Authentication response. Jim Major 1. Do we have any other examples where we might have a SAML requester/responder other than the case of the RP/IdP? If so, it might be wise to mention at least one other case in the introductory paragraph in section 1. Otherwise it might be easier to just say that we are sending messages between the RP and the IdP and not generalize it. Can anybody see a reason that one might want to reverse the endpoints? So that the RP becomes the server and the IdP the client??? 2. In section 3, I would suggest adding the text "There MUST be at most one SAML-Message Attribute in either a RADIUS request or response message." 3. In section 4.1 and 5.1, the Identification will require an IANA action. I think we are looking at urn:ietf:params:xml:ns:abfab: I think that something probably looks like SAML:binding:RADIUS-binding in section 4.1. The contact information should be iesg@ietf.org. I don't see any requirement that the binding should be specific to the RADIUS transport - do you? 4. In section 4.2 item #2 - If the SAML responder is going to response to a SAML request, is there a requirement that the responder MUST response no later than the Access-Accept or Access-Reject message? Also what other currently defined packets is the element permitted in - for example can I include it in an Access-Challenge packet? 5. In section 5.2 - Section on Responses: - I am confused when I read this text. It first says that you must return exactly one authentication statement. It then says that the IdP can return other statements in the assertion. Are these other assertions allowed to be authentication statements or are they some other type of statement? 6. The last sentence in section 5.2 makes no sense to me. I believe the sentence should finish "to a Relying Part without step 2 occurring." Doing it without having the EAP protocol run in section 3 would be bad news. Ditto the last paragraph in section 5.3 - I think it should just say that "The Request in section 5.3.2 is omitted from the process." 7. In section 5.3.4 - I would like to see a statement that in this profile, if the is marked as fail then the EAP should also return fail. That is there should not be difference in the returned value for the SAML request and the EAP dialog. 8. In section 5.4.1 paragraph 3 - I am not sure how this section interacts with the ability of an IdP to return a Pseudonymous identifier. Are you stating that the identifier must already exist, or just that the policy for creating the identifier must already exist in the case AllowCreate is set to "false". 9. In section 5.4.1 last paragraph - I think we should make some type of statement about what happens if either the request is not signed, or the signature on the request cannot be validated by the IdP. I think that both of these cases are going to be more likely that the case of it is signed and the IdP happens to be able to validate the signature. 10. I believe that a discussion of what is expected to happen as these messages cross federation boundaries is probably in order. Nits 1. We need to get a consistent method of doing Abfab or ABFAB. I have always used all upper case, this document is doing mixed case. We should be consistent and I think the all upper case is the normal way. Please change. 2. I object to the capitalization in the following sentence "The NAI SHOULD be used to route the message towards the SAML responder, which MAY be more than one RADIUS hop distant." How are these requirements on the binding that is being produced? Are these not intrinsic properties that are true just by saying that we are using RAIDUS? 3. There is an extraneous period in the last sentence of section 5.3.3 4. Bad grammar /confirmation as the processing as defined in/ I don't know what this should be. 5. Please add http links to your SAML references so I don't have to search for them - I am very lazy. 6. Can we move some of the references out of normative? For example I think that 3575 could be informative since it affects only the document writer and not the implementer. The same is probably true for some of the other references. s/reponse/response/ s/Consequently here exists/Consequently there exists/ s/unsolicited responser/unsolicited response/ s/disgression/discretion/ From ietf@augustcellars.com Wed Mar 14 23:41:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0AE21F8782 for ; Wed, 14 Mar 2012 23:41:35 -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 8JSPm7N40CH3 for ; Wed, 14 Mar 2012 23:41:34 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8447A21F877F for ; Wed, 14 Mar 2012 23:41:34 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 96F102CA0B; Wed, 14 Mar 2012 23:41:22 -0700 (PDT) From: "Jim Schaad" To: , "Hannes Tschofenig" Date: Wed, 14 Mar 2012 23:39:54 -0700 Message-ID: <000f01cd0276$8cd63f20$a682bd60$@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: Ac0CdeeIwSuS+DEQTmShJW7z2Jm1dA== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] draft-jones-diameter-abfab-00 question X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 06:41:35 -0000 I will state upfront that I know less about diameter than I do about Radius so the questions I have are to be taken with that grain of salt. 1. Is it possible to include a more general SAML query than just an authorization request in a DER message? Specifically, I would like to be able to query for a set of attributes about the entity that was authorized as oppose to get the fact they are authorized. 2. Does Diameter give any way of sending the keys around that are to be used for doing the xml encryption operation? I understand that diameter is more point-to-point than RADIUS but I do not know that to be a fact. Does this mean that there is more likely to have end-to-end signing and encryption capabilities present? 3. Is there a concept of proxies that sit on boundaries that could modify the SAML constructs to deal with mapping of attributes? Jim From hannes.tschofenig@nsn.com Thu Mar 15 00:10:58 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 603F121F8545 for ; Thu, 15 Mar 2012 00:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.402 X-Spam-Level: X-Spam-Status: No, score=-106.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v2vF5PQ7yIuj for ; Thu, 15 Mar 2012 00:10:57 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 345CF21F853E for ; Thu, 15 Mar 2012 00:10:57 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id q2F7Aoul008849 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 15 Mar 2012 08:10:50 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id q2F7Ai0j021910; Thu, 15 Mar 2012 08:10:49 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 15 Mar 2012 08:10:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 Mar 2012 09:10:42 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D01382874@FIESEXC035.nsn-intra.net> In-Reply-To: <000f01cd0276$8cd63f20$a682bd60$@augustcellars.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [abfab] draft-jones-diameter-abfab-00 question Thread-Index: Ac0CdeeIwSuS+DEQTmShJW7z2Jm1dAABAdBw References: <000f01cd0276$8cd63f20$a682bd60$@augustcellars.com> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Jim Schaad" , , "Hannes Tschofenig" X-OriginalArrivalTime: 15 Mar 2012 07:10:44.0060 (UTC) FILETIME=[BCCF99C0:01CD027A] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2203 X-purgate-ID: 151667::1331795450-000033AC-02B6601F/0-0/0-0 Cc: abfab@ietf.org Subject: Re: [abfab] draft-jones-diameter-abfab-00 question X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 07:10:58 -0000 Hi Jim,=20 > I will state upfront that I know less about diameter than I do about > Radius > so the questions I have are to be taken with that grain of salt. >=20 > 1. Is it possible to include a more general SAML query than just an > authorization request in a DER message? Specifically, I would like to > be > able to query for a set of attributes about the entity that was > authorized > as oppose to get the fact they are authorized. Yes, this is possible.=20 Some problems we are dealing with in RADIUS, such as the fragmentation issue, does not exist in Diameter due to the TCP transport.=20 >=20 > 2. Does Diameter give any way of sending the keys around that are to > be > used for doing the xml encryption operation? I understand that > diameter is > more point-to-point than RADIUS but I do not know that to be a fact. > Does > this mean that there is more likely to have end-to-end signing and > encryption capabilities present? Diameter also exchanges keys in the same manner as RADIUS does. This is, for example, used for the Diameter EAP application. These keys are, however, secured only in a hop-by-hop fashion (and not end-to-end; the ends are Diameter client and Diameter server).=20 Currently, there is no standard for e2e AVP encryption in Diameter natively although there are discussions ongoing to do some work in the DIME working group. Two relevant contributions for that matter are:=20 http://datatracker.ietf.org/doc/draft-korhonen-dime-e2e-security/ http://datatracker.ietf.org/doc/draft-zorn-dime-n2n-sec-lite/ (Note that the scope of the two drafts is a bit different.) >=20 > 3. Is there a concept of proxies that sit on boundaries that could > modify > the SAML constructs to deal with mapping of attributes? There are proxies in Diameter but what they specifically do with certain AVPs depends very much on the application. The document I have submitted describes such an application but does not describe such operation.=20 Ciao Hannes >=20 > Jim >=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From alex@um.es Thu Mar 15 01:05:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0C821F862A for ; Thu, 15 Mar 2012 01:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.38 X-Spam-Level: X-Spam-Status: No, score=-6.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 VP-gz6mvuob5 for ; Thu, 15 Mar 2012 01:05:25 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 5D25221F8629 for ; Thu, 15 Mar 2012 01:05:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 255215D4A4 for ; Thu, 15 Mar 2012 09:05:21 +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 EVU86AU6f5e3 for ; Thu, 15 Mar 2012 09:05:16 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id C42C65D4D0 for ; Thu, 15 Mar 2012 09:05:15 +0100 (CET) Message-ID: <4F61A2BB.5070408@um.es> Date: Thu, 15 Mar 2012 09:05:15 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> In-Reply-To: <000801cd026e$19e4b710$4dae2530$@augustcellars.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 08:05:26 -0000 > Comments on the current version of the document. > > First let me say that overall I am very happy with the state of this > document. It is slightly repetitive, but is very clear about what happens > when and where. I believe that I now have a clear understanding of how I > would go about using SAML statements in Plasma by starting with using the > Authentication Profile and then following it up with generic queries using > the identity that was returned in the Authentication response. > > Jim > > > Major > > 1. Do we have any other examples where we might have a SAML > requester/responder other than the case of the RP/IdP? If so, it might be > wise to mention at least one other case in the introductory paragraph in > section 1. Otherwise it might be easier to just say that we are sending > messages between the RP and the IdP and not generalize it. Can anybody see > a reason that one might want to reverse the endpoints? So that the RP > becomes the server and the IdP the client??? > > 2. In section 3, I would suggest adding the text "There MUST be at most one > SAML-Message Attribute in either a RADIUS request or response message." It is almost impossible to fit a entire SAML message into a single SAML-Message attribute (253 bytes), so almost always there will be more than on SAML-Message attribute in both, RADIUS requests and responses when transporting SAML data. All these attributes are part of the same extended fragmented attribute, but section 3 is talking about the basic RADIUS attribute. Note that this draft has not yet adopted extended attributes format. If your intention was to suggest that no more than 1 SAML Message MUST be included per RADIUS packet, I'm not sure to agree either. At least, I do not see a clear motivation for such limitation. > > 3. In section 4.1 and 5.1, the Identification will require an IANA action. > I think we are looking at urn:ietf:params:xml:ns:abfab: > I think that something probably looks like SAML:binding:RADIUS-binding in > section 4.1. The contact information should be iesg@ietf.org. I don't see > any requirement that the binding should be specific to the RADIUS transport > - do you? > > 4. In section 4.2 item #2 - If the SAML responder is going to response to a > SAML request, is there a requirement that the responder MUST response no > later than the Access-Accept or Access-Reject message? Also what other > currently defined packets is the element permitted in - for example can I > include it in an Access-Challenge packet? That's an interesting question. In a previous discussion we were thinking on moving all the authorization data retrieval exchanges _after_ the Access-Accept exchange. I think Josh already shown interest on changing to that kind of flow, though I guess until radius-fragmentation draft moves a little forward this need to be hold on. The basic idea would be to perform the EAP authentication without SAML exchanges. Within the Access-Accept, the RADIUS server provides a State attribute and the service-type would be Authorize-Only, indicationg further authorization need to be performed. Then the RP sends the SAML Authn Req and the IdP provides the SAML Assertion. This way both authentication and attribute retrieval follow the same exchange pattern. > > 5. In section 5.2 - Section on Responses: - I am confused when I read this > text. It first says that you must return exactly one authentication > statement. It then says that the IdP can return other statements in the > assertion. Are these other assertions allowed to be authentication > statements or are they some other type of statement? Other type of statement, for example, attribute statement. > > 6. The last sentence in section 5.2 makes no sense to me. I believe the > sentence should finish "to a Relying Part without step 2 occurring." Doing > it without having the EAP protocol run in section 3 would be bad news. > Ditto the last paragraph in section 5.3 - I think it should just say that > "The Request in section 5.3.2 is omitted from the process." > > 7. In section 5.3.4 - I would like to see a statement that in this profile, > if the is marked as fail then the EAP should also > return fail. That is there should not be difference in the returned value > for the SAML request and the EAP dialog. IMO this is not required. EAP is meant to provide authentication, while SAML is intended to provide authorization. A principal may be succesfuly authenticated, but fail to obtain authorization information. One process should not interfere in the other. Think that a RP may not issue the AuthnReq. Besides, if the RADIUS server and the IdP are not collocated, I do not think it is a good idea to trick the EAP stack in the RADIUS server to force an EAP failure if the IdP replies with an SAML error. > > 8. In section 5.4.1 paragraph 3 - I am not sure how this section interacts > with the ability of an IdP to return a Pseudonymous identifier. Are you > stating that the identifier must already exist, or just that the policy for > creating the identifier must already exist in the case AllowCreate is set to > "false". > > 9. In section 5.4.1 last paragraph - I think we should make some type of > statement about what happens if either the request is not signed, or the > signature on the request cannot be validated by the IdP. I think that both > of these cases are going to be more likely that the case of it is signed and > the IdP happens to be able to validate the signature. I think a general statement must be included saying that if SAML messages/assertion are not singed, authenticity and integrity protection are implicitly provided by the AAA infrastructure. If signatures are provided, they have precedence. > > 10. I believe that a discussion of what is expected to happen as these > messages cross federation boundaries is probably in order. > > Nits > > 1. We need to get a consistent method of doing Abfab or ABFAB. I have > always used all upper case, this document is doing mixed case. We should be > consistent and I think the all upper case is the normal way. Please change. Agree > > 2. I object to the capitalization in the following sentence "The NAI SHOULD > be used to route the > message towards the SAML responder, which MAY be more than one > RADIUS hop distant." How are these requirements on the binding that > is being produced? Are these not intrinsic properties that are true just by > saying that we are using RAIDUS? > > 3. There is an extraneous period in the last sentence of section 5.3.3 > > 4. Bad grammar /confirmation as the processing as defined in/ I don't know > what this should be. > > 5. Please add http links to your SAML references so I don't have to search > for them - I am very lazy. > > 6. Can we move some of the references out of normative? For example I > think that 3575 could be informative since it affects only the document > writer and not the implementer. The same is probably true for some of the > other references. > > s/reponse/response/ > s/Consequently here exists/Consequently there exists/ > s/unsolicited responser/unsolicited response/ > s/disgression/discretion/ > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From aland@deployingradius.com Thu Mar 15 04:57:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D09921F86AA for ; Thu, 15 Mar 2012 04:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Fqq4YE0oXQV for ; Thu, 15 Mar 2012 04:57:21 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id BF66F21F86A0 for ; Thu, 15 Mar 2012 04:57:20 -0700 (PDT) Received: from thor.lan (206-248-130-83.dsl.teksavvy.com [206.248.130.83]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 0BD2512344CE; Thu, 15 Mar 2012 12:56:50 +0100 (CET) Message-ID: <4F61D901.10004@deployingradius.com> Date: Thu, 15 Mar 2012 07:56:49 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> In-Reply-To: <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 11:57:21 -0000 Jim Schaad wrote: > Do you have any data which we could start getting some data about how > proxies are currently used. I have opinions, but getting *public* data is difficult. > 1. How many places are there were we see transitions from Diameter to > RADIUS or vice versa? These would be places where we already have a > situation where messages might need to be fragmented because of the > different sizes of packets. I don't see many RADIUS to Diameter gateways. > 2. Are you aware of any places where information needs to be translated as > they go past proxies in the manner we are talking about where things cross > federation boundaries and the data needs to be either validated or modified > to fit how the federation thinks about the data? Yes. Many roaming providers go through integrators. Those integrators take care of mangling packets back & forth. This is one of the value-adds of the integrator. They present a uniform RADIUS framework to the home servers, by normalizing the weird things produced by each roaming / WiFi operator. > 3. How much routing data is placed into packets today in semi-complex > arrangements by proxies? How many of them cache the data locally for the > return trip rather than just append data to the message? There is no routing data in packets. I'm not sure what your question even means. RADIUS is a request/response protocol. A proxy simply ties together a request/response on the incoming side to a request/response on the outgoing side. It keeps track of the relationship in its internal memory. This information doesn't go into packets. There *is* a Proxy-State attribute in RADIUS. But it's pretty much useless. It can be used to detect routing loops (100 Proxy-State is bad). I know all of the RADIUS servers I've worked with since 1997 don't do anything with it. Alan DeKok. From hartmans@painless-security.com Thu Mar 15 05:52:20 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D198F21F8687 for ; Thu, 15 Mar 2012 05:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 PuIWNJEhQMh7 for ; Thu, 15 Mar 2012 05:52:18 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id E57FF21F84A7 for ; Thu, 15 Mar 2012 05:52:17 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id DD1F620289; Thu, 15 Mar 2012 08:51:48 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 31FAB4767; Thu, 15 Mar 2012 08:52:05 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> Date: Thu, 15 Mar 2012 08:52:05 -0400 In-Reply-To: <4F61A2BB.5070408@um.es> (Alejandro Perez Mendez's message of "Thu, 15 Mar 2012 09:05:15 +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: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 12:52:20 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: item #2 - If the SAML responder is going to >> response to a SAML request, is there a requirement that the >> responder MUST response no later than the Access-Accept or >> Access-Reject message? Also what other currently defined packets >> is the element permitted in - for example can I include it in an >> Access-Challenge packet? Alejandro> That's an interesting question. In a previous discussion Alejandro> we were thinking on moving all the authorization data Alejandro> retrieval exchanges _after_ the Access-Accept exchange. I Alejandro> think Josh already shown interest on changing to that Alejandro> kind of flow, though I guess until radius-fragmentation Alejandro> draft moves a little forward this need to be hold on. I do not support moving to that flow all the time. I think if the message fits in the access-accept it should be sent there. Also true for access-reject. >> >> 6. The last sentence in section 5.2 makes no sense to me. I >> believe the sentence should finish "to a Relying Part without >> step 2 occurring." Doing it without having the EAP protocol run >> in section 3 would be bad news. Ditto the last paragraph in >> section 5.3 - I think it should just say that "The Request in >> section 5.3.2 is omitted from the process." >> >> 7. In section 5.3.4 - I would like to see a statement that in >> this profile, if the is marked as fail then >> the EAP should also return fail. That is there should not be >> difference in the returned value for the SAML request and the EAP >> dialog. Alejandro> IMO this is not required. EAP is meant to provide Alejandro> authentication, while SAML is intended to provide Alejandro> authorization. A principal may be succesfuly Alejandro> authenticated, but fail to obtain authorization Alejandro> information. One process should not interfere in the Alejandro> other. Think that a RP may not issue the Alejandro> AuthnReq. Besides, if the RADIUS server and the IdP are Alejandro> not collocated, I do not think it is a good idea to trick Alejandro> the EAP stack in the RADIUS server to force an EAP Alejandro> failure if the IdP replies with an SAML error. Typically a RADIUS access-accept implies both authorization and authentication. I don't particularly care if the saml and EAP results are consistent, but I don't think it's appropriate to include a SAML failure in an access accept. From alex@um.es Thu Mar 15 06:07:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C330821F86EC for ; Thu, 15 Mar 2012 06:07:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 JchbHl39CB6k for ; Thu, 15 Mar 2012 06:07:15 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id A3FEA21F86AB for ; Thu, 15 Mar 2012 06:07:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 29B8D53673; Thu, 15 Mar 2012 14:07:13 +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 BQ-abID2Cpk4; Thu, 15 Mar 2012 14:07:12 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id E783E535DF; Thu, 15 Mar 2012 14:07:10 +0100 (CET) Message-ID: <4F61E97E.3050602@um.es> Date: Thu, 15 Mar 2012 14:07:10 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 13:07:15 -0000 El 15/03/12 13:52, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > item #2 - If the SAML responder is going to > >> response to a SAML request, is there a requirement that the > >> responder MUST response no later than the Access-Accept or > >> Access-Reject message? Also what other currently defined packets > >> is the element permitted in - for example can I include it in an > >> Access-Challenge packet? > > Alejandro> That's an interesting question. In a previous discussion > Alejandro> we were thinking on moving all the authorization data > Alejandro> retrieval exchanges _after_ the Access-Accept exchange. I > Alejandro> think Josh already shown interest on changing to that > Alejandro> kind of flow, though I guess until radius-fragmentation > Alejandro> draft moves a little forward this need to be hold on. > > I do not support moving to that flow all the time. > I think if the message fits in the access-accept it should be sent > there. > Also true for access-reject. > > >> > >> 6. The last sentence in section 5.2 makes no sense to me. I > >> believe the sentence should finish "to a Relying Part without > >> step 2 occurring." Doing it without having the EAP protocol run > >> in section 3 would be bad news. Ditto the last paragraph in > >> section 5.3 - I think it should just say that "The Request in > >> section 5.3.2 is omitted from the process." > >> > >> 7. In section 5.3.4 - I would like to see a statement that in > >> this profile, if the is marked as fail then > >> the EAP should also return fail. That is there should not be > >> difference in the returned value for the SAML request and the EAP > >> dialog. > > Alejandro> IMO this is not required. EAP is meant to provide > Alejandro> authentication, while SAML is intended to provide > Alejandro> authorization. A principal may be succesfuly > Alejandro> authenticated, but fail to obtain authorization > Alejandro> information. One process should not interfere in the > Alejandro> other. Think that a RP may not issue the > Alejandro> AuthnReq. Besides, if the RADIUS server and the IdP are > Alejandro> not collocated, I do not think it is a good idea to trick > Alejandro> the EAP stack in the RADIUS server to force an EAP > Alejandro> failure if the IdP replies with an SAML error. > > > Typically a RADIUS access-accept implies both authorization and > authentication. > > I don't particularly care if the saml and EAP results are consistent, > but I don't think it's appropriate to include a SAML failure in an > access accept. I didn't mean that a RADIUS Access-Accept should be sent if a SAML failure occurs. I was just talking about EAP, not RADIUS. I mean, we are using RADIUS to transport both EAP and SAML. If the conjunction of a SAML failure and a EAP success should have the result of denial of access (because of the failure in the authorization), then an Access-Reject should be sent. Now, I have to admint that I don't really know if it is possible to send an EAP-Success packet within an Access-Reject RADIUS message. But tricking the EAP stack to force the EAP method to fail even when the method was actually successful does not sound very well either. What do you think? Regards, Alejandro > From hartmans@painless-security.com Thu Mar 15 07:28:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C17B21F8578 for ; Thu, 15 Mar 2012 07:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.022, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 bM2Qm5BiLP7c for ; Thu, 15 Mar 2012 07:28:45 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 79D5E21F848B for ; Thu, 15 Mar 2012 07:28:44 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 7773620289; Thu, 15 Mar 2012 10:28:15 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EBB994767; Thu, 15 Mar 2012 10:28:30 -0400 (EDT) From: Sam Hartman To: Alejandro Perez Mendez References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> Date: Thu, 15 Mar 2012 10:28:30 -0400 In-Reply-To: <4F61E97E.3050602@um.es> (Alejandro Perez Mendez's message of "Thu, 15 Mar 2012 14:07: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: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:28:46 -0000 >>>>> "Alejandro" == Alejandro Perez Mendez writes: I think we're in general agreement. Alejandro> I mean, we are using RADIUS to transport both EAP and Alejandro> SAML. If the conjunction of a SAML failure and a EAP Alejandro> success should have the result of denial of access Alejandro> (because of the failure in the authorization), then an Alejandro> Access-Reject should be sent. Now, I have to admint that Alejandro> I don't really know if it is possible to send an Alejandro> EAP-Success packet within an Access-Reject RADIUS Alejandro> message. But tricking the EAP stack to force the EAP Alejandro> method to fail even when the method was actually Alejandro> successful does not sound very well either. What do you Alejandro> think? In this case my preference would be to send no EAP message back at all but only to send an access-reject possibly with the SAML failure. --Sam From gabilm@um.es Thu Mar 15 07:33:45 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4038821F84AE for ; Thu, 15 Mar 2012 07:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.549 X-Spam-Level: X-Spam-Status: No, score=-5.549 tagged_above=-999 required=5 tests=[AWL=0.750, 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 MLn+OxyWfPWH for ; Thu, 15 Mar 2012 07:33:19 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id DD9A721F8698 for ; Thu, 15 Mar 2012 07:33:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id E5EFF5D4C8; Thu, 15 Mar 2012 15:33:17 +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 VdqMy0qPxp6I; Thu, 15 Mar 2012 15:33:17 +0100 (CET) Received: from eduroam_um-230-64.inf.um.es (eduroam_um-230-64.inf.um.es [155.54.230.64]) (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 804845D4A4; Thu, 15 Mar 2012 15:33:14 +0100 (CET) Message-ID: <4F61FDA9.3080000@um.es> Date: Thu, 15 Mar 2012 15:33:13 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Sam Hartman References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> In-Reply-To: X-Enigmail-Version: 1.4 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:33:45 -0000 El 15/03/12 15:28, Sam Hartman escribió: >>>>>> "Alejandro" == Alejandro Perez Mendez writes: > > I think we're in general agreement. > > Alejandro> I mean, we are using RADIUS to transport both EAP and > Alejandro> SAML. If the conjunction of a SAML failure and a EAP > Alejandro> success should have the result of denial of access > Alejandro> (because of the failure in the authorization), then an > Alejandro> Access-Reject should be sent. Now, I have to admint that > Alejandro> I don't really know if it is possible to send an > Alejandro> EAP-Success packet within an Access-Reject RADIUS > Alejandro> message. But tricking the EAP stack to force the EAP > Alejandro> method to fail even when the method was actually > Alejandro> successful does not sound very well either. What do you > Alejandro> think? > > > In this case my preference would be to send no EAP message back at all > but only to send an access-reject possibly with the SAML failure. I agree Regards, Gabi. > > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- 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 cantor.2@osu.edu Thu Mar 15 07:58:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2F4721F86C3 for ; Thu, 15 Mar 2012 07:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyKgCmkUbg4v for ; Thu, 15 Mar 2012 07:58:08 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id 866DF21F8666 for ; Thu, 15 Mar 2012 07:58:08 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2FEvsCs019732; Thu, 15 Mar 2012 10:58:05 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.01.0355.002; Thu, 15 Mar 2012 10:57:49 -0400 From: "Cantor, Scott" To: Jim Schaad , Sam Hartman , "josh.howlett@ja.net" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEebN+v1EjYXZ0KvOV3A9EeDm5ZrHnKAgABW04A= Date: Thu, 15 Mar 2012 14:57:47 +0000 Message-ID: References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> In-Reply-To: <000801cd026e$19e4b710$4dae2530$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:58:10 -0000 > 1. Do we have any other examples where we might have a SAML > requester/responder other than the case of the RP/IdP? If so, it might b= e > wise to mention at least one other case in the introductory paragraph in > section 1. Otherwise it might be easier to just say that we are sending > messages between the RP and the IdP and not generalize it. Can anybody > see a reason that one might want to reverse the endpoints? So that the R= P > becomes the server and the IdP the client??? Any binding should be left generically defined as SAML requester and respon= der, even if you don't specifically have a use case to hand. It's just the = right layering. But aside from that, I can at least point to some protocols= that could be useful and would reverse the flows. NameID mgmt, ID mapping,= and the Oracle Change-Notify proposal would all be possible flows that rev= erse the roles. But whether that's possible in ABFAB I don't know. > 8. In section 5.4.1 paragraph 3 - I am not sure how this section interac= ts > with the ability of an IdP to return a Pseudonymous identifier. Are you > stating that the identifier must already exist, or just that the policy f= or > creating the identifier must already exist in the case AllowCreate is set= to > "false". That text is probably somewhat ill-advised. It most likely got copied from = the original browser SSO profile, and I never wanted it there either. It's = repeating SAML core rules, and I don't like repeating spec language. But to= answer your question, for more ill-advised reasons, there's a flag in SAML= with a very poor default that's used to specifically limit the IdP from ma= nufacturing an identifier for a user if the identifier doesn't already exis= t. If AllowCreate is false, the IdP is supposed to fail rather than mint ne= w state between itself and the SP. =20 -- Scott From alex@um.es Thu Mar 15 07:59:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B5721F8666 for ; Thu, 15 Mar 2012 07:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 CVTGBBiHapLB for ; Thu, 15 Mar 2012 07:59:27 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6ED9B21F8652 for ; Thu, 15 Mar 2012 07:59:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 4A4C64BE9F; Thu, 15 Mar 2012 15:59:26 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 69Y8Iokhwq4m; Thu, 15 Mar 2012 15:59:25 +0100 (CET) Received: from [192.168.1.131] (64.227.14.37.dynamic.jazztel.es [37.14.227.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 7682F4BE9D; Thu, 15 Mar 2012 15:59:23 +0100 (CET) Message-ID: <4F6203CA.7050804@um.es> Date: Thu, 15 Mar 2012 15:59:22 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> <4F61FDA9.3080000@um.es> In-Reply-To: <4F61FDA9.3080000@um.es> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 14:59:28 -0000 El 15/03/12 15:33, Gabriel López escribió: > El 15/03/12 15:28, Sam Hartman escribió: >>>>>>> "Alejandro" == Alejandro Perez Mendez writes: >> I think we're in general agreement. >> >> Alejandro> I mean, we are using RADIUS to transport both EAP and >> Alejandro> SAML. If the conjunction of a SAML failure and a EAP >> Alejandro> success should have the result of denial of access >> Alejandro> (because of the failure in the authorization), then an >> Alejandro> Access-Reject should be sent. Now, I have to admint that >> Alejandro> I don't really know if it is possible to send an >> Alejandro> EAP-Success packet within an Access-Reject RADIUS >> Alejandro> message. But tricking the EAP stack to force the EAP >> Alejandro> method to fail even when the method was actually >> Alejandro> successful does not sound very well either. What do you >> Alejandro> think? >> >> >> In this case my preference would be to send no EAP message back at all >> but only to send an access-reject possibly with the SAML failure. > I agree I think that is a reasonable solution. > > Regards, Gabi. >> --Sam >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Thu Mar 15 08:32:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 560F221F8733 for ; Thu, 15 Mar 2012 08:32:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 wNpSXii51fMD for ; Thu, 15 Mar 2012 08:32:13 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id A162321F8742 for ; Thu, 15 Mar 2012 08:32:13 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C7EE52058F; Thu, 15 Mar 2012 11:31:44 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6AD924767; Thu, 15 Mar 2012 11:32:00 -0400 (EDT) From: Sam Hartman To: "Cantor\, Scott" References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> Date: Thu, 15 Mar 2012 11:32:00 -0400 In-Reply-To: (Scott Cantor's message of "Thu, 15 Mar 2012 14:57:47 +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: Jim Schaad , "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:32:14 -0000 >>>>> "Cantor," == Cantor, Scott writes: >> 1. Do we have any other examples where we might have a SAML >> requester/responder other than the case of the RP/IdP? If so, it >> might be wise to mention at least one other case in the >> introductory paragraph in section 1. Otherwise it might be >> easier to just say that we are sending messages between the RP >> and the IdP and not generalize it. Can anybody see a reason that >> one might want to reverse the endpoints? So that the RP becomes >> the server and the IdP the client??? Cantor,> Any binding should be left generically defined as SAML Cantor,> requester and responder, even if you don't specifically Cantor,> have a use case to hand. It's just the right layering. Conceptually I agree that defining things in terms of requester and responder are desirable. If we do that, thought, it seems like we need to describe how to identify and route things at the AAA layer. Routing to IDP associated with that AAA server is easy. However going beyond that is tricky at the RADIUS layer. From ietf@augustcellars.com Thu Mar 15 08:59:59 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFE821F8735 for ; Thu, 15 Mar 2012 08:59:59 -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 LQKK7as3A50N for ; Thu, 15 Mar 2012 08:59:58 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 2442521F85AE for ; Thu, 15 Mar 2012 08:59:58 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 6BC8138F13; Thu, 15 Mar 2012 08:59:56 -0700 (PDT) From: "Jim Schaad" To: "'Alejandro Perez Mendez'" , References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> In-Reply-To: <4F61A2BB.5070408@um.es> Date: Thu, 15 Mar 2012 08:59:05 -0700 Message-ID: <009101cd02c4$8ed287e0$ac7797a0$@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: AQLr+32EzPhx8XDlot9yxh/WPNQDpgFEttRaAm9uv2SUD+2lEA== Content-Language: en-us Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 15:59:59 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Alejandro Perez Mendez > Sent: Thursday, March 15, 2012 1:05 AM > To: abfab@ietf.org > Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt > > > > Comments on the current version of the document. > > > > First let me say that overall I am very happy with the state of this > > document. It is slightly repetitive, but is very clear about what > > happens when and where. I believe that I now have a clear > > understanding of how I would go about using SAML statements in Plasma > > by starting with using the Authentication Profile and then following > > it up with generic queries using the identity that was returned in the > Authentication response. > > > > Jim > > > > > > Major > > > > 1. Do we have any other examples where we might have a SAML > > requester/responder other than the case of the RP/IdP? If so, it > > might be wise to mention at least one other case in the introductory > > paragraph in section 1. Otherwise it might be easier to just say that > > we are sending messages between the RP and the IdP and not generalize > > it. Can anybody see a reason that one might want to reverse the > > endpoints? So that the RP becomes the server and the IdP the client??? > > > > 2. In section 3, I would suggest adding the text "There MUST be at > > most one SAML-Message Attribute in either a RADIUS request or response > message." > > It is almost impossible to fit a entire SAML message into a single SAML- > Message attribute (253 bytes), so almost always there will be more than on > SAML-Message attribute in both, RADIUS requests and responses when > transporting SAML data. All these attributes are part of the same extended > fragmented attribute, but section 3 is talking about the basic RADIUS > attribute. Note that this draft has not yet adopted extended attributes > format. > > If your intention was to suggest that no more than 1 SAML Message MUST > be included per RADIUS packet, I'm not sure to agree either. At least, I do not > see a clear motivation for such limitation. My intent was to say that there was at most one SAML Assertion in a RADIUS request or response message. If this is not true then we need to find a way to say that assertion #1 has ended and we are now dealing with assertion #2. > > > > > 3. In section 4.1 and 5.1, the Identification will require an IANA action. > > I think we are looking at urn:ietf:params:xml:ns:abfab: here> > > I think that something probably looks like SAML:binding:RADIUS-binding in > > section 4.1. The contact information should be iesg@ietf.org. I don't see > > any requirement that the binding should be specific to the RADIUS > transport > > - do you? > > > > 4. In section 4.2 item #2 - If the SAML responder is going to response to a > > SAML request, is there a requirement that the responder MUST response > no > > later than the Access-Accept or Access-Reject message? Also what other > > currently defined packets is the element permitted in - for example can I > > include it in an Access-Challenge packet? > > That's an interesting question. In a previous discussion we were > thinking on moving all the authorization data retrieval exchanges > _after_ the Access-Accept exchange. I think Josh already shown interest > on changing to that kind of flow, though I guess until > radius-fragmentation draft moves a little forward this need to be hold on. > > The basic idea would be to perform the EAP authentication without SAML > exchanges. Within the Access-Accept, the RADIUS server provides a State > attribute and the service-type would be Authorize-Only, indicationg > further authorization need to be performed. Then the RP sends the SAML > Authn Req and the IdP provides the SAML Assertion. This way both > authentication and attribute retrieval follow the same exchange pattern. > > > > > > 5. In section 5.2 - Section on Responses: - I am confused when I read this > > text. It first says that you must return exactly one authentication > > statement. It then says that the IdP can return other statements in the > > assertion. Are these other assertions allowed to be authentication > > statements or are they some other type of statement? > > Other type of statement, for example, attribute statement. > Ok the text could be clearer. > > > > 6. The last sentence in section 5.2 makes no sense to me. I believe the > > sentence should finish "to a Relying Part without step 2 occurring." Doing > > it without having the EAP protocol run in section 3 would be bad news. > > Ditto the last paragraph in section 5.3 - I think it should just say that > > "The Request in section 5.3.2 is omitted from the process." > > > > 7. In section 5.3.4 - I would like to see a statement that in this profile, > > if the is marked as fail then the EAP should also > > return fail. That is there should not be difference in the returned value > > for the SAML request and the EAP dialog. > > IMO this is not required. EAP is meant to provide authentication, while > SAML is intended to provide authorization. A principal may be succesfuly > authenticated, but fail to obtain authorization information. One process > should not interfere in the other. Think that a RP may not issue the > AuthnReq. Besides, if the RADIUS server and the IdP are not collocated, > I do not think it is a good idea to trick the EAP stack in the RADIUS > server to force an EAP failure if the IdP replies with an SAML error. > > Allowing for different answers makes more sense if the flow changes as above. Otherwise I don't see that this is necessarily true. We have already stated that the AuthnRequest can and should in some cases affect how the EAP is performed. Are you talking about failing because you are not going to return some attributes or because you are going to say that yes I know who they are, but they are not supposed to talk to you. In this case ABFAB has already said you are supposed to fail the EAP conversation as well. Under what circumstances do you think this would occur. > > > > 8. In section 5.4.1 paragraph 3 - I am not sure how this section interacts > > with the ability of an IdP to return a Pseudonymous identifier. Are you > > stating that the identifier must already exist, or just that the policy for > > creating the identifier must already exist in the case AllowCreate is set to > > "false". > > > > 9. In section 5.4.1 last paragraph - I think we should make some type of > > statement about what happens if either the request is not signed, or the > > signature on the request cannot be validated by the IdP. I think that both > > of these cases are going to be more likely that the case of it is signed and > > the IdP happens to be able to validate the signature. > > I think a general statement must be included saying that if SAML > messages/assertion are not singed, authenticity and integrity protection > are implicitly provided by the AAA infrastructure. If signatures are > provided, they have precedence. > > > > > 10. I believe that a discussion of what is expected to happen as these > > messages cross federation boundaries is probably in order. > > > > Nits > > > > 1. We need to get a consistent method of doing Abfab or ABFAB. I have > > always used all upper case, this document is doing mixed case. We should > be > > consistent and I think the all upper case is the normal way. Please change. > Agree > > > > > 2. I object to the capitalization in the following sentence "The NAI SHOULD > > be used to route the > > message towards the SAML responder, which MAY be more than one > > RADIUS hop distant." How are these requirements on the binding that > > is being produced? Are these not intrinsic properties that are true just by > > saying that we are using RAIDUS? > > > > 3. There is an extraneous period in the last sentence of section 5.3.3 > > > > 4. Bad grammar /confirmation as the processing as defined in/ I don't > know > > what this should be. > > > > 5. Please add http links to your SAML references so I don't have to search > > for them - I am very lazy. > > > > 6. Can we move some of the references out of normative? For example I > > think that 3575 could be informative since it affects only the document > > writer and not the implementer. The same is probably true for some of > the > > other references. > > > > s/reponse/response/ > > s/Consequently here exists/Consequently there exists/ > > s/unsolicited responser/unsolicited response/ > > s/disgression/discretion/ > > > > > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Thu Mar 15 09:17:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AA321F877F for ; Thu, 15 Mar 2012 09:17:46 -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 Ks5nRcFtwI+Q for ; Thu, 15 Mar 2012 09:17:45 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6486B21F8779 for ; Thu, 15 Mar 2012 09:17:38 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 8AAB938EF1; Thu, 15 Mar 2012 09:17:36 -0700 (PDT) From: "Jim Schaad" To: "'Alan DeKok'" References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> In-Reply-To: <4F61D901.10004@deployingradius.com> Date: Thu, 15 Mar 2012 09:16:46 -0700 Message-ID: <009201cd02c7$07188f90$1549aeb0$@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: AQDNHPJXnRNudUwKAHwUV1skxOAxCwHX+tEvAeRn0gABnLtYsgIyq6+zAeE7zx8CneIZzQHwW0QiAfg1o/kCicRlngIy0JQeAYQceTYCfrTJx5elvBlA Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 16:17:46 -0000 Alan, Thanks for the response > -----Original Message----- > From: Alan DeKok [mailto:aland@deployingradius.com] > Sent: Thursday, March 15, 2012 4:57 AM > To: Jim Schaad > Cc: 'Sam Hartman'; 'Alejandro Perez Mendez'; 'Josh Howlett'; abfab@ietf.org > Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext- > radius-fragmentation-01.txt > > Jim Schaad wrote: > > Do you have any data which we could start getting some data about how > > proxies are currently used. > > I have opinions, but getting *public* data is difficult. > > > 1. How many places are there were we see transitions from Diameter to > > RADIUS or vice versa? These would be places where we already have a > > situation where messages might need to be fragmented because of the > > different sizes of packets. > > I don't see many RADIUS to Diameter gateways. > > > 2. Are you aware of any places where information needs to be > > translated as they go past proxies in the manner we are talking about > > where things cross federation boundaries and the data needs to be > > either validated or modified to fit how the federation thinks about the > data? > > Yes. Many roaming providers go through integrators. Those integrators > take care of mangling packets back & forth. This is one of the value-adds of > the integrator. They present a uniform RADIUS framework to the home > servers, by normalizing the weird things produced by each roaming / WiFi > operator. Do these integrators end up with lots of local state for each set of packets going back and forth? Do they end up carrying state between packets? Would it be unreasonable or unnecessary for them to do the packet re-assembly and then re-send that would be required by the fragmentation draft? > > > 3. How much routing data is placed into packets today in semi-complex > > arrangements by proxies? How many of them cache the data locally for > > the return trip rather than just append data to the message? > > There is no routing data in packets. I'm not sure what your question even > means. > > RADIUS is a request/response protocol. A proxy simply ties together a > request/response on the incoming side to a request/response on the > outgoing side. It keeps track of the relationship in its internal memory. This > information doesn't go into packets. > > There *is* a Proxy-State attribute in RADIUS. But it's pretty much useless. > It can be used to detect routing loops (100 Proxy-State is bad). I know all of > the RADIUS servers I've worked with since 1997 don't do anything with it. > My mistake - I assumed that the in memory state that was being cached was being cached into the Proxy-State attribute rather than being stored on the proxy itself. This would allow for a "state-less" proxy to be created. Jim > Alan DeKok. From aland@deployingradius.com Thu Mar 15 12:33:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2783E21E8015 for ; Thu, 15 Mar 2012 12:33: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 4iYLCoICLpgS for ; Thu, 15 Mar 2012 12:33:54 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 090EA21E800C for ; Thu, 15 Mar 2012 12:33:54 -0700 (PDT) Received: from thor.lan (206-248-130-83.dsl.teksavvy.com [206.248.130.83]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 848A012344CE; Thu, 15 Mar 2012 20:33:23 +0100 (CET) Message-ID: <4F624402.4060801@deployingradius.com> Date: Thu, 15 Mar 2012 15:33:22 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jim Schaad References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> In-Reply-To: <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:33:55 -0000 Jim Schaad wrote: > Do these integrators end up with lots of local state for each set of packets > going back and forth? Do they end up carrying state between packets? The only state is (a) per packet for proxying, and (b) per session for accounting. The session state enables the same rewriting to be done for each accounting packet. > Would it be unreasonable or unnecessary for them to do the packet > re-assembly and then re-send that would be required by the fragmentation > draft? I don't think re-assembly is required by the fragmentation draft. I would strongly avoid requiring such reassembly. Implementing it could require major changes to the proxies. The re-writing done by current proxies is fairly minimal. So it should have minimal effect on the fragments as suggested by the draft. > My mistake - I assumed that the in memory state that was being cached was > being cached into the Proxy-State attribute rather than being stored on the > proxy itself. This would allow for a "state-less" proxy to be created. That isn't done, and likely wouldn't work. There's a history of RADIUS proxies mangling Proxy-State, for no good reason. As a result, most modern implementations don't depend on it. Alan DeKok. From ietf@augustcellars.com Thu Mar 15 12:49:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37AE21F8581 for ; Thu, 15 Mar 2012 12:49:39 -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 EdLRlSO6J3OM for ; Thu, 15 Mar 2012 12:49:39 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 62F7621F857F for ; Thu, 15 Mar 2012 12:49:39 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 87B322CA28; Thu, 15 Mar 2012 12:49:37 -0700 (PDT) From: "Jim Schaad" To: "'Cantor, Scott'" , "'Sam Hartman'" , References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> In-Reply-To: Date: Thu, 15 Mar 2012 12:48:44 -0700 Message-ID: <00c601cd02e4$a522c210$ef684630$@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: AQLr+32EzPhx8XDlot9yxh/WPNQDpgFEttRaAj6lMbiUEbcrIA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 19:49:40 -0000 > -----Original Message----- > From: Cantor, Scott [mailto:cantor.2@osu.edu] > Sent: Thursday, March 15, 2012 7:58 AM > To: Jim Schaad; Sam Hartman; josh.howlett@ja.net > Cc: abfab@ietf.org > Subject: RE: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt > > > 1. Do we have any other examples where we might have a SAML > > requester/responder other than the case of the RP/IdP? If so, it > > might be wise to mention at least one other case in the introductory > > paragraph in section 1. Otherwise it might be easier to just say that > > we are sending messages between the RP and the IdP and not generalize > > it. Can anybody see a reason that one might want to reverse the > > endpoints? So that the RP becomes the server and the IdP the client??? > > Any binding should be left generically defined as SAML requester and > responder, even if you don't specifically have a use case to hand. It's just the > right layering. But aside from that, I can at least point to some protocols that > could be useful and would reverse the flows. NameID mgmt, ID mapping, > and the Oracle Change-Notify proposal would all be possible flows that > reverse the roles. > > But whether that's possible in ABFAB I don't know. > > > 8. In section 5.4.1 paragraph 3 - I am not sure how this section > > interacts with the ability of an IdP to return a Pseudonymous > > identifier. Are you stating that the identifier must already exist, > > or just that the policy for creating the identifier must already exist > > in the case AllowCreate is set to "false". > > That text is probably somewhat ill-advised. It most likely got copied from the > original browser SSO profile, and I never wanted it there either. It's repeating > SAML core rules, and I don't like repeating spec language. But to answer your > question, for more ill-advised reasons, there's a flag in SAML with a very poor > default that's used to specifically limit the IdP from manufacturing an > identifier for a user if the identifier doesn't already exist. If AllowCreate is > false, the IdP is supposed to fail rather than mint new state between itself > and the SP. Based on this would you be in favor of adding the statement that AllowCreate SHOULD be set to true? Jim > > -- Scott From hartmans@painless-security.com Thu Mar 15 13:04:56 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD5221E8017 for ; Thu, 15 Mar 2012 13:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 kEbTOE-D5ZQu for ; Thu, 15 Mar 2012 13:04:56 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 42D3021F865F for ; Thu, 15 Mar 2012 13:04:56 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id A43B02021E; Thu, 15 Mar 2012 16:04:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D569E4767; Thu, 15 Mar 2012 16:04:41 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> Date: Thu, 15 Mar 2012 16:04:41 -0400 In-Reply-To: <4F624402.4060801@deployingradius.com> (Alan DeKok's message of "Thu, 15 Mar 2012 15:33:22 -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: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:04:56 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> I don't think re-assembly is required by the fragmentation Alan> draft. I would strongly avoid requiring such reassembly. Alan> Implementing it could require major changes to the proxies. Alan> The re-writing done by current proxies is fairly minimal. Alan> So it should have minimal effect on the fragments as suggested Alan> by the draft. so, I think you may be missing what Jim is asking about. Jim is talking about a proxy that wants to radically change the SAML assertion being carried. We think the only way to do that is for the proxy to act as a client, grab the entire SAML assertion using the fragmentation protocol, then originate an assertion of its own that it fragments and passes along. --Sam From aland@deployingradius.com Thu Mar 15 13:32:05 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2A121F8617 for ; Thu, 15 Mar 2012 13:32:05 -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 3Ujp8CzqkiNb for ; Thu, 15 Mar 2012 13:32:04 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 45A4D21F860D for ; Thu, 15 Mar 2012 13:32:04 -0700 (PDT) Received: from thor.lan (206-248-130-83.dsl.teksavvy.com [206.248.130.83]) by liberty.deployingradius.com (Postfix) with ESMTPSA id AAF2B12344CE; Thu, 15 Mar 2012 21:31:26 +0100 (CET) Message-ID: <4F62519D.1080608@deployingradius.com> Date: Thu, 15 Mar 2012 16:31:25 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:32:05 -0000 Sam Hartman wrote: > so, I think you may be missing what Jim is asking about. Jim is talking > about a proxy that wants to radically change the SAML assertion being > carried. We think the only way to do that is for the proxy to act as a > client, grab the entire SAML assertion using the fragmentation protocol, > then originate an assertion of its own that it fragments and passes > along. Yeah... It's possible, but I'm scared of that. It involves changing the design assumptions of many servers. Proxying would no longer be an event / packet-driven mechanism. Instead, the inputs and outputs would be largely decoupled. It could also greatly latencies in the network. What happens when you have 2-3 layers of proxies, and each wants to change the SAML assertions? Instead of one client-server latency, you'd have 3 times that, due to the sequential nature of the proxying. My take is that proxies which do re-writes SHOULD pro-actively request the authorization data. This would mean watching the Access-Accept for a "more authorization" flag, and the immediately requesting the authorization data. That data would be cached locally. When the client requests the authorization data, any response would be delayed until all of the data was available. Then, the re-write would occur, and the response sent. This design simplifies the proxy implementation. Instead of having to juggle multiple packets, it just sends back a cached response. Since servers already send back canned responses, we know that the design works. Alan DeKok. From hartmans@painless-security.com Thu Mar 15 13:43:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62BA21E8025 for ; Thu, 15 Mar 2012 13:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 VmXSfVKqfdfn for ; Thu, 15 Mar 2012 13:43:01 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 624C121E801E for ; Thu, 15 Mar 2012 13:43:01 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 10F022021E; Thu, 15 Mar 2012 16:42:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 865714767; Thu, 15 Mar 2012 16:42:47 -0400 (EDT) From: Sam Hartman To: Alan DeKok References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> <4F62519D.1080608@deployingradius.com> Date: Thu, 15 Mar 2012 16:42:47 -0400 In-Reply-To: <4F62519D.1080608@deployingradius.com> (Alan DeKok's message of "Thu, 15 Mar 2012 16:31:25 -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: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:43:02 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> My take is that proxies which do re-writes SHOULD Alan> pro-actively request the authorization data. This would mean Alan> watching the Access-Accept for a "more authorization" flag, Alan> and the immediately requesting the authorization data. That Alan> data would be cached locally. Alan> When the client requests the authorization data, any Alan> response would be delayed until all of the data was available. Alan> Then, the re-write would occur, and the response sent. Alan> This design simplifies the proxy implementation. Instead of Alan> having to juggle multiple packets, it just sends back a cached Alan> response. Since servers already send back canned responses, Alan> we know that the design works. That certainly sounds like an improvement. Assuming someone were looking at that design for rewriting SAML assertions, how scared would you be? From aland@deployingradius.com Thu Mar 15 13:50:13 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 085E621F8649 for ; Thu, 15 Mar 2012 13:50:13 -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 KlKZtrAHpDPH for ; Thu, 15 Mar 2012 13:50:12 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id DF68C21F8646 for ; Thu, 15 Mar 2012 13:50:11 -0700 (PDT) Received: from thor.lan (206-248-130-83.dsl.teksavvy.com [206.248.130.83]) by liberty.deployingradius.com (Postfix) with ESMTPSA id BA82E12344CE; Thu, 15 Mar 2012 21:49:39 +0100 (CET) Message-ID: <4F6255E1.9050901@deployingradius.com> Date: Thu, 15 Mar 2012 16:49:37 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> <4F62519D.1080608@deployingradius.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:50:13 -0000 Sam Hartman wrote: > That certainly sounds like an improvement. > Assuming someone were looking at that design for rewriting SAML > assertions, how scared would you be? A lot less. It's a lot more manageable. Alan DeKok. From cantor.2@osu.edu Thu Mar 15 13:57:36 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D0A21F86E0 for ; Thu, 15 Mar 2012 13:57: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 8TsJom5t387p for ; Thu, 15 Mar 2012 13:57:36 -0700 (PDT) Received: from defang23.it.ohio-state.edu (defang23.it.ohio-state.edu [128.146.216.226]) by ietfa.amsl.com (Postfix) with ESMTP id C38C721F86D9 for ; Thu, 15 Mar 2012 13:57:35 -0700 (PDT) Received: from CIO-TNC-HT05.osuad.osu.edu (cio-tnc-ht05.osuad.osu.edu [164.107.81.168]) by defang23.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2FKvXuC018385; Thu, 15 Mar 2012 16:57:33 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT05.osuad.osu.edu ([fe80::d0be:603:484c:5a2f%10]) with mapi id 14.01.0355.002; Thu, 15 Mar 2012 16:57:32 -0400 From: "Cantor, Scott" To: Jim Schaad , "'Sam Hartman'" , "josh.howlett@ja.net" Thread-Topic: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt Thread-Index: AQHNAEebN+v1EjYXZ0KvOV3A9EeDm5ZrHnKAgABW04CAAJZ7AP//z+jA Date: Thu, 15 Mar 2012 20:57:32 +0000 Message-ID: References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <00c601cd02e4$a522c210$ef684630$@augustcellars.com> In-Reply-To: <00c601cd02e4$a522c210$ef684630$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.160.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.168; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.226 Cc: "abfab@ietf.org" Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 20:57:36 -0000 > Based on this would you be in favor of adding the statement that > AllowCreate SHOULD be set to true? I wouldn't be against it particularly, but we've treated that more as a dep= loyment profile sort of thing, rather than something to bake into technical= profiles for software to implement. -- Scott From ietf@augustcellars.com Thu Mar 15 15:05:56 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C04121E8025 for ; Thu, 15 Mar 2012 15:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, 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 6NkZUBK7+yVS for ; Thu, 15 Mar 2012 15:05:55 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id D503721E8010 for ; Thu, 15 Mar 2012 15:05:55 -0700 (PDT) Received: from Tobias (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (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 ECC4E2C9F4; Thu, 15 Mar 2012 15:05:53 -0700 (PDT) From: "Jim Schaad" To: "'Tschofenig, Hannes \(NSN - FI/Espoo\)'" , , "'Hannes Tschofenig'" References: <000f01cd0276$8cd63f20$a682bd60$@augustcellars.com> <999913AB42CC9341B05A99BBF358718D01382874@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D01382874@FIESEXC035.nsn-intra.net> Date: Thu, 15 Mar 2012 15:05:06 -0700 Message-ID: <00e401cd02f7$ae742f80$0b5c8e80$@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: AQHkMINDqyxdz9wNe3UR6qg+Vl/lfgJBakrrliuAE3A= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] draft-jones-diameter-abfab-00 question X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Mar 2012 22:05:56 -0000 > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: Thursday, March 15, 2012 12:11 AM > To: ext Jim Schaad; mark@azu.ca; Hannes Tschofenig > Cc: abfab@ietf.org > Subject: RE: [abfab] draft-jones-diameter-abfab-00 question > > Hi Jim, > > > I will state upfront that I know less about diameter than I do about > > Radius so the questions I have are to be taken with that grain of > > salt. > > > > 1. Is it possible to include a more general SAML query than just an > > authorization request in a DER message? Specifically, I would like to > > be able to query for a set of attributes about the entity that was > > authorized as oppose to get the fact they are authorized. > > Yes, this is possible. > > Some problems we are dealing with in RADIUS, such as the fragmentation > issue, does not exist in Diameter due to the TCP transport. Ok - I am slightly confused. When I look at the answer ABNF - it has both a SAML-AuthnResponse and a SAML-Assertion. However the request ABNF - it only has SAML-AuthnRequest but not the SAML-Assertion. I read this as saying that one should/could not include the SAML-Assertion at this point. > > > > > 2. Does Diameter give any way of sending the keys around that are to > > be used for doing the xml encryption operation? I understand that > > diameter is more point-to-point than RADIUS but I do not know that to > > be a fact. > > Does > > this mean that there is more likely to have end-to-end signing and > > encryption capabilities present? > > Diameter also exchanges keys in the same manner as RADIUS does. This is, > for example, used for the Diameter EAP application. These keys are, > however, secured only in a hop-by-hop fashion (and not end-to-end; the > ends are Diameter client and Diameter server). > > Currently, there is no standard for e2e AVP encryption in Diameter natively > although there are discussions ongoing to do some work in the DIME working > group. Two relevant contributions for that matter are: > > http://datatracker.ietf.org/doc/draft-korhonen-dime-e2e-security/ > http://datatracker.ietf.org/doc/draft-zorn-dime-n2n-sec-lite/ > > (Note that the scope of the two drafts is a bit different.) > But back to my original question - where would the xml encryption process get it's keys? Jim > > > > 3. Is there a concept of proxies that sit on boundaries that could > > modify the SAML constructs to deal with mapping of attributes? > > There are proxies in Diameter but what they specifically do with certain AVPs > depends very much on the application. The document I have submitted > describes such an application but does not describe such operation. > > Ciao > Hannes > > > > > Jim > > > > > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab From gabilm@um.es Fri Mar 16 00:30:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 869C421F86D5 for ; Fri, 16 Mar 2012 00:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.500, 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 9cBlLKmCSG-g for ; Fri, 16 Mar 2012 00:30:41 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id A0E5321F8710 for ; Fri, 16 Mar 2012 00:30:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 4F2E85368D; Fri, 16 Mar 2012 08:30:39 +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 GlQGh-BC9ieG; Fri, 16 Mar 2012 08:30:38 +0100 (CET) Received: from vpn_um-194-39.inf.um.es (vpn_um-194-39.inf.um.es [155.54.194.39]) (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 EDCE953648; Fri, 16 Mar 2012 08:30:29 +0100 (CET) Message-ID: <4F62EC15.4070404@um.es> Date: Fri, 16 Mar 2012 08:30:29 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan DeKok References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> <4F62519D.1080608@deployingradius.com> In-Reply-To: <4F62519D.1080608@deployingradius.com> X-Enigmail-Version: 1.4 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 07:30:41 -0000 I agree with Alan, I would like to know a representative use case where SAML assertions have to be rewritten by intermediate proxys It is not only a problem of delay, and deployment complexity. It a problem of semantic about SAML assertion. The question is: What kind of attributes will be placed in the assertion that need to be rewriteen? As far I know SAML assertion should carry on information about the end user (information about the network should be transported in RADIUS attributes) so I don't see what is the purpose of rewriting that. Best regards, Gabi. El 15/03/12 21:31, Alan DeKok escribió: > Sam Hartman wrote: >> so, I think you may be missing what Jim is asking about. Jim is talking >> about a proxy that wants to radically change the SAML assertion being >> carried. We think the only way to do that is for the proxy to act as a >> client, grab the entire SAML assertion using the fragmentation protocol, >> then originate an assertion of its own that it fragments and passes >> along. > Yeah... It's possible, but I'm scared of that. > > It involves changing the design assumptions of many servers. Proxying > would no longer be an event / packet-driven mechanism. Instead, the > inputs and outputs would be largely decoupled. > > It could also greatly latencies in the network. What happens when you > have 2-3 layers of proxies, and each wants to change the SAML > assertions? Instead of one client-server latency, you'd have 3 times > that, due to the sequential nature of the proxying. > > My take is that proxies which do re-writes SHOULD pro-actively request > the authorization data. This would mean watching the Access-Accept for > a "more authorization" flag, and the immediately requesting the > authorization data. That data would be cached locally. > > When the client requests the authorization data, any response would be > delayed until all of the data was available. Then, the re-write would > occur, and the response sent. > > This design simplifies the proxy implementation. Instead of having to > juggle multiple packets, it just sends back a cached response. Since > servers already send back canned responses, we know that the design works. > > Alan DeKok. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab -- ---------------------------------------------------------------- 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 16 00:54:17 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527FE21F85B8 for ; Fri, 16 Mar 2012 00:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.904 X-Spam-Level: X-Spam-Status: No, score=-4.904 tagged_above=-999 required=5 tests=[AWL=-1.305, 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 oIlL5v7o7iLL for ; Fri, 16 Mar 2012 00:54:16 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 6895221F85A2 for ; Fri, 16 Mar 2012 00:54:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 7A6464BEAF; Fri, 16 Mar 2012 08:54:15 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SBQhHJj-OMKX; Fri, 16 Mar 2012 08:54:15 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon12.um.es (Postfix) with ESMTPSA id 3CD7E4BEA5; Fri, 16 Mar 2012 08:54:13 +0100 (CET) Message-ID: <4F62F1A4.2090801@um.es> Date: Fri, 16 Mar 2012 08:54:12 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Jim Schaad References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <009101cd02c4$8ed287e0$ac7797a0$@augustcellars.com> In-Reply-To: <009101cd02c4$8ed287e0$ac7797a0$@augustcellars.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 07:54:17 -0000 >>> Jim >>> >>> >>> Major >>> >>> 1. Do we have any other examples where we might have a SAML >>> requester/responder other than the case of the RP/IdP? If so, it >>> might be wise to mention at least one other case in the introductory >>> paragraph in section 1. Otherwise it might be easier to just say that >>> we are sending messages between the RP and the IdP and not generalize >>> it. Can anybody see a reason that one might want to reverse the >>> endpoints? So that the RP becomes the server and the IdP the client??? >>> >>> 2. In section 3, I would suggest adding the text "There MUST be at >>> most one SAML-Message Attribute in either a RADIUS request or response >> message." >> >> It is almost impossible to fit a entire SAML message into a single SAML- >> Message attribute (253 bytes), so almost always there will be more than on >> SAML-Message attribute in both, RADIUS requests and responses when >> transporting SAML data. All these attributes are part of the same extended >> fragmented attribute, but section 3 is talking about the basic RADIUS >> attribute. Note that this draft has not yet adopted extended attributes >> format. >> >> If your intention was to suggest that no more than 1 SAML Message MUST >> be included per RADIUS packet, I'm not sure to agree either. At least, I > do not >> see a clear motivation for such limitation. > My intent was to say that there was at most one SAML Assertion in a RADIUS > request or response message. If this is not true then we need to find a way > to say that assertion #1 has ended and we are now dealing with assertion #2. Extended attributes already deal with this situation thanks to the M flag. Last fragment of an attribute is not marked with M flag. Hence you know when SAML message #1 ends, and thus a different one starts if you find another SAML-Message attribute. that >> IMO this is not required. EAP is meant to provide authentication, while >> SAML is intended to provide authorization. A principal may be succesfuly >> authenticated, but fail to obtain authorization information. One process >> should not interfere in the other. Think that a RP may not issue the >> AuthnReq. Besides, if the RADIUS server and the IdP are not collocated, >> I do not think it is a good idea to trick the EAP stack in the RADIUS >> server to force an EAP failure if the IdP replies with an SAML error. >> >> > Allowing for different answers makes more sense if the flow changes as > above. Otherwise I don't see that this is necessarily true. We have > already stated that the AuthnRequest can and should in some cases affect how > the EAP is performed. Are you talking about failing because you are not > going to return some attributes or because you are going to say that yes I > know who they are, but they are not supposed to talk to you. In this case > ABFAB has already said you are supposed to fail the EAP conversation as > well. Under what circumstances do you think this would occur. I think this has already been solved by Sam in a previous message. Regards, Alejandro From rafa@um.es Fri Mar 16 05:09:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1D821F865C for ; Fri, 16 Mar 2012 05:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.456 X-Spam-Level: X-Spam-Status: No, score=-4.456 tagged_above=-999 required=5 tests=[AWL=-0.857, 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 P7ZIGYaOKJ1O for ; Fri, 16 Mar 2012 05:09:24 -0700 (PDT) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id 2A17E21F8639 for ; Fri, 16 Mar 2012 05:09:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 4749A4BEB2; Fri, 16 Mar 2012 13:09:23 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon12.um.es Received: from xenon12.um.es ([127.0.0.1]) by localhost (xenon12.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ynY901Avzjnl; Fri, 16 Mar 2012 13:09:22 +0100 (CET) Received: from inf-205-67.inf.um.es (inf-205-67.inf.um.es [155.54.205.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon12.um.es (Postfix) with ESMTPSA id 05DCF4BEA7; Fri, 16 Mar 2012 13:09:19 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Fri, 16 Mar 2012 13:09:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1257) Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:09:25 -0000 Hi all: Just one comment. In RFC 3579 (section 2.6.3), there is text about = conflicting messages. =20 I believe we are discussing these two cases: Access-Reject/EAP-Message/EAP Success Access-Reject/no EAP-Message attribute (or even Access-Reject/EAP-Start = being EAP-Start an empty EAP attribute) These cases are NOT recommended in that section. Reasoning is given in = the text and are different for each case: For the Access-Reject/EAP-Message/EAP Success case: "For example, if the NAS receives an Access-Reject with an encapsulated EAP Success, it will not grant access to the peer. However, on receiving the EAP Success, the peer will be lead to believe that it authenticated successfully." For Access-Reject/no EAP-Message attribute "If no EAP-Message attribute is included within an Access-Accept or Access-Reject, then the peer may not be informed as to the outcome of the authentication, while the NAS will take action to allow or deny access." However I believe that, with GSS-EAP, these cases (and the consequent = confusion) could be easily solved. When the acceptor receives an = Access-Reject it should inform the initiator about an authorization = problem. This could be done by defining an error code Authorization = failed in GSS-EAP (maybe existing error codes could be used for that). = In other words, as long as the initiator does not get confused , then = both cases are ok. Personally, I would send a GSS token with the EAP Success and the error = code Authorization failed to the initiator. This would allow the = initiator to know that authentication was ok but authorization failed. = Thus, the initiator does not get confused at all about what happened.=20 Also, some insights from RADIUS server developers are important so that = we can see how RADIUS server typically do (e.g. whether they allow = Access-Reject/EAP-Message/EAP Success or Access-Reject/no EAP-Message = attribute) =20 My 0.02 cents. El 15/03/2012, a las 15:28, Sam Hartman escribi=F3: >>>>>> "Alejandro" =3D=3D Alejandro Perez Mendez writes: >=20 >=20 > I think we're in general agreement. >=20 > Alejandro> I mean, we are using RADIUS to transport both EAP and > Alejandro> SAML. If the conjunction of a SAML failure and a EAP > Alejandro> success should have the result of denial of access > Alejandro> (because of the failure in the authorization), then an > Alejandro> Access-Reject should be sent. Now, I have to admint that > Alejandro> I don't really know if it is possible to send an > Alejandro> EAP-Success packet within an Access-Reject RADIUS > Alejandro> message. But tricking the EAP stack to force the EAP > Alejandro> method to fail even when the method was actually > Alejandro> successful does not sound very well either. What do you > Alejandro> think? >=20 >=20 > In this case my preference would be to send no EAP message back at all > but only to send an access-reject possibly with the SAML failure. >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From alex@um.es Fri Mar 16 05:38:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6269D21F866D for ; Fri, 16 Mar 2012 05:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 CZkxj3xbRxSE for ; Fri, 16 Mar 2012 05:38:24 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 1223D21F85B8 for ; Fri, 16 Mar 2012 05:38:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id D1CEC535C2; Fri, 16 Mar 2012 13:38:19 +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 IBlkOuLi08Fb; Fri, 16 Mar 2012 13:38:19 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon11.um.es (Postfix) with ESMTPSA id BC13B53696; Fri, 16 Mar 2012 13:38:11 +0100 (CET) Message-ID: <4F633434.1020202@um.es> Date: Fri, 16 Mar 2012 13:38:12 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan DeKok References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> <4F62519D.1080608@deployingradius.com> In-Reply-To: <4F62519D.1080608@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:38:25 -0000 El 15/03/12 21:31, Alan DeKok escribió: > Sam Hartman wrote: >> so, I think you may be missing what Jim is asking about. Jim is talking >> about a proxy that wants to radically change the SAML assertion being >> carried. We think the only way to do that is for the proxy to act as a >> client, grab the entire SAML assertion using the fragmentation protocol, >> then originate an assertion of its own that it fragments and passes >> along. > Yeah... It's possible, but I'm scared of that. > > It involves changing the design assumptions of many servers. Proxying > would no longer be an event / packet-driven mechanism. Instead, the > inputs and outputs would be largely decoupled. > > It could also greatly latencies in the network. What happens when you > have 2-3 layers of proxies, and each wants to change the SAML > assertions? Instead of one client-server latency, you'd have 3 times > that, due to the sequential nature of the proxying. > > My take is that proxies which do re-writes SHOULD pro-actively request > the authorization data. This would mean watching the Access-Accept for > a "more authorization" flag, and the immediately requesting the > authorization data. That data would be cached locally. > > When the client requests the authorization data, any response would be > delayed until all of the data was available. Then, the re-write would > occur, and the response sent. > > This design simplifies the proxy implementation. Instead of having to > juggle multiple packets, it just sends back a cached response. Since > servers already send back canned responses, we know that the design works. I do not see how this simplifies the flow. The number of messages are exactly the same, and there seem to not be much difference on the amount of state to be hold either. As I understand, the only difference is the pro-active nature of the request by the proxy. What's the difference of doing that pro-actively or just waiting until the Access-Request from the client requesting the authorization data passed through the proxy? Regards, Alejandro > > Alan DeKok. From aland@deployingradius.com Fri Mar 16 05:49:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4D3221F8682 for ; Fri, 16 Mar 2012 05:49:28 -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 kLESy92xvQDr for ; Fri, 16 Mar 2012 05:49:28 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 1864A21F8559 for ; Fri, 16 Mar 2012 05:49:28 -0700 (PDT) Received: from thor.lan (69-196-167-168.dsl.teksavvy.com [69.196.167.168]) by liberty.deployingradius.com (Postfix) with ESMTPSA id 786A712344CE; Fri, 16 Mar 2012 13:48:58 +0100 (CET) Message-ID: <4F6336B8.9060101@deployingradius.com> Date: Fri, 16 Mar 2012 08:48:56 -0400 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alejandro Perez Mendez References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> <4F62519D.1080608@deployingradius.com> <4F633434.1020202@um.es> In-Reply-To: <4F633434.1020202@um.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 12:49:29 -0000 Alejandro Perez Mendez wrote: > I do not see how this simplifies the flow. The number of messages are > exactly the same, and there seem to not be much difference on the amount > of state to be hold either. As I understand, the only difference is the > pro-active nature of the request by the proxy. The issue is that the proxy needs to have ALL of the SAML data before it can rewrite ANY of it. Since the SAML data is spread over multiple packets, the current near-stateless approach won't work. i.e. current proxies apply the same rewrite rules to every packet. They don't change packet N+1 of a stream based on data seen in packet N. > What's the difference of doing that pro-actively or just waiting until > the Access-Request from the client requesting the authorization data > passed through the proxy? Latency. When a client sends the first "get more data" packet, the proxy CANNOT respond until it has ALL of the SAML data from the home server. This may take a large number of round trips. During those round trips, the client is waiting for a response to ONE packet. The client will think that the proxy is unresponsive, or just very slow. Also, current proxy implementations are largely event-driven. They receive a packet from a client, proxy it, receive the response, and send that to the client. Changing the implementation is hard. Changing it so that the event loop becomes "receive one packet, send many many packets" can be challenging. An explicitly decoupled approach can be simpler. I wouldn't say it's a requirement. I would say it would be my preferred implementation. Alan DeKok. From alex@um.es Fri Mar 16 06:01:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D717521F86CE for ; Fri, 16 Mar 2012 06:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.349 X-Spam-Level: X-Spam-Status: No, score=-6.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 3YfQ-men5-eU for ; Fri, 16 Mar 2012 06:01:52 -0700 (PDT) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8AB21F86CA for ; Fri, 16 Mar 2012 06:01:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 1FFF75D501; Fri, 16 Mar 2012 14:01:51 +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 uA-16tIIeeKg; Fri, 16 Mar 2012 14:01:50 +0100 (CET) Received: from [155.54.205.90] (inf-205-90.inf.um.es [155.54.205.90]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon14.um.es (Postfix) with ESMTPSA id 955915D502; Fri, 16 Mar 2012 14:01:45 +0100 (CET) Message-ID: <4F6339B9.3050509@um.es> Date: Fri, 16 Mar 2012 14:01:45 +0100 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan DeKok References: <4F5D0834.2050501@um.es> <4F5D30F1.4040808@um.es> <4F5E1A5C.3080209@um.es> <4F5E1F3D.5090909@um.es> <001e01cd00a7$cb0e8fc0$612baf40$@augustcellars.com> <000701cd025a$9cfb9ce0$d6f2d6a0$@augustcellars.com> <4F61D901.10004@deployingradius.com> <009201cd02c7$07188f90$1549aeb0$@augustcellars.com> <4F624402.4060801@deployingradius.com> <4F62519D.1080608@deployingradius.com> <4F633434.1020202@um.es> <4F6336B8.9060101@deployingradius.com> In-Reply-To: <4F6336B8.9060101@deployingradius.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] FYI: New Version Notification for draft-perez-radext-radius-fragmentation-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 13:01:54 -0000 > Alejandro Perez Mendez wrote: >> I do not see how this simplifies the flow. The number of messages are >> exactly the same, and there seem to not be much difference on the amount >> of state to be hold either. As I understand, the only difference is the >> pro-active nature of the request by the proxy. > The issue is that the proxy needs to have ALL of the SAML data before > it can rewrite ANY of it. Since the SAML data is spread over multiple > packets, the current near-stateless approach won't work. > > i.e. current proxies apply the same rewrite rules to every packet. > They don't change packet N+1 of a stream based on data seen in packet N. Sure, I got that part :) > >> What's the difference of doing that pro-actively or just waiting until >> the Access-Request from the client requesting the authorization data >> passed through the proxy? > Latency. When a client sends the first "get more data" packet, the > proxy CANNOT respond until it has ALL of the SAML data from the home > server. This may take a large number of round trips. During those > round trips, the client is waiting for a response to ONE packet. The > client will think that the proxy is unresponsive, or just very slow. So, basically we are saving some time, so when the client requests the data, the proxy may already have been received some fragments (may be not all) from the server. This reduces latency, but depending on the number of fragments, the client may need to wait anyway and think the proxy is unresponsive. > > Also, current proxy implementations are largely event-driven. They > receive a packet from a client, proxy it, receive the response, and send > that to the client. Changing the implementation is hard. Changing it > so that the event loop becomes "receive one packet, send many many > packets" can be challenging. Yes, but that should be done pro-actively or re-actively, either way. The only difference is what is triggering the several roundtrip exchange to retrive the data. In the pro-active mode is the presence of the Authorize-Only service type, indicating that *probably* the client will request for authorization data. In the re-active mode, the trigger is the actual Access-Request from the client requesting the data. Am I wrong? > > An explicitly decoupled approach can be simpler. I wouldn't say it's > a requirement. I would say it would be my preferred implementation. That's something I don't really know, as I never implemented a RADIUS server. If you say so, I'm completely confident :) Regards, Alejandro > > Alan DeKok. From hartmans@painless-security.com Fri Mar 16 07:51:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5150D21F8779 for ; Fri, 16 Mar 2012 07:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.285 X-Spam-Level: X-Spam-Status: No, score=-2.285 tagged_above=-999 required=5 tests=[AWL=-0.020, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 8lO4+dlHiR9i for ; Fri, 16 Mar 2012 07:51:30 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id D250021F8773 for ; Fri, 16 Mar 2012 07:51:29 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id B56F72023F; Fri, 16 Mar 2012 10:50:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 86B9A4767; Fri, 16 Mar 2012 10:51:14 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> Date: Fri, 16 Mar 2012 10:51:14 -0400 In-Reply-To: (Rafa Marin Lopez's message of "Fri, 16 Mar 2012 13:09:19 +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: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 14:51:31 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Personally, I would send a GSS token with the EAP Success and Rafa> the error code Authorization failed to the initiator. This Rafa> would allow the initiator to know that authentication was ok Rafa> but authorization failed. Thus, the initiator does not get Rafa> confused at all about what happened. I'd just send the error. EAP success doesn't actually allow you to know much of anything because it's pnot integrity-protected from the EAP server. You need to send it in success cases so the state machines are in sync. From rafa@um.es Fri Mar 16 08:01:53 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895FE21F8735 for ; Fri, 16 Mar 2012 08:01:53 -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 jovDcAUXAhTt for ; Fri, 16 Mar 2012 08:01:52 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C221F86B2 for ; Fri, 16 Mar 2012 08:01:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 996DD536B1; Fri, 16 Mar 2012 16:01:51 +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 pCf2TKQITUNE; Fri, 16 Mar 2012 16:01:51 +0100 (CET) Received: from inf-205-67.inf.um.es (inf-205-67.inf.um.es [155.54.205.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id B7C165368F; Fri, 16 Mar 2012 16:01:47 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Fri, 16 Mar 2012 16:01:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1257) Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:01:53 -0000 Hi Sam:=20 El 16/03/2012, a las 15:51, Sam Hartman escribi=F3: >>>>>> "Rafa" =3D=3D Rafa Marin Lopez writes: >=20 >=20 > Rafa> Personally, I would send a GSS token with the EAP Success and > Rafa> the error code Authorization failed to the initiator. This > Rafa> would allow the initiator to know that authentication was ok > Rafa> but authorization failed. Thus, the initiator does not get > Rafa> confused at all about what happened. >=20 > I'd just send the error. > EAP success doesn't actually allow you to know much of anything = because > it's pnot integrity-protected from the EAP server. It is just a matter to be coherent with each part. If the EAP = authentication is successful why do not to state so? > You need to send it in success cases so the state machines are in = sync. Precisely because of that, I believe EAP success should reach the EAP = peer state machine. If the authentication is succesful the EAP success = should reach the EAP state machine to move it to the final state. And if = the authorization is not, the error code Authorization fail is sent in = the GSS-EAP. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From hartmans@painless-security.com Fri Mar 16 08:46:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DD921F866D for ; Fri, 16 Mar 2012 08:46:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 AZVeVDrrHP1A for ; Fri, 16 Mar 2012 08:46:02 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 083B921F86B5 for ; Fri, 16 Mar 2012 08:46:02 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 5051420289; Fri, 16 Mar 2012 11:45:29 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1EFDF4767; Fri, 16 Mar 2012 11:45:44 -0400 (EDT) From: Sam Hartman To: Rafa Marin Lopez References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> Date: Fri, 16 Mar 2012 11:45:44 -0400 In-Reply-To: (Rafa Marin Lopez's message of "Fri, 16 Mar 2012 16:01:47 +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=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 15:46:03 -0000 >>>>> "Rafa" == Rafa Marin Lopez writes: Rafa> Hi Sam: El 16/03/2012, a las 15:51, Sam Hartman escribió: >>>>>>> "Rafa" == Rafa Marin Lopez writes: >> >> Rafa> Personally, I would send a GSS token with the EAP Success and Rafa> the error code Authorization failed to the initiator. This Rafa> would allow the initiator to know that authentication was ok Rafa> but authorization failed. Thus, the initiator does not get Rafa> confused at all about what happened. >> >> I'd just send the error. EAP success doesn't actually allow you >> to know much of anything because it's pnot integrity-protected >> from the EAP server. Rafa> It is just a matter to be coherent with each part. If the EAP Rafa> authentication is successful why do not to state so? Because it's none of the peer's business whether the access is being denied for an authorization or authentication reason. Also, peers have to be able to deal with the case where the EAP message is absent, so that code path is going to be better tested. From rafa@um.es Fri Mar 16 09:37:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5E121F85B4 for ; Fri, 16 Mar 2012 09:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.932 X-Spam-Level: X-Spam-Status: No, score=-5.932 tagged_above=-999 required=5 tests=[AWL=0.667, 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 oC9owV+JaJMq for ; Fri, 16 Mar 2012 09:37:22 -0700 (PDT) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE2221F8597 for ; Fri, 16 Mar 2012 09:37:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id B1814536AB; Fri, 16 Mar 2012 17:37:21 +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 lRlirPgN5jFt; Fri, 16 Mar 2012 17:37:21 +0100 (CET) Received: from inf-205-67.inf.um.es (inf-205-67.inf.um.es [155.54.205.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id 7C7E1535E8; Fri, 16 Mar 2012 17:37:17 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Fri, 16 Mar 2012 17:37:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <19A69BF5-8A6A-46E9-A6A2-45EFBC1A1129@um.es> References: <20120312115935.20797.19077.idtracker@ietfa.amsl.com> <000801cd026e$19e4b710$4dae2530$@augustcellars.com> <4F61A2BB.5070408@um.es> <4F61E97E.3050602@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1257) Cc: abfab@ietf.org Subject: Re: [abfab] I-D Action: draft-ietf-abfab-aaa-saml-03.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 16:37:23 -0000 Hi Sam: >=20 > Rafa> It is just a matter to be coherent with each part. If the EAP > Rafa> authentication is successful why do not to state so? >=20 > Because it's none of the peer's business whether the access is being > denied for an authorization or authentication reason. Not sure if I agree with that in all use cases...=20 > Also, peers have > to be able to deal with the case where the EAP message is absent, so > that code path is going to be better tested. Following that reasoning, perhaps we should consider both options since = they may be both possible. If the EAP server sends the EAP success = ("Access-Reject/EAP-Message/EAP Success" case) I think the acceptor = should not remove the EAP success and send it to the initiator. In fact, = the acceptor as EAP authenticator should not care about what the EAP = server is sending to the EAP peer, and just paying attention to what the = AAA server is sending to the acceptor via AAA protocol. If we have = "Access-Reject/no EAP-Message attribute" case the initiator will not = receive the EAP success. But this is not problematic either, due to the = initiator can send an AltReject to the EAP peer state machine (due to = Authorization failed error code is set) to stop it and inform about such = situation. In conclusion, if you think that by not sending the EAP success to the = initiator will simplify implementations, that is fine with me. Although = it would be interesting to know if existing RADIUS server = implementations will support any of the cases :). Best regards. ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From ietf@augustcellars.com Fri Mar 16 10:34:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE01E21F8667 for ; Fri, 16 Mar 2012 10:34: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 wPIAewTWuz89 for ; Fri, 16 Mar 2012 10:34:15 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 264AC21F85CC for ; Fri, 16 Mar 2012 10:34:15 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 892372CA37; Fri, 16 Mar 2012 10:34:13 -0700 (PDT) From: "Jim Schaad" To: "Sam Hartman" , Date: Fri, 16 Mar 2012 10:33:18 -0700 Message-ID: <007e01cd039a$e51de140$af59a3c0$@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: Ac0DQARII93oayqiQJmHovfmlXpj2A== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments on abfab-gss-eap-naming-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:34:15 -0000 Sam & Josh, This document looks good, only a couple of issues most of which are probably not too contentious. In terms of tone, I am making the assumption that there is nothing in the naming that prevents a set as well as a get for many of the properties. I am not sure that it makes any sense to do a set for SAML Attributes and maybe Name Identifiers, just the entire SAML statement. That could potentially be done via the RADIUS attribute and just say that all of the fed-saml-* names are read-only names. I don't know if this is a GSS-API concept or not. Jim Major: 1. In section 5 - I believe the following text should be added to the last paragraph. "If more than one attribute for the name exists in the packet, a multi-valued value is returned." 2. In section 5 - What text do we need to put in here about the temporal nature of the values? I assume, but don't know, that all of the values would be wiped out and a new set of values would be populated when, and if, a new RADIUS response is received. An alternative would be to state that only some values are over-written - either a specific set or those with new values. I do not believe that we generally want to always just append values together. This would lead to possibly n State attribute values, one for every RADIUS message pair exchanged. 3. In section 5 - Is there a need for the Code of the last packet to be retrievable from the GSS-API interface? This is not currently doable. 4. In section 5/6.1 - There is a restriction on getting the SAML assertion via the fed-saml-assertion name. Does the same restriction exist if the value is retrieved via the radius-attr name? 5. In section 6 - Is there a need to distinguish between the an empty AttributeValue and a Nil AttributeValue. There is text in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not reflected in section 6.2. Minor: 1. In section 4 para #5 - I think that s/MUST not/MUST NOT/ - however - how would that GSS-API code be able to possibly enforce the requirement? From hartmans@painless-security.com Fri Mar 16 10:53:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652D821F86D7 for ; Fri, 16 Mar 2012 10:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 wdzYhxkaEhHC for ; Fri, 16 Mar 2012 10:53:40 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7B21F86CB for ; Fri, 16 Mar 2012 10:53:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 4BE46203BA; Fri, 16 Mar 2012 13:53:10 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id BC0894767; Fri, 16 Mar 2012 13:53:24 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <007e01cd039a$e51de140$af59a3c0$@augustcellars.com> Date: Fri, 16 Mar 2012 13:53:24 -0400 In-Reply-To: <007e01cd039a$e51de140$af59a3c0$@augustcellars.com> (Jim Schaad's message of "Fri, 16 Mar 2012 10:33:18 -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: abfab@ietf.org Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 17:53:41 -0000 >>>>> "Jim" == Jim Schaad writes: I think it's up to an implementation whether it chooses to let you set them. For most of these I would not expect setting to work. What affect would you expect setting the RADIUS name to have? Jim> Major: Jim> 1. In section 5 - I believe the following text should be added Jim> to the last paragraph. "If more than one attribute for the Jim> name exists in the packet, a multi-valued value is returned." Agreed. Jim> 2. In section 5 - What text do we need to put in here about the Jim> temporal nature of the values? I assume, but don't know, that Jim> all of the values would be wiped out and a new set of values Jim> would be populated when, and if, a new RADIUS response is Jim> received. An alternative would be to state that only some Jim> values are over-written - either a specific set or those with Jim> new values. I do not believe that we generally want to always Jim> just append values together. This would lead to possibly n Jim> State attribute values, one for every RADIUS message pair Jim> exchanged. OK. So with regard to SAML things I think the text for this belongs in draft-ietf-abfab-aaa-saml. For the RADIUS attributes, I think the answer belongs in this draft and should be that only attributes in an access-accept are expected to be in the name. Jim> 3. In section 5 - Is there a need for the Code of the last Jim> packet to be retrievable from the GSS-API interface? This is Jim> not currently doable. What do you mean code? access-accept? Again, my assumption was that you'd really only look at the initiator name after gss_accept_sec_context returned success. Jim> 4. In section 5/6.1 - There is a restriction on getting the Jim> SAML assertion via the fed-saml-assertion name. Does the same Jim> restriction exist if the value is retrieved via the radius-attr Jim> name? What restriction are you talking about? Jim> 5. In section 6 - Is there a need to distinguish between the an Jim> empty AttributeValue and a Nil AttributeValue. There is text Jim> in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not Jim> reflected in section 6.2. Minor: Scott? Jim> 1. In section 4 para #5 - I think that s/MUST not/MUST NOT/ - Jim> however - how would that GSS-API code be able to possibly Jim> enforce the requirement? Well, the reason to include the normative language here is so applications know what they can assume. However, I think the same restriction needs to be repeated in draft-ietf-abfab-aaa-saml about putting SAML messages in those specific RADIUS attributes. I.E. new attributes will be required for a new context. In terms of how you implement it, things like Moonshot's freeradius SAML integration should only use the attributes defined in aaa-saml for federated context assertions from the IDP unless the RADIUS server is configured to re-assert/vouch for these attributes. From cantor.2@osu.edu Fri Mar 16 11:17:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AD521E8059 for ; Fri, 16 Mar 2012 11:17: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 owXW1Ig7lFj1 for ; Fri, 16 Mar 2012 11:17:41 -0700 (PDT) Received: from defang22.it.ohio-state.edu (defang22.it.ohio-state.edu [128.146.216.225]) by ietfa.amsl.com (Postfix) with ESMTP id DC77321F8636 for ; Fri, 16 Mar 2012 11:17:40 -0700 (PDT) Received: from CIO-KRC-HT01.osuad.osu.edu (cio-krc-ht01.osuad.osu.edu [164.107.81.37]) by defang22.it.ohio-state.edu (8.13.1/8.13.1) with ESMTP id q2GIHWuF012959; Fri, 16 Mar 2012 14:17:38 -0400 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.01.0355.002; Fri, 16 Mar 2012 14:17:32 -0400 From: "Cantor, Scott" To: Sam Hartman , Jim Schaad Thread-Topic: [abfab] Comments on abfab-gss-eap-naming-02 Thread-Index: Ac0DQARII93oayqiQJmHovfmlXpj2AAXbhwjAADT+QA= Date: Fri, 16 Mar 2012 18:17:31 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.146.178.9] Content-Type: text/plain; charset="us-ascii" Content-ID: <03ED9B9DB153444694860BFFD8B0DF3D@exchange.osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CanIt-Geo: ip=164.107.81.37; country=US; region=OH; city=Wooster; postalcode=44691; latitude=40.8077; longitude=-81.9730; metrocode=510; areacode=330; http://maps.google.com/maps?q=40.8077,-81.9730&z=6 X-CanItPRO-Stream: outbound X-Scanned-By: CanIt (www . roaringpenguin . com) on 128.146.216.225 Cc: "abfab@ietf.org" Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:17:41 -0000 On 3/16/12 1:53 PM, "Sam Hartman" wrote: > > Jim> 5. In section 6 - Is there a need to distinguish between the an > Jim> empty AttributeValue and a Nil AttributeValue. There is text > Jim> in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not > Jim> reflected in section 6.2. Minor: > >Scott? The current text in 6.2 talks about whether the value is "simple" AND "is a text node or nodes". I suspect the simplest way to address this is to tweak the text to say: "If the value is not simple or is empty, then..." That will result in the serialization just capturing the element, and since I don't know of any use cases for "nil" anyway, that avoids any extra work to handle that case. -- Scott From ietf@augustcellars.com Fri Mar 16 11:28:33 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585DC21E806A for ; Fri, 16 Mar 2012 11:28:33 -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 d0wGDRA1IIgL for ; Fri, 16 Mar 2012 11:28:32 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8D53B21E8059 for ; Fri, 16 Mar 2012 11:28:32 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 EB5B638F27; Fri, 16 Mar 2012 11:28:30 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <007e01cd039a$e51de140$af59a3c0$@augustcellars.com> In-Reply-To: Date: Fri, 16 Mar 2012 11:27:39 -0700 Message-ID: <008e01cd03a2$7a9dce40$6fd96ac0$@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: AQIwjpAxq/PQ+lppJFSYZhT6Nv4xZgDeJDKxlZ8xNdA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:28:33 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Friday, March 16, 2012 10:53 AM > To: Jim Schaad > Cc: josh.howlett@ja.net; abfab@ietf.org > Subject: Re: Comments on abfab-gss-eap-naming-02 > > >>>>> "Jim" == Jim Schaad writes: > > > I think it's up to an implementation whether it chooses to let you set them. > For most of these I would not expect setting to work. > What affect would you expect setting the RADIUS name to have? Probably nothing good. Your right which elements one can set need to be setup on a case by case basis. The problem is that one kind of needs a blanket statement for every RADIUS attribute that the code does not know about. > > Jim> Major: > > Jim> 1. In section 5 - I believe the following text should be added > Jim> to the last paragraph. "If more than one attribute for the > Jim> name exists in the packet, a multi-valued value is returned." > > Agreed. > > Jim> 2. In section 5 - What text do we need to put in here about the > Jim> temporal nature of the values? I assume, but don't know, that > Jim> all of the values would be wiped out and a new set of values > Jim> would be populated when, and if, a new RADIUS response is > Jim> received. An alternative would be to state that only some > Jim> values are over-written - either a specific set or those with > Jim> new values. I do not believe that we generally want to always > Jim> just append values together. This would lead to possibly n > Jim> State attribute values, one for every RADIUS message pair > Jim> exchanged. > > OK. So with regard to SAML things I think the text for this belongs in draft- > ietf-abfab-aaa-saml. > For the RADIUS attributes, I think the answer belongs in this draft and should > be that only attributes in an access-accept are expected to be in the name. That would be reasonable (for SAML), but you don't have any reference in that direction or (I think) back in this direction. Saying that you only have access to the attributes in the access-accept message partly solves this question. It depends on if you think that secondary conversations can occur after the EAP wrapper message. For example, if the RP wanted to send an updated SAML request, would you expect that it goes via the GSS-API or should a direct AAA interface be used. I think that one might also set some RAIDUS attributes before the message is sent out to the AAA side in order to control specific things. They might be vender specific. A SAML AuthnRequest might be one. Also I don't know how one would affect the AAA logic selection rules but that might be a third area that could be treated in this manner. > > Jim> 3. In section 5 - Is there a need for the Code of the last > Jim> packet to be retrievable from the GSS-API interface? This is > Jim> not currently doable. > > What do you mean code? > access-accept? > Again, my assumption was that you'd really only look at the initiator name > after gss_accept_sec_context returned success. > > Jim> 4. In section 5/6.1 - There is a restriction on getting the > Jim> SAML assertion via the fed-saml-assertion name. Does the same > Jim> restriction exist if the value is retrieved via the radius-attr > Jim> name? > > What restriction are you talking about? There is a local policy check on assertions - It would be on attributes and name ids and might be on the entire SAML assertion. > > Jim> 5. In section 6 - Is there a need to distinguish between the an > Jim> empty AttributeValue and a Nil AttributeValue. There is text > Jim> in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not > Jim> reflected in section 6.2. Minor: > > Scott? > > Jim> 1. In section 4 para #5 - I think that s/MUST not/MUST NOT/ - > Jim> however - how would that GSS-API code be able to possibly > Jim> enforce the requirement? > > Well, the reason to include the normative language here is so applications > know what they can assume. > However, I think the same restriction needs to be repeated in draft-ietf- > abfab-aaa-saml about putting SAML messages in those specific RADIUS > attributes. > I.E. new attributes will be required for a new context. > > In terms of how you implement it, things like Moonshot's freeradius SAML > integration should only use the attributes defined in aaa-saml for federated > context assertions from the IDP unless the RADIUS server is configured to re- > assert/vouch for these attributes. I would feel more comfortable if this statement as a protocol restriction were placed in the main document then. To say that the names must not be used for attributes issued by a party other than on closely associated with the source of credentials would appear to make it something that the GSS-API code on my side should be able to enforce. I do not believe that it has any ability to do anything but assume that this was done by the IdP/AAA server side and assign the names willy-nilly. You description above would support that assertion. jim From ietf@augustcellars.com Fri Mar 16 11:38:59 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9991D21F8417 for ; Fri, 16 Mar 2012 11:38:59 -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 GLFFZ2MyMaHr for ; Fri, 16 Mar 2012 11:38:58 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBFD21F842C for ; Fri, 16 Mar 2012 11:38:47 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 74EDB38EFE; Fri, 16 Mar 2012 11:38:44 -0700 (PDT) From: "Jim Schaad" To: "'Cantor, Scott'" , "'Sam Hartman'" References: In-Reply-To: Date: Fri, 16 Mar 2012 11:37:52 -0700 Message-ID: <008f01cd03a3$e8dad320$ba907960$@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: AQJVYFlJyN8GV1yEzhk/UjG9L6Q2AZVchwGw Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 18:38:59 -0000 > -----Original Message----- > From: Cantor, Scott [mailto:cantor.2@osu.edu] > Sent: Friday, March 16, 2012 11:18 AM > To: Sam Hartman; Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02 > > On 3/16/12 1:53 PM, "Sam Hartman" > wrote: > > > > Jim> 5. In section 6 - Is there a need to distinguish between the an > > Jim> empty AttributeValue and a Nil AttributeValue. There is text > > Jim> in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not > > Jim> reflected in section 6.2. Minor: > > > >Scott? > > The current text in 6.2 talks about whether the value is "simple" AND "is a > text node or nodes". I suspect the simplest way to address this is to tweak > the text to say: > > "If the value is not simple or is empty, then..." > > That will result in the serialization just capturing the element, and since I > don't know of any use cases for "nil" anyway, that avoids any extra work to > handle that case. > > -- Scott This sounds very reasonable to me. Jim From hartmans@painless-security.com Fri Mar 16 12:16:49 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A4221F8639 for ; Fri, 16 Mar 2012 12:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 jFWOoKu4-6QZ for ; Fri, 16 Mar 2012 12:16:48 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5B121F858B for ; Fri, 16 Mar 2012 12:16:48 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (carter-zimmerman.suchdamage.org [69.25.196.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id E715A20289; Fri, 16 Mar 2012 15:16:17 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 9544C4767; Fri, 16 Mar 2012 15:16:31 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <007e01cd039a$e51de140$af59a3c0$@augustcellars.com> <008e01cd03a2$7a9dce40$6fd96ac0$@augustcellars.com> Date: Fri, 16 Mar 2012 15:16:31 -0400 In-Reply-To: <008e01cd03a2$7a9dce40$6fd96ac0$@augustcellars.com> (Jim Schaad's message of "Fri, 16 Mar 2012 11:27:39 -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: abfab@ietf.org Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 19:16:49 -0000 >>>>> "Jim" == Jim Schaad writes: >> -----Original Message----- From: Sam Hartman >> [mailto:hartmans@painless-security.com] Sent: Friday, March 16, >> 2012 10:53 AM To: Jim Schaad Cc: josh.howlett@ja.net; >> abfab@ietf.org Subject: Re: Comments on abfab-gss-eap-naming-02 >> >> >>>>> "Jim" == Jim Schaad writes: >> >> >> I think it's up to an implementation whether it chooses to let >> you set Jim> them. >> For most of these I would not expect setting to work. What >> affect would you expect setting the RADIUS name to have? Jim> Probably nothing good. Your right which elements one can set Jim> need to be setup on a case by case basis. The problem is that Jim> one kind of needs a blanket statement for every RADIUS Jim> attribute that the code does not know about. Well, no, I mean even more basic than that. You set a RADIUs attribute. Are you expecting the code to do something with that like send it to the RADIUS server? I'd expect that it would go via the GSS-API. I'd prefer to leave behavior regarding that undefined in this document because we don't have enough experience with it to specify behavior today. >> Jim> 3. In section 5 - Is there a need for the Code of the last Jim> packet to be retrievable from the GSS-API interface? This is Jim> not currently doable. >> >> What do you mean code? access-accept? Again, my assumption was >> that you'd really only look at the initiator name after >> gss_accept_sec_context returned success. >> Jim> 4. In section 5/6.1 - There is a restriction on getting the Jim> SAML assertion via the fed-saml-assertion name. Does the same Jim> restriction exist if the value is retrieved via the radius-attr Jim> name? >> >> What restriction are you talking about? Jim> There is a local policy check on assertions - It would be on Jim> attributes and name ids and might be on the entire SAML Jim> assertion. I'd assume the RADIUS attribute would still be present even if this check failed. However I'd prefer not to mandate that here. >> Jim> 5. In section 6 - Is there a need to distinguish between the an Jim> empty AttributeValue and a Nil AttributeValue. There is text Jim> in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not Jim> reflected in section 6.2. Minor: >> >> Scott? >> Jim> 1. In section 4 para #5 - I think that s/MUST not/MUST NOT/ - Jim> however - how would that GSS-API code be able to possibly Jim> enforce the requirement? >> >> Well, the reason to include the normative language here is so >> applications know what they can assume. However, I think the >> same restriction needs to be repeated in draft-ietf- >> abfab-aaa-saml about putting SAML messages in those specific >> RADIUS attributes. I.E. new attributes will be required for a >> new context. >> >> In terms of how you implement it, things like Moonshot's >> freeradius SAML integration should only use the attributes >> defined in aaa-saml for Jim> federated >> context assertions from the IDP unless the RADIUS server is >> configured to Jim> re- >> assert/vouch for these attributes. Jim> I would feel more comfortable if this statement as a protocol Jim> restriction were placed in the main document then. To say that Jim> the names must not be used for attributes issued by a party Jim> other than on closely associated with the source of credentials Jim> would appear to make it something that the GSS-API code on my Jim> side should be able to enforce. I do not believe that it has Jim> any ability to do anything but assume that this was done by the Jim> IdP/AAA server side and assign the names willy-nilly. You Jim> description above would support that assertion. So, I think if we add text to aaa-saml about the attribute use then this text makes sense. (I assume by main document you're talking about aaa-saml not gss-eap.) I'd like to keep the text here as well as in aaa-saml because: 1) I think that a saml-ec implementation is in a position to enforce this in GSS-API 2) I think that this restriction is important for future GSS specs considering whether these attributes are appropriate 3) If we get right text into aaa-saml it's easy for a GSS EAP implementation to enforce this by only mapping the right RADIUS attributes. Thoughts? From ietf@augustcellars.com Fri Mar 16 12:40:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDC221E8068 for ; Fri, 16 Mar 2012 12:40:38 -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 zfe9eW6A2nWx for ; Fri, 16 Mar 2012 12:40:37 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 90A0A21E801A for ; Fri, 16 Mar 2012 12:40:37 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (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 7711D38EA7; Fri, 16 Mar 2012 12:40:35 -0700 (PDT) From: "Jim Schaad" To: "'Sam Hartman'" References: <007e01cd039a$e51de140$af59a3c0$@augustcellars.com> <008e01cd03a2$7a9dce40$6fd96ac0$@augustcellars.com> In-Reply-To: Date: Fri, 16 Mar 2012 12:39:43 -0700 Message-ID: <00a201cd03ac$8c4235a0$a4c6a0e0$@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: AQIwjpAxq/PQ+lppJFSYZhT6Nv4xZgDeJDKxAUyeDpACmMqPx5WAHm2Q Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Comments on abfab-gss-eap-naming-02 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Mar 2012 19:40:38 -0000 > -----Original Message----- > From: Sam Hartman [mailto:hartmans@painless-security.com] > Sent: Friday, March 16, 2012 12:17 PM > To: Jim Schaad > Cc: josh.howlett@ja.net; abfab@ietf.org > Subject: Re: Comments on abfab-gss-eap-naming-02 > > >>>>> "Jim" == Jim Schaad writes: > > >> -----Original Message----- From: Sam Hartman > >> [mailto:hartmans@painless-security.com] Sent: Friday, March 16, > >> 2012 10:53 AM To: Jim Schaad Cc: josh.howlett@ja.net; > >> abfab@ietf.org Subject: Re: Comments on abfab-gss-eap-naming-02 > >> > >> >>>>> "Jim" == Jim Schaad writes: > >> > >> > >> I think it's up to an implementation whether it chooses to let > >> you set > Jim> them. > >> For most of these I would not expect setting to work. What > >> affect would you expect setting the RADIUS name to have? > > Jim> Probably nothing good. Your right which elements one can set > Jim> need to be setup on a case by case basis. The problem is that > Jim> one kind of needs a blanket statement for every RADIUS > Jim> attribute that the code does not know about. > > Well, no, I mean even more basic than that. > You set a RADIUs attribute. > Are you expecting the code to do something with that like send it to the > RADIUS server? > > I'd expect that it would go via the GSS-API. > I'd prefer to leave behavior regarding that undefined in this document > because we don't have enough experience with it to specify behavior today. > That is fine, I was just looking at various things. I am happy with allowing the precise behavior to slide at the moment. However I think that if we ever expect to have multiple of something over time that behavior should at least be said as unspecified at this time. > >> > Jim> 3. In section 5 - Is there a need for the Code of the last > Jim> packet to be retrievable from the GSS-API interface? This is > Jim> not currently doable. > >> > >> What do you mean code? access-accept? Again, my assumption was > >> that you'd really only look at the initiator name after > >> gss_accept_sec_context returned success. > >> > Jim> 4. In section 5/6.1 - There is a restriction on getting the > Jim> SAML assertion via the fed-saml-assertion name. Does the same > Jim> restriction exist if the value is retrieved via the radius-attr > Jim> name? > >> > >> What restriction are you talking about? > > Jim> There is a local policy check on assertions - It would be on > Jim> attributes and name ids and might be on the entire SAML > Jim> assertion. > > I'd assume the RADIUS attribute would still be present even if this check > failed. > However I'd prefer not to mandate that here. That is fine. I was more worried about the opposite case - i.e. that the RADIUS attribute SHOULD be hidden. > > >> > Jim> 5. In section 6 - Is there a need to distinguish between the an > Jim> empty AttributeValue and a Nil AttributeValue. There is text > Jim> in 2.7.3.1 of SAML-CORE-2.0 that does so, but it is not > Jim> reflected in section 6.2. Minor: > >> > >> Scott? > >> > Jim> 1. In section 4 para #5 - I think that s/MUST not/MUST NOT/ - > Jim> however - how would that GSS-API code be able to possibly > Jim> enforce the requirement? > >> > >> Well, the reason to include the normative language here is so > >> applications know what they can assume. However, I think the > >> same restriction needs to be repeated in draft-ietf- > >> abfab-aaa-saml about putting SAML messages in those specific > >> RADIUS attributes. I.E. new attributes will be required for a > >> new context. > >> > >> In terms of how you implement it, things like Moonshot's > >> freeradius SAML integration should only use the attributes > >> defined in aaa-saml for > Jim> federated > >> context assertions from the IDP unless the RADIUS server is > >> configured to > Jim> re- > >> assert/vouch for these attributes. > > Jim> I would feel more comfortable if this statement as a protocol > Jim> restriction were placed in the main document then. To say that > Jim> the names must not be used for attributes issued by a party > Jim> other than on closely associated with the source of credentials > Jim> would appear to make it something that the GSS-API code on my > Jim> side should be able to enforce. I do not believe that it has > Jim> any ability to do anything but assume that this was done by the > Jim> IdP/AAA server side and assign the names willy-nilly. You > Jim> description above would support that assertion. > > So, I think if we add text to aaa-saml about the attribute use then this text > makes sense. > (I assume by main document you're talking about aaa-saml not gss-eap.) No I was talking about gss-eap since it would be applicable for both RADIUS attributes and SAML attributes. > > I'd like to keep the text here as well as in aaa-saml because: > > 1) I think that a saml-ec implementation is in a position to enforce this in GSS- > API > > 2) I think that this restriction is important for future GSS specs considering > whether these attributes are appropriate > > 3) If we get right text into aaa-saml it's easy for a GSS EAP implementation to > enforce this by only mapping the right RADIUS attributes. > > Thoughts? Other than I think that would should state the same thing in GSS-EAP if it is not already there, I would agree that this is fine. Jim From trac+abfab@trac.tools.ietf.org Sat Mar 17 22:40:52 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E63121F84FD for ; Sat, 17 Mar 2012 22:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 aAMNgma3PcHc for ; Sat, 17 Mar 2012 22:40:51 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2466E21F84F9 for ; Sat, 17 Mar 2012 22:40:49 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S98qq-0002UO-Nq; Sun, 18 Mar 2012 01:40:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 18 Mar 2012 05:40:20 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/20#comment:2 Message-ID: <077.abcbae3dafd1251614474641050cb3f9@trac.tools.ietf.org> References: <062.cfa02a9afc09132a4c9e05582acc5b72@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 In-Reply-To: <062.cfa02a9afc09132a4c9e05582acc5b72@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120318054051.2466E21F84F9@ietfa.amsl.com> Resent-Date: Sat, 17 Mar 2012 22:40:49 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #20: Section 1.4 - digaram correction X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 05:40:52 -0000 #20: Section 1.4 - digaram correction Changes (by ietf@…): * status: closed => reopened * resolution: fixed => Comment: Incorrect formatting - The (11) is not really in the column, and the comment should be in the far left column -- ---------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: reopened Priority: trivial | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | ---------------------+-------------------------------------- Ticket URL: abfab From ietf@augustcellars.com Sat Mar 17 22:49:34 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AE321F858B for ; Sat, 17 Mar 2012 22:49:34 -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 bLpXHfVS0lpj for ; Sat, 17 Mar 2012 22:49:33 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id B1CF621F8554 for ; Sat, 17 Mar 2012 22:49:33 -0700 (PDT) Received: from Tobias (unknown [68.25.130.116]) (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 245BC38EFF; Sat, 17 Mar 2012 22:49:26 -0700 (PDT) From: "Jim Schaad" To: Date: Sat, 17 Mar 2012 22:48:35 -0700 Message-ID: <011801cd04ca$c4f7ee20$4ee7ca60$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac0EyrYLik4pCvrrQFWyshS6Sz71CQ== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Who write section 2.4 of the -00 draft of the architecture document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 05:49:34 -0000 I want to pop this up with a different title so that we can make sure = people are actually going to see the message and what happened because = of it. =20 Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of abfab issue tracker > Sent: Saturday, March 10, 2012 2:33 AM > To: draft-ietf-abfab-arch@tools.ietf.org; hannes.tschofenig@gmx.net > Cc: abfab@ietf.org > Subject: Re: [abfab] #25: Section 2.4 - Section title is confusing >=20 > #25: Section 2.4 - Section title is confusing >=20 >=20 > Comment (by hannes.tschofenig@ ): >=20 > I agree with the comment. The title and the content of the section is > confusing. >=20 > For version -01 I omit this section since I don't understand it = either. > I suggest to re-introduce this section once we know what to say. >=20 > Who wrote this section? >=20 > -- > --------------------+-------------------------------------- > Reporter: ietf@ | Owner: draft-ietf-abfab-arch@ > Type: defect | Status: new > Priority: minor | Milestone: > Component: arch | Version: > Severity: - | Resolution: > Keywords: | > --------------------+-------------------------------------- >=20 > Ticket URL: = > abfab >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From trac+abfab@trac.tools.ietf.org Sat Mar 17 23:26:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A02D11E8081 for ; Sat, 17 Mar 2012 23:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 5mvjeNp0WPeX for ; Sat, 17 Mar 2012 23:26:46 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC9B11E8076 for ; Sat, 17 Mar 2012 23:26:43 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1S99ZZ-0001gl-F2; Sun, 18 Mar 2012 02:26:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "abfab issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com X-Trac-Project: abfab Date: Sun, 18 Mar 2012 06:26:33 -0000 X-URL: http://tools.ietf.org/abfab/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/abfab/trac/ticket/28#comment:2 Message-ID: <077.56965797c5c5a4cef4c1915f068074d6@trac.tools.ietf.org> References: <062.6d0caaa3bde28c503e5a4879aaaf29db@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <062.6d0caaa3bde28c503e5a4879aaaf29db@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-abfab-arch@tools.ietf.org, hannes.tschofenig@gmx.net, ietf@augustcellars.com, abfab@ietf.org X-SA-Exim-Mail-From: trac+abfab@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120318062643.2FC9B11E8076@ietfa.amsl.com> Resent-Date: Sat, 17 Mar 2012 23:26:43 -0700 (PDT) Resent-From: trac+abfab@trac.tools.ietf.org Cc: abfab@ietf.org Subject: Re: [abfab] #28: Missing Security Consideration - AAA protection of the MSK X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 06:26:46 -0000 #28: Missing Security Consideration - AAA protection of the MSK Changes (by ietf@…): * status: closed => reopened * resolution: fixed => Comment: You did in fact make the general change that was requested, however I think this needs to be an extremely explicit statement on the lack of protection. Currently text in -01 requires that the reader knit this together from Client <-> RP no security until the MSK is sent from the IdP RP <-> IdP Everything is point to point. I thin that in the RP <-> IdP the text should include Since all of the security is provided on a Point-to-Point bases, and the RP cannot know if the message is seen by a AAA proxy, there is always a possibility that a AAA proxy can break the security. -- --------------------+-------------------------------------- Reporter: ietf@… | Owner: draft-ietf-abfab-arch@… Type: defect | Status: reopened Priority: major | Milestone: Component: arch | Version: Severity: - | Resolution: Keywords: | --------------------+-------------------------------------- Ticket URL: abfab From Josh.Howlett@ja.net Sun Mar 18 06:37:13 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AA3C21F864F for ; Sun, 18 Mar 2012 06:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.607 X-Spam-Level: X-Spam-Status: No, score=-102.607 tagged_above=-999 required=5 tests=[AWL=-0.008, 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 PYIB5dRKcJxG for ; Sun, 18 Mar 2012 06:37:13 -0700 (PDT) Received: from egw002.ukerna.ac.uk (egw002.ukerna.ac.uk [194.81.3.65]) by ietfa.amsl.com (Postfix) with ESMTP id B5AED21F864B for ; Sun, 18 Mar 2012 06:37:12 -0700 (PDT) Received: from egw002.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id DA6B020C7359_F65E504B; Sun, 18 Mar 2012 13:37:08 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk (exc001.atlas.ukerna.ac.uk [193.62.83.37]) by egw002.ukerna.ac.uk (Sophos Email Appliance) with ESMTP id 1CA7720C710B_F65E504F; Sun, 18 Mar 2012 13:37:08 +0000 (GMT) Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.01.0355.002; Sun, 18 Mar 2012 13:37:07 +0000 From: Josh Howlett To: Jim Schaad , "hannes.tschofenig@gmx.net" Thread-Topic: [abfab] Who write section 2.4 of the -00 draft of the architecture document Thread-Index: AQHNBQw1goQXtEldRU6V1qolEFPzzw== Date: Sun, 18 Mar 2012 13:37:06 +0000 Message-ID: In-Reply-To: <011801cd04ca$c4f7ee20$4ee7ca60$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Who write section 2.4 of the -00 draft of the architecture document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 13:37:13 -0000 Guilty. I now think its superfluous/orthogonal; I have no objection to its removal and would probably prefer that. Josh. On 18/03/2012 05:48, "Jim Schaad" wrote: >I want to pop this up with a different title so that we can make sure >people are actually going to see the message and what happened because of >it.=20=20 > >Jim > > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf >> Of abfab issue tracker >> Sent: Saturday, March 10, 2012 2:33 AM >> To: draft-ietf-abfab-arch@tools.ietf.org; hannes.tschofenig@gmx.net >> Cc: abfab@ietf.org >> Subject: Re: [abfab] #25: Section 2.4 - Section title is confusing >>=20 >> #25: Section 2.4 - Section title is confusing >>=20 >>=20 >> Comment (by hannes.tschofenig@ ): >>=20 >> I agree with the comment. The title and the content of the section is >> confusing. >>=20 >> For version -01 I omit this section since I don't understand it either. >> I suggest to re-introduce this section once we know what to say. >>=20 >> Who wrote this section? >>=20 >> -- >> --------------------+-------------------------------------- >> Reporter: ietf@ | Owner: draft-ietf-abfab-arch@ >> Type: defect | Status: new >> Priority: minor | Milestone: >> Component: arch | Version: >> Severity: - | Resolution: >> Keywords: | >> --------------------+-------------------------------------- >>=20 >> Ticket URL:=20 >> >> abfab >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > >_______________________________________________ >abfab mailing list >abfab@ietf.org >https://www.ietf.org/mailman/listinfo/abfab Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From wei.yinxing@zte.com.cn Wed Mar 21 20:03:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33A621F8648 for ; Wed, 21 Mar 2012 20:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.381 X-Spam-Level: X-Spam-Status: No, score=-97.381 tagged_above=-999 required=5 tests=[AWL=-2.346, BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 Q-BsLpJGptg8 for ; Wed, 21 Mar 2012 20:03:14 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 07E8C21F8646 for ; Wed, 21 Mar 2012 20:03:13 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 12280967931198; Thu, 22 Mar 2012 10:28:09 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 19209.1614906896; Thu, 22 Mar 2012 11:02:51 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id q2M32wab028045; Thu, 22 Mar 2012 11:02:58 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Rafa Marin Lopez MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Thu, 22 Mar 2012 10:58:47 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-22 11:02:59, Serialize complete at 2012-03-22 11:02:59 Content-Type: multipart/alternative; boundary="=_alternative 00112630482579C9_=" X-MAIL: mse01.zte.com.cn q2M32wab028045 Cc: abfab@ietf.org Subject: Re: [abfab] draft-wei-abfab-fcla-02 is posted (fast re-auth) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 03:03:15 -0000 This is a multipart message in MIME format. --=_alternative 00112630482579C9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJhZmE6DQoNCiAgVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzIQ0KICBGYXN0IHJlLWF1dGhl bnRpY2F0aW9uIGlzIG9uZSBwcm9taXNpbmcgbWVjaGFuaXNtIHRvIHJlZHVjZSB0aGUgZGVsYXkg aW4gDQphY2Nlc3MgYXV0aGVudGljYXRpb24uDQogIFlvdSBoYXZlIHBvaW50ZWQgb3V0IHRoZSBw b3NzaWJsZSB3YXlzIGZvciB0aGlzIHNjZW5hcmlvIGluIGFiZmFio7oNCiAgLSBwcm9ibGVtIHN0 YXRtZW50LCByZXF1aXJlbWVudCwgc29sdXRpb24oMS4gZXh0ZW5kIEdTUy1FQVAsIG9yIDIuIA0K Y3JlYXRlIGEgR1NTLUVSUCBtZWNoYW5pc20pDQogDQogIFlvdXIgc3VnZ2VzdGlvbiBpcyBmaW5l IGZvciBtZS4NCg0KLS0tLS0tLS0tLS0tDQpZaW54aW5nIFdlaQ0KDQoNCg0KDQoNClJhZmEgTWFy aW4gTG9wZXogPHJhZmFAdW0uZXM+IA0KMjAxMi8wMy8xMiAyMDoxNg0KDQrK1bz+yMsNCndlaS55 aW54aW5nQHp0ZS5jb20uY24NCrOty80NClJhZmEgTWFyaW4gTG9wZXogPHJhZmFAdW0uZXM+LCBh YmZhYkBpZXRmLm9yZw0K1vfM4g0KUmU6IFthYmZhYl0gIGRyYWZ0LXdlaS1hYmZhYi1mY2xhLTAy IGlzIHBvc3RlZCAoZmFzdCByZS1hdXRoKQ0KDQoNCg0KDQoNCg0KSGkgWWlueGluZzoNCg0KSSBo YXZlIHNlZW4gdGhhdCB5b3UgaGF2ZSBhbHNvIG1lbnRpb25lZCBhbmQgZGVzY3JpYmVkIHRoZSBw cm9ibGVtIG9mIGZhc3QgDQpyZS1hdXRoZW50aWNhdGlvbiBpbiB5b3VyIEktRC4gV2UgaGF2ZSBi ZWVuIGp1c3QgZGlzY3Vzc2luZyBhcyB5b3UgbWF5IA0KaGF2ZSBub3RpY2VkLg0KDQpBbHRob3Vn aCBJIGFtIHN0aWxsIGluIGZhdm9yIHRvIGRlZmluZSBhIGdlbmVyYWwgcHJvYmxlbSBzdGF0ZW1l bnQgZm9yIA0KdGhpcyBpbiBBQkZBQiBiZWZvcmUgZ29pbmcgdG8gc29sdXRpb24gc3BhY2UsIEkg bXVzdCBzYXkgdGhhdCBoZXJlIGluIFVNVSANCndlIGhhdmUgYmVlbiB0aGlua2luZyBhYm91dCBh IHBvc3NpYmxlIHNvbHV0aW9uIGZvciBwcm92aWRpbmcgdGhpcyBmYXN0IA0KcmUtYXV0aGVudGlj YXRpb24gcHJvY2VkdXJlLCB3aGljaCBtYXkgaGF2ZSBzb21lIHNpbWlsYXJpdGllcyB3aXRoIHlv dXJzLg0KDQpCYXNpY2FsbHksIHNpbmNlIEdTUy1FQVAgaXMgdXNlZCBpbiBBQkZBQiB0byBwcm92 aWRlIGF1dGhlbnRpY2F0aW9uLCBvdXIgDQppZGVhIGlzIHRvIHVzZSBFUlAgKFJGQyA1Mjk2KSAo YW5kIHRoZSBhc3NvY2lhdGVkIGluZnJhc3RydWN0dXJlKSB0byANCnByb3ZpZGUgZmFzdCByZS1h dXRoZW50aWNhdGlvbiBpbiBBQkZBQi4gQWZ0ZXIgYWxsLCBFUlAgaXMgdGhlIHN0YW5kYXJkIHRv IA0KcmVkdWNlIHRoZSBhdXRoZW50aWNhdGlvbiB0aW1lIGluIEVBUC1iYXNlZCBhdXRoZW50aWNh dGlvbnMuDQoNCkluIHRoaXMgd2F5LCB3ZSBjb3VsZCBleHRlbmQgR1NTLUVBUCBvciBjcmVhdGUg YSBHU1MtRVJQIG1lY2hhbmlzbSB0byANCnRyYW5zcG9ydCBFUlAgbWVzc2FnZXMgd2l0aGluIEdT UyB0b2tlbnMuIFNvbWV0aGluZyBsaWtlOg0KDQoNCiAxLiBJbml0aWF0b3IgLS0+IEFjY2VwdG9y OiAgR1NTLUVBUCAoRUFQIEluaXRpYXRlL1JlLWF1dGgoU0VRLCANCmtleU5hbWUtTkFJLA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBjcnlwdG9zdWl0ZSxBdXRoLXRhZyopKSANCg0K ICAgMWEuIEFjY2VwdG9yIC0tPiBFUi1TZXJ2ZXI6IEFBQS1SZXF1ZXN0e0F1dGhlbnRpY2F0b3It SWQsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEVBUCBJbml0aWF0ZS9SZS1hdXRo KFNFUSxrZXlOYW1lLU5BSSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3J5cHRv c3VpdGUsQXV0aC10YWcqKQ0KDQogICAyLiBFUi1TZXJ2ZXIgLS0+IEFjY2VwdG9yOiBBQUEtUmVz cG9uc2V7ck1TSywNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRUFQLUZpbmlzaC9S ZS1hdXRoKFNFUSxrZXlOYW1lLU5BSSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Y3J5cHRvc3VpdGUsW0NCLUluZm9dLEF1dGgtdGFnKikNCg0KICAgMmIuIEFjY2VwdG9yIC0tPiBJ bml0aWF0b3I6IEdTUy1FQVAgDQooRUFQLUZpbmlzaC9SZS1hdXRoKFNFUSxrZXlOYW1lLU5BSSwN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgY3J5cHRvc3VpdGUsW0NCLUluZm9dLEF1 dGgtdGFnKikpDQoNCg0KRXZlbiB0aGUgRVItU2VydmVyIGNvdWxkIGJlIHBsYWNlZCBuZWFyIHRo ZSBzZXJ2ZXIgKGxvY2FsIEVSIHNlcnZlcikgDQpyZWR1Y2luZyB0aGUgdHJhdmVsIHRpbWUgb2Yg dGhlIG1lc3NhZ2VzLiANCg0KT2J2aW91c2x5IHRoaXMgaXMganVzdCBhbiBpZGVhLCB3aGljaCBu ZWVkcyB0byBiZSBlbGFib3JhdGVkIGFuZCANCmRpc2N1c3NlZC4gSW4gZmFjdCwgYXMgSSBzYWlk LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBzdGFydCANCmRlZmluaW5nIGEgcHJvYmxl bSBzdGF0ZW1lbnQsIHJlcXVpcmVtZW50cyBldGMuLi4gZm9yIGZhc3QgDQpyZS1hdXRoZW50aWNh dGlvbiBpbiBBQkZBQi4gVU1VIHdvdWxkIGJlIHdpbGxpbmcgdG8gd29yayBvbiB0aGF0Lg0KDQpC ZXN0IHJlZ2FyZHMuDQoNCkVsIDEyLzAzLzIwMTIsIGEgbGFzIDEwOjE4LCB3ZWkueWlueGluZ0B6 dGUuY29tLmNuIGVzY3JpYmmorjoNCg0KDQpIaSwgYWxsIA0KDQogIEFuIHVwZGF0ZWQgdmVyc2lv biBvZiBGZWRlcmF0ZWQgQ3Jvc3MtTGF5ZXIgQWNjZXNzIA0KKGRyYWZ0LXdlaS1hYmZhYi1mY2xh LTAyKSBpcyBwb3N0ZWQuIA0KICBUaGUgbWFqb3IgY2hhbmdlcyBpcyBpbiBjbGF1c3QgNCA6IA0K IC0gNC4gbWVzc2FnZSBmbG93IA0KIC0gNC4xIGZhc3QgcmUtYXV0aGVudGljYXRpb24gDQogLSA0 LjIgc2VjdXJlIGRhdGEgc2hhcmluZyANCg0KaGVyZSBpcyB0aGUgZHJhZnQ6IA0KICBodHRwOi8v d3d3LmlldGYub3JnL2lkL2RyYWZ0LXdlaS1hYmZhYi1mY2xhLTAyLnR4dCANCg0KQW55IGNvbW1l bnRzIGFyZSBhcHByZWNpYXRlZCEgDQoNCi0tLS0tLS0tLS0tLS0gDQpZaW54aW5nIFdlaQ0KDQph YmZhYiBtYWlsaW5nIGxpc3QNCmFiZmFiQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FiZmFiDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClJhZmFlbCBNYXJpbiBMb3BleiwgUGhEDQpEZXB0LiBJ bmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcgKERJSUMpDQpGYWN1bHR5 IG9mIENvbXB1dGVyIFNjaWVuY2UtVW5pdmVyc2l0eSBvZiBNdXJjaWENCjMwMTAwIE11cmNpYSAt IFNwYWluDQpUZWxmOiArMzQ4Njg4ODg1MDEgRmF4OiArMzQ4Njg4ODQxNTEgZS1tYWlsOiByYWZh QHVtLmVzDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQoNCg0KDQoNCg0K --=_alternative 00112630482579C9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSYWZhOjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFRoYW5rcyBmb3Ig eW91ciBjb21tZW50cyE8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyBGYXN0IHJlLWF1dGhlbnRpY2F0aW9uIGlzIG9uZQ0KcHJvbWlzaW5nIG1lY2hhbmlz bSB0byByZWR1Y2UgdGhlIGRlbGF5IGluIGFjY2VzcyBhdXRoZW50aWNhdGlvbi48L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBZb3UgaGF2ZSBwb2ludGVk IG91dCB0aGUgcG9zc2libGUNCndheXMgZm9yIHRoaXMgc2NlbmFyaW8gaW4gYWJmYWKjujwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IC0gcHJvYmxlbSBz dGF0bWVudCwgcmVxdWlyZW1lbnQsDQpzb2x1dGlvbigxLiBleHRlbmQgR1NTLUVBUCwgb3IgMi4g Y3JlYXRlIGEgR1NTLUVSUCBtZWNoYW5pc20pPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyBZb3VyIHN1Z2dlc3Rpb24gaXMgZmluZSBmb3IgbWUuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLS0tLS0tLS08L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPllpbnhpbmcgV2VpPC9mb250Pg0K PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxi PlJhZmEgTWFyaW4gTG9wZXogJmx0O3JhZmFAdW0uZXMmZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTIvMDMvMTIgMjA6MTY8L2ZvbnQ+DQo8dGQg d2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxk aXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+d2VpLnlpbnhpbmdA enRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmFmYSBNYXJpbiBMb3BleiAmbHQ7cmFmYUB1 bS5lcyZndDssDQphYmZhYkBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9u dD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFthYmZhYl0g Jm5ic3A7ZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDINCmlzIHBvc3RlZCAoZmFzdCByZS1hdXRoKTwv Zm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+ PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mz5IaSBZ aW54aW5nOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+SSBoYXZlIHNlZW4gdGhhdCB5 b3UgaGF2ZSBhbHNvIG1lbnRpb25lZCBhbmQgZGVzY3JpYmVkDQp0aGUgcHJvYmxlbSBvZiBmYXN0 IHJlLWF1dGhlbnRpY2F0aW9uIGluIHlvdXIgSS1ELiBXZSBoYXZlIGJlZW4ganVzdCBkaXNjdXNz aW5nDQphcyB5b3UgbWF5IGhhdmUgbm90aWNlZC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zPkFsdGhvdWdoIEkgYW0gc3RpbGwgaW4gZmF2b3IgdG8gZGVmaW5lIGEgZ2VuZXJhbCBwcm9i bGVtDQpzdGF0ZW1lbnQgZm9yIHRoaXMgaW4gQUJGQUIgYmVmb3JlIGdvaW5nIHRvIHNvbHV0aW9u IHNwYWNlLCBJIG11c3Qgc2F5DQp0aGF0IGhlcmUgaW4gVU1VIHdlIGhhdmUgYmVlbiB0aGlua2lu ZyBhYm91dCBhIHBvc3NpYmxlIHNvbHV0aW9uIGZvciBwcm92aWRpbmcNCnRoaXMgZmFzdCByZS1h dXRoZW50aWNhdGlvbiBwcm9jZWR1cmUsIHdoaWNoIG1heSBoYXZlIHNvbWUgc2ltaWxhcml0aWVz DQp3aXRoIHlvdXJzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTM+QmFzaWNhbGx5LCBz aW5jZSBHU1MtRUFQIGlzIHVzZWQgaW4gQUJGQUIgdG8gcHJvdmlkZSBhdXRoZW50aWNhdGlvbiwN Cm91ciBpZGVhIGlzIHRvIHVzZSBFUlAgKFJGQyA1Mjk2KSAoYW5kIHRoZSBhc3NvY2lhdGVkIGlu ZnJhc3RydWN0dXJlKSB0bw0KcHJvdmlkZSBmYXN0IHJlLWF1dGhlbnRpY2F0aW9uIGluIEFCRkFC LiBBZnRlciBhbGwsIEVSUCBpcyB0aGUgc3RhbmRhcmQNCnRvIHJlZHVjZSB0aGUgYXV0aGVudGlj YXRpb24gdGltZSBpbiBFQVAtYmFzZWQgYXV0aGVudGljYXRpb25zLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTM+SW4gdGhpcyB3YXksIHdlIGNvdWxkIGV4dGVuZCBHU1MtRUFQIG9yIGNy ZWF0ZSBhIEdTUy1FUlANCm1lY2hhbmlzbSB0byB0cmFuc3BvcnQgRVJQIG1lc3NhZ2VzIHdpdGhp biBHU1MgdG9rZW5zLiBTb21ldGhpbmcgbGlrZTo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIj4mbmJzcDsxLiBJbml0aWF0b3IgLS0mZ3Q7IEFjY2VwdG9y OiAmbmJzcDtHU1MtRUFQDQooRUFQIEluaXRpYXRlL1JlLWF1dGgoU0VRLCBrZXlOYW1lLU5BSSw8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwO2NyeXB0b3N1aXRlLEF1dGgtdGFnKikpIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMiPjxicj4NCiAmbmJzcDsgMWEuIEFjY2VwdG9yIC0tJmd0OyBFUi1TZXJ2ZXI6IEFB QS1SZXF1ZXN0e0F1dGhlbnRpY2F0b3ItSWQsPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtFQVAgSW5pdGlhdGUvUmUtYXV0aChTRVEs a2V5TmFtZS1OQUksPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtjcnlwdG9zdWl0ZSxBdXRoLXRhZyopPGJyPg0KPGJyPg0KICZuYnNw OyAyLiBFUi1TZXJ2ZXIgLS0mZ3Q7IEFjY2VwdG9yOiBBQUEtUmVzcG9uc2V7ck1TSyw8YnI+DQog Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0VB UC1GaW5pc2gvUmUtYXV0aChTRVEsa2V5TmFtZS1OQUksPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjcnlwdG9zdWl0ZSxbQ0ItSW5m b10sQXV0aC10YWcqKTxicj4NCjxicj4NCiAmbmJzcDsgMmIuIEFjY2VwdG9yIC0tJmd0OyBJbml0 aWF0b3I6IEdTUy1FQVAgKEVBUC1GaW5pc2gvUmUtYXV0aChTRVEsa2V5TmFtZS1OQUksPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtj cnlwdG9zdWl0ZSxbQ0ItSW5mb10sQXV0aC10YWcqKSk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0zPkV2ZW4gdGhlIEVSLVNlcnZlciBjb3VsZCBiZSBwbGFjZWQgbmVhciB0aGUg c2VydmVyIChsb2NhbA0KRVIgc2VydmVyKSByZWR1Y2luZyB0aGUgdHJhdmVsIHRpbWUgb2YgdGhl IG1lc3NhZ2VzLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPk9idmlvdXNseSB0aGlz IGlzIGp1c3QgYW4gaWRlYSwgd2hpY2ggbmVlZHMgdG8gYmUgZWxhYm9yYXRlZA0KYW5kIGRpc2N1 c3NlZC4gSW4gZmFjdCwgYXMgSSBzYWlkLCBJIHRoaW5rIGl0IHdvdWxkIGJlIGJldHRlciB0byBz dGFydA0KZGVmaW5pbmcgYSBwcm9ibGVtIHN0YXRlbWVudCwgcmVxdWlyZW1lbnRzIGV0Yy4uLiBm b3IgZmFzdCByZS1hdXRoZW50aWNhdGlvbg0KaW4gQUJGQUIuIFVNVSB3b3VsZCBiZSB3aWxsaW5n IHRvIHdvcmsgb24gdGhhdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkJlc3QgcmVn YXJkcy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPkVsIDEyLzAzLzIwMTIsIGEgbGFz IDEwOjE4LCA8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86d2VpLnlpbnhpbmdAenRlLmNvbS5jbj48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZT48dT53ZWkueWlueGluZ0B6dGUuY29tLmNuPC91PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0zPg0KZXNjcmliaaiuOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTI+PHR0Pjxicj4NCkhpLCBhbGw8L3R0PjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9u dD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiAmbmJzcDtBbiB1cGRhdGVkIHZlcnNpb24gb2YgRmVk ZXJhdGVkIENyb3NzLUxheWVyIEFjY2VzcyAoZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDIpDQppcyBw b3N0ZWQuPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD48 YnI+DQogJm5ic3A7VGhlIG1ham9yIGNoYW5nZXMgaXMgaW4gY2xhdXN0IDQgOjwvdHQ+PC9mb250 Pjxmb250IHNpemU9Mz4gPC9mb250Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KIC0gNC4gbWVzc2Fn ZSBmbG93PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD48 YnI+DQogLSA0LjEgZmFzdCByZS1hdXRoZW50aWNhdGlvbjwvdHQ+PC9mb250Pjxmb250IHNpemU9 Mz4gPC9mb250Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KIC0gNC4yIHNlY3VyZSBkYXRhIHNoYXJp bmc8L3R0PjwvZm9udD48Zm9udCBzaXplPTM+IDxicj4NCjwvZm9udD48Zm9udCBzaXplPTI+PHR0 Pjxicj4NCmhlcmUgaXMgdGhlIGRyYWZ0OjwvdHQ+PC9mb250Pjxmb250IHNpemU9Mz4gPC9mb250 Pjxmb250IHNpemU9Mj48dHQ+PGJyPg0KICZuYnNwOzwvdHQ+PC9mb250PjxhIGhyZWY9Imh0dHA6 Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDIudHh0Ij48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZT48dHQ+PHU+aHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC13ZWktYWJm YWItZmNsYS0wMi50eHQ8L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4NCjxicj4NCjwv Zm9udD48Zm9udCBzaXplPTI+PHR0Pjxicj4NCkFueSBjb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQh PC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8YnI+DQo8L2ZvbnQ+PGZvbnQgc2l6ZT0yPjx0dD48 YnI+DQotLS0tLS0tLS0tLS0tPC90dD48L2ZvbnQ+PGZvbnQgc2l6ZT0zPiA8L2ZvbnQ+PGZvbnQg c2l6ZT0yPjx0dD48YnI+DQpZaW54aW5nIFdlaTwvdHQ+PC9mb250Pjxmb250IHNpemU9Mz48YnI+ DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPmFiZmFiIG1haWxpbmcgbGlzdDwvZm9udD48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZT48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOmFi ZmFiQGlldGYub3JnPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1PmFiZmFiQGlldGYub3JnPC91 PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYWJmYWI8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNv dXJpZXIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIiPlJhZmFlbCBNYXJp biBMb3BleiwgUGhEPC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJDb3VyaWVyIj5EZXB0 LiBJbmZvcm1hdGlvbiBhbmQgQ29tbXVuaWNhdGlvbnMgRW5naW5lZXJpbmcNCihESUlDKTwvZm9u dD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iQ291cmllciI+RmFjdWx0eSBvZiBDb21wdXRlciBT Y2llbmNlLVVuaXZlcnNpdHkNCm9mIE11cmNpYTwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iQ291cmllciI+MzAxMDAgTXVyY2lhIC0gU3BhaW48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IkNvdXJpZXIiPlRlbGY6ICszNDg2ODg4ODUwMSBGYXg6ICszNDg2ODg4NDE1MSBlLW1h aWw6DQo8L2ZvbnQ+PGEgaHJlZj1tYWlsdG86cmFmYUB1bS5lcz48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZSBmYWNlPSJDb3VyaWVyIj48dT5yYWZhQHVtLmVzPC91PjwvZm9udD48L2E+DQo8YnI+PGZv bnQgc2l6ZT0zIGZhY2U9IkNvdXJpZXIiPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo= --=_alternative 00112630482579C9_=-- From wei.yinxing@zte.com.cn Wed Mar 21 20:42:18 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C69F21E8094; Wed, 21 Mar 2012 20:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.749 X-Spam-Level: X-Spam-Status: No, score=-96.749 tagged_above=-999 required=5 tests=[AWL=-1.414, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_SEX=2.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 qMOhr7fbLfNT; Wed, 21 Mar 2012 20:42:18 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2FF21E8054; Wed, 21 Mar 2012 20:42:14 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 122802100040734; Thu, 22 Mar 2012 11:07:58 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 84000.4119498997; Thu, 22 Mar 2012 11:42:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id q2M3g41C057271; Thu, 22 Mar 2012 11:42:04 +0800 (GMT-8) (envelope-from wei.yinxing@zte.com.cn) In-Reply-To: To: Sam Hartman MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: wei.yinxing@zte.com.cn Date: Thu, 22 Mar 2012 11:37:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2012-03-22 11:42:06, Serialize complete at 2012-03-22 11:42:06 Content-Type: multipart/alternative; boundary="=_alternative 0014BB17482579C9_=" X-MAIL: mse02.zte.com.cn q2M3g41C057271 Cc: "abfab@ietf.org" , abfab-bounces@ietf.org Subject: Re: [abfab] draft-wei-abfab-fcla-02 is posted (fast re-auth) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 03:42:18 -0000 This is a multipart message in MIME format. --=_alternative 0014BB17482579C9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 ICAgICBIaSwgU2FtOg0KDQogICAgIENvbW1lbnRzIGZvciBjbGFyaWZpY2F0aW9uLg0KDQogICAg IEluIFJGQzI3NDMoR1NTLUFQSSksIHRoZXJlIGFyZSBzb21lIHNlY2VudGVuY2VzOg0KICAgICAg IFA0ICJUaGUgc2VjdXJpdHkgc2VydmljZXMgYXZhaWxhYmxlIHRocm91Z2ggR1NTLUFQSSBhcmUg DQppbXBsZW1lbnRhYmxlIG92ZXIgYSANCiAgICAgICByYW5nZSBvZiB1bmRlcmx5aW5nIG1lY2hh bmlzbXMgYmFzZWQgb24gc2VjcmV0LWtleSBhbmQgcHVibGljLWtleSANCmNyeXB0b2dyYXBoaWMg dGVjaG5vbGlnZXMiLg0KDQogICAgICAgUDg4ICJDbGF1c2UgNSwgTWVjaGFuaXNtLXNwZWNpZmlj IGV4YW1wbGUgc2NlbmFyaW9zDQogICAgICAgNS4xIEtlcmJlcm9zIFY1IA0KICAgICAgIDUuMyBY LjUwOSBBdXRoZW50aWNhdGlvbiBGcmFtZXdvcmsiDQogDQogICAgIEFjY29yZGluZyB0byB0aGUg dGV4dCBhYm92ZSwgbXkgdW5kZXJzdGFuZGluZyBpcyB0aGF0IEdTUy1BUEkgY2FuIA0Kc3VwcG9y dA0KICAgICBhIHNldCBvZiBzZWN1cml0eSBtZWNoYW5pc21zLCBpdCBpcyBOT1QgbGltaXRlZCBp bnRvIHRoZSBzaW5nbGUgDQpLZXJiZXJvcw0KICAgICBtZWNoYW5pc21zLiANCg0KICAgICBJbiBS RkM1Mjk2KEVSUCksIGl0IHNheXMgIjMuIEVSUCBEZXNjcmlwdGlvbiANCiAgICAgLi4uIEVSUCBp cyBhIHNpbmdsZSByb3VuZC10cmlwIGV4Y2hhbmdlIGJldHdlZW4gdGhlIHBlZXIgYW5kIHRoZSAN CnNlcnZlcjsgDQogICAgIGl0IGlzIGluZGVwZW5kZW50IG9mIHRoZSBsb3dlciBsYXllciBhbmQg dGhlIEVBUCBtZXRob2QgdXNlZCBkdXJpbmcgDQogICAgIHRoZSBmdWxsIEVBUCBleGNoYW5nZS4i IA0KICAgICBZb3Ugd3JvdGUgIkVSUC0taXQncyBqdXN0IGFub3RoZXIgRUFQIG1ldGhvZCBhZnRl ciBhbGwiLiANCg0KICAgICBJIGFtIG5vdCBzdXJlIHdoZXRoZXIgdGhleSBhcmUgY29uc2lzdGVu dC4gDQoNCi0tLS0tLS0tLS0tLQ0KWWlueGluZyBXZWkNCg0KDQoNCg0KU2FtIEhhcnRtYW4gPGhh cnRtYW5zQHBhaW5sZXNzLXNlY3VyaXR5LmNvbT4gDQq3orz+yMs6ICBhYmZhYi1ib3VuY2VzQGll dGYub3JnDQoyMDEyLzAzLzEyIDIxOjQwDQoNCsrVvP7Iyw0KUmFmYSBNYXJpbiBMb3BleiA8cmFm YUB1bS5lcz4NCrOty80NCiJhYmZhYkBpZXRmLm9yZyIgPGFiZmFiQGlldGYub3JnPg0K1vfM4g0K UmU6IFthYmZhYl0gZHJhZnQtd2VpLWFiZmFiLWZjbGEtMDIgaXMgcG9zdGVkIChmYXN0IHJlLWF1 dGgpDQoNCg0KDQoNCg0KDQo+Pj4+PiAiUmFmYSIgPT0gUmFmYSBNYXJpbiBMb3BleiA8cmFmYUB1 bS5lcz4gd3JpdGVzOg0KDQogICAgUmFmYT4gSGkgTHVrZTogVGhhdCBraW5kIG9mIGZhc3QgcmUt YXV0aCBiYXNlZCBvbiBLZXJiZXJvcyBpcyBhbHNvDQogICAgUmFmYT4gaW50cmluc2ljIHRvIGRy YWZ0LXBlcmV6LWFiZmFiLWVhcC1nc3MtcHJlYXV0aC0wMQ0KDQogICAgUmFmYT4gQmVzdCByZWdh cmRzLg0KDQogICAgUmFmYT4gRWwgMTIvMDMvMjAxMiwgYSBsYXMgMTM6MTgsIEx1a2UgSG93YXJk IGVzY3JpYmkgOg0KDQpSaWdodC4gIEknZCBwcmVmZXIgdG8gZm9jdXMgb24gdGhlIEtlcmJlcm9z LWJhc2VkIGFwcHJvYWNoZXMgYmVjYXVzZSB3ZQ0KaGF2ZSBhIGxvdCBvZiBleHBlcmllbmNlIHdp dGggdGhlbSAodGhlIE1vb25zaG90IGltcGxlbWVudGF0aW9uIGFuZCB5b3VyDQppbXBsZW1lbnRh dGlvbikgYW5kIGJlY2F1c2UgdGhleSBzZWVtIHRvIGJlIHJhdGhlciBzaW1wbGUuICBJIHRoaW5r IGZvcg0KdGhlIHNvcnRzIG9mIHNlcnZpY2VzIHRoYXQgdXNlIEFCRkFCLCBFUlAgd291bGQgcmVx dWlyZSBtb3JlDQppbmZyYXN0cnVjdHVyZSBhbmQgbWlnaHQgYmUgbW9yZSBjb21wbGV4LiAgTm90 aGluZyBwcmVjbHVkZXMgdXNpbmcNCkVSUC0taXQncyBqdXN0IGFub3RoZXIgRUFQIG1ldGhvZCBh ZnRlciBhbGwuICBIb3dldmVyIGZvciBhcHBsaWNhdGlvbg0KYnJpZGdpbmcgaXQgc2VlbXMgbGlr ZSB0aGVyZSBhcmUgZW52aXJvbm1lbnRzIHdoZXJlIHRoZSB0d28gZGlyZWN0aW9ucw0Kd2UncmUg YWxyZWFkeSB3b3JraW5nIG9uIChnc3MtcHJlYXV0aCBhbmQgdGhlIHJlYXV0aCB3aXRoaW4gTW9v bnNob3QpDQphcmUgZmFyIG1vcmUgYXR0cmFjdGl2ZS4NCg0KLS1TYW0NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQphYmZhYiBtYWlsaW5nIGxpc3QNCmFi ZmFiQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FiZmFi DQoNCg0KDQo= --=_alternative 0014BB17482579C9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 SGksIFNhbTo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PiZuYnNwOyAmbmJzcDsgJm5ic3A7Q29tbWVudHMgZm9yIGNsYXJpZmljYXRpb24uPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZu YnNwO0luIFJGQzI3NDMoR1NTLUFQSSksDQp0aGVyZSBhcmUgc29tZSBzZWNlbnRlbmNlczo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwO1A0ICZxdW90O1RoZQ0Kc2VjdXJpdHkgc2VydmljZXMgYXZhaWxhYmxlIHRocm91 Z2ggR1NTLUFQSSBhcmUgaW1wbGVtZW50YWJsZSBvdmVyIGEgPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtyYW5nZSBv Zg0KdW5kZXJseWluZyBtZWNoYW5pc21zIGJhc2VkIG9uIHNlY3JldC1rZXkgYW5kIHB1YmxpYy1r ZXkgY3J5cHRvZ3JhcGhpYw0KdGVjaG5vbGlnZXMmcXVvdDsuPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtQ ODggJnF1b3Q7Q2xhdXNlDQo1LCBNZWNoYW5pc20tc3BlY2lmaWMgZXhhbXBsZSBzY2VuYXJpb3M8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzUuMSBLZXJiZXJvcw0KVjUgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs1LjMgWC41MDkNCkF1 dGhlbnRpY2F0aW9uIEZyYW1ld29yayZxdW90OzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwO0FjY29yZGlu ZyB0byB0aGUNCnRleHQgYWJvdmUsIG15IHVuZGVyc3RhbmRpbmcgaXMgdGhhdCBHU1MtQVBJIGNh biBzdXBwb3J0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgJm5ic3A7ICZuYnNwO2Egc2V0IG9mIHNlY3VyaXR5DQptZWNoYW5pc21zLCBpdCBpcyBOT1Qg bGltaXRlZCBpbnRvIHRoZSBzaW5nbGUgS2VyYmVyb3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7bWVjaGFuaXNtcy4gPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7 ICZuYnNwO0luIFJGQzUyOTYoRVJQKSwNCml0IHNheXMgJnF1b3Q7My4gRVJQIERlc2NyaXB0aW9u IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsuLi4gRVJQIGlzIGEgc2luZ2xlDQpyb3VuZC10cmlwIGV4Y2hhbmdlIGJldHdlZW4g dGhlIHBlZXIgYW5kIHRoZSBzZXJ2ZXI7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtpdCBpcyBpbmRlcGVuZGVudA0Kb2YgdGhl IGxvd2VyIGxheWVyIGFuZCB0aGUgRUFQIG1ldGhvZCB1c2VkIGR1cmluZyA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7dGhlIGZ1 bGwgRUFQIGV4Y2hhbmdlLiZxdW90Ow0KJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7WW91IHdyb3RlICZx dW90O0VSUC0taXQncw0KanVzdCBhbm90aGVyIEVBUCBtZXRob2QgYWZ0ZXIgYWxsJnF1b3Q7LiA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgJm5ic3A7SSBhbSBub3Qgc3VyZSB3aGV0aGVyDQp0aGV5IGFyZSBjb25zaXN0ZW50LiA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tLS0t LS0tLTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+WWlueGluZyBX ZWk8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0 ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+PGI+U2FtIEhhcnRtYW4gJmx0O2hhcnRtYW5zQHBhaW5sZXNzLXNlY3VyaXR5LmNvbSZndDs8 L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7Iyzog Jm5ic3A7YWJmYWItYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj4yMDEyLzAzLzEyIDIxOjQwPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0 YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJhZmEgTWFyaW4gTG9wZXogJmx0O3JhZmFA dW0uZXMmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDthYmZhYkBpZXRmLm9yZyZxdW90OyAm bHQ7YWJmYWJAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW2FiZmFiXSBkcmFm dC13ZWktYWJmYWItZmNsYS0wMg0KaXMgcG9zdGVkIChmYXN0IHJlLWF1dGgpPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD4mZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmcXVvdDtSYWZhJnF1b3Q7ID09IFJhZmEgTWFyaW4NCkxvcGV6ICZsdDtyYWZh QHVtLmVzJmd0OyB3cml0ZXM6PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDtSYWZhJmd0OyBIaSBM dWtlOiBUaGF0IGtpbmQgb2YgZmFzdCByZS1hdXRoIGJhc2VkIG9uIEtlcmJlcm9zDQppcyBhbHNv PGJyPg0KICZuYnNwOyAmbmJzcDtSYWZhJmd0OyBpbnRyaW5zaWMgdG8gZHJhZnQtcGVyZXotYWJm YWItZWFwLWdzcy1wcmVhdXRoLTAxPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDtSYWZhJmd0OyBC ZXN0IHJlZ2FyZHMuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDtSYWZhJmd0OyBFbCAxMi8wMy8y MDEyLCBhIGxhcyAxMzoxOCwgTHVrZSBIb3dhcmQgZXNjcmliaQ0KOjxicj4NCjxicj4NClJpZ2h0 LiAmbmJzcDtJJ2QgcHJlZmVyIHRvIGZvY3VzIG9uIHRoZSBLZXJiZXJvcy1iYXNlZCBhcHByb2Fj aGVzIGJlY2F1c2UNCndlPGJyPg0KaGF2ZSBhIGxvdCBvZiBleHBlcmllbmNlIHdpdGggdGhlbSAo dGhlIE1vb25zaG90IGltcGxlbWVudGF0aW9uIGFuZCB5b3VyPGJyPg0KaW1wbGVtZW50YXRpb24p IGFuZCBiZWNhdXNlIHRoZXkgc2VlbSB0byBiZSByYXRoZXIgc2ltcGxlLiAmbmJzcDtJIHRoaW5r DQpmb3I8YnI+DQp0aGUgc29ydHMgb2Ygc2VydmljZXMgdGhhdCB1c2UgQUJGQUIsIEVSUCB3b3Vs ZCByZXF1aXJlIG1vcmU8YnI+DQppbmZyYXN0cnVjdHVyZSBhbmQgbWlnaHQgYmUgbW9yZSBjb21w bGV4LiAmbmJzcDtOb3RoaW5nIHByZWNsdWRlcyB1c2luZzxicj4NCkVSUC0taXQncyBqdXN0IGFu b3RoZXIgRUFQIG1ldGhvZCBhZnRlciBhbGwuICZuYnNwO0hvd2V2ZXIgZm9yIGFwcGxpY2F0aW9u PGJyPg0KYnJpZGdpbmcgaXQgc2VlbXMgbGlrZSB0aGVyZSBhcmUgZW52aXJvbm1lbnRzIHdoZXJl IHRoZSB0d28gZGlyZWN0aW9uczxicj4NCndlJ3JlIGFscmVhZHkgd29ya2luZyBvbiAoZ3NzLXBy ZWF1dGggYW5kIHRoZSByZWF1dGggd2l0aGluIE1vb25zaG90KTxicj4NCmFyZSBmYXIgbW9yZSBh dHRyYWN0aXZlLjxicj4NCjxicj4NCi0tU2FtPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQphYmZhYiBtYWlsaW5nIGxpc3Q8YnI+DQphYmZh YkBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWJm YWI8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCg== --=_alternative 0014BB17482579C9_=-- From ietf@augustcellars.com Wed Mar 21 21:40:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845E921E8121 for ; Wed, 21 Mar 2012 21:40:12 -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 JQJrQDFpJzXR for ; Wed, 21 Mar 2012 21:40:11 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id DA24C21E80EB for ; Wed, 21 Mar 2012 21:40:11 -0700 (PDT) Received: from Tobias (68-25-130-116.pools.static.spcsdns.net [68.25.130.116]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id AF11B38F14; Wed, 21 Mar 2012 21:40:10 -0700 (PDT) From: "Jim Schaad" To: Date: Wed, 21 Mar 2012 21:39:14 -0700 Message-ID: <007001cd07e5$c099e9f0$41cdbdd0$@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: Ac0E9ejMJF8N+TJ/TFGedek+c1DHeg== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] GSS-EAP-05 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Mar 2012 04:40:12 -0000 Yeah!!! The list is getting shorter. Jim Section 5.6.1 - Which mutual authentication has the initiator successfully performed? Section 5.6.2 - It says that one must send 4 octets of flags, but the flags field is descried as one octet in length. I suggest adding in the other 24 its as reserved Section 5.6.2 - I am having a problem understanding why this token is sent from the initiator to the acceptor. If one assumes that the problem is going to at the acceptor end rather than at the initiator end, then allowing the acceptor to do the check would appear to be problematic. Additionally, it appears that the check is "optional" for the acceptor to do, but not doing it is not reflected back to the initiator. Section 5.8 - If one is using a tunnel method, is the rule about dictionary attack resistance still true? Or do we say that is provided by the tunnel itself? I don't know that any change needs to be made for this. Minor: s/referrs/refers/ From hartmans@painless-security.com Sun Mar 25 06:55:24 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC721F84DD for ; Sun, 25 Mar 2012 06:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 LbcrUI5+ZHsX for ; Sun, 25 Mar 2012 06:55:24 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 2110621F84D9 for ; Sun, 25 Mar 2012 06:55:24 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id C2E0D2023F; Sun, 25 Mar 2012 09:54:40 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 6D1554766; Sun, 25 Mar 2012 09:55:17 -0400 (EDT) From: Sam Hartman To: "Jim Schaad" References: <007001cd07e5$c099e9f0$41cdbdd0$@augustcellars.com> Date: Sun, 25 Mar 2012 09:55:17 -0400 In-Reply-To: <007001cd07e5$c099e9f0$41cdbdd0$@augustcellars.com> (Jim Schaad's message of "Wed, 21 Mar 2012 21:39:14 -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: abfab@ietf.org, draft-ietf-abfab-eap@tools.ietf.org Subject: Re: [abfab] GSS-EAP-05 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 13:55:24 -0000 >>>>> "Jim" == Jim Schaad writes: Jim> Yeah!!! The list is getting shorter. Jim Jim> Section 5.6.1 - Which mutual authentication has the initiator Jim> successfully performed? initiator confirms identity of acceptor. That's what the mutual authentication service in RFC 2743 means. GSS is another protocol like EAP where mutual authentication is a synonym for server authentication. I've clarified in text and explained why the acceptor cares. Jim> Section 5.6.2 - It says that one must send 4 octets of flags, Jim> but the flags field is descried as one octet in length. I Jim> suggest adding in the other 24 its as reserved I'm confused because I tried to find a reference in 5.6.1 and 5..2 to one octet and couldn't find it. Would you be willing to more clearly indicate what text you're referring to? Jim> Section 5.6.2 - I am having a problem understanding why this Jim> token is sent from the initiator to the acceptor. If one Jim> assumes that the problem is going to at the acceptor end rather Jim> than at the initiator end, then allowing the acceptor to do the Jim> check would appear to be problematic. GSS channel bindings assume trust in both endpoints to verify that the channel containing the GSS context is the same at both endpoints. So, both the acceptor and initiator need to do the check. I haven't found a reason to believe one should be more trusted, but my track record on this sort of analysis is not great. However if you have found a problem here it's much bigger than GSS-EAP. Jim> Additionally, it appears Jim> that the check is "optional" for the acceptor to do, but not Jim> doing it is not reflected back to the initiator. True. That's how existing GSS mechanisms work. I don't particularly mind having a protocol level facility to reflect this back, but I wouldn't be able to do anything with the information in a GSS implementation. Jim> Section 5.8 - If one is using a tunnel method, is the rule Jim> about dictionary attack resistance still true? Or do we say Jim> that is provided by the tunnel itself? I don't know that any Jim> change needs to be made for this. The composition provides this protection if the tunnel is any good. From hartmans@painless-security.com Sun Mar 25 07:08:07 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9FD821F84C5 for ; Sun, 25 Mar 2012 07:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Cgu8pY2NQ9n7 for ; Sun, 25 Mar 2012 07:08:07 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id 77C1521F84AA for ; Sun, 25 Mar 2012 07:08:07 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-9251.meeting.ietf.org [130.129.10.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 96D4B202D8 for ; Sun, 25 Mar 2012 10:07:26 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 5FF3E4766; Sun, 25 Mar 2012 10:08:05 -0400 (EDT) From: Sam Hartman To: abfab@ietf.org Date: Sun, 25 Mar 2012 10:08:05 -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: [abfab] EAP applicability and ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 14:08:08 -0000 Hi. At the ABFAB BOF, we said that we would work on updating the EAP applicability statement in order to permit what we're doing. We included that in our charter. After the last meeting Stephen indicated he'd be OK with us doing a document that was very specific to ABFAB but was uncomfortable with the general document covering NEA, ABFAB and other uses. He seemed to question whether we actually needed to do this work. Things seem to have stalled. I'd really like to see this work get unstalled. It's my belief that a number of people (myself included) would have objected to the ABFAB charter if we didn't plan on doing this applicability work. I would strongly object to the IESG approving draft-ietf-abfab-gss-eap without a clear plan to update the applicability statement. I really don't want to be in a silly position like ending up filing an appeal on a document I edit. I'd really appreciate if we can all work together to unblock this issue and respect the desires of us who in good faith agreed to support ABFAB on the grounds that this work would be done. Thanks for your consideration, --Sam From leifj@sunet.se Sun Mar 25 13:27:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B12B21F8452 for ; Sun, 25 Mar 2012 13:27: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 j5zl6SC5aG8n for ; Sun, 25 Mar 2012 13:27:15 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id A86DC21F8446 for ; Sun, 25 Mar 2012 13:27:14 -0700 (PDT) Received: from [10.59.90.48] (access-49.80.rev.fr.colt.net [213.41.80.49]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2PKR8LV001909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sun, 25 Mar 2012 22:27:11 +0200 (CEST) Message-ID: <4F6F7F9C.1090400@sunet.se> Date: Sun, 25 Mar 2012 22:27:08 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] EAP applicability and ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:27:15 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/25/2012 04:08 PM, Sam Hartman wrote: > At the ABFAB BOF, we said that we would work on updating the EAP > applicability statement in order to permit what we're doing. We > included that in our charter. > > After the last meeting Stephen indicated he'd be OK with us doing > a document that was very specific to ABFAB but was uncomfortable > with the general document covering NEA, ABFAB and other uses. He > seemed to question whether we actually needed to do this work. I think Stephen was uncomfortable because there was no clear owner of a general applicability statement. My recollection is that Stefan and Joe agreed to split off the abfab bits into a separate eap-applicability statement particular to abfab. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9vf5sACgkQ8Jx8FtbMZneBbwCeN8mXtTJX+1kThxynsH77UAF6 sCsAn3BJt/UrAIMJQhRFT3yoLMEpw3DL =9gvr -----END PGP SIGNATURE----- From hartmans@painless-security.com Sun Mar 25 13:59:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D480D21E801A for ; Sun, 25 Mar 2012 13:59:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.988 X-Spam-Level: X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 UeyrjP6Q3gW2 for ; Sun, 25 Mar 2012 13:59:41 -0700 (PDT) Received: from permutation-city.suchdamage.org (permutation-city.suchdamage.org [69.25.196.28]) by ietfa.amsl.com (Postfix) with ESMTP id F028521E800C for ; Sun, 25 Mar 2012 13:59:40 -0700 (PDT) Received: from carter-zimmerman.suchdamage.org (dhcp-46bc.meeting.ietf.org [130.129.70.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.suchdamage.org (Postfix) with ESMTPS id 9CD14202D8; Sun, 25 Mar 2012 16:58:59 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 006DF4766; Sun, 25 Mar 2012 16:59:36 -0400 (EDT) From: Sam Hartman To: Leif Johansson References: <4F6F7F9C.1090400@sunet.se> Date: Sun, 25 Mar 2012 16:59:36 -0400 In-Reply-To: <4F6F7F9C.1090400@sunet.se> (Leif Johansson's message of "Sun, 25 Mar 2012 22:27:08 +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: abfab@ietf.org Subject: Re: [abfab] EAP applicability and ABFAB X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Mar 2012 20:59:41 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> My recollection is that Stefan and Joe agreed to split off the Leif> abfab bits into a separate eap-applicability statement Leif> particular to abfab. Ah, and that's the excellent news I didn't have! Thanks for filling me in. From leifj@sunet.se Mon Mar 26 00:20:13 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A1821F847C for ; Mon, 26 Mar 2012 00:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 BQApV-LrMHqV for ; Mon, 26 Mar 2012 00:20:13 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 7632921F846E for ; Mon, 26 Mar 2012 00:20:09 -0700 (PDT) Received: from [130.129.8.54] (dhcp-9036.meeting.ietf.org [130.129.8.54]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2Q7K3vZ004288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 26 Mar 2012 09:20:07 +0200 (CEST) Message-ID: <4F7018A3.3060006@sunet.se> Date: Mon, 26 Mar 2012 09:20:03 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] slides etc X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Mar 2012 07:20:14 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Those of you who are on the agenda for Paris should feel free to drop slides on me and/or Klaas. Our happiness and appreciation is a function of the time before meeting start t_{\delta}: appreciation = 1/e^{t_{\delta}} Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9wGKMACgkQ8Jx8FtbMZnd/DQCgycVpKQH31YzHICaN28JE4l9/ YFsAoJSna6RfSAL/KR0RuUAB/tFUn8cH =MMX3 -----END PGP SIGNATURE----- From smith@Cardiff.ac.uk Thu Mar 29 03:49:34 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E5E21F88AD for ; Thu, 29 Mar 2012 03:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.304 X-Spam-Level: X-Spam-Status: No, score=-5.304 tagged_above=-999 required=5 tests=[AWL=1.294, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-GVmPodSLyu for ; Thu, 29 Mar 2012 03:49:32 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFF121F848F for ; Thu, 29 Mar 2012 03:49:32 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1SDCtg-0005WF-KQ for abfab@ietf.org; Thu, 29 Mar 2012 11:49:20 +0100 Received: from [131.251.122.197] (helo=vpn-197.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SDCtg-0001oi-IO for abfab@ietf.org; Thu, 29 Mar 2012 11:48:04 +0100 From: Rhys Smith Content-Type: multipart/alternative; boundary="Apple-Mail=_04F77BF3-4975-4538-83CD-F8F5FBA9C23B" Date: Thu, 29 Mar 2012 12:48:04 +0200 References: <20120329104448.27463.67229.idtracker@ietfa.amsl.com> To: abfab@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: [abfab] Fwd: New Version Notification for draft-smith-abfab-usability-ui-considerations-01.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:49:34 -0000 --Apple-Mail=_04F77BF3-4975-4538-83CD-F8F5FBA9C23B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just posted -01 of the usability/ui considerations draft. It's the same = as -00, just reposting to make it current. I'm going to be working on this between now and IETF84 so any = comments/suggestions/criticisms would be great so I can use them when = carrying on with the document. This draft was mostly about figuring out the kind of things we need to = talk about regarding usability and UI shenanigans in an ABFAB world, the = text itself is still very draft where it exists at all. Thx, R. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's education and research network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-01.txt > Date: 29 March 2012 12:44:48 CEST > To: smith@cardiff.ac.uk >=20 > A new version of I-D, = draft-smith-abfab-usability-ui-considerations-01.txt has been = successfully submitted by Rhys Smith and posted to the IETF repository. >=20 > Filename: draft-smith-abfab-usability-ui-considerations > Revision: 01 > Title: Application Bridging for Federated Access = Beyond web (ABFAB) Usability and User Interface Considerations > Creation date: 2012-03-29 > WG ID: Individual Submission > Number of pages: 11 >=20 > Abstract: > The use of ABFAB-based technologies requires that each user's = machine > is configured with the user's identities. This will require > something on that machine which will manage the user's = identities and > services. Anyone designing that "something" will face the = same set > of challenges. This document aims to document these challenges with > the aim of producing well-thought out UIs with some consistency. >=20 >=20 >=20 >=20 > The IETF Secretariat --Apple-Mail=_04F77BF3-4975-4538-83CD-F8F5FBA9C23B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = posted -01 of the usability/ui considerations draft. It's the same as = -00, just reposting to make it current.

I'm going to = be working on this between now and IETF84 so any = comments/suggestions/criticisms would be great so I can use them when = carrying on with the document.

This draft was = mostly about figuring out the kind of things we need to talk about = regarding usability and UI shenanigans in an ABFAB world, the text = itself is still very draft where it exists at = all.

Thx,
R.
--
Dr Rhys Smith
Identity, Access, and = Middleware Specialist
Cardiff University & Janet - the UK's = education and research network
smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

Begin forwarded message:

Subject: New Version Notification for = draft-smith-abfab-usability-ui-considerations-01.txt
<= div style=3D"margin-top: 0px; margin-right: 0px; margin-bottom: 0px; = margin-left: 0px;">Date: 29 March 2012 = 12:44:48 CEST
To: smith@cardiff.ac.uk

A new version of I-D, = draft-smith-abfab-usability-ui-considerations-01.txt has been = successfully submitted by Rhys Smith and posted to the IETF = repository.

Filename: = draft-smith-abfab-usability-ui-considerations
Revision: = 01
Title: = = Application Bridging for Federated Access Beyond web (ABFAB) = Usability and User Interface Considerations
Creation date: = 2012-03-29
WG ID: Individual Submission
Number = of pages: 11

Abstract:
  The use of ABFAB-based = technologies requires that each user&#39;s machine
=   is configured with the user&#39;s identities.  This = will require
  something on that machine which will manage = the user&#39;s identities and
  services.  Anyone = designing that &quot;something&quot; will face the same set
=   of challenges.  This document aims to document these = challenges with
  the aim of producing well-thought out = UIs with some consistency.




The IETF = Secretariat

= --Apple-Mail=_04F77BF3-4975-4538-83CD-F8F5FBA9C23B-- From aland@deployingradius.com Thu Mar 29 03:59:08 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B03AB21F87D6 for ; Thu, 29 Mar 2012 03:59: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 7yeDHP7Q0tOH for ; Thu, 29 Mar 2012 03:59:07 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id AEF3021F87AE for ; Thu, 29 Mar 2012 03:59:07 -0700 (PDT) Received: from dhcp-5051.meeting.ietf.org (dhcp-5051.meeting.ietf.org [130.129.80.81]) by liberty.deployingradius.com (Postfix) with ESMTPSA id A95C912340D7 for ; Thu, 29 Mar 2012 12:58:37 +0200 (CEST) Message-ID: <4F74405A.3010802@deployingradius.com> Date: Thu, 29 Mar 2012 12:58:34 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: abfab@ietf.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 10:59:08 -0000 My take-away from the meeting today is this: - the documents talk about solutions instead of problems. - perhaps this is because they use terms from a particular design, rather than generic terms - knowing WHO to talk to is a separate problem from HOW to talk to them My comments were that the "how" portion should be relatively simple. I assume a base set of interconnections done via RadSec. These connections are provisioned off-line (contracts, legal, phone calls, etc.) If A has provisioned a RadSec connection to B, then they share a TLS session key. That key can be used to derive additional credentials. e.g. A connects to B, and B to C. If A wants an introduction to C, it asks B how to find C. B responds, and gives A and identity based on the A->B TLS data. A then connects to C, using the credentials derived from B. C can then use it's connection to B in order to validate those credentials. The process can be chained, to allow A to connect to B, then C, then D, etc. Each node can decide whether or not it provides an introduction to another one. This means that B (above) and be a "registrar", with a list of members. It will introduce the members to each other, but not to anyone else. This design is simple, and flat. It means that each system is nearly identical. There are no central registration authorities, except by prior convention. Alan DeKok. From leifj@sunet.se Thu Mar 29 05:23:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA4721F8A92 for ; Thu, 29 Mar 2012 05:23: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=[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 HQ-fMJimuJTj for ; Thu, 29 Mar 2012 05:23:40 -0700 (PDT) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 06CD721F86B2 for ; Thu, 29 Mar 2012 05:23:39 -0700 (PDT) Received: from [130.129.23.57] (dhcp-1739.meeting.ietf.org [130.129.23.57]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id q2TCNYub014416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Mar 2012 14:23:37 +0200 (CEST) Message-ID: <4F745446.9020406@sunet.se> Date: Thu, 29 Mar 2012 14:23:34 +0200 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120310 Thunderbird/11.0 MIME-Version: 1.0 To: "abfab@ietf.org" X-Enigmail-Version: 1.4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] notes from Paris meeting is online X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 12:23:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thank you David Black for some of the best notes I've ever seen. Cheers Leif -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk90VEYACgkQ8Jx8FtbMZnfRdgCdHCISDS5pVabfBkQwq/Myvv9F lJ0AoIOwc42rnxUViDrRkmFSrf9l6nnO =HyT/ -----END PGP SIGNATURE----- From smith@Cardiff.ac.uk Thu Mar 29 09:00:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE4721E8200 for ; Thu, 29 Mar 2012 09:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5+sgxh9BNPn for ; Thu, 29 Mar 2012 09:00:10 -0700 (PDT) Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id AD39A21E8213 for ; Thu, 29 Mar 2012 09:00:09 -0700 (PDT) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.76) (envelope-from ) id 1SDHlg-0003yl-Lr; Thu, 29 Mar 2012 17:00:08 +0100 Received: from [130.129.8.190] (helo=dhcp-90be.meeting.ietf.org) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1SDHlg-0007I5-K0; Thu, 29 Mar 2012 17:00:08 +0100 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_EA333876-9C45-4D32-B992-D536B0938D09" From: Rhys Smith In-Reply-To: <4F745446.9020406@sunet.se> Date: Thu, 29 Mar 2012 18:00:08 +0200 Message-Id: <3EF409AD-D46C-4C0F-A636-15A92858A63E@cardiff.ac.uk> References: <4F745446.9020406@sunet.se> To: Leif Johansson X-Mailer: Apple Mail (2.1257) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Cc: "abfab@ietf.org" Subject: Re: [abfab] notes from Paris meeting is online X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:00:12 -0000 --Apple-Mail=_EA333876-9C45-4D32-B992-D536B0938D09 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Where are they online? I don't see them anywhere*. [ * anywhere ~= http://tools.ietf.org/wg/abfab | abfab@ietf.org ] -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's education and research network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 29 Mar 2012, at 14:23, Leif Johansson wrote: > Thank you David Black for some of the best notes I've ever seen. > > Cheers Leif --Apple-Mail=_EA333876-9C45-4D32-B992-D536B0938D09 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Where = are they online? I don't see them anywhere*.

[ * = anywhere ~=3D http://tools.ietf.org/wg/abfab= | abfab@ietf.org ]
--
Dr Rhys Smith
Identity, Access, and = Middleware Specialist
Cardiff University & Janet - the UK's = education and research network
smith@cardiff.ac.uk / rhys.smith@ja.net
GPG: = 0xDE2F024C

On 29 Mar 2012, at 14:23, Leif Johansson wrote:

Thank = you David Black for some of the best notes I've ever seen.

Cheers = Leif

= --Apple-Mail=_EA333876-9C45-4D32-B992-D536B0938D09-- From shawn.emery@oracle.com Thu Mar 29 09:02:43 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29ED221F89EA for ; Thu, 29 Mar 2012 09:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.027 X-Spam-Level: X-Spam-Status: No, score=-10.027 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eGCUBVpT+bx for ; Thu, 29 Mar 2012 09:02:42 -0700 (PDT) Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by ietfa.amsl.com (Postfix) with ESMTP id 9BE5521F89F6 for ; Thu, 29 Mar 2012 09:02:42 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q2TG2fxh017871 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 29 Mar 2012 16:02:42 GMT Received: from acsmt356.oracle.com (acsmt356.oracle.com [141.146.40.156]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q2TG2eBU006197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 29 Mar 2012 16:02:41 GMT Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by acsmt356.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q2TG2egq015113 for ; Thu, 29 Mar 2012 11:02:40 -0500 Received: from dhcp-1599.meeting.ietf.org (/10.175.60.153) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Mar 2012 09:02:40 -0700 Message-ID: <4F74879F.9060408@oracle.com> Date: Thu, 29 Mar 2012 10:02:39 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: abfab@ietf.org References: <4F745446.9020406@sunet.se> <3EF409AD-D46C-4C0F-A636-15A92858A63E@cardiff.ac.uk> In-Reply-To: <3EF409AD-D46C-4C0F-A636-15A92858A63E@cardiff.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090204.4F7487A2.0039,ss=1,re=0.000,fgs=0 Subject: Re: [abfab] notes from Paris meeting is online X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Mar 2012 16:02:43 -0000 On 3/29/12 10:00 AM, Rhys Smith wrote: > Where are they online? I don't see them anywhere*. http://www.ietf.org/proceedings/83/minutes/minutes-83-abfab.txt Shawn. -- > [ * anywhere ~= http://tools.ietf.org/wg/abfab | abfab@ietf.org > ] > -- > Dr Rhys Smith > Identity, Access, and Middleware Specialist > Cardiff University & Janet - the UK's education and research network > > email: smith@cardiff.ac.uk / > rhys.smith@ja.net > GPG: 0xDE2F024C > > On 29 Mar 2012, at 14:23, Leif Johansson wrote: > >> Thank you David Black for some of the best notes I've ever seen. >> >> Cheers Leif > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From diego@tid.es Fri Mar 30 10:49:44 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DE121F8633 for ; Fri, 30 Mar 2012 10:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.954 X-Spam-Level: X-Spam-Status: No, score=-3.954 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_40=-0.185, 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 dcNXpIYlYCXm for ; Fri, 30 Mar 2012 10:49:43 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 70A1521F8625 for ; Fri, 30 Mar 2012 10:49:43 -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 <0M1P00GPXLITET@tid.hi.inet> for abfab@ietf.org; Fri, 30 Mar 2012 19:49:41 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id CA.3C.02597.532F57F4; Fri, 30 Mar 2012 19:49:41 +0200 (CEST) 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 <0M1P00GQ2LITET@tid.hi.inet> for abfab@ietf.org; Fri, 30 Mar 2012 19:49:41 +0200 (MEST) Received: from EXCLU2K7.hi.inet ([10.95.67.65]) by htcasmad1.hi.inet ([192.168.0.1]) with mapi; Fri, 30 Mar 2012 19:49:41 +0200 Date: Fri, 30 Mar 2012 19:49:41 +0200 From: DIEGO LOPEZ GARCIA In-reply-to: <4F74405A.3010802@deployingradius.com> To: Alan DeKok Message-id: <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] Trust router work Thread-index: Ac0OnXuvjUSbHagFSaeIf528Bvun7g== acceptlanguage: en-US X-AuditID: 0a5f4e69-b7f4d6d000000a25-6f-4f75f2352854 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMKsWRmVeSWpSXmKPExsXCFe9nqGv6qdTfoPuqgcXH628YHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMa33JmPBNO6KiQ/2szYwfuDqYuTkkBAwkdh3dTcLhC0mceHe erYuRi4OIYHtjBJdq1oYIZyfjBJv+6ZCOY2MEkfnPmEDaWERUJX4sPY2K4jNJqAu0XL0G9go YQE1iRVTjjOD2JwCxhJ3P99iBLFFBLQkFqxfBFbDDNT7duICoF4ODl4BS4lH66tAwrwCghI/ Jt9jAQkzA42cMiUXolpcorn1JlSnosS0RQ1gExmBjv5+ag0TxHR1iQ2nNjFD2HoSl/Z/Zoeo EZW4076eEeJJAYkle84zQ9iiEi8f/wO7XkjASGLftBOsExjFZyG5YhbCFbOQXDELyRULGFlW MYoVJxVlpmeU5CZm5qQbGOllZOpl5qWWbGKExFDmDsblO1UOMQpwMCrx8DK0l/gLsSaWFVfm HmKU5GBSEuW9+qHUX4gvKT+lMiOxOCO+qDQntfgQowQHs5IIb/dqoHLelMTKqtSifJiUDAeH kgTvS5A2waLU9NSKtMwcYKKASTNxcIK08wC1C3wEquEtLkjMLc5Mh8ifYpSUEud9A9IsAJLI KM2D633FKA50pDDvGZAsDzClwXW9AhrIBDSQmRfknuKSRISUVAOj0pw/b2u2/K0SnuO85dDd w/m2ffxXA/2+Ll0hvZ79Y8qPInuR/rlxonIpaSHW1rfOKwf+ufntafnDr1qLzzyvtpXw2Ns7 +ZrzBt2OY4e4bn+I8siL5J1wRev28tl3224oT/l/zUti+YIlnV/tW177NHCIPAs5tKbJQzF0 4URDie+LZn5Tmfb0lhJLcUaioRZzUXEiACko1/wmAwAA References: <4F74405A.3010802@deployingradius.com> Cc: "abfab@ietf.org" Subject: Re: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Mar 2012 17:49:44 -0000 DQpPbiAyOSBNYXIgMjAxMiwgYXQgMTI6NTggLCBBbGFuIERlS29rIHdyb3RlOg0KPiAgVGhpcyBk ZXNpZ24gaXMgc2ltcGxlLCBhbmQgZmxhdC4gIEl0IG1lYW5zIHRoYXQgZWFjaCBzeXN0ZW0gaXMg bmVhcmx5DQo+IGlkZW50aWNhbC4gIFRoZXJlIGFyZSBubyBjZW50cmFsIHJlZ2lzdHJhdGlvbiBh dXRob3JpdGllcywgZXhjZXB0IGJ5DQo+IHByaW9yIGNvbnZlbnRpb24uDQoNCg0KVGhhdCdzIHBy ZWNpc2VseSBteSB0YWtlIGFzIHdlbGwuIFlvdSBjYW4gZHluYW1pY2FsbHkgYnVpbGQgdHJ1c3Qg bGlua3Mgb3V0DQpvZiBhIGZldyBwcmV2aW91c2x5IGVzdGFibGlzaGVkIG9uZXMsIHRoYXQgY29t ZSBmcm9tIHdoYXQgd2UgY291bGQgY2FsbA0KbmF0dXJhbCBleHRlcm5hbCBjb252ZW50aW9ucy4N Cg0KU2hhbGwgdGhlIHByb2JsZW0gc3RhdGVtZW50IGdvIGluIHRoYXQgd2F5Pw0KDQpCZSBnb29k ZSwNCg0KLS0NCiJFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8iDQoNCkRy IERpZWdvIFIuIExvcGV6DQpUZWxlZm9uaWNhIEkrRA0KaHR0cDovL3Blb3BsZS50aWQuZXMvZGll Z28ubG9wZXovDQoNCmUtbWFpbDogZGllZ29AdGlkLmVzDQpUZWw6ICAgICszNCA5MTMgMTI5IDA0 MQ0KTW9iaWxlOiArMzQgNjgyIDA1MSAwOTENCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoNCg0KRXN0ZSBtZW5zYWplIHNlIGRpcmlnZSBleGNsdXNpdmFtZW50ZSBh IHN1IGRlc3RpbmF0YXJpby4gUHVlZGUgY29uc3VsdGFyIG51ZXN0cmEgcG9sw610aWNhIGRlIGVu dsOtbyB5IHJlY2VwY2nDs24gZGUgY29ycmVvIGVsZWN0csOzbmljbyBlbiBlbCBlbmxhY2Ugc2l0 dWFkbyBtw6FzIGFiYWpvLg0KVGhpcyBtZXNzYWdlIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZv ciBpdHMgYWRkcmVzc2VlLiBXZSBvbmx5IHNlbmQgYW5kIHJlY2VpdmUgZW1haWwgb24gdGhlIGJh c2lzIG9mIHRoZSB0ZXJtcyBzZXQgb3V0IGF0DQpodHRwOi8vd3d3LnRpZC5lcy9FUy9QQUdJTkFT L2Rpc2NsYWltZXIuYXNweA0K From aland@deployingradius.com Sat Mar 31 01:27:57 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D2821F865A for ; Sat, 31 Mar 2012 01:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 qjoosxzC-l0H for ; Sat, 31 Mar 2012 01:27:56 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF7B21F8659 for ; Sat, 31 Mar 2012 01:27:56 -0700 (PDT) Message-ID: <4F76BFF2.3060902@deployingradius.com> Date: Sat, 31 Mar 2012 10:27:30 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: DIEGO LOPEZ GARCIA References: <4F74405A.3010802@deployingradius.com> <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> In-Reply-To: <7905F054-6E0E-4605-966F-37A686C361AC@tid.es> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Trust router work X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 08:27:57 -0000 DIEGO LOPEZ GARCIA wrote: > That's precisely my take as well. You can dynamically build trust links out > of a few previously established ones, that come from what we could call > natural external conventions. > > Shall the problem statement go in that way? I talked with Josh && Sam a bit more. I think we're converging, but there is still some difference. I think the dynamic trust links are the best way to do the introductions. I think the RADIUS routing protocol needs more definition before I understand it. Alan DeKok. From aland@deployingradius.com Sat Mar 31 01:48:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DBC21F865E; Sat, 31 Mar 2012 01:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.4 X-Spam-Level: X-Spam-Status: No, score=-102.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 En3AP3fwopHs; Sat, 31 Mar 2012 01:48:54 -0700 (PDT) Received: from liberty.deployingradius.com (liberty.deployingradius.com [88.191.76.128]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4C921F8645; Sat, 31 Mar 2012 01:48:54 -0700 (PDT) Message-ID: <4F76C4D8.9080804@deployingradius.com> Date: Sat, 31 Mar 2012 10:48:24 +0200 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "radext@ietf.org" , "abfab@ietf.org" X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [abfab] Fragmentation in RADIUS X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 08:48:55 -0000 Alejandro presented the fragmentation draft in RADEXT. There was a long discussion around it. One suggestion was to just use Diameter for transporting large amounts of authorization data. That won't work, for the simple reason that the people involved don't run Diameter, have no plans to run Diameter, and have no budget to get Diameter. The consensus was that the document presents 3 related problems and solutions: 1) using Authorize-Only with Access-Accept It's currently specified for CoA (RFC 5176, Section 3.2). In this use-case, a CoA packet contains a State and Service-Type = Authorize-Only. The NAS then sends an Access-Request, with the same State and Authorize-Only. The RADIUS server responds with new authorization data. The same method could be used by sending Service-Type = Authorize-Only in an Access-Accept. This would need standardization. 2) Sending large amounts of authorization data The limit on RADIUS packet size is 4K. These limits have been run into in real-world deployments. e.g. sending large amounts of filter rules to a NAS. It would be useful to extend method (1) above to allow for more than 4K of authorization data to be sent. The draft proposes using Authorize-Only, and a sequence of Access-Request / Access-Challenge packets. Since challenges are widely implemented in servers and clients, this is an appealing approach. The major change to RADIUS here is to update RFC 2865 Section 5.44, to allow authorization attributes inside of Access-Challenge packets. This permission should be limited to Access-Requests having Service-Type = Authorize-Only. The result is a way to send arbitrary amounts of authorization data to a NAS. The extensions to RADIUS are hopefully minor, and not contentious. 3) Proxying large packets The solution to (2) above aggravates an existing problem in RADIUS. The specs are silent on what to do when a Proxy receives a large packet (<4K), and wants to add data to make the packet >4K. The problem is made worse by UDP fragmentation. Fragmented UDP packets can be dropped by intermediate routers, making the practical limit for RADIUS packets to be much smaller. The result is that it's difficult to send large amounts of authorization data from a server to a client, through intermediate proxies. The solution to (2) above helps by fragmenting the packets. However, we still don't know how large to make those fragments. And we don't know how to allow the proxies to re-write attributes when the authorization data is fragmented across multiple packets. The goal is to allow proxies to know how large to make the fragments, and also to allow them to re-write the authorization data. The draft proposes a number of work-arounds. One would be to have a new attribute like Framed-MTU, but instead "RADIUS MTU". It would signify the maximum size for RADIUS packets. This would allow home servers to know how large to make the fragments. The difficulty there is that the proxies still see fragments, and they want to re-write all of the authorization data. So they need to see *all* of the data. Re-writing each packet on the fly is likely unworkable. The draft proposes that the proxies obtain *all* of the data before re-writing it. This involves no changes to RADIUS. It does, however, require changes to implementations. These changes are documented, so that everyone is aware of the costs and benefits of the solution. And, so that the implementations are guided to a method that works. This message is long, but I hope it clarifies issues around the fragmentation draft. Alan DeKok.