From ietf@augustcellars.com Fri Mar 1 10:23:01 2013 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 E2E5121F93BE for ; Fri, 1 Mar 2013 10:23:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqauirEEM22R for ; Fri, 1 Mar 2013 10:22:58 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id A267421F93BD for ; Fri, 1 Mar 2013 10:22:57 -0800 (PST) Received: from Philemon (75-148-161-130-Houston.hfc.comcastbusiness.net [75.148.161.130]) (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 A58632C9BE; Fri, 1 Mar 2013 10:22:31 -0800 (PST) From: "Jim Schaad" To: Date: Fri, 1 Mar 2013 12:21:51 -0600 Message-ID: <03a101ce16a9$ab322f40$01968dc0$@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: Ac4WjMgOr398ifT8RQCjlSNQwR6FpQ== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Comments on draft-smith-abfab-usability-ui-considerations-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: Fri, 01 Mar 2013 18:23:05 -0000 Rhys, 1. Terminology - Bullet #1 - s/which they have an organization/which they have an association/ 2. Terminology - Move NAI before Identity to deal with problem of expand on first use. 3. Terminology - Bullet # 2 - Message sentence with the "and". I mis-read it the first time as the GSS-API would do the mapping rather than the identity selector. 4. Section 4- Context - s/user to user/user to use/ 5. Section 4 - Context - In the first bullet - I think you want to say that this is a GSS-API implementation specific file and not an application specific file. The term application is overloaded with the application that the user is using to talk to the service. 6. Section 6.1 - Is the issuing organization always going to be derivable from the NAI of the user? Under what circumstances would this not be the case? 7. Section 6.2.2. - Implies either a lot of different ways or some standard way being created to do this. This needs to be made clearer that there is going to be an association between the implementation of ABFAB, the UI and the IDP service. 8. Section 6.4 - bullet #2 - s/the identity provisioned/the identity automatically provisioned/ 9. Section 7 - add new section - Server identification. There are a number of different ways that services can be identified. The name of the service, the name of the server, parameters that are included in the service (for example the account that I am going to use to send mail), or some combination of the above. 10 Section 7 - Identity selection by calling application rather than GSS-API 11 Section 7 - last paragraph - last sentence - should this be an "automatic" option on some types of authentication failures? 12. Section 7.3 - why should the association only be doable after authentication? Esp for manual authentications. 13. Section 7.3.1 - It would be beneficial to list the types of things that are selections. I don't know that it is necessary to know the realm in all cases. 14. Section 7.3.1 - User-driven - on demand associations - Pop up a selection dialog box when you are trying to get to a service you have never seen before. 15. Section 8 - should applications attempt to use multiple names if there are multiple names associated with the service. Need to discuss possible privacy implications of this approach in terms of association of multiple names together. Import/Export of credentials Password protect the store - not the same as password used for the IDP Credentials that are "pluggable" - that may or may not be present on the machine From smith@Cardiff.ac.uk Mon Mar 4 08:50:45 2013 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 F2E9921F8581 for ; Mon, 4 Mar 2013 08:50:44 -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 HJk6wszhFn0t for ; Mon, 4 Mar 2013 08:50:41 -0800 (PST) Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4560221F85AC for ; Mon, 4 Mar 2013 08:50:40 -0800 (PST) Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.77) (envelope-from ) id 1UCYaz-0000GB-TM; Mon, 04 Mar 2013 16:50:37 +0000 Received: from [131.251.122.199] (helo=vpn-199.insrv.cf.ac.uk) by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1UCYaz-0002ox-OC; Mon, 04 Mar 2013 16:50:37 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Rhys Smith In-Reply-To: Date: Mon, 4 Mar 2013 16:50:36 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1794784A-629B-4FFA-BEA8-57C2694FB5CB@cardiff.ac.uk> References: To: "Joseph Salowey (jsalowey)" , "abfab@ietf.org" X-Mailer: Apple Mail (2.1499) Sender: smith@Cardiff.ac.uk X-Virus-Scanned: Cardiff University Virus Scanner X-Virus-Scanned: Cardiff University Virus Scanner Subject: Re: [abfab] Summary of proposed changes to eat applicability 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: Mon, 04 Mar 2013 16:50:45 -0000 I have no issues with the text as is (when Yoshi's points are included). Rhys. -- Dr Rhys Smith Identity, Access, and Middleware Specialist Cardiff University & Janet - the UK's research and education network email: smith@cardiff.ac.uk / rhys.smith@ja.net GPG: 0xDE2F024C On 22 Feb 2013, at 23:37, Joseph Salowey (jsalowey) = wrote: > After going through the comments on the list here is where I think we = are with changes to the document: >=20 > 1) Section 3=20 >=20 > OLD > It is important > for the protocol carrying EAP to prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. >=20 > NEW > The protocol carrying EAP MUST prove possession of the EAP MSK > between the EAP Peer and EAP Authenticator. >=20 > ADD >=20 > In the context of EAP for Application-Layer Access the application is = providing the EAP Lower Layer. Applications protocols vary so their = specific behavior and transport characteristics needs to be considered = when determining their retransmission and re-authentication behavior as = discussed in section 3. =20 >=20 >=20 > 3) Retransmissions >=20 > ADD=20 >=20 > 2.1 Retransmission >=20 > In EAP, the authenticator is responsible for retransmission. By = default > EAP assumes that the lower layer (the application in this context) is > unreliable. The authenticator can send a packet whenever its > retransmission timer triggers. In this mode, applications need to be = able to receive and process=20 > EAP messages at any time during the authentication conversation. >=20 > Alternatively, EAP permits a lower layer to set the retransmission = timer > to infinite. When this happens, the lower layer becomes responsible = for > reliable delivery of EAP messages. Applications that use a lock-step = or > client-driven authentication protocol might benefit from this = approach. >=20 > In addition to retransmission behavior applications need to deal with > discarded EAP messages. For example, whenever some EAP methods receive = erroneous > input, these methods discard the input rather than generating an error > response. If the erroneous input was generated by an attacker, > legitimate input can sometimes be received after the erroneous > input. Applications MUST handle discarded EAP messages, > although the specific way in which discarded messages will be handled > depend on the characteristics of the application. Options include > failing the authentication at the application level, requesting an EAP=20= > retransmit and waiting for additional EAP input. =20 >=20 > Specifications of how EAP is used for application authentication = SHOULD > document how retransmission and message discards are handled. >=20 > 4) Re-Authentication >=20 > ADD >=20 > 2.2 Re-Authentication >=20 > EAP lower layers MAY provide a mechanism for re-authentication to = happen > within an existing session [RFC 3748]. Diameter standardizes a = mechanism > for a AAA server to request re-authentication [RFC > 4005]. Re-authentication permits security associations to be updated > without establishing a new session. For network access, this can be > important because interrupting network access can disrupt connections > and media. >=20 > Some applications might not need re-authentication support. For = example > if sessions are relatively short-lived or if sessions can be replaced > without significant disruption, re-authentication might not provide > value. Protocols like HypertextTransport Protocol (HTTP) and Simple > Mail Transport Protocol (SMTP) are examples of protocols where > establishing a new connection to update security associations is = likely > to be sufficient. >=20 > Re-authentication is likely to be valuable if sessions or connections > are long-lived or if there is a significant cost to disrupting them. >=20 > Another factor may make re-authentication important. Some protocols = only > permit one part in a protocol (for example the client) to establish a > new connection. If another party in the protocol needs the security > association refreshed then re-authentication can provide a mechanism = to > do so. >=20 > Lower layers SHOULD describe whether re-authentication is provided and > which parties can initiate it. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Mar 6 09:39:39 2013 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 A163921F8A56; Wed, 6 Mar 2013 09:39:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCqCV6BtmQAv; Wed, 6 Mar 2013 09:39:35 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 927A821F89B3; Wed, 6 Mar 2013 09:39:26 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 1E01C2014B; Wed, 6 Mar 2013 12:39:17 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 83BE141CE; Wed, 6 Mar 2013 12:39:25 -0500 (EST) From: Sam Hartman To: abfab@ietf.org, radext@ietf.org, saag@ietf.org Date: Wed, 06 Mar 2013 12:39:25 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 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, 06 Mar 2013 17:39:39 -0000 The ABFAB working group has been busy at work describing a federated identity and access management model that enables federated identity for a wide variety of use cases and applications; this work is currently drawing to a close. However, one of the typical problems in the federated world - and a problem that any ABFAB implementations needs to address - is managing the scaling of number of partners involved in the federation (this is because configuration changes need to be made at all interested partners when new entities join). Existing federation technologies attempt to solve this problem in a variety of ways (e.g. SAML metadata, hierarchical RADIUS federations) but each has their own unique disadvantages. A much more elegant, flexible, and extensible way to achieve the same goals would be beneficial - especially for when scaling up to the potential number of entities in a community of ABFAB-enabled partners. Alongside this, operationally, there is also a need to separate the authentication process from the creation of a new partnership across a set of federated entities - so as to allow existing credentials to be used for new communities of users with minimal operation and infrastructure costs. This is crucial in driving adoption of federated technologies on a wide scale, and in reducing the cost of operating and being a part of federation on such a wide scale. Trust Router is an attempt to build an infrastructure that solves these - and other - problems (see the full problem statement for more details). Essentially, trust Router works by distributing information about new and existing trust relationships across a network of entities. It achieves this distribution using protocols with many similarities to existing routing protocols, and avoids any requirement for technologies such as PKI. The broad applicability of a general infrastructure for routing trust information between arbitrary entities and allowing them to communicate securely means that this is potentially quite an exciting topic, and one ripe for standardisation. Come join us to talk all about trust and trust routing at our Bar BOF - to be held on Thursday March 14th @ 11:30AM, located in Caribbean 7. Documents to read: * Trust Router problem statement - http://tools.ietf.org/html/ draft-howlett-abfab-trust-router-ps-02 * ABFAB Architecture document - http://tools.ietf.org/html/ draft-ietf-abfab-arch-05 * Trust router protocol overview - http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02.txt From kwiereng@cisco.com Wed Mar 6 09:43:16 2013 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 4B18D21F8CF5; Wed, 6 Mar 2013 09:43:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cVbpoI31w+k4; Wed, 6 Mar 2013 09:43:12 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id B4E9021F8CEB; Wed, 6 Mar 2013 09:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3059; q=dns/txt; s=iport; t=1362591791; x=1363801391; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DasIbZK0n/TPwikN7ER4p4l0Kkft1EBAWy+FQIhJH+4=; b=AbLj++XzO9fpH3gIsRwlLovpXHHbumzHmVSz0Ua2FGAtx21dCTLBNufU xkA1CGGX56mKbVr3kGG9YsOU1y3iFoZ9sRxbiLzrKL7HIZUof2MiMVKrS lfH3uHkCdupEa9mSlU0L4a7gtf6RLByvxFttmSQnW5h2+hjCxa2Ya1jvO Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAKZ+N1GtJV2c/2dsb2JhbAA7CcRGgVoWc4IqAQEBAwEBAQE3NAMBBwULAgEIEiQQJwsXDgIEDgUUh3kGDLx+jUoIgQczB4JfYQOWS4Eeij2FFYMI X-IronPort-AV: E=Sophos;i="4.84,795,1355097600"; d="scan'208";a="184270458" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 06 Mar 2013 17:43:11 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r26HhAPv015744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Mar 2013 17:43:11 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.138]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Wed, 6 Mar 2013 11:43:10 -0600 From: "Klaas Wierenga (kwiereng)" To: Sam Hartman Thread-Topic: [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 Thread-Index: AQHOGpGXSYJnqNzinkOuD8EzixwzxZiY7v8G Date: Wed, 6 Mar 2013 17:43:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "radext@ietf.org" , "abfab@ietf.org" , "saag@ietf.org" Subject: Re: [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 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, 06 Mar 2013 17:43:16 -0000 Sam, How does this relate to the trust router slot in Routing Area Open Meeting? Klaas Sent from my iPad On 6 mrt. 2013, at 18:39, "Sam Hartman" wr= ote: > The ABFAB working group has been busy at work describing a federated iden= tity > and access management model that enables federated identity for a wide va= riety > of use cases and applications; this work is currently drawing to a close. >=20 > However, one of the typical problems in the federated world - and a probl= em > that any ABFAB implementations needs to address - is managing the scaling= of > number of partners involved in the federation (this is because configurat= ion > changes need to be made at all interested partners when new entities join= ). > Existing federation technologies attempt to solve this problem in a varie= ty of > ways (e.g. SAML metadata, hierarchical RADIUS federations) but each has t= heir > own unique disadvantages. A much more elegant, flexible, and extensible w= ay to > achieve the same goals would be beneficial - especially for when scaling = up to > the potential number of entities in a community of ABFAB-enabled partners= . >=20 > Alongside this, operationally, there is also a need to separate the > authentication process from the creation of a new partnership across a se= t of > federated entities - so as to allow existing credentials to be used for n= ew > communities of users with minimal operation and infrastructure costs. Thi= s is > crucial in driving adoption of federated technologies on a wide scale, an= d in > reducing the cost of operating and being a part of federation on such a w= ide > scale. >=20 > Trust Router is an attempt to build an infrastructure that solves these -= and > other - problems (see the full problem statement for more details). > Essentially, trust Router works by distributing information about new and > existing trust relationships across a network of entities. It achieves th= is > distribution using protocols with many similarities to existing routing > protocols, and avoids any requirement for technologies such as PKI. The b= road > applicability of a general infrastructure for routing trust information b= etween > arbitrary entities and allowing them to communicate securely means that t= his is > potentially quite an exciting topic, and one ripe for standardisation. >=20 > Come join us to talk all about trust and trust routing at our Bar BOF - t= o be > held on Thursday March 14th @ 11:30AM, located in Caribbean 7. >=20 > Documents to read: > * Trust Router problem statement - http://tools.ietf.org/html/ > draft-howlett-abfab-trust-router-ps-02 > * ABFAB Architecture document - http://tools.ietf.org/html/ > draft-ietf-abfab-arch-05 > * Trust router protocol overview - > http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02.txt > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Mar 6 09:46:01 2013 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 94B4021F8CFA; Wed, 6 Mar 2013 09:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylbPdggsiprA; Wed, 6 Mar 2013 09:46:01 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 05A3D21F8C12; Wed, 6 Mar 2013 09:45:56 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id A30A12014B; Wed, 6 Mar 2013 12:45:46 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4A20041CE; Wed, 6 Mar 2013 12:45:55 -0500 (EST) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: Date: Wed, 06 Mar 2013 12:45:55 -0500 In-Reply-To: (Klaas Wierenga's message of "Wed, 6 Mar 2013 17:43:10 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "radext@ietf.org" , "abfab@ietf.org" , "saag@ietf.org" Subject: Re: [abfab] Trust Router BAR BOF at IETF 86: Thursday at 1130 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, 06 Mar 2013 17:46:01 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: Klaas> Sam, How does this relate to the trust router slot in Routing Klaas> Area Open Meeting? we're going to introduce the topic and try and get routing folks to go to the bar bof. We think having routing clue review the trust router would be valuable. From klaas@wierenga.net Wed Mar 6 11:55:02 2013 Return-Path: X-Original-To: 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 3177D21F8949; Wed, 6 Mar 2013 11:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-2XbCdbWZa5; Wed, 6 Mar 2013 11:54:57 -0800 (PST) Received: from out45-ams.mf.surf.net (out45-ams.mf.surf.net [145.0.1.45]) by ietfa.amsl.com (Postfix) with ESMTP id D063A21F897A; Wed, 6 Mar 2013 11:54:44 -0800 (PST) Received: from teletubbie.het.net.je (teletubbie.het.net.je [192.87.110.29]) by outgoing2-ams.mf.surf.net (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id r26JseG9003213; Wed, 6 Mar 2013 20:54:40 +0100 Received: from 5355139f.cm-6-6a.dynamic.ziggo.nl ([83.85.19.159] helo=[192.168.1.87]) by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1UDKP5-000KeL-Q5; Wed, 06 Mar 2013 20:53:31 +0100 References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <3B80CEB5-B1D0-4A3B-A9E9-C8AABD854BEE@wierenga.net> X-Mailer: iPad Mail (10B146) From: Klaas Wierenga Date: Wed, 6 Mar 2013 20:54:41 +0100 To: Sam Hartman X-Antivirus: no malware found X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: ip=192.87.110.29; country=NL; latitude=52.5000; longitude=5.7500; http://maps.google.com/maps?q=52.5000,5.7500&z=6 X-CanItPRO-Stream: p-out:default (inherits from p:default,base:default) X-Canit-Stats-ID: 0vJ8jSEag - 288397efad06 - 20130306 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Cc: "radext@ietf.org" , "abfab@ietf.org" , "Klaas Wierenga \(kwiereng\)" , "saag@ietf.org" Subject: Re: [abfab] [radext] Trust Router BAR BOF at IETF 86: Thursday at 1130 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, 06 Mar 2013 19:55:02 -0000 On 6 mrt. 2013, at 18:45, Sam Hartman wrote: >>>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: > > Klaas> Sam, How does this relate to the trust router slot in Routing > Klaas> Area Open Meeting? > > we're going to introduce the topic and try and get routing folks to go > to the bar bof. > We think having routing clue review the trust router would be valuable. Agreed, makes a lot of sense. Klaas > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext From hartmans@painless-security.com Thu Mar 7 07:34:25 2013 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 5AFF921F8D62 for ; Thu, 7 Mar 2013 07:34:25 -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 6gkUxA7lCJL7 for ; Thu, 7 Mar 2013 07:34:25 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6391C21F8D61 for ; Thu, 7 Mar 2013 07:34:24 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id B169220183 for ; Thu, 7 Mar 2013 10:34:12 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 50C4141CE; Thu, 7 Mar 2013 10:34:21 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Thu, 07 Mar 2013 10:34:21 -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] an attribute assignment unfortunateness 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, 07 Mar 2013 15:34:25 -0000 The IANA has assigned us ATTRIBUTE GSS-Acceptor-Service-Name 164 string for our service name. Unfortunately, it looks like Ascend (remember them from times gone by) squatted on this attribute: root@debian:/usr/share/freeradius# grep -i X-Ascend-FR-DCE-N393 * dictionary.ascend.illegal:ATTRIBUTE X-Ascend-FR-DCE-N393 164 integer do we care? I don't have enough RADIUS experience to evaluate this. From aland@deployingradius.com Thu Mar 7 07:47:40 2013 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 3B69C21F8D79 for ; Thu, 7 Mar 2013 07:47: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=[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 ACQqCAcqAzNL for ; Thu, 7 Mar 2013 07:47:39 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id E324C21F8B1E for ; Thu, 7 Mar 2013 07:47:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 2228422403DE; Thu, 7 Mar 2013 16:47:02 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZDLujcpXTGk; Thu, 7 Mar 2013 16:47:01 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.60]) by power.freeradius.org (Postfix) with ESMTPSA id 939CC2240223; Thu, 7 Mar 2013 16:47:01 +0100 (CET) Message-ID: <5138B674.3020404@deployingradius.com> Date: Thu, 07 Mar 2013 10:47:00 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Sam Hartman References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] an attribute assignment unfortunateness 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, 07 Mar 2013 15:47:40 -0000 Sam Hartman wrote: > Unfortunately, it looks like Ascend (remember them from times gone by) > squatted on this attribute: ... > do we care? No. > I don't have enough RADIUS experience to evaluate this. Most of the equipment using that attribute is either dead, or can be configured to *not* use it. There may be issues with broken RADIUS servers (see Operator-Name). But the solution there is the same: fix the broken software. It's not hard. This squatting issue will come up for *all* of the new RADIUS attributes. The only approach is to ignore it. People still using broken equipment need to upgrade before using new standards. Alan DeKok. From stefan.winter@restena.lu Thu Mar 7 07:54:06 2013 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 CDE5F21F8D12 for ; Thu, 7 Mar 2013 07:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JjgPnNt0xBdJ for ; Thu, 7 Mar 2013 07:54:04 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 2965621F8D0E for ; Thu, 7 Mar 2013 07:54:04 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 11668109F6 for ; Thu, 7 Mar 2013 16:54:03 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:21d4:198d:f1b1:9879]) by smtprelay.restena.lu (Postfix) with ESMTPS id 030A5107C2 for ; Thu, 7 Mar 2013 16:54:03 +0100 (CET) Message-ID: <5138B816.7030403@restena.lu> Date: Thu, 07 Mar 2013 16:53:58 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2NKLKEDTVJOOOXWEAWKPW" X-Virus-Scanned: ClamAV Subject: Re: [abfab] an attribute assignment unfortunateness 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, 07 Mar 2013 15:54:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2NKLKEDTVJOOOXWEAWKPW Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, > ATTRIBUTE GSS-Acceptor-Service-Name 164 string > dictionary.ascend.illegal:ATTRIBUTE X-Ascend-FR-DCE-N393 > 164 integer >=20 > do we care? The same has happened (repeatedly) with other attributes - pretty much all attributes from RFC5580 were in the "stolen" space from Ascend. We've had actual deployment due to that: Operator-Name is a string, but defined by Ascend as an Integer (for something totally different). Some RADIUS servers found that an incoming packet with Operator-Name set, and with a length that was different from 4 characters (i.e. 32 bit "integer") was malformed and discarded the entire request! Others truncated the value after 4 Bytes when proxying - an arguable sanitisation. Others just left it as is - notably FreeRADIUS. I guess all RADIUS servers can be convinced to operate correctly - a simple change of dictionary is required (on MS IAS, the "simple" meant editing an MS Access database with some strange GUI tool though). We are meanwhile actively testing on this particular oddity and warn operators when we find them dropping packets on the floor which have Operator-Name set; and there are instructions for fixing. Your case is the exact same - so I think you have some reason to be slightly worried. It is not unsurmountable though. Greetings, Stefan Winter --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2NKLKEDTVJOOOXWEAWKPW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE4uBoACgkQ+jm90f8eFWYjaQCfearkh7kPydsQS1XhmOIK+g4B 34IAn1CzC3kdlAwprj1th/eSPxh0lBtZ =IBci -----END PGP SIGNATURE----- ------enig2NKLKEDTVJOOOXWEAWKPW-- From stefan.winter@restena.lu Thu Mar 7 07:54:56 2013 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 E755121F8D39 for ; Thu, 7 Mar 2013 07:54:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qW73iDl8jQ9W for ; Thu, 7 Mar 2013 07:54:56 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 7759721F8C0C for ; Thu, 7 Mar 2013 07:54:56 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id D48DF109F6 for ; Thu, 7 Mar 2013 16:54:55 +0100 (CET) Received: from aragorn.restena.lu (unknown [IPv6:2001:a18:1:8:21d4:198d:f1b1:9879]) by smtprelay.restena.lu (Postfix) with ESMTPS id C53DA107C2 for ; Thu, 7 Mar 2013 16:54:55 +0100 (CET) Message-ID: <5138B84F.2080100@restena.lu> Date: Thu, 07 Mar 2013 16:54:55 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: abfab@ietf.org References: <5138B816.7030403@restena.lu> In-Reply-To: <5138B816.7030403@restena.lu> X-Enigmail-Version: 1.5.1 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2SRDSFHVDTQIEMDXGARAL" X-Virus-Scanned: ClamAV Subject: Re: [abfab] an attribute assignment unfortunateness 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, 07 Mar 2013 15:54:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2SRDSFHVDTQIEMDXGARAL Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable > We've had actual deployment=20 =2E.. issues Stefan --=20 Stefan WINTER Ingenieur de Recherche Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education National= e et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473 ------enig2SRDSFHVDTQIEMDXGARAL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlE4uE8ACgkQ+jm90f8eFWYj1QCfX3ypj0hHeyCDYAJEIblcPElD z2sAn0sv1C6cLTJQLHUDcLdfl2I7cR1d =Z2Mq -----END PGP SIGNATURE----- ------enig2SRDSFHVDTQIEMDXGARAL-- From aland@deployingradius.com Thu Mar 7 08:11:01 2013 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 1D03321F893E for ; Thu, 7 Mar 2013 08:11:01 -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 XyUWqAGARDJq for ; Thu, 7 Mar 2013 08:11:00 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7874A21F88F0 for ; Thu, 7 Mar 2013 08:11:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id CB3FB22403DE; Thu, 7 Mar 2013 17:10:20 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVv5Pd9tYjgI; Thu, 7 Mar 2013 17:10:20 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.60]) by power.freeradius.org (Postfix) with ESMTPSA id 54A7822402AD; Thu, 7 Mar 2013 17:10:20 +0100 (CET) Message-ID: <5138BBEB.3080605@deployingradius.com> Date: Thu, 07 Mar 2013 11:10:19 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Stefan Winter References: <5138B816.7030403@restena.lu> In-Reply-To: <5138B816.7030403@restena.lu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] an attribute assignment unfortunateness 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, 07 Mar 2013 16:11:01 -0000 Stefan Winter wrote: > We are meanwhile actively testing on this particular oddity and warn > operators when we find them dropping packets on the floor which have > Operator-Name set; Which is absolutely not supported by RFC 2865, or its precursors. The RADEXT extensions document has text to address this specific issue. Alan DeKok. From hartmans@painless-security.com Fri Mar 8 04:41:59 2013 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 B092D21F8639 for ; Fri, 8 Mar 2013 04:41:59 -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 l-4RswXyXOk4 for ; Fri, 8 Mar 2013 04:41:59 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 1899621F8630 for ; Fri, 8 Mar 2013 04:41:59 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id B52672016B; Fri, 8 Mar 2013 07:41:45 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7DE5041CE; Fri, 8 Mar 2013 07:41:54 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Fri, 08 Mar 2013 07:41:54 -0500 Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Cc: radext-chairs@tools.ietf.org Subject: [abfab] One of abfab's dependencies is not moving as quickly as we had hoped 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, 08 Mar 2013 12:41:59 -0000 --=-=-= folks, the radext chairs have decided there is not currently rough consensus to adopt the fragmentation draft. We should track this closely. --=-=-= Content-Type: message/rfc822 Content-Disposition: inline Return-Path: Received: from localhost ([unix socket]) by mail.suchdamage.org (Cyrus v2.2.13-Debian-2.2.13-10) with LMTPA; Fri, 08 Mar 2013 06:26:42 -0500 X-Sieve: CMU Sieve 2.2 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by mail.painless-security.com (Postfix) with ESMTP id 8FB422026C for ; Fri, 8 Mar 2013 06:26:41 -0500 (EST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF0921F86EF; Fri, 8 Mar 2013 03:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1362742012; bh=l4mssd9G0nLwpXQMAicLxZnEbuHKAW4tp42tGfwH4xU=; h=Mime-Version:From:In-Reply-To:Date:Message-Id:References:To: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Type:Content-Transfer-Encoding:Sender; b=udi05QH8/02qnq3hm34cuT/fr4pr9JcTI71oZ+dRMuLwgGWSXQlaQKYjdyvW9DoL0 +clohqS5iPNlU0cew3XMtXOwTumam8qLEkfjFY357Q2G6yQkaNDu8vW92SfYwo/LCO dc/uoDLdGvI13I7dPlE2Iw5SRNj9uWJIen1ql8lM= X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733DF21F86C5 for ; Fri, 8 Mar 2013 03:26:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 tagged_above=-999 required=5 tests=[AWL=0.788, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B71RopdUmUV3 for ; Fri, 8 Mar 2013 03:26:50 -0800 (PST) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 9374B21F8698 for ; Fri, 8 Mar 2013 03:26:49 -0800 (PST) Received: by mail-lb0-f177.google.com with SMTP id go11so1229672lbb.22 for ; Fri, 08 Mar 2013 03:26:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=9ohCXsBYTSGsMzL6FD8hsnw2wL1tY9f2e/3zLJaKuYE=; b=0I7F84xrI2tjh6x08728eB6sfDDQ3pm1d7wgfso9iyxPM8h3KnUFHYRt1Q3hi7Ojeb gqLEGg35ffPofoKBtDQkWGkya+F7CtS/amUzFhhgDMR4N7PTStcd1Pb+4DGscAilTx0q r/VyT8klNnWE1gCTTal8M4X2jUJtOVjYgYNNYeXIR5U+eztQaufvq7aAlWXx/xFCllbs MWVZml4Axe99AXQURKPpJJvnA8/9RT8K5BbJ5iTfEvVLhpvdSYa+jL1RAvy03EWw3t1E XPPzHO1l1tgASRklZloHytHn+JV8GkBSPcex3TXQ3LXJ8PN/FO6pv+oB5k6FfbLaHAu6 WE2A== X-Received: by 10.112.26.10 with SMTP id h10mr942268lbg.63.1362742008557; Fri, 08 Mar 2013 03:26:48 -0800 (PST) Received: from [192.168.250.164] ([194.100.71.98]) by mx.google.com with ESMTPS id m1sm1553524lbh.5.2013.03.08.03.26.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Mar 2013 03:26:47 -0800 (PST) From: Jouni Korhonen In-Reply-To: <51275AA9.4070306@um.es> Date: Fri, 8 Mar 2013 13:26:48 +0200 Message-Id: References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> <51275AA9.4070306@um.es> To: Alejandro Perez Mendez , "radext\@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [radext] Adoption call for draft-perez-radext-radius-fragmentation-05 X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: radext-bounces@ietf.org Errors-To: radext-bounces@ietf.org X-DSPAM-Result: Innocent X-DSPAM-Processed: Fri Mar 8 06:26:42 2013 X-DSPAM-Confidence: 0.9995 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 8042,5139caf2222709399221916 X-DSPAM-Factors: 27, References*mit.edu>, 0.00014, From*Jouni Korhonen , 0.00020, Received*f177.google.com, 0.00023, Received*f177.google.com, 0.00023, DKIM-Signature*c=relaxed/simple, 0.00023, Errors-To*bounces, 0.00026, X-Mailman-Version*2.1.12, 0.00026, Sender*bounces, 0.00026, List-Help*, 0.00030, Received*mail.ietf.org, 0.00030, Received*mail.ietf.org, 0.00030, ietf, 0.00030, ietf, 0.00030, Precedence*list, 0.00030, Received*10024), 0.00030, List-Post*ietf.org>, 0.00030, DKIM-Signature*d=ietf.org, 0.00030, X-Virus-Scanned*at, 0.00030 MIME-Version: 1.0 Folks, It seems the document as such still needs more work to be acceptable as a WG item. We will have time for a discussion around the fragmentation in Orlando meeting agenda and see then where to head to. Related to this, we will also have a presentation of the other alternative proposals seen on the list. - Jouni & Mauricio On Feb 22, 2013, at 1:46 PM, Alejandro Perez Mendez wrote: > >> I support adopting the previous version of this draft >> (draft-perez-radext-radius-fragmentation-04) and would support adopting >> the current version (draft-perez-radext-radius-fragmentation-05) if a >> mechanism was added for fragmented information in access-request prior >> to authentication. That is, I disagree with one of the changes the >> authors made between 04 and 05. > > Hi Sam, > > we have been discussing this aspect internally, and we have concluded that the support of fragmentation prior to authentication will be re-incorporated into the next version of the document, though it will be noted that it may have the potential to allow DoS attacks. > > Best regards, > Alejandro > > >> >> --Sam >> _______________________________________________ >> radext mailing list >> radext@ietf.org >> https://www.ietf.org/mailman/listinfo/radext > > _______________________________________________ > radext mailing list > radext@ietf.org > https://www.ietf.org/mailman/listinfo/radext _______________________________________________ radext mailing list radext@ietf.org https://www.ietf.org/mailman/listinfo/radext --=-=-=-- From aland@deployingradius.com Fri Mar 8 06:55:02 2013 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 61ED621F8493; Fri, 8 Mar 2013 06:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iuwg11+4BCZ; Fri, 8 Mar 2013 06:55:01 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id CF36B21F8491; Fri, 8 Mar 2013 06:55:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id C89E72240DAF; Fri, 8 Mar 2013 15:54:59 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 784y89NoH5QO; Fri, 8 Mar 2013 15:54:59 +0100 (CET) Received: from Thor-2.local (unknown [70.50.217.60]) by power.freeradius.org (Postfix) with ESMTPSA id 9421B224036D; Fri, 8 Mar 2013 15:54:58 +0100 (CET) Message-ID: <5139FBC1.7030909@deployingradius.com> Date: Fri, 08 Mar 2013 09:54:57 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Jouni Korhonen References: <14C85EF3-B67D-405A-B8CD-BFF9DF26B92D@gmail.com> <51275AA9.4070306@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "radext@ietf.org" , "abfab@ietf.org" Subject: Re: [abfab] [radext] Adoption call for draft-perez-radext-radius-fragmentation-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: Fri, 08 Mar 2013 14:55:02 -0000 Jouni Korhonen wrote: > It seems the document as such still needs more work to be > acceptable as a WG item. We will have time for a discussion > around the fragmentation in Orlando meeting agenda and see > then where to head to. After much discussion in the past week, the fragmentation draft authors have decided to change the draft, and re-issue it under a new name. The name change reflects a change in focus which we hope makes fragmentation easier to understand. The net result is the same, but the underlying theory is different. I'll give a short explanation here. The first goal is to work with existing RADIUS proxies. This goal is satisfied by using Access-Request / Access-Accept. A User-Name is included in the Access-Request, so that existing proxies can forward the packets. The second goal is to do this *only* for authorization. There is no need to support "large data" for CoA, Accounting, etc. This goal is satisfied by using Access-Request / Access-Accept. The third goal is to not change existing authentication methods or packet flows. This goal is new, and results in the name change. We are no longer fragmenting "access requests", we are exchanging large amounts of authorization data. The third goal is satisfied by exchanging *references* to the authorization data in the Access-Request and Access-Accept. These references satisfy the requirements of RFC 6158, as pointed out by Bernard. The problem we're solving then becomes "how to dynamically provision authorization data". When defined that way, the discussion becomes simpler. The exchange of this data no longer affects existing authentication methods. The exchange of large data happens pretty much as discussed in the current draft. There are technical details, of course. These details again become simpler when they don't affect existing methods. The resulting exchange is then done in three steps. 1. send pre-authentication authorization data NAS to Server. 2. authentication (as is done now) 3. send post-authentication authorization data Server to NAS. Step (1) finishes with a token which is used in the Access-Request for step (2). Step (2) finishes with a token in the Access-Accept, which refers to step (3). Either or both of steps (1) and (2) can be omitted. If the authorization data is small enough, it can just be put into packets for step (2). I hope that this explanation is clear, and satisfies the concerns raised here. We hope to have an updated draft ready by next week. Alan DeKok. From alper.yegin@yegin.org Sat Mar 9 06:09:50 2013 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 7F70621F8635 for ; Sat, 9 Mar 2013 06:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLVj1Mvaw-Mz for ; Sat, 9 Mar 2013 06:09:49 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 1964221F841D for ; Sat, 9 Mar 2013 06:09:48 -0800 (PST) Received: from [192.168.2.49] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M4GBn-1V4Msz0s7v-00rRGm; Sat, 09 Mar 2013 09:09:36 -0500 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_A289CAB2-4D1D-40A5-B579-333B2332F7C7" From: Alper Yegin In-Reply-To: <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> Date: Sat, 9 Mar 2013 16:09:27 +0200 Message-Id: References: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> To: Leif Johansson X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:2QO38zoL+ePw40bXM87m4mbM+E5bk6uP/UZejmIjem8 0wRiamj3NcvZ0sESxmraQEc+84O8LydyAjD2zX1I4LAGAVLOL9 Bw/Y+T57N0fNmxFp+LdQ3i20585OobJKcnyWl7UOI3FVB/52wz tn0r7h235U/Q12sezCQOd7sQvzXPPSw2jBt4lWwRQt33BhasTy lZF4OYSR/dzWyHjabtPi0uh9+EVOI1LkSjaO1ctOyPTpin79W6 1xQQv4w/FEsQJlbm1GQ98zxN6R/3ySjRenYFyGRsVcOqwAJ0yU LZz4Qe2VCHmPn33Bbye7ChQ5XqPwslXQ8ECXCq8nppn97/nhQu xSVkn1gtjeGcELonZIAFqAwr/Qk72RW2i1qzgV5tQXXxRXAUMa nP/ZjbfY75Dzg== Cc: "abfab@ietf.org" Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Sat, 09 Mar 2013 14:09:50 -0000 --Apple-Mail=_A289CAB2-4D1D-40A5-B579-333B2332F7C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Leif, >=20 >=20 >>=20 >> This "MUST" cannot be implemented. It's not clear what an implementor = "must" be doing to comply. >> This is merely telling us "there's a problem, you MUST deal with it".=20= >> This reads more like recognition of an issue, rather than a solution. >=20 > I' going to weigh in (as an individual) on this point.=20 >=20 > There is (imo) nothing inherently problematic about calling out a = problem that needs to be addressed in another specification, especially = when writing an applicability statement. >=20 I read the text again, and let me recap it here: > Alternatively, EAP permits a lower layer to set the retransmission = timer > to infinite. When this happens, the lower layer becomes responsible = for > reliable delivery of EAP messages. Applications that use a lock-step = or > client-driven authentication protocol might benefit from this = approach. >=20 > In addition to retransmission behavior applications need to deal with > discarded EAP messages. For example, whenever some EAP methods receive = erroneous > input, these methods discard the input rather than generating an error > response. If the erroneous input was generated by an attacker, > legitimate input can sometimes be received after the erroneous > input. Applications MUST handle discarded EAP messages, > although the specific way in which discarded messages will be handled > depend on the characteristics of the application. Options include > failing the authentication at the application level, requesting an EAP=20= > retransmit and waiting for additional EAP input. =20 This text implies there is a problem, but it does not define what the = problem is. Or under what circumstances that problem arises. The issue is very specific to the case where the EAP lower layer is in = charge of rexmits, and the rexmits are solely client-side driven. It does not apply to any other case.=20 And if the EAP stack (the combination of EAP method, EAP layer, and EAP = lower layer) does not handle this case in a special way, then the state = machines may stall. None of that can be understood from the above text at all. Once the readers understand the issue, then they can proceed to "dealing = with it".=20 As for the suggested solutions, failing the authentication reduces the = resiliency of EAP solutions.=20 The other option requires an API between EAP method and EAP lower-layer.=20= OK, maybe we don't care about the analysis of the solutions, but we do = care about defining what the problem is. And also, this issue is not really an "applicability statement" matter. = This is a "requirement on EAP lower layer (which is based on strictly = client-driven rexmits)" matter, IMHO.=20 (I understand some people might want to get done with this, but if we = don't do it properly I'm afraid it'd open more problems than it solves = for people down the road). Alper =20 > Cheers Leif >=20 >=20 --Apple-Mail=_A289CAB2-4D1D-40A5-B579-333B2332F7C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Leif,





This "MUST" = cannot be implemented. It's not clear what an implementor "must" be = doing to comply.
This is = merely telling us "there's a problem, you MUST deal with it". =
This reads more like = recognition of an issue, rather than a solution.

I' = going to weigh in (as an individual) on this point.

There is = (imo) nothing inherently problematic about calling out a problem that = needs to be addressed in another specification, especially when writing = an applicability = statement.


I read the text = again, and let me recap it here:
> Alternatively, EAP permits a =
lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible =
for
> reliable delivery of EAP messages. Applications that use a =
lock-step or
> client-driven authentication protocol might benefit from this =
approach.
> 
> =
In addition to retransmission behavior applications need to deal =
with
> =
discarded EAP messages. For example, whenever some EAP methods receive  =
erroneous
> input, these methods discard the input rather than generating an =
error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be =
handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an =
EAP=20
> retransmit and waiting for additional EAP input.  =

This text implies there is a problem, but it = does not define what the problem is.
Or under what = circumstances that problem arises.

The issue is = very specific to the case where the EAP lower layer is in charge of = rexmits, and the rexmits are solely client-side driven.
It = does not apply to any other case. 
And if the EAP stack = (the combination of EAP method, EAP layer, and EAP lower layer) does not = handle this case in a special way, then the state machines may = stall.

None of that can be understood from the = above text at all.

Once the readers understand = the issue, then they can proceed to "dealing with = it". 

As for the suggested solutions, = failing the authentication reduces the resiliency of EAP = solutions. 
The other option requires an API between EAP = method and EAP lower-layer. 

OK, maybe we = don't care about the analysis of the solutions, but we do care about = defining what the problem is.

And also, this = issue is not really an "applicability statement" matter. This is a = "requirement on EAP lower layer (which is based on strictly = client-driven rexmits)" matter, IMHO. 

(I = understand some people might want to get done with this, but if we don't = do it properly I'm afraid it'd open more problems than it solves for = people down the = road).


Alper
 
























     Cheers = Leif



= --Apple-Mail=_A289CAB2-4D1D-40A5-B579-333B2332F7C7-- From hartmans@painless-security.com Sat Mar 9 06:41:53 2013 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 9439421F8635 for ; Sat, 9 Mar 2013 06:41: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=[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 zlcT-pzqus4E for ; Sat, 9 Mar 2013 06:41:34 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 81C5421F85E8 for ; Sat, 9 Mar 2013 06:41:34 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2CA08201F7; Sat, 9 Mar 2013 09:41:18 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id F1D2541CE; Sat, 9 Mar 2013 09:41:26 -0500 (EST) From: Sam Hartman To: Alper Yegin References: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> Date: Sat, 09 Mar 2013 09:41:26 -0500 In-Reply-To: (Alper Yegin's message of "Sat, 9 Mar 2013 16:09:27 +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" , Leif Johansson Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Sat, 09 Mar 2013 14:41:53 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Hi Leif, This "MUST" cannot be implemented. It's not clear Alper> what an implementor "must" be doing to comply. I've read the text and I agree with Leif; I believe it is fine as-in. I believe it's entirely reasonable to require applications to deal with an issue and to leave them several options how to do so. Yes, a particular application will probably only pick one of these options. --Sam From leifj@mnt.se Sat Mar 9 07:58:37 2013 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 7A1DE21F8673 for ; Sat, 9 Mar 2013 07:58:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[AWL=0.601, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ArftkjWS+cpS for ; Sat, 9 Mar 2013 07:58:36 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 557FE21F865D for ; Sat, 9 Mar 2013 07:58:30 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id ro8so2267392pbb.4 for ; Sat, 09 Mar 2013 07:58:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:content-transfer-encoding:subject :references:from:mime-version:in-reply-to:message-id:date:cc:to :x-mailer:x-gm-message-state; bh=EbplxZAIkef77sU15WzWDxqrT2HA+Tq+xPR3XWO+GLI=; b=Qa3KpfmxJuNVtz0zJCL6e3R1q9XmX86yLQepH6VvFHAMwy3qL4rizSA7QilHuY9XOv BWyklfaXILTdmupQvXRo3wES2jLQYol3L1X2xqEYlThzaa3XG/Yp+ULpFzXITBVWcI1W aOPxY6uDgXfrASrdNujP3ElvtJrZ8KM1xtkTJcj/ymaWXlshOtS3WV24O13S98lapIcF vRTdhSM3XDoPITHDX78iPTEVYVRVcmXuYaSFonVtSvwSQEwqbxdcltiMuXC7fFl1O9+q PrVFpUa0n4RV7EH4aaSttCounqQtrpERJXNI0QbqV5qjZuQ2IdeB1f8zytD64dyulYHG hTUA== X-Received: by 10.68.135.168 with SMTP id pt8mr12376687pbb.10.1362844709545; Sat, 09 Mar 2013 07:58:29 -0800 (PST) Received: from ?IPv6:2001:df8::64:60f6:f588:95aa:9dc0? ([2001:df8:0:64:60f6:f588:95aa:9dc0]) by mx.google.com with ESMTPS id ol7sm10837029pbb.14.2013.03.09.07.58.27 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 09 Mar 2013 07:58:28 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-4CB28D7B-26FB-44B5-BCED-2F3F4A7AE34A Content-Transfer-Encoding: 7bit References: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> From: Leif Johansson Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> Date: Sat, 9 Mar 2013 10:45:30 -0500 To: Alper Yegin X-Mailer: iPad Mail (10B146) X-Gm-Message-State: ALoCoQleYsQAnyHNuYk/RE0MoSwv1Wf++8mafVvHnzhBKO9YX2nevBwlCeFiHOcziO6wxOaW+nai Cc: "abfab@ietf.org" , Leif Johansson Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Sat, 09 Mar 2013 15:58:37 -0000 --Apple-Mail-4CB28D7B-26FB-44B5-BCED-2F3F4A7AE34A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 9 mar 2013 kl. 09:09 skrev Alper Yegin : > Hi Leif, >=20 >=20 >>=20 >>=20 >>>=20 >>> This "MUST" cannot be implemented. It's not clear what an implementor "m= ust" be doing to comply. >>> This is merely telling us "there's a problem, you MUST deal with it".=20= >>> This reads more like recognition of an issue, rather than a solution. >>=20 >> I' going to weigh in (as an individual) on this point.=20 >>=20 >> There is (imo) nothing inherently problematic about calling out a problem= that needs to be addressed in another specification, especially when writin= g an applicability statement. >>=20 >=20 > I read the text again, and let me recap it here: > > Alternatively, EAP permits a lower layer to set the retransmission timer= > > to infinite. When this happens, the lower layer becomes responsible for > > reliable delivery of EAP messages. Applications that use a lock-step or > > client-driven authentication protocol might benefit from this approach. > >=20 > > In addition to retransmission behavior applications need to deal with > > discarded EAP messages. For example, whenever some EAP methods receive e= rroneous > > input, these methods discard the input rather than generating an error > > response. If the erroneous input was generated by an attacker, > > legitimate input can sometimes be received after the erroneous > > input. Applications MUST handle discarded EAP messages, > > although the specific way in which discarded messages will be handled > > depend on the characteristics of the application. Options include > > failing the authentication at the application level, requesting an EAP=20= > > retransmit and waiting for additional EAP input. =20 >=20 > This text implies there is a problem, but it does not define what the prob= lem is. > Or under what circumstances that problem arises. >=20 > The issue is very specific to the case where the EAP lower layer is in cha= rge of rexmits, and the rexmits are solely client-side driven. > It does not apply to any other case.=20 > And if the EAP stack (the combination of EAP method, EAP layer, and EAP lo= wer layer) does not handle this case in a special way, then the state machin= es may stall. >=20 > None of that can be understood from the above text at all. >=20 > Once the readers understand the issue, then they can proceed to "dealing w= ith it".=20 >=20 > As for the suggested solutions, failing the authentication reduces the res= iliency of EAP solutions.=20 > The other option requires an API between EAP method and EAP lower-layer.=20= >=20 > OK, maybe we don't care about the analysis of the solutions, but we do car= e about defining what the problem is. >=20 > And also, this issue is not really an "applicability statement" matter. Th= is is a "requirement on EAP lower layer (which is based on strictly client-d= riven rexmits)" matter, IMHO.=20 >=20 > (I understand some people might want to get done with this, but if we don'= t do it properly I'm afraid it'd open more problems than it solves for peopl= e down the road). >=20 >=20 > Alper > =20 >=20 Why don't you propose text! >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> Cheers Leif >>=20 >>=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --Apple-Mail-4CB28D7B-26FB-44B5-BCED-2F3F4A7AE34A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


9 mar 2013 kl. 09:0= 9 skrev Alper Yegin <alper.yegin= @yegin.org>:

Hi Leif,




This "MUST" cannot b= e implemented. It's not clear what an implementor "must" be doing to comply.=
This is merely telling us "there'= s a problem, you MUST deal with it".
This reads more like recognition of an issue, rather than a solution.

I' going to weigh in (as an individual) on this point.
There is (imo) nothing inherently problematic about calling out a probl= em that needs to be addressed in another specification, especially when writ= ing an applicability statement.


I read the text again, and let me recap it here:
> Alternativel=
y, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible for=

> reliable delivery of EAP messages. Applications that use a lock-step or=

> client-driven authentication protocol might benefit from this approach.=

> 
> In addition to retransmission behavior applications need to d=
eal with
> discarded EAP messages. For example, whenever so=
me EAP methods receive  erroneous
> input, these methods discard the input rather than generating an error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an EAP=20=

> retransmit and waiting for additional EAP input.

=
This text implies there is a problem, but it does not define what the p= roblem is.
Or under what circumstances that problem arises.
<= div>
The issue is very specific to the case where the EAP lowe= r layer is in charge of rexmits, and the rexmits are solely client-side driv= en.
It does not apply to any other case. 
And if th= e EAP stack (the combination of EAP method, EAP layer, and EAP lower layer) d= oes not handle this case in a special way, then the state machines may stall= .

None of that can be understood from the above tex= t at all.

Once the readers understand the issue, th= en they can proceed to "dealing with it". 

As f= or the suggested solutions, failing the authentication reduces the resilienc= y of EAP solutions. 
The other option requires an API between= EAP method and EAP lower-layer. 

OK, maybe we= don't care about the analysis of the solutions, but we do care about defini= ng what the problem is.

And also, this issue is not= really an "applicability statement" matter. This is a "requirement on EAP l= ower layer (which is based on strictly client-driven rexmits)" matter, IMHO.=  

(I understand some people might want to get d= one with this, but if we don't do it properly I'm afraid it'd open more prob= lems than it solves for people down the road).


=
Alper
 


Why don't you propose text!








=




<= br>




<= div>




     Cheers Leif<= br>


_______________________________________________
abfab mailing list
abfab@ietf.org
https://www.ietf.org/mailman/listinfo/abfab=
= --Apple-Mail-4CB28D7B-26FB-44B5-BCED-2F3F4A7AE34A-- From leifj@sunet.se Sat Mar 9 08:03:35 2013 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 E84D121F86AE for ; Sat, 9 Mar 2013 08:03:35 -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 z-fqF5QQ91Kg for ; Sat, 9 Mar 2013 08:03:35 -0800 (PST) Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id 96DAA21F86AD for ; Sat, 9 Mar 2013 08:03:34 -0800 (PST) Received: from [130.129.64.98] (dhcp-4062.meeting.ietf.org [130.129.64.98]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r29G3SZK021400 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 9 Mar 2013 16:03:32 GMT Message-ID: <513B5D50.3020601@sunet.se> Date: Sat, 09 Mar 2013 17:03:28 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] One of abfab's dependencies is not moving as quickly as we had hoped 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, 09 Mar 2013 16:03:36 -0000 On 03/08/2013 01:41 PM, Sam Hartman wrote: > folks, the radext chairs have decided there is not currently rough > consensus to adopt the fragmentation draft. > We should track this closely. > > Thanks for keeping an eye on this Sam. I encourage everyone in the WG who is able, to show up at radext and express our need for this. Cheers Leif From alper.yegin@yegin.org Mon Mar 11 12:13:02 2013 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 25E8D21F8F7D for ; Mon, 11 Mar 2013 12:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S0P-UzFXD+Ak for ; Mon, 11 Mar 2013 12:13:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E45DC21F8DE6 for ; Mon, 11 Mar 2013 12:13:00 -0700 (PDT) Received: from [10.119.8.3] (prod01.i.dfw.fullmeshnetworks.com [174.34.133.220]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MDyyt-1TyKUb1FT5-00Gudj; Mon, 11 Mar 2013 15:12:58 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_92CC925A-2CFF-4685-B6EC-5DC8EBEF276E" From: Alper Yegin In-Reply-To: <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> Date: Mon, 11 Mar 2013 21:12:52 +0200 Message-Id: <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org> References: <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> To: Leif Johansson X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:6kUL15pMVxQclPjf6DnQlBe/AOlMV08hyuUSgqp0BiY o0+I3W8armwlemQhLG8FOoY5QECO6XN3HdkVC5v1QAHIb1I05U qbtlIj0oVtrn61myGp46Dzuv0Ga2KHPAvcjZYhvHZ5vQddXVhf FpIfAXtZuRPwd042DnZ1xRoTb0xmZSBUzhvFjU9NKC9y5vUTkk yGWfKikPwIYoRY0cE7sowtl089B8THZtXItf7g5QjPgf1kJIy7 X3GuXLNnW9A10MBvemmZRGHroevSqXuRMfunwt7BZtEtft4h0J 0ufMAGATkBpjU+9Qr5b3b22ttsH5bOkDb04PlUSBPU6FE3aM6E Zz96a4IvAzyOTivCfTT2QINtCS3YMe/U1HCAAgI0y Cc: abfab@ietf.org, Leif Johansson Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Mon, 11 Mar 2013 19:13:02 -0000 --Apple-Mail=_92CC925A-2CFF-4685-B6EC-5DC8EBEF276E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Here you go: 2.1 Retransmission In EAP, the authenticator is responsible for retransmission. By default EAP assumes that the lower layer (the application in this context) is unreliable. The authenticator can send a packet whenever its retransmission timer triggers. In this mode, applications need to be = able to receive and process=20 EAP messages at any time during the authentication conversation. Alternatively, EAP permits a lower layer to set the retransmission timer to infinite. When this happens, the lower layer becomes responsible for reliable delivery of EAP messages. Applications that use a lock-step or client-driven authentication protocol might benefit from this approach. When retransmission is exclusively handled by the client-side EAP = lower-layer,=20 an EAP message that gets silently discarded by the EAP method may stall = the=20 EAP lower-layer state machine. In such a case, applications MUST handle = discarded=20 EAP messages. The specific way in which discarded messages will be = handled depend on the characteristics of the application. Solution options = include,=20 but are not limited to, failing the authentication at the application = level,=20 and requesting an EAP retransmit and waiting for additional EAP input. = Both of=20 these options require the EAP methods to notify the EAP and/or EAP = lower-layer=20 when an EAP message is discarded. =20 Specifications of how EAP is used for application authentication MUST document how retransmission are handled. If the retransmissions are = exclusively=20 handled by the client-side EAP lower-layer, then the specifications MUST = also=20 document how message discards are handled. Alper On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote: >=20 >=20 > 9 mar 2013 kl. 09:09 skrev Alper Yegin : >=20 >> Hi Leif, >>=20 >>=20 >>>=20 >>>=20 >>>>=20 >>>> This "MUST" cannot be implemented. It's not clear what an = implementor "must" be doing to comply. >>>> This is merely telling us "there's a problem, you MUST deal with = it".=20 >>>> This reads more like recognition of an issue, rather than a = solution. >>>=20 >>> I' going to weigh in (as an individual) on this point.=20 >>>=20 >>> There is (imo) nothing inherently problematic about calling out a = problem that needs to be addressed in another specification, especially = when writing an applicability statement. >>>=20 >>=20 >> I read the text again, and let me recap it here: >> > Alternatively, EAP permits a lower layer to set the retransmission = timer >> > to infinite. When this happens, the lower layer becomes responsible = for >> > reliable delivery of EAP messages. Applications that use a = lock-step or >> > client-driven authentication protocol might benefit from this = approach. >> >=20 >> > In addition to retransmission behavior applications need to deal = with >> > discarded EAP messages. For example, whenever some EAP methods = receive erroneous >> > input, these methods discard the input rather than generating an = error >> > response. If the erroneous input was generated by an attacker, >> > legitimate input can sometimes be received after the erroneous >> > input. Applications MUST handle discarded EAP messages, >> > although the specific way in which discarded messages will be = handled >> > depend on the characteristics of the application. Options include >> > failing the authentication at the application level, requesting an = EAP=20 >> > retransmit and waiting for additional EAP input. =20 >>=20 >> This text implies there is a problem, but it does not define what the = problem is. >> Or under what circumstances that problem arises. >>=20 >> The issue is very specific to the case where the EAP lower layer is = in charge of rexmits, and the rexmits are solely client-side driven. >> It does not apply to any other case.=20 >> And if the EAP stack (the combination of EAP method, EAP layer, and = EAP lower layer) does not handle this case in a special way, then the = state machines may stall. >>=20 >> None of that can be understood from the above text at all. >>=20 >> Once the readers understand the issue, then they can proceed to = "dealing with it".=20 >>=20 >> As for the suggested solutions, failing the authentication reduces = the resiliency of EAP solutions.=20 >> The other option requires an API between EAP method and EAP = lower-layer.=20 >>=20 >> OK, maybe we don't care about the analysis of the solutions, but we = do care about defining what the problem is. >>=20 >> And also, this issue is not really an "applicability statement" = matter. This is a "requirement on EAP lower layer (which is based on = strictly client-driven rexmits)" matter, IMHO.=20 >>=20 >> (I understand some people might want to get done with this, but if we = don't do it properly I'm afraid it'd open more problems than it solves = for people down the road). >>=20 >>=20 >> Alper >> =20 >>=20 >=20 > Why don't you propose text! >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> Cheers Leif >>>=20 >>>=20 >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab --Apple-Mail=_92CC925A-2CFF-4685-B6EC-5DC8EBEF276E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Here = you go:
2.1 =
Retransmission

In =
EAP, the authenticator is responsible for retransmission. By =
default
EAP assumes that the lower layer (the application =
in this context) is
unreliable. The authenticator can send a packet =
whenever its
retransmission timer triggers. In this mode, =
applications need to be able to receive and process 
EAP =
messages at any time during the authentication conversation.

Alternatively, EAP permits a lower =
layer to set the retransmission timer
to infinite. When this =
happens, the lower layer becomes responsible for

When =
retransmission is exclusively handled by the client-side EAP =
lower-layer, 
an EAP message that gets silently discarded by the =
EAP method may stall the 
EAP lower-layer state machine.  =
In such a case, applications MUST handle discarded 
EAP =
messages. The specific way in which discarded messages will be =
handled
depend on the characteristics of the application. =
Solution options include, 
but are not limited to, failing the =
authentication at the application level, 
and =
requesting an EAP retransmit and waiting for additional EAP input. Both =
of 
these options require the EAP methods to notify =
the EAP and/or EAP lower-layer 
when an EAP message is discarded. =
 

document how retransmission are handled. If the =
retransmissions are exclusively 
handled by the client-side =
EAP lower-layer, then the specifications MUST also 


9 mar 2013 kl. 09:09 skrev Alper =
Yegin <alper.yegin@yegin.org>:
Hi =
Leif,





This "MUST" =
cannot be implemented. It's not clear what an implementor "must" be =
doing to comply.
This is =
merely telling us "there's a problem, you MUST deal with it". =

This reads more like =
recognition of an issue, rather than a solution.

I' =
going to weigh in (as an individual) on this point. 

There is =
(imo) nothing inherently problematic about calling out a problem that =
needs to be addressed in another specification, especially when writing =
an applicability =
statement.


I read the text =
again, and let me recap it here:
> Alternatively, EAP permits a =
lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible =
for
> reliable delivery of EAP messages. Applications that use a =
lock-step or
> client-driven authentication protocol might benefit from this =
approach.
> 
> =
In addition to retransmission behavior applications need to deal =
with
> =
discarded EAP messages. For example, whenever some EAP methods receive  =
erroneous
> input, these methods discard the input rather than generating an =
error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be =
handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an =
EAP=20
> retransmit and waiting for additional EAP input.  =


This text implies there is a problem, but it =
does not define what the problem is.
Or under what =
circumstances that problem arises.

The issue is =
very specific to the case where the EAP lower layer is in charge of =
rexmits, and the rexmits are solely client-side driven.
It =
does not apply to any other case. 
And if the EAP stack =
(the combination of EAP method, EAP layer, and EAP lower layer) does not =
handle this case in a special way, then the state machines may =
stall.

None of that can be understood from the =
above text at all.

Once the readers understand =
the issue, then they can proceed to "dealing with =
it". 

As for the suggested solutions, =
failing the authentication reduces the resiliency of EAP =
solutions. 
The other option requires an API between EAP =
method and EAP lower-layer. 

OK, maybe we =
don't care about the analysis of the solutions, but we do care about =
defining what the problem is.

And also, this =
issue is not really an "applicability statement" matter. This is a =
"requirement on EAP lower layer (which is based on strictly =
client-driven rexmits)" matter, IMHO. 

(I =
understand some people might want to get done with this, but if we don't =
do it properly I'm afraid it'd open more problems than it solves for =
people down the =
road).


Alper
 


W=
hy don't you propose text!




<=
/div>





=









<=
div>




=

      Cheers =
Leif



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

=

--Apple-Mail=_92CC925A-2CFF-4685-B6EC-5DC8EBEF276E--

From alper.yegin@yegin.org  Mon Mar 11 12:26:41 2013
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 5752221F8F7A for ; Mon, 11 Mar 2013 12:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CLDpZXCpT9CX for ; Mon, 11 Mar 2013 12:26:40 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8883C21F8EDF for ; Mon, 11 Mar 2013 12:26:40 -0700 (PDT)
Received: from [10.119.8.3] (prod01.i.dfw.fullmeshnetworks.com [174.34.133.220]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0M7p1M-1V1kmT3KZU-00vlMX; Mon, 11 Mar 2013 15:26:39 -0400
From: Alper Yegin 
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_821850F8-B6E4-4895-89B7-547D2A68819B"
Date: Mon, 11 Mar 2013 21:26:37 +0200
In-Reply-To: <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org>
To: abfab@ietf.org
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net>  <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org>
Message-Id: <9B8A9FC0-F7A8-458E-9C86-61810976949C@yegin.org>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:aAbz+S4gFNcHkT+2Tu51MDv0F4BtcW7Exf7nmGemJ9p A9UWev3stcFghYpJkG72EG/xKnkglLarnIMDMH8K2idkX4M3aD 4Dqox0Tmss56/hRaP2pQeKMky1zUI4NDvIj7Xq5I7cD7qVa2cq 4ynmHVGQTlDqoKRfi4mc4hRiveaB+3x5VCn7zXXzd4JWn6aDJu j8Z6b92Yg2qhsBYL98jKtsrmrRVX37y6j3lUEpVEUV9jHulZ1B jSeeLjkj93ZSW8BwyMrH3iUJT/1kteZGHQeaKTgia43NbAVjaF wZu+SXCTrjrSjFO6JMDR25dvMiJJmcngYlAB7Q21IJhlWvvI2w dZBn+JCxAwFD3/MyqVc9kcR3UKN3dwSsEvkAlf5sz
Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Mon, 11 Mar 2013 19:26:41 -0000

--Apple-Mail=_821850F8-B6E4-4895-89B7-547D2A68819B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

One more issue=85


  Uses of EAP for Application-Layer Access

   Ongoing work in the IETF (abfab working group) specifies the use of
   EAP over GSSAPI for generic application layer access.  In the past,
   using EAP in this context has met resistance due to the lack of
   channel bindings [RFC6677].  Without channel bindings, a peer cannot
   verify if an authenticator is authorized to provide an advertised
   service.  >>> In most network access use cases all access servers =
that
   are served by a particular EAP server are providing the same or very
   similar types of service.  The peer does not need to differentiate
   between different access network services supported by the same EAP
   server. <<<


The statement conveyed by those last two sentences are not accurate. The =
services provided across different access networks can vary a lot. The =
simplest example is WiFi roaming. You could be using the same =
subscription across the globe, but each time you may be accessing the =
Internet via a distinct WiFi operator. =20

Now, the authors may feel reluctant to mandate channel binding on the =
network access authentication case as well. But at least, they shouldn't =
include a statement like the one above, which claims channel binding is =
not necessary for the network access case.

Alper













--Apple-Mail=_821850F8-B6E4-4895-89B7-547D2A68819B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

One more =
issue=85


  Uses of EAP =
for Application-Layer Access

   EAP over GSSAPI for generic =
application layer access.  In the past,
   channel bindings [RFC6677].  Without channel bindings, a peer =
cannot
   verify if an authenticator is =
authorized to provide an advertised
   service.  =
>>> In most network access use cases all access servers =
that
   are served by a particular EAP =
server are providing the same or very
   similar types =
of service.  The peer does not need to differentiate
   server. <<<

The statement conveyed by those =
last two sentences are not accurate. The services provided across =
different access networks can vary a lot. The simplest example is =
WiFi roaming. You could be using the same subscription across the globe, =
but each time you may be accessing the Internet via a distinct WiFi =
operator.  

Now, the authors may feel reluctant =
to mandate channel binding on the network access authentication case as =
well. But at least, they shouldn't include a statement like the one =
above, which claims channel binding is not necessary for the network =
access case.

Alper









=

--Apple-Mail=_821850F8-B6E4-4895-89B7-547D2A68819B--

From leifj@sunet.se  Mon Mar 11 12:35:52 2013
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 53A3A21F8FD4 for ; Mon, 11 Mar 2013 12:35:52 -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.001, BAYES_00=-2.599, HTML_MESSAGE=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 U2M2jfJ0ltPB for ; Mon, 11 Mar 2013 12:35:51 -0700 (PDT)
Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id 78E9121F8E5A for ; Mon, 11 Mar 2013 12:35:50 -0700 (PDT)
Received: from [130.129.10.34] (dhcp-9222.meeting.ietf.org [130.129.10.34]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r2BJZhOM018603 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 11 Mar 2013 19:35:48 GMT
Message-ID: <513E320E.5090904@sunet.se>
Date: Mon, 11 Mar 2013 20:35:42 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: abfab@ietf.org
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net>  <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org>
In-Reply-To: <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org>
Content-Type: multipart/alternative; boundary="------------090309090900070401050504"
Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Mon, 11 Mar 2013 19:35:52 -0000

This is a multi-part message in MIME format.
--------------090309090900070401050504
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 03/11/2013 08:12 PM, Alper Yegin wrote:
> Here you go:
So this replaces all of 2.1 (just to be clear) ?
> 2.1 Retransmission
> In EAP, the authenticator is responsible for retransmission. By default
> EAP assumes that the lower layer (the application in this context) is
> unreliable. The authenticator can send a packet whenever its
> retransmission timer triggers. In this mode, applications need to be
> able to receive and process 
> EAP messages at any time during the authentication conversation.
> Alternatively, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible for
> reliable delivery of EAP messages. Applications that use a lock-step or
> client-driven authentication protocol might benefit from this approach.
> When retransmission is exclusively handled by the client-side EAP
> lower-layer, 
> an EAP message that gets silently discarded by the EAP method may
> stall the 
> EAP lower-layer state machine.  In such a case, applications MUST
> handle discarded 
> EAP messages. The specific way in which discarded messages will be handled
> depend on the characteristics of the application. Solution options
> include, 
> but are not limited to, failing the authentication at the application
> level, 
> and requesting an EAP retransmit and waiting for additional EAP input.
> Both of 
> these options require the EAP methods to notify the EAP and/or EAP
> lower-layer 
> when an EAP message is discarded.  
> Specifications of how EAP is used for application authentication MUST
> document how retransmission are handled. If the retransmissions are
> exclusively 
> handled by the client-side EAP lower-layer, then the specifications
> MUST also 
> document how message discards are handled.
>
> Alper
>
>
>
>
>
> On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote:
>
>>
>>
>> 9 mar 2013 kl. 09:09 skrev Alper Yegin > >:
>>
>>> Hi Leif,
>>>
>>>
>>>>
>>>>
>>>>>
>>>>> This "MUST" cannot be implemented. It's not clear what an
>>>>> implementor "must" be doing to comply.
>>>>> This is merely telling us "there's a problem, you MUST deal with it".
>>>>> This reads more like recognition of an issue, rather than a solution.
>>>>
>>>> I' going to weigh in (as an individual) on this point.
>>>>
>>>> There is (imo) nothing inherently problematic about calling out a
>>>> problem that needs to be addressed in another specification,
>>>> especially when writing an applicability statement.
>>>>
>>>
>>> I read the text again, and let me recap it here:
>>> > Alternatively, EAP permits a lower layer to set the retransmission timer
>>> > to infinite. When this happens, the lower layer becomes responsible for
>>> > reliable delivery of EAP messages. Applications that use a lock-step or
>>> > client-driven authentication protocol might benefit from this approach.
>>> > 
>>> > In addition to retransmission behavior applications need to deal with
>>> > discarded EAP messages. For example, whenever some EAP methods receive  erroneous
>>> > input, these methods discard the input rather than generating an error
>>> > response. If the erroneous input was generated by an attacker,
>>> > legitimate input can sometimes be received after the erroneous
>>> > input. Applications MUST handle discarded EAP messages,
>>> > although the specific way in which discarded messages will be handled
>>> > depend on the characteristics of the application. Options include
>>> > failing the authentication at the application level, requesting an EAP 
>>> > retransmit and waiting for additional EAP input.  
>>>
>>> This text implies there is a problem, but it does not define what
>>> the problem is.
>>> Or under what circumstances that problem arises.
>>>
>>> The issue is very specific to the case where the EAP lower layer is
>>> in charge of rexmits, and the rexmits are solely client-side driven.
>>> It does not apply to any other case. 
>>> And if the EAP stack (the combination of EAP method, EAP layer, and
>>> EAP lower layer) does not handle this case in a special way, then
>>> the state machines may stall.
>>>
>>> None of that can be understood from the above text at all.
>>>
>>> Once the readers understand the issue, then they can proceed to
>>> "dealing with it". 
>>>
>>> As for the suggested solutions, failing the authentication reduces
>>> the resiliency of EAP solutions. 
>>> The other option requires an API between EAP method and EAP
>>> lower-layer. 
>>>
>>> OK, maybe we don't care about the analysis of the solutions, but we
>>> do care about defining what the problem is.
>>>
>>> And also, this issue is not really an "applicability statement"
>>> matter. This is a "requirement on EAP lower layer (which is based on
>>> strictly client-driven rexmits)" matter, IMHO. 
>>>
>>> (I understand some people might want to get done with this, but if
>>> we don't do it properly I'm afraid it'd open more problems than it
>>> solves for people down the road).
>>>
>>>
>>> Alper
>>>  
>>>
>>
>> Why don't you propose text!
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>>      Cheers Leif
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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


--------------090309090900070401050504
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/11/2013 08:12 PM, Alper Yegin
      wrote:

    

    

      

        
Here you go:

      

    

    So this replaces all of 2.1 (just to be clear) ?

    

      

        
2.1 Retransmission


In EAP, the authenticator is responsible for retransmission. By default
EAP assumes that the lower layer (the application in this context) is
unreliable. The authenticator can send a packet whenever its
retransmission timer triggers. In this mode, applications need to be able to receive and process 
EAP messages at any time during the authentication conversation.


Alternatively, EAP permits a lower layer to set the retransmission timer
to infinite. When this happens, the lower layer becomes responsible for
reliable delivery of EAP messages. Applications that use a lock-step or
client-driven authentication protocol might benefit from this approach.


When retransmission is exclusively handled by the client-side EAP lower-layer, 
an EAP message that gets silently discarded by the EAP method may stall the 
EAP lower-layer state machine.  In such a case, applications MUST handle discarded 
EAP messages. The specific way in which discarded messages will be handled
depend on the characteristics of the application. Solution options include, 
but are not limited to, failing the authentication at the application level, 
and requesting an EAP retransmit and waiting for additional EAP input. Both of 
these options require the EAP methods to notify the EAP and/or EAP lower-layer 
when an EAP message is discarded.  


Specifications of how EAP is used for application authentication MUST
document how retransmission are handled. If the retransmissions are exclusively 
handled by the client-side EAP lower-layer, then the specifications MUST also 
document how message discards are handled.

      

      


      

      
Alper

      


      

      


      

      


      

      


      

      

      

        
On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote:

        

        

          
          

            


            

            


              9 mar 2013 kl. 09:09 skrev Alper Yegin <alper.yegin@yegin.org>:

              

            

            

              
Hi Leif,
                


                  

                    


                    

                    

                      


                        

                        


                        

                        
This "MUST" cannot be
                          implemented. It's not clear what an
                          implementor "must" be doing to comply.

                        

                        
This is merely telling
                          us "there's a problem, you MUST deal with it".
                          

                        

                        
This reads more like
                          recognition of an issue, rather than a
                          solution.

                        

                        

                        I' going to weigh in (as an individual) on this
                        point. 

                        

                        There is (imo) nothing inherently problematic
                        about calling out a problem that needs to be
                        addressed in another specification, especially
                        when writing an applicability statement.

                        

                      

                    

                    


                    

                    
I read the text again, and let me recap it
                      here:

                    

                      
> Alternatively, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible for
> reliable delivery of EAP messages. Applications that use a lock-step or
> client-driven authentication protocol might benefit from this approach.
> 

                      
> In addition to retransmission behavior applications need to deal with

                    

                    

                      
> discarded EAP messages. For example, whenever some EAP methods receive  erroneous
> input, these methods discard the input rather than generating an error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an EAP 
> retransmit and waiting for additional EAP input.  

                      


                      

                      
This text implies there is a problem, but it
                        does not define what the problem is.

                      
Or under what circumstances that problem
                        arises.

                      


                      

                      
The issue is very specific to the case where
                        the EAP lower layer is in charge of rexmits, and
                        the rexmits are solely client-side driven.

                      
It does not apply to any other case. 

                      
And if the EAP stack (the combination of EAP
                        method, EAP layer, and EAP lower layer) does not
                        handle this case in a special way, then the
                        state machines may stall.

                      


                      

                      
None of that can be understood from the above
                        text at all.

                      


                      

                      
Once the readers understand the issue, then
                        they can proceed to "dealing with it". 

                      


                      

                      
As for the suggested solutions, failing the
                        authentication reduces the resiliency of EAP
                        solutions. 

                      
The other option requires an API between EAP
                        method and EAP lower-layer. 

                      


                      

                      
OK, maybe we don't care about the analysis of
                        the solutions, but we do care about defining
                        what the problem is.

                      


                      

                      
And also, this issue is not really an
                        "applicability statement" matter. This is a
                        "requirement on EAP lower layer (which is based
                        on strictly client-driven rexmits)" matter,
                        IMHO. 

                      


                      

                      
(I understand some people might want to get
                        done with this, but if we don't do it properly
                        I'm afraid it'd open more problems than it
                        solves for people down the road).

                      


                      

                      


                      

                      
Alper

                      
 

                      


                      

                    

                  

                

              

            

            


            

            
Why don't you propose text!

            

            

              

                

                  

                    

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                    

                    


                    

                    


                    

                    


                    

                    


                    

                    


                    

                    


                    

                    

                    

                      
      Cheers Leif

                        

                        

                      

                    

                  

                  

                

              

            

            

              
_______________________________________________

                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


    

    

  


--------------090309090900070401050504--

From hartmans@painless-security.com  Tue Mar 12 04:51:34 2013
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 B5BC021F87AA for ; Tue, 12 Mar 2013 04:51:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.604
X-Spam-Level: 
X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.995,  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 OG6go1IARF+6 for ; Tue, 12 Mar 2013 04:51:34 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 3E31621F8793 for ; Tue, 12 Mar 2013 04:51:33 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (unknown [130.129.129.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id BCA4320167; Tue, 12 Mar 2013 07:51:11 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id A839441CF; Tue, 12 Mar 2013 07:51:31 -0400 (EDT)
From: Sam Hartman 
To: Alper Yegin 
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net>  <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org> <9B8A9FC0-F7A8-458E-9C86-61810976949C@yegin.org>
Date: Tue, 12 Mar 2013 07:51:31 -0400
In-Reply-To: <9B8A9FC0-F7A8-458E-9C86-61810976949C@yegin.org> (Alper Yegin's message of "Mon, 11 Mar 2013 21:26:37 +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] Summary of proposed changes to eat applicability.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: Tue, 12 Mar 2013 11:51:34 -0000

>>>>> "Alper" == Alper Yegin  writes:

    Alper> One more issue Uses of EAP for Application-Layer Access

    Alper> The statement conveyed by those last two sentences are not
    Alper> accurate. The services provided across different access
    Alper> networks can vary a lot. The simplest example is WiFi
    Alper> roaming. You could be using the same subscription across the
    Alper> globe, but each time you may be accessing the Internet via a
    Alper> distinct WiFi operator.

I agree.  I propose we drop those sentences; RFc 6677 already goes into
detail about channel binding and network access.

From hartmans@painless-security.com  Tue Mar 12 05:02:36 2013
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 BF53D21F8751 for ; Tue, 12 Mar 2013 05:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.936
X-Spam-Level: 
X-Spam-Status: No, score=-1.936 tagged_above=-999 required=5 tests=[AWL=0.664,  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 UQCP7qr4xrsn for ; Tue, 12 Mar 2013 05:02:36 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 480C221F8714 for ; Tue, 12 Mar 2013 05:02:36 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (unknown [130.129.129.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 0AFE220167 for ; Tue, 12 Mar 2013 08:02:14 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1636841CF; Tue, 12 Mar 2013 08:02:34 -0400 (EDT)
From: Sam Hartman 
To: abfab@ietf.org
Date: Tue, 12 Mar 2013 08:02:34 -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] trust-router@ietf.org mailing list
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, 12 Mar 2013 12:02:36 -0000

Folks, we've asked and received the trust-router@ietf.org mailing list
to discuss the trust router and our bar BOF on Thursday and ongoing
efforts.

Thanks,

--Sam

From alper.yegin@yegin.org  Tue Mar 12 05:04:58 2013
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 3AF2D21F859C for ; Tue, 12 Mar 2013 05:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Level: 
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E0+WMvN5Dxp4 for ; Tue, 12 Mar 2013 05:04:57 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C8A9521F85EE for ; Tue, 12 Mar 2013 05:04:56 -0700 (PDT)
Received: from [10.119.8.6] ([208.81.246.117]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MO8aK-1U9sAw1rka-005WuX; Tue, 12 Mar 2013 08:04:54 -0400
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_E1589C67-31E0-4736-A704-F4A66B23C5A1"
From: Alper Yegin 
In-Reply-To: <513E320E.5090904@sunet.se>
Date: Tue, 12 Mar 2013 14:04:49 +0200
Message-Id: 
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net>  <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org> <513E320E.5090904@sunet.se>
To: Leif Johansson 
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:kpNA1YQn8oXWKS4VUCKhruS/bPXd+YnbO8dcoOb3fVC LaGtfeMy/w1aLI7cbJSImpOBlOnS/s8dfhxF+CbaCofUZb5Xx/ KVwk7zdtjWK/myWp6797kKmv5bzofyy3N2KMcDlUNm0WW591K1 +Xe2va7JAtizA9/qysg+Mh5Robws+EWQ268X0kMpmKh1w5Kkif +WDeynqYo7GZAO+YXaLDSpguN/0lF/FaN/Ok0J38Eupyx+KDr7 YcXo6ajWPBJ6bYhFjxJkBUtvUdc2+Z4lG6d2OfgCtov95SE7cb D6e/KRFtPXiwVNqFDTytWyGmNgmKvzrQQkbC89WjIYZjZ7XnO5 omALbS/myGfcOeSs6iTSLc7ENAjvKdQCM1dBxLhBO
Cc: abfab@ietf.org
Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Tue, 12 Mar 2013 12:04:58 -0000

--Apple-Mail=_E1589C67-31E0-4736-A704-F4A66B23C5A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

Yes.

On Mar 11, 2013, at 9:35 PM, Leif Johansson wrote:

> On 03/11/2013 08:12 PM, Alper Yegin wrote:
>> Here you go:
> So this replaces all of 2.1 (just to be clear) ?
>> 2.1 Retransmission
>>=20
>> In EAP, the authenticator is responsible for retransmission. By =
default
>> EAP assumes that the lower layer (the application in this context) is
>> unreliable. The authenticator can send a packet whenever its
>> retransmission timer triggers. In this mode, applications need to be =
able to receive and process=20
>> EAP messages at any time during the authentication conversation.
>>=20
>> Alternatively, EAP permits a lower layer to set the retransmission =
timer
>> to infinite. When this happens, the lower layer becomes responsible =
for
>> reliable delivery of EAP messages. Applications that use a lock-step =
or
>> client-driven authentication protocol might benefit from this =
approach.
>>=20
>> When retransmission is exclusively handled by the client-side EAP =
lower-layer,=20
>> an EAP message that gets silently discarded by the EAP method may =
stall the=20
>> EAP lower-layer state machine.  In such a case, applications MUST =
handle discarded=20
>> EAP messages. The specific way in which discarded messages will be =
handled
>> depend on the characteristics of the application. Solution options =
include,=20
>> but are not limited to, failing the authentication at the application =
level,=20
>> and requesting an EAP retransmit and waiting for additional EAP =
input. Both of=20
>> these options require the EAP methods to notify the EAP and/or EAP =
lower-layer=20
>> when an EAP message is discarded. =20
>>=20
>> Specifications of how EAP is used for application authentication MUST
>> document how retransmission are handled. If the retransmissions are =
exclusively=20
>> handled by the client-side EAP lower-layer, then the specifications =
MUST also=20
>> document how message discards are handled.
>>=20
>> Alper
>>=20
>>=20
>>=20
>>=20
>>=20
>> On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote:
>>=20
>>>=20
>>>=20
>>> 9 mar 2013 kl. 09:09 skrev Alper Yegin :
>>>=20
>>>> Hi Leif,
>>>>=20
>>>>=20
>>>>>=20
>>>>>=20
>>>>>>=20
>>>>>> This "MUST" cannot be implemented. It's not clear what an =
implementor "must" be doing to comply.
>>>>>> This is merely telling us "there's a problem, you MUST deal with =
it".=20
>>>>>> This reads more like recognition of an issue, rather than a =
solution.
>>>>>=20
>>>>> I' going to weigh in (as an individual) on this point.=20
>>>>>=20
>>>>> There is (imo) nothing inherently problematic about calling out a =
problem that needs to be addressed in another specification, especially =
when writing an applicability statement.
>>>>>=20
>>>>=20
>>>> I read the text again, and let me recap it here:
>>>> > Alternatively, EAP permits a lower layer to set the =
retransmission timer
>>>> > to infinite. When this happens, the lower layer becomes =
responsible for
>>>> > reliable delivery of EAP messages. Applications that use a =
lock-step or
>>>> > client-driven authentication protocol might benefit from this =
approach.
>>>> >=20
>>>> > In addition to retransmission behavior applications need to deal =
with
>>>> > discarded EAP messages. For example, whenever some EAP methods =
receive  erroneous
>>>> > input, these methods discard the input rather than generating an =
error
>>>> > response. If the erroneous input was generated by an attacker,
>>>> > legitimate input can sometimes be received after the erroneous
>>>> > input. Applications MUST handle discarded EAP messages,
>>>> > although the specific way in which discarded messages will be =
handled
>>>> > depend on the characteristics of the application. Options include
>>>> > failing the authentication at the application level, requesting =
an EAP=20
>>>> > retransmit and waiting for additional EAP input. =20
>>>>=20
>>>> This text implies there is a problem, but it does not define what =
the problem is.
>>>> Or under what circumstances that problem arises.
>>>>=20
>>>> The issue is very specific to the case where the EAP lower layer is =
in charge of rexmits, and the rexmits are solely client-side driven.
>>>> It does not apply to any other case.=20
>>>> And if the EAP stack (the combination of EAP method, EAP layer, and =
EAP lower layer) does not handle this case in a special way, then the =
state machines may stall.
>>>>=20
>>>> None of that can be understood from the above text at all.
>>>>=20
>>>> Once the readers understand the issue, then they can proceed to =
"dealing with it".=20
>>>>=20
>>>> As for the suggested solutions, failing the authentication reduces =
the resiliency of EAP solutions.=20
>>>> The other option requires an API between EAP method and EAP =
lower-layer.=20
>>>>=20
>>>> OK, maybe we don't care about the analysis of the solutions, but we =
do care about defining what the problem is.
>>>>=20
>>>> And also, this issue is not really an "applicability statement" =
matter. This is a "requirement on EAP lower layer (which is based on =
strictly client-driven rexmits)" matter, IMHO.=20
>>>>=20
>>>> (I understand some people might want to get done with this, but if =
we don't do it properly I'm afraid it'd open more problems than it =
solves for people down the road).
>>>>=20
>>>>=20
>>>> Alper
>>>> =20
>>>>=20
>>>=20
>>> Why don't you propose text!
>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>>      Cheers Leif
>>>>>=20
>>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> abfab mailing list
>>>> abfab@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/abfab
>>=20
>>=20
>>=20
>> _______________________________________________
>> abfab mailing list
>> abfab@ietf.org
>> https://www.ietf.org/mailman/listinfo/abfab
>=20
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab


--Apple-Mail=_E1589C67-31E0-4736-A704-F4A66B23C5A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1



 =20
    
 =20
  

    
On 03/11/2013 08:12 PM, Alper Yegin
      wrote:

    

    
=

      

        
Here =
you go:

      

    

    So this replaces all of 2.1 (just to be clear) ?

    
=

      

        
2.1 =
Retransmission


EAP assumes that the lower layer (the application =
in this context) is
unreliable. The authenticator can send a packet =
whenever its
retransmission timer triggers. In this mode, =
applications need to be able to receive and process 
EAP messages at any time during the authentication =
conversation.


to infinite. When this happens, the lower layer =
becomes responsible for
reliable delivery of EAP messages. =
Applications that use a lock-step or
client-driven authentication =
protocol might benefit from this approach.


an EAP message that gets silently discarded by the =
EAP method may stall the 
EAP lower-layer state machine.  =
In such a case, applications MUST handle discarded 
EAP =
messages. The specific way in which discarded messages will be =
handled
depend on the characteristics of =
the application. Solution options include, 
but =
are not limited to, failing the authentication at the application =
level, 
and requesting an EAP retransmit and waiting for =
additional EAP input. Both of 
these options require the EAP =
methods to notify the EAP and/or EAP lower-layer 
when =
an EAP message is discarded.  


document how retransmission are handled. If the =
retransmissions are exclusively 
handled by the client-side =
EAP lower-layer, then the specifications MUST also 

        

          
          

            


            

            


              9 mar 2013 kl. 09:09 skrev Alper Yegin <alper.yegin@yegin.org>:

              

            

            

              
Hi Leif,
                


                  

                    


                    

                    

                      


                        

                        


                        

                        
This "MUST" cannot be
                          implemented. It's not clear what an
                          implementor "must" be doing to comply.

                        

                        
This is merely telling
                          us "there's a problem, you MUST deal with it".
                          

                        

                        
This reads more like
                          recognition of an issue, rather than a
                          solution.

                        

                        

                        I' going to weigh in (as an individual) on this
                        point. 

                        

                        There is (imo) nothing inherently problematic
                        about calling out a problem that needs to be
                        addressed in another specification, especially
                        when writing an applicability statement.

                        

                      

                    

                    


                    

                    
I read the text again, and let me recap it
                      here:

                    

                      
> =
Alternatively, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible =
for
> reliable delivery of EAP messages. Applications that use a =
lock-step or
> client-driven authentication protocol might benefit from this =
approach.
> 

                      
> =
In addition to retransmission behavior applications need to deal =
with

                    

                    

                      
> =
discarded EAP messages. For example, whenever some EAP methods receive  =
erroneous
> input, these methods discard the input rather than generating an =
error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be =
handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an =
EAP=20
> retransmit and waiting for additional EAP input.  

                      


                      

                      
This text implies there is a problem, but it
                        does not define what the problem is.

                      
Or under what circumstances that problem
                        arises.

                      


                      

                      
The issue is very specific to the case where
                        the EAP lower layer is in charge of rexmits, and
                        the rexmits are solely client-side driven.

                      
It does not apply to any other =
case. 

                      
And if the EAP stack (the combination of EAP
                        method, EAP layer, and EAP lower layer) does not
                        handle this case in a special way, then the
                        state machines may stall.

                      


                      

                      
None of that can be understood from the above
                        text at all.

                      


                      

                      
Once the readers understand the issue, then
                        they can proceed to "dealing with =
it". 

                      


                      

                      
As for the suggested solutions, failing the
                        authentication reduces the resiliency of EAP
                        solutions. 

                      
The other option requires an API between EAP
                        method and EAP lower-layer. 

                      


                      

                      
OK, maybe we don't care about the analysis of
                        the solutions, but we do care about defining
                        what the problem is.

                      


                      

                      
And also, this issue is not really an
                        "applicability statement" matter. This is a
                        "requirement on EAP lower layer (which is based
                        on strictly client-driven rexmits)" matter,
                        IMHO. 

                      


                      

                      
(I understand some people might want to get
                        done with this, but if we don't do it properly
                        I'm afraid it'd open more problems than it
                        solves for people down the road).

                      


                      

                      


                      

                      
Alper

                      
 

                      


                      

                    

                  

                

              

            

            


            

            
Why don't you propose text!

            

            

              

                

                  

                    

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                      


                      

                    

                    


                    

                    


                    

                    


                    

                    


                    

                    


                    

                    


                    

                    

                    

                      
      Cheers =
Leif

                        

                        

                      

                    

                  

                  

                

              

            

            

              =

_______________________________________________

                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


    

    

  


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

=

--Apple-Mail=_E1589C67-31E0-4736-A704-F4A66B23C5A1--

From leifj@sunet.se  Tue Mar 12 06:06:38 2013
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 8678E21F8A47 for ; Tue, 12 Mar 2013 06:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=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 SJDugwAHXZ-n for ; Tue, 12 Mar 2013 06:06:37 -0700 (PDT)
Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id 9855721F8A2A for ; Tue, 12 Mar 2013 06:06:36 -0700 (PDT)
Received: from [130.129.10.34] (dhcp-9222.meeting.ietf.org [130.129.10.34]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r2CD6TuX002610 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Mar 2013 13:06:34 GMT
Message-ID: <513F2855.3000803@sunet.se>
Date: Tue, 12 Mar 2013 14:06:29 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: Alper Yegin 
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net>  <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org> <513E320E.5090904@sunet.se> 
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------080704070906080204030502"
Cc: abfab@ietf.org
Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Tue, 12 Mar 2013 13:06:38 -0000

This is a multi-part message in MIME format.
--------------080704070906080204030502
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 03/12/2013 01:04 PM, Alper Yegin wrote:
> Yes.
>

So at this point I want to hear from others in the WG about this
proposed change.

> On Mar 11, 2013, at 9:35 PM, Leif Johansson wrote:
>
>> On 03/11/2013 08:12 PM, Alper Yegin wrote:
>>> Here you go:
>> So this replaces all of 2.1 (just to be clear) ?
>>> 2.1 Retransmission
>>> In EAP, the authenticator is responsible for retransmission. By default
>>> EAP assumes that the lower layer (the application in this context) is
>>> unreliable. The authenticator can send a packet whenever its
>>> retransmission timer triggers. In this mode, applications need to be
>>> able to receive and process 
>>> EAP messages at any time during the authentication conversation.
>>> Alternatively, EAP permits a lower layer to set the retransmission timer
>>> to infinite. When this happens, the lower layer becomes responsible for
>>> reliable delivery of EAP messages. Applications that use a lock-step or
>>> client-driven authentication protocol might benefit from this approach.
>>> When retransmission is exclusively handled by the client-side EAP
>>> lower-layer, 
>>> an EAP message that gets silently discarded by the EAP method may
>>> stall the 
>>> EAP lower-layer state machine.  In such a case, applications MUST
>>> handle discarded 
>>> EAP messages. The specific way in which discarded messages will be
>>> handled
>>> depend on the characteristics of the application. Solution options
>>> include, 
>>> but are not limited to, failing the authentication at the
>>> application level, 
>>> and requesting an EAP retransmit and waiting for additional EAP
>>> input. Both of 
>>> these options require the EAP methods to notify the EAP and/or EAP
>>> lower-layer 
>>> when an EAP message is discarded.  
>>> Specifications of how EAP is used for application authentication MUST
>>> document how retransmission are handled. If the retransmissions are
>>> exclusively 
>>> handled by the client-side EAP lower-layer, then the specifications
>>> MUST also 
>>> document how message discards are handled.
>>>
>>> Alper
>>>
>>>
>>>
>>>
>>>
>>> On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote:
>>>
>>>>
>>>>
>>>> 9 mar 2013 kl. 09:09 skrev Alper Yegin >>> >:
>>>>
>>>>> Hi Leif,
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> This "MUST" cannot be implemented. It's not clear what an
>>>>>>> implementor "must" be doing to comply.
>>>>>>> This is merely telling us "there's a problem, you MUST deal with
>>>>>>> it".
>>>>>>> This reads more like recognition of an issue, rather than a
>>>>>>> solution.
>>>>>>
>>>>>> I' going to weigh in (as an individual) on this point.
>>>>>>
>>>>>> There is (imo) nothing inherently problematic about calling out a
>>>>>> problem that needs to be addressed in another specification,
>>>>>> especially when writing an applicability statement.
>>>>>>
>>>>>
>>>>> I read the text again, and let me recap it here:
>>>>> > Alternatively, EAP permits a lower layer to set the retransmission timer
>>>>> > to infinite. When this happens, the lower layer becomes responsible for
>>>>> > reliable delivery of EAP messages. Applications that use a lock-step or
>>>>> > client-driven authentication protocol might benefit from this approach.
>>>>> > 
>>>>> > In addition to retransmission behavior applications need to deal with
>>>>> > discarded EAP messages. For example, whenever some EAP methods receive  erroneous
>>>>> > input, these methods discard the input rather than generating an error
>>>>> > response. If the erroneous input was generated by an attacker,
>>>>> > legitimate input can sometimes be received after the erroneous
>>>>> > input. Applications MUST handle discarded EAP messages,
>>>>> > although the specific way in which discarded messages will be handled
>>>>> > depend on the characteristics of the application. Options include
>>>>> > failing the authentication at the application level, requesting an EAP 
>>>>> > retransmit and waiting for additional EAP input.  
>>>>>
>>>>> This text implies there is a problem, but it does not define what
>>>>> the problem is.
>>>>> Or under what circumstances that problem arises.
>>>>>
>>>>> The issue is very specific to the case where the EAP lower layer
>>>>> is in charge of rexmits, and the rexmits are solely client-side
>>>>> driven.
>>>>> It does not apply to any other case. 
>>>>> And if the EAP stack (the combination of EAP method, EAP layer,
>>>>> and EAP lower layer) does not handle this case in a special way,
>>>>> then the state machines may stall.
>>>>>
>>>>> None of that can be understood from the above text at all.
>>>>>
>>>>> Once the readers understand the issue, then they can proceed to
>>>>> "dealing with it". 
>>>>>
>>>>> As for the suggested solutions, failing the authentication reduces
>>>>> the resiliency of EAP solutions. 
>>>>> The other option requires an API between EAP method and EAP
>>>>> lower-layer. 
>>>>>
>>>>> OK, maybe we don't care about the analysis of the solutions, but
>>>>> we do care about defining what the problem is.
>>>>>
>>>>> And also, this issue is not really an "applicability statement"
>>>>> matter. This is a "requirement on EAP lower layer (which is based
>>>>> on strictly client-driven rexmits)" matter, IMHO. 
>>>>>
>>>>> (I understand some people might want to get done with this, but if
>>>>> we don't do it properly I'm afraid it'd open more problems than it
>>>>> solves for people down the road).
>>>>>
>>>>>
>>>>> Alper
>>>>>  
>>>>>
>>>>
>>>> Why don't you propose text!
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>      Cheers Leif
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> abfab mailing list
>> abfab@ietf.org 
>> https://www.ietf.org/mailman/listinfo/abfab
>


--------------080704070906080204030502
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/12/2013 01:04 PM, Alper Yegin
      wrote:

    

    
Yes.
      


      

    

    

    So at this point I want to hear from others in the WG about this
    proposed change.

    

    

      

        

          
On Mar 11, 2013, at 9:35 PM, Leif Johansson wrote:

          

          

            
            

              
On 03/11/2013 08:12 PM, Alper
                Yegin wrote:

              

              

                

                  
Here you go:

                

              

              So this replaces all of 2.1 (just to be clear) ?

              

                

                  
2.1 Retransmission


In EAP, the authenticator is responsible for retransmission. By default
EAP assumes that the lower layer (the application in this context) is
unreliable. The authenticator can send a packet whenever its
retransmission timer triggers. In this mode, applications need to be able to receive and process 
EAP messages at any time during the authentication conversation.


Alternatively, EAP permits a lower layer to set the retransmission timer
to infinite. When this happens, the lower layer becomes responsible for
reliable delivery of EAP messages. Applications that use a lock-step or
client-driven authentication protocol might benefit from this approach.


When retransmission is exclusively handled by the client-side EAP lower-layer, 
an EAP message that gets silently discarded by the EAP method may stall the 
EAP lower-layer state machine.  In such a case, applications MUST handle discarded 
EAP messages. The specific way in which discarded messages will be handled
depend on the characteristics of the application. Solution options include, 
but are not limited to, failing the authentication at the application level, 
and requesting an EAP retransmit and waiting for additional EAP input. Both of 
these options require the EAP methods to notify the EAP and/or EAP lower-layer 
when an EAP message is discarded.  


Specifications of how EAP is used for application authentication MUST
document how retransmission are handled. If the retransmissions are exclusively 
handled by the client-side EAP lower-layer, then the specifications MUST also 
document how message discards are handled.

                

                


                

                
Alper

                


                

                


                

                


                

                


                

                

                

                  
On Mar 9, 2013, at 5:45 PM, Leif Johansson wrote:

                  

                  

                    
                    

                      


                      

                      


                        9 mar 2013 kl. 09:09 skrev Alper Yegin <alper.yegin@yegin.org>:

                        

                      

                      

                        
Hi Leif,
                          


                            

                              


                              

                              

                                


                                  

                                  


                                  

                                  
This "MUST"
                                    cannot be implemented. It's not
                                    clear what an implementor "must" be
                                    doing to comply.

                                  

                                  
This is merely
                                    telling us "there's a problem, you
                                    MUST deal with it". 

                                  

                                  
This reads
                                    more like recognition of an issue,
                                    rather than a solution.

                                  

                                  

                                  I' going to weigh in (as an
                                  individual) on this point. 

                                  

                                  There is (imo) nothing inherently
                                  problematic about calling out a
                                  problem that needs to be addressed in
                                  another specification, especially when
                                  writing an applicability statement.

                                  

                                

                              

                              


                              

                              
I read the text again, and let me
                                recap it here:

                              

                                
> Alternatively, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible for
> reliable delivery of EAP messages. Applications that use a lock-step or
> client-driven authentication protocol might benefit from this approach.
> 

                                
> In addition to retransmission behavior applications need to deal with

                              

                              

                                
> discarded EAP messages. For example, whenever some EAP methods receive  erroneous
> input, these methods discard the input rather than generating an error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an EAP 
> retransmit and waiting for additional EAP input.  

                                


                                

                                
This text implies there is a
                                  problem, but it does not define what
                                  the problem is.

                                
Or under what circumstances that
                                  problem arises.

                                


                                

                                
The issue is very specific to the
                                  case where the EAP lower layer is in
                                  charge of rexmits, and the rexmits are
                                  solely client-side driven.

                                
It does not apply to any other
                                  case. 

                                
And if the EAP stack (the
                                  combination of EAP method, EAP layer,
                                  and EAP lower layer) does not handle
                                  this case in a special way, then the
                                  state machines may stall.

                                


                                

                                
None of that can be understood from
                                  the above text at all.

                                


                                

                                
Once the readers understand the
                                  issue, then they can proceed to
                                  "dealing with it". 

                                


                                

                                
As for the suggested solutions,
                                  failing the authentication reduces the
                                  resiliency of EAP solutions. 

                                
The other option requires an API
                                  between EAP method and EAP
                                  lower-layer. 

                                


                                

                                
OK, maybe we don't care about the
                                  analysis of the solutions, but we do
                                  care about defining what the problem
                                  is.

                                


                                

                                
And also, this issue is not really
                                  an "applicability statement" matter.
                                  This is a "requirement on EAP lower
                                  layer (which is based on strictly
                                  client-driven rexmits)" matter, IMHO. 

                                


                                

                                
(I understand some people might
                                  want to get done with this, but if we
                                  don't do it properly I'm afraid it'd
                                  open more problems than it solves for
                                  people down the road).

                                


                                

                                


                                

                                
Alper

                                
 

                                


                                

                              

                            

                          

                        

                      

                      


                      

                      
Why don't you propose text!

                      

                      

                        

                          

                            

                              

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                                


                                

                              

                              


                              

                              


                              

                              


                              

                              


                              

                              


                              

                              


                              

                              

                              

                                
      Cheers Leif

                                  

                                  

                                

                              

                            

                            

                          

                        

                      

                      

                        
_______________________________________________

                          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


              

              

            

            _______________________________________________

            abfab mailing list

            abfab@ietf.org

            https://www.ietf.org/mailman/listinfo/abfab

          

        

        

      

    

    

  


--------------080704070906080204030502--

From jsalowey@cisco.com  Tue Mar 12 07:24:55 2013
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 B4C0721F87CE for ; Tue, 12 Mar 2013 07:24:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -111.599
X-Spam-Level: 
X-Spam-Status: No, score=-111.599 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpacGJydE5UF for ; Tue, 12 Mar 2013 07:24:48 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BF22821F8525 for ; Tue, 12 Mar 2013 07:24:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10546; q=dns/txt; s=iport; t=1363098286; x=1364307886; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=OV/4ymjnLp9xRvKSM3ZCn+GAJnqrLWwmwW3Zipa/6mY=; b=mMXFhpnAJ9k5X5Hyk4nEPueM6ShCc6E7LmHfS7MWxS88+AozcVgheV80 wMJ3g/CL/vQQeIcjOgZbWRayds21dAHkCOX+wJIyVLdeS1Y3cMKQNPM7D BfLDABrxf80/kQthqBHfsAByWWKbCPPYefb/YjtViLx48eDwyoMdflF9P Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAGI6P1GtJXHA/2dsb2JhbABDxGOBRxZ0gigBAQEDAQEBAWsLBQsCAQgiHQcnCxQRAgQOBQgTh3MGDLBKj3gTBI5cMQeCX2EDp0yDCoIo
X-IronPort-AV: E=Sophos;i="4.84,830,1355097600";  d="scan'208,217";a="186336386"
Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 12 Mar 2013 14:24:46 +0000
Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r2CEOkd3011244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Mar 2013 14:24:46 GMT
Received: from xmb-rcd-x09.cisco.com ([169.254.9.206]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Tue, 12 Mar 2013 09:24:35 -0500
From: "Joseph Salowey (jsalowey)" 
To: Alper Yegin 
Thread-Topic: [abfab] Summary of proposed changes to eat applicability.document
Thread-Index: AQHOFcnPN1HKtdZ7l0uADzcW4jrNeJid2GyAgASqdAA=
Date: Tue, 12 Mar 2013 14:24:34 +0000
Message-ID: 
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.82.217.82]
Content-Type: multipart/alternative; boundary="_000_A95B4818FD85874D8F16607F1AC7C628A90CBExmbrcdx09ciscocom_"
MIME-Version: 1.0
Cc: "abfab@ietf.org" , Leif Johansson 
Subject: Re: [abfab] Summary of proposed changes to eat	applicability.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: Tue, 12 Mar 2013 14:24:56 -0000

--_000_A95B4818FD85874D8F16607F1AC7C628A90CBExmbrcdx09ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


On Mar 9, 2013, at 6:09 AM, Alper Yegin > wrote:

Hi Leif,





This "MUST" cannot be implemented. It's not clear what an implementor "must=
" be doing to comply.
This is merely telling us "there's a problem, you MUST deal with it".
This reads more like recognition of an issue, rather than a solution.

I' going to weigh in (as an individual) on this point.

There is (imo) nothing inherently problematic about calling out a problem t=
hat needs to be addressed in another specification, especially when writing=
 an applicability statement.


I read the text again, and let me recap it here:

> Alternatively, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible for
> reliable delivery of EAP messages. Applications that use a lock-step or
> client-driven authentication protocol might benefit from this approach.
>

> In addition to retransmission behavior applications need to deal with

> discarded EAP messages. For example, whenever some EAP methods receive  e=
rroneous
> input, these methods discard the input rather than generating an error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an EAP
> retransmit and waiting for additional EAP input.

This text implies there is a problem, but it does not define what the probl=
em is.
Or under what circumstances that problem arises.

The issue is very specific to the case where the EAP lower layer is in char=
ge of rexmits, and the rexmits are solely client-side driven.
It does not apply to any other case.
And if the EAP stack (the combination of EAP method, EAP layer, and EAP low=
er layer) does not handle this case in a special way, then the state machin=
es may stall.


[Joe] Its not clear to me that it is just one case.  Either side could poss=
ibly discard a message so it seems that you can have stalls with either cli=
ent or server side retransmission.



None of that can be understood from the above text at all.

Once the readers understand the issue, then they can proceed to "dealing wi=
th it".

As for the suggested solutions, failing the authentication reduces the resi=
liency of EAP solutions.
The other option requires an API between EAP method and EAP lower-layer.

OK, maybe we don't care about the analysis of the solutions, but we do care=
 about defining what the problem is.

And also, this issue is not really an "applicability statement" matter. Thi=
s is a "requirement on EAP lower layer (which is based on strictly client-d=
riven rexmits)" matter, IMHO.

(I understand some people might want to get done with this, but if we don't=
 do it properly I'm afraid it'd open more problems than it solves for peopl=
e down the road).


Alper

























     Cheers Leif



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


--_000_A95B4818FD85874D8F16607F1AC7C628A90CBExmbrcdx09ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-ID: <09649EA6AAEFA648881A876A3A5C91EE@cisco.com>
Content-Transfer-Encoding: quoted-printable











On Mar 9, 2013, at 6:09 AM, Alper Yegin <alper.yegin@yegin.org> wrote:







Hi Leif,





















This "MUST" cannot be implemented. It's=
 not clear what an implementor "must" be doing to comply.




This is merely telling us "there's a problem=
, you MUST deal with it".





This reads more like recognition of an issue, rat=
her than a solution.





I' going to weigh in (as an individual) on this point. 



There is (imo) nothing inherently problematic about calling out a problem t=
hat needs to be addressed in another specification, especially when writing=
 an applicability statement.











I read the text again, and let me recap it here:




> Alternatively=
, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible fo=
r
> reliable delivery of EAP messages. Applications that use a lock-step o=
r
> client-driven authentication protocol might benefit from this approach=
.
> 


> In addition t=
o retransmission behavior applications need to deal with






> discarded EAP=
 messages. For example, whenever some EAP methods receive  erroneous
> input, these methods discard the input rather than generating an error
> response. If the erroneous input was generated by an attacker,
> legitimate input can sometimes be received after the erroneous
> input. Applications MUST handle discarded EAP messages,
> although the specific way in which discarded messages will be handled
> depend on the characteristics of the application. Options include
> failing the authentication at the application level, requesting an EAP=
=20
> retransmit and waiting for additional EAP input.  







This text implies there is a problem, but it does not define what the =
problem is.


Or under what circumstances that problem arises.







The issue is very specific to the case where the EAP lower layer is in=
 charge of rexmits, and the rexmits are solely client-side driven.


It does not apply to any other case. 


And if the EAP stack (the combination of EAP method, EAP layer, and EA=
P lower layer) does not handle this case in a special way, then the state m=
achines may stall.






















[Joe] Its not clear to me that it is just one case.  Either side =
could possibly discard a message so it seems that you can have stalls with =
either client or server side retransmission. 
























None of that can be understood from the above text at all.







Once the readers understand the issue, then they can proceed to "=
dealing with it". 







As for the suggested solutions, failing the authentication reduces the=
 resiliency of EAP solutions. 


The other option requires an API between EAP method and EAP lower-laye=
r. 







OK, maybe we don't care about the analysis of the solutions, but we do=
 care about defining what the problem is.







And also, this issue is not really an "applicability statement&qu=
ot; matter. This is a "requirement on EAP lower layer (which is based =
on strictly client-driven rexmits)" matter, IMHO. 







(I understand some people might want to get done with this, but if we =
don't do it properly I'm afraid it'd open more problems than it solves for =
people down the road).












Alper


 

























































































































     Cheers Leif















_______________________________________________

abfab mailing list

abfab@ietf.org

https://www.ietf.org/mailman/listinfo/abfab










--_000_A95B4818FD85874D8F16607F1AC7C628A90CBExmbrcdx09ciscocom_--

From smith@Cardiff.ac.uk  Tue Mar 12 10:35:49 2013
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 760FB11E80EA for ; Tue, 12 Mar 2013 10:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.599
X-Spam-Level: 
X-Spam-Status: No, score=-7.599 tagged_above=-999 required=5 tests=[AWL=-1.000, 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 Yrjmf71cWkkQ for ; Tue, 12 Mar 2013 10:35:48 -0700 (PDT)
Received: from smtpout1.cf.ac.uk (smtpout1.cf.ac.uk [131.251.137.125]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7CD11E80A6 for ; Tue, 12 Mar 2013 10:35:47 -0700 (PDT)
Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout1.cf.ac.uk with esmtp (Exim 4.77) (envelope-from ) id 1UFT75-0003A4-6S for abfab@ietf.org; Tue, 12 Mar 2013 17:35:47 +0000
Received: from [130.129.132.40] by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1UFT75-0004qH-1I for abfab@ietf.org; Tue, 12 Mar 2013 17:35:47 +0000
From: Rhys Smith 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Tue, 12 Mar 2013 13:35:44 -0400
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com>
To: "abfab@ietf.org" 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
Sender: smith@Cardiff.ac.uk
X-Virus-Scanned: Cardiff University Virus Scanner
X-Virus-Scanned: Cardiff University Virus Scanner
Subject: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 17:35:49 -0000

Hi all,

FYI, a new version of a problem statement driving the reasoning for =
needing trust router has been posted. There's still a lot of work =
needing doing on it. Compared to previous versions, this is trying to =
articulate the problem in a more general sense than has previously been =
done, to see if that helps in explaining the problem.

Rhys.

Begin forwarded message:

> From: internet-drafts@ietf.org
> Subject: I-D Action: draft-howlett-abfab-trust-router-ps-03.txt
> Date: 11 March 2013 18:25:28 EDT
> To: i-d-announce@ietf.org
> Reply-To: internet-drafts@ietf.org
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>=20
>=20
> 	Title           : Trust Requirements in a Federated World
> 	Author(s)       : Josh Howlett
>                          Rhys Smith
>                          Margaret Wasserman
> 	Filename        : draft-howlett-abfab-trust-router-ps-03.txt
> 	Pages           : 14
> 	Date            : 2013-03-11
>=20
> Abstract:
>   TODO: This document outlines the requirements for trust in a
>   federated environment, and enumerates the requirements for a trust
>   infrastructure.  It also examines existing trust infrastructures
>   given these requirements and concludes that none fulfil all of the
>   requirements, and suggests that maybe a new one is required that
>   does.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-howlett-abfab-trust-router-ps
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-03
>=20
> A diff from the previous version is available at:
> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-howlett-abfab-trust-router-ps-03
>=20
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


From hannes.tschofenig@gmx.net  Tue Mar 12 10:51:13 2013
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 73FF111E8114 for ; Tue, 12 Mar 2013 10:51:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.565
X-Spam-Level: 
X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 1bJf47FkV+Br for ; Tue, 12 Mar 2013 10:51:10 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 96B5111E8103 for ; Tue, 12 Mar 2013 10:50:59 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.31]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MCvpV-1U5oJe1PaF-009e7l for ; Tue, 12 Mar 2013 18:50:57 +0100
Received: (qmail invoked by alias); 12 Mar 2013 17:50:56 -0000
Received: from dhcp-1077.meeting.ietf.org (EHLO dhcp-1077.meeting.ietf.org) [130.129.16.119] by mail.gmx.net (mp031) with SMTP; 12 Mar 2013 18:50:56 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19u8qxJ385u6gbBh3IjDk5nXNJeLgLKreNTCAJO8+ RBSHB6Eu+w9ZVE
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: 
Date: Tue, 12 Mar 2013 13:50:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com> 
To: Rhys Smith 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "abfab@ietf.org" 
Subject: Re: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 17:51:15 -0000

Here is also a good document related to this topic:=20
http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02


On Mar 12, 2013, at 1:35 PM, Rhys Smith wrote:

> Hi all,
>=20
> FYI, a new version of a problem statement driving the reasoning for =
needing trust router has been posted. There's still a lot of work =
needing doing on it. Compared to previous versions, this is trying to =
articulate the problem in a more general sense than has previously been =
done, to see if that helps in explaining the problem.
>=20
> Rhys.
>=20
> Begin forwarded message:
>=20
>> From: internet-drafts@ietf.org
>> Subject: I-D Action: draft-howlett-abfab-trust-router-ps-03.txt
>> Date: 11 March 2013 18:25:28 EDT
>> To: i-d-announce@ietf.org
>> Reply-To: internet-drafts@ietf.org
>>=20
>>=20
>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>=20
>>=20
>> 	Title           : Trust Requirements in a Federated World
>> 	Author(s)       : Josh Howlett
>>                         Rhys Smith
>>                         Margaret Wasserman
>> 	Filename        : draft-howlett-abfab-trust-router-ps-03.txt
>> 	Pages           : 14
>> 	Date            : 2013-03-11
>>=20
>> Abstract:
>>  TODO: This document outlines the requirements for trust in a
>>  federated environment, and enumerates the requirements for a trust
>>  infrastructure.  It also examines existing trust infrastructures
>>  given these requirements and concludes that none fulfil all of the
>>  requirements, and suggests that maybe a new one is required that
>>  does.
>>=20
>>=20
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-howlett-abfab-trust-router-ps
>>=20
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-03
>>=20
>> A diff from the previous version is available at:
>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-howlett-abfab-trust-router-ps-03
>>=20
>>=20
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>=20
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>=20
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab


From hartmans@painless-security.com  Tue Mar 12 11:06:13 2013
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 0109311E80E9 for ; Tue, 12 Mar 2013 11:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.067
X-Spam-Level: 
X-Spam-Status: No, score=-2.067 tagged_above=-999 required=5 tests=[AWL=0.532,  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 EltnZa2b5rT6 for ; Tue, 12 Mar 2013 11:06:09 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9639F11E811F for ; Tue, 12 Mar 2013 11:06:09 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-922b.meeting.ietf.org [130.129.10.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 8B75C20167; Tue, 12 Mar 2013 14:05:46 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id B4EC341CF; Tue, 12 Mar 2013 14:06:05 -0400 (EDT)
From: Sam Hartman 
To: Alper Yegin 
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net>  <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org>
Date: Tue, 12 Mar 2013 14:06:05 -0400
In-Reply-To: <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org> (Alper Yegin's message of "Mon, 11 Mar 2013 21:12:52 +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, Leif Johansson 
Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Tue, 12 Mar 2013 18:06:13 -0000

>>>>> "Alper" == Alper Yegin  writes:


    Alper> When retransmission is exclusively handled by the client-side
    Alper> EAP lower-layer, an EAP message that gets silently discarded
    Alper> by the EAP method may stall the EAP lower-layer state
    Alper> machine.  In such a case, applications MUST handle discarded
    Alper> EAP messages. 

Hi.
I prefer the existing text  to this new text.
The existing text is:

    > In addition to retransmission behavior applications need to deal with

    > discarded EAP messages. For example, whenever some EAP methods receive  erroneous
    > input, these methods discard the input rather than generating an error
    > response. If the erroneous input was generated by an attacker,
    > legitimate input can sometimes be received after the erroneous
    > input. Applications MUST handle discarded EAP messages,

I like the existing text for several reasons.  First, like Joe I think
this is not just a client controlled EAP lower layer retransmit issue.
I believe you can get stalls both in server and client.  Second, I
believe that even if it is true, the way the existing text is written
will be easier for application developers to understand than the new
text.
I  also like the explanation of how the discards come up because it
helps application developers understand the issue.

I don't see problems with the existing text so I am against adopting
this change.

    Alper> input. Both of these options require the EAP methods to
    Alper> notify the EAP and/or EAP lower-layer when an EAP message is
    Alper> discarded.

This is true, but the state machine in section 4.1 of RFC 4137 provides
this interface.  While that's not normative text, it seems fairly clear
that if you think about how to implement EAP you're going to need the no
response variable described in RFC 4137.

    Alper> Specifications of how EAP is used for application
    Alper> authentication MUST document how retransmission are
    Alper> handled. If the retransmissions are exclusively handled by
    Alper> the client-side EAP lower-layer, then the specifications MUST
    Alper> also document how message discards are handled.

I'm happier with that being a SHOULD than a MUST.
Also my comments about how the discard issue are described here apply as
well.

In conclusion, I do not support these changes and prefer the existing
text.


From hartmans@painless-security.com  Tue Mar 12 11:08:32 2013
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 487561F0D08 for ; Tue, 12 Mar 2013 11:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.156
X-Spam-Level: 
X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443,  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 6CoWYeC25V2e for ; Tue, 12 Mar 2013 11:08:30 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id CFD021F0C36 for ; Tue, 12 Mar 2013 11:08:29 -0700 (PDT)
Received: from carter-zimmerman.suchdamage.org (dhcp-922b.meeting.ietf.org [130.129.10.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id F327420167; Tue, 12 Mar 2013 14:08:06 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1F02641CF; Tue, 12 Mar 2013 14:08:26 -0400 (EDT)
From: Sam Hartman 
To: Hannes Tschofenig 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com>  
Date: Tue, 12 Mar 2013 14:08:26 -0400
In-Reply-To:  (Hannes Tschofenig's message of "Tue, 12 Mar 2013 13:50:51 -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: "abfab@ietf.org" 
Subject: Re: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 18:08:33 -0000

>>>>> "Hannes" == Hannes Tschofenig  writes:

    Hannes> Here is also a good document related to this topic:
    Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02


The multihop federation document is somewhat out of date.
we believe that the introductory text  from that document has been
migrated to the new protocol document.

--Sam

From hannes.tschofenig@gmx.net  Tue Mar 12 11:22:19 2013
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 0C70A21F8AB2 for ; Tue, 12 Mar 2013 11:22:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.068
X-Spam-Level: 
X-Spam-Status: No, score=-103.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qFdCDvRUEPYk for ; Tue, 12 Mar 2013 11:22:12 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) by ietfa.amsl.com (Postfix) with ESMTP id 0B4DC21F8940 for ; Tue, 12 Mar 2013 11:22:09 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0Ls6Bl-1UtOox24zf-013xtA for ; Tue, 12 Mar 2013 19:22:08 +0100
Received: (qmail invoked by alias); 12 Mar 2013 18:22:08 -0000
Received: from dhcp-1077.meeting.ietf.org (EHLO dhcp-1077.meeting.ietf.org) [130.129.16.119] by mail.gmx.net (mp030) with SMTP; 12 Mar 2013 19:22:08 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX1/iGYFrb7rigRfPd/boN2stltDd7WJ4qzSzpnr3Xy kO3g2WoFxQ8TT3
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Hannes Tschofenig 
In-Reply-To: 
Date: Tue, 12 Mar 2013 14:22:04 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com>   
To: Sam Hartman 
X-Mailer: Apple Mail (2.1085)
X-Y-GMX-Trusted: 0
Cc: "abfab@ietf.org" 
Subject: Re: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 18:22:19 -0000

Btw, I never understood why Josh, Rhys, and Margaret suddenly started a =
new document.=20
I like draft-mrw-abfab-multihop-fed-02 more.=20

On Mar 12, 2013, at 2:08 PM, Sam Hartman wrote:

>>>>>> "Hannes" =3D=3D Hannes Tschofenig  =
writes:
>=20
>    Hannes> Here is also a good document related to this topic:
>    Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02
>=20
>=20
> The multihop federation document is somewhat out of date.
> we believe that the introductory text  from that document has been
> migrated to the new protocol document.
>=20
> --Sam


From smith@Cardiff.ac.uk  Tue Mar 12 11:33:30 2013
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 E941F11E8175 for ; Tue, 12 Mar 2013 11:33:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.099
X-Spam-Level: 
X-Spam-Status: No, score=-7.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 2Tpl9UJlxDic for ; Tue, 12 Mar 2013 11:33:29 -0700 (PDT)
Received: from smtpout2.cf.ac.uk (smtpout2.cf.ac.uk [131.251.137.139]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7F011E8121 for ; Tue, 12 Mar 2013 11:33:29 -0700 (PDT)
Received: from smtpauth.cf.ac.uk ([131.251.248.19]) by smtpout2.cf.ac.uk with esmtp (Exim 4.77) (envelope-from ) id 1UFU0t-0004Ge-MT; Tue, 12 Mar 2013 18:33:27 +0000
Received: from [130.129.132.40] by smtpauth.cf.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1UFU0t-00066f-HL; Tue, 12 Mar 2013 18:33:27 +0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Rhys Smith 
In-Reply-To: 
Date: Tue, 12 Mar 2013 14:33:25 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com>    
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1499)
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] I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 18:33:30 -0000

There's a separate document so as to separate out a description of the =
problem from the solution we've designed (trust router) that tries to =
solve the problem.

So the latest version of an attempt to articulate the problem is at =
http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-03 and =
the newest version of the trust router solution is at =
http://tools.ietf.org/html/draft-mrw-abfab-trust-router-02

Rhys.


On 12 Mar 2013, at 14:22, Hannes Tschofenig  =
wrote:

> Btw, I never understood why Josh, Rhys, and Margaret suddenly started =
a new document.=20
> I like draft-mrw-abfab-multihop-fed-02 more.=20
>=20
> On Mar 12, 2013, at 2:08 PM, Sam Hartman wrote:
>=20
>>>>>>> "Hannes" =3D=3D Hannes Tschofenig  =
writes:
>>=20
>>   Hannes> Here is also a good document related to this topic:
>>   Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02
>>=20
>>=20
>> The multihop federation document is somewhat out of date.
>> we believe that the introductory text  from that document has been
>> migrated to the new protocol document.
>>=20
>> --Sam
>=20


From d.w.chadwick@kent.ac.uk  Tue Mar 12 11:48:56 2013
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 0FF1411E811D for ; Tue, 12 Mar 2013 11:48:56 -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 cvrWLXanVubK for ; Tue, 12 Mar 2013 11:48:54 -0700 (PDT)
Received: from mx2.kent.ac.uk (mx2.kent.ac.uk [129.12.21.33]) by ietfa.amsl.com (Postfix) with ESMTP id B7DF611E8117 for ; Tue, 12 Mar 2013 11:48:54 -0700 (PDT)
Received: from vpnfa4e.kent.ac.uk ([129.12.250.78]) by mx2.kent.ac.uk with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1UFUFp-0004Cx-3t; Tue, 12 Mar 2013 18:48:53 +0000
Message-ID: <513F7896.8060603@kent.ac.uk>
Date: Tue, 12 Mar 2013 18:48:54 +0000
From: David Chadwick 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
To: Rhys Smith 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "abfab@ietf.org" 
Subject: Re: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 18:48:56 -0000

Hi Rhys

having read your draft could I suggest

1. some changes in terminology

Trust Arbitrator - > Reputation Service or Reputation Service Operator 
depending upon context

Trust Advisor - > Root of Trust

These two entities are quite different, but by using very similar 
notation for both, as you do, it tends to conflate them into being 
almost the same. I would prefer it if different terms could be used, 
that a) better describe their functionality, and b) better differentiate 
between them. It would also remove the tautology from this sentence

A Trust Arbitrators/Advisors can attempt to become the arbiter of
        trust for multiple communities.


2. that you have downplayed the complexity in establishing technical 
trust between entities. Joining an Authentication Policy Community might 
actually be quite time consuming and tedious, if you have to prove that 
you conform to a certain set of policies (e.g. LOA 3).

3. wrt section 5.1, the scientific EGI community might strongly disagree 
with your conclusions here. I think they think that PKI works just fine, 
is infinitely scalable and very secure. But you should check with them.

regards

David

On 12/03/2013 17:35, Rhys Smith wrote:
> Hi all,
>
> FYI, a new version of a problem statement driving the reasoning for needing trust router has been posted. There's still a lot of work needing doing on it. Compared to previous versions, this is trying to articulate the problem in a more general sense than has previously been done, to see if that helps in explaining the problem.
>
> Rhys.
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: I-D Action: draft-howlett-abfab-trust-router-ps-03.txt
>> Date: 11 March 2013 18:25:28 EDT
>> To: i-d-announce@ietf.org
>> Reply-To: internet-drafts@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>> 	Title           : Trust Requirements in a Federated World
>> 	Author(s)       : Josh Howlett
>>                           Rhys Smith
>>                           Margaret Wasserman
>> 	Filename        : draft-howlett-abfab-trust-router-ps-03.txt
>> 	Pages           : 14
>> 	Date            : 2013-03-11
>>
>> Abstract:
>>    TODO: This document outlines the requirements for trust in a
>>    federated environment, and enumerates the requirements for a trust
>>    infrastructure.  It also examines existing trust infrastructures
>>    given these requirements and concludes that none fulfil all of the
>>    requirements, and suggests that maybe a new one is required that
>>    does.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-howlett-abfab-trust-router-ps
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-howlett-abfab-trust-router-ps-03
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab
>

From Josh.Howlett@ja.net  Tue Mar 12 13:58:45 2013
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 2C1C711E810A for ; Tue, 12 Mar 2013 13:58:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLuO2csOfJfN for ; Tue, 12 Mar 2013 13:58:43 -0700 (PDT)
Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFF811E80E3 for ; Tue, 12 Mar 2013 13:58:42 -0700 (PDT)
Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 51F801C031B8_13F9701B; Tue, 12 Mar 2013 20:58:41 +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 23E131C0318E_13F9701F; Tue, 12 Mar 2013 20:58:41 +0000 (GMT)
Received: from EXC001.atlas.ukerna.ac.uk ([193.62.83.37]) by EXC001 ([193.62.83.37]) with mapi id 14.02.0247.003; Tue, 12 Mar 2013 20:58:40 +0000
From: Josh Howlett 
To: Hannes Tschofenig , Sam Hartman 
Thread-Topic: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-03.txt
Thread-Index: AQHOH2Rfjc2nv5Bl4kCDwBAPxCxSsQ==
Date: Tue, 12 Mar 2013 20:58:40 +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.3.1.130117
x-originating-ip: [194.82.140.76]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9DC56AFA1E07F74381DED5207440608B@ukerna.ac.uk>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "abfab@ietf.org" 
Subject: Re: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 20:58:45 -0000

Hi Hannes,

The problem statement was written as a response to feedback that
draft-mrw-abfab-multihop-fed did not explain the problem that the
architecture it describes is meant to address, so they're doing different
things. I agree that draft-mrw-abfab-multihop-fed is a more interesting
document if you're sold on the problem.

Josh.

On 12/03/2013 18:22, "Hannes Tschofenig"  wrote:

>Btw, I never understood why Josh, Rhys, and Margaret suddenly started a
>new document.=20
>I like draft-mrw-abfab-multihop-fed-02 more.
>
>On Mar 12, 2013, at 2:08 PM, Sam Hartman wrote:
>
>>>>>>> "Hannes" =3D=3D Hannes Tschofenig  write=
s:
>>=20
>>    Hannes> Here is also a good document related to this topic:
>>    Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02
>>=20
>>=20
>> The multihop federation document is somewhat out of date.
>> we believe that the introductory text  from that document has been
>> migrated to the new protocol document.
>>=20
>> --Sam
>
>_______________________________________________
>abfab mailing list
>abfab@ietf.org
>https://www.ietf.org/mailman/listinfo/abfab


Janet(UK) is a trading name of Jisc Collections and Janet Limited, a=20
not-for-profit company 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. VAT No. 614944238


From mrw@lilacglade.org  Tue Mar 12 14:18:53 2013
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 03A4721F8B13 for ; Tue, 12 Mar 2013 14:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 TuQyMOuWZ5wM for ; Tue, 12 Mar 2013 14:18:52 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAFF21F8ADC for ; Tue, 12 Mar 2013 14:18:52 -0700 (PDT)
Received: from dhcp-922d.meeting.ietf.org (dhcp-922d.meeting.ietf.org [130.129.10.45]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.painless-security.com (Postfix) with ESMTPSA id DBEBC20167; Tue, 12 Mar 2013 17:18:28 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Margaret Wasserman 
In-Reply-To: 
Date: Tue, 12 Mar 2013 17:18:50 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com>    
To: Hannes Tschofenig 
X-Mailer: Apple Mail (2.1499)
Cc: "abfab@ietf.org" 
Subject: Re: [abfab] I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 21:18:53 -0000

Hi Hannes,

We were advised by the ABFAB Chairs that we needed to get consensus on a =
problem statement before we could work on the solution documents in =
ABFAB.  The -ps document were an attempt to document a problem statement =
for that purpose.

I think that all of the still-pertinent information in the multihop-fed =
document has been moved to the Trust Router protocol document, and =
multihop-fed has been abandoned.  Let me know if I've missed anything =
you would like to see preserved.

Margaret


On Mar 12, 2013, at 2:22 PM, Hannes Tschofenig =
 wrote:

> Btw, I never understood why Josh, Rhys, and Margaret suddenly started =
a new document.=20
> I like draft-mrw-abfab-multihop-fed-02 more.=20
>=20
> On Mar 12, 2013, at 2:08 PM, Sam Hartman wrote:
>=20
>>>>>>> "Hannes" =3D=3D Hannes Tschofenig  =
writes:
>>=20
>>   Hannes> Here is also a good document related to this topic:
>>   Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02
>>=20
>>=20
>> The multihop federation document is somewhat out of date.
>> we believe that the introductory text  from that document has been
>> migrated to the new protocol document.
>>=20
>> --Sam
>=20
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab


From hannes.tschofenig@gmx.net  Tue Mar 12 14:24:32 2013
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 8A18111E80C5 for ; Tue, 12 Mar 2013 14:24:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.936
X-Spam-Level: 
X-Spam-Status: No, score=-101.936 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_TAG_BALANCE_HEAD=1.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 kuRqVs4trVxj for ; Tue, 12 Mar 2013 14:24:30 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id D6AFC21F85DB for ; Tue, 12 Mar 2013 14:24:20 -0700 (PDT)
Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M0NrX-1V2fMM1Iy5-00udds for ; Tue, 12 Mar 2013 22:24:19 +0100
Received: (qmail invoked by alias); 12 Mar 2013 21:24:18 -0000
Received: from dhcp-1372.meeting.ietf.org (EHLO dhcp-1372.meeting.ietf.org) [130.129.19.114] by mail.gmx.net (mp016) with SMTP; 12 Mar 2013 22:24:18 +0100
X-Authenticated: #29516787
X-Provags-ID: V01U2FsdGVkX19Fqoo3SaJFeo359KEm4A4zAV+HZ2ivpbbI95faqA RMdEcK7XbYgPJm
User-Agent: K-9 Mail for Android
In-Reply-To: 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com>     
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----Y1XMTFFUY8NU4W9P6DO507YZE0CG41"
From: hannes.tschofenig@gmx.net
Date: Tue, 12 Mar 2013 23:24:09 +0200
To: Margaret Wasserman 
Message-ID: <17f88b9c-097e-42a7-83eb-2f382ce2aa2f@email.android.com>
X-Y-GMX-Trusted: 0
Cc: "abfab@ietf.org" 
Subject: Re: [abfab] I-D Action: draft-howlett-abfab-trust-router-ps-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: Tue, 12 Mar 2013 21:24:32 -0000

------Y1XMTFFUY8NU4W9P6DO507YZE0CG41
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 8bit

I didn't know that you had decided to move text into the new -ps document and to abandon the document that I co-authored with you.

Hannes

Margaret Wasserman  wrote:

>
>Hi Hannes,
>
>We were advised by the ABFAB Chairs that we needed to get consensus on
>a problem statement before we could work on the solution documents in
>ABFAB.  The -ps document were an attempt to document a problem
>statement for that purpose.
>
>I think that all of the still-pertinent information in the multihop-fed
>document has been moved to the Trust Router protocol document, and
>multihop-fed has been abandoned.  Let me know if I've missed anything
>you would like to see preserved.
>
>Margaret
>
>
>On Mar 12, 2013, at 2:22 PM, Hannes Tschofenig
> wrote:
>
>> Btw, I never understood why Josh, Rhys, and Margaret suddenly started
>a new document. 
>> I like draft-mrw-abfab-multihop-fed-02 more. 
>> 
>> On Mar 12, 2013, at 2:08 PM, Sam Hartman wrote:
>> 
>>>>>>>> "Hannes" == Hannes Tschofenig 
>writes:
>>> 
>>>   Hannes> Here is also a good document related to this topic:
>>>   Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02
>>> 
>>> 
>>> The multihop federation document is somewhat out of date.
>>> we believe that the introductory text  from that document has been
>>> migrated to the new protocol document.
>>> 
>>> --Sam
>> 
>> _______________________________________________
>> abfab mailing list
>> abfab@ietf.org
>> https://www.ietf.org/mailman/listinfo/abfab

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------Y1XMTFFUY8NU4W9P6DO507YZE0CG41
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: 8bit

I didn't know that you had decided to move text into the new -ps document and to abandon the document that I co-authored with you.



Hannes

Margaret Wasserman <mrw@lilacglade.org> wrote:



Hi Hannes,

We were advised by the ABFAB Chairs that we needed to get consensus on a problem statement before we could work on the solution documents in ABFAB.  The -ps document were an attempt to document a problem statement for that purpose.

I think that all of the still-pertinent information in the multihop-fed document has been moved to the Trust Router protocol document, and multihop-fed has been abandoned.  Let me know if I've missed anything you would like to see preserved.

Margaret


On Mar 12, 2013, at 2:22 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:

Btw, I never understood why Josh, Rhys, and Margaret suddenly started a new document. 
I like draft-mrw-abfab-multihop-
 fed-02
more. 

On Mar 12, 2013, at 2:08 PM, Sam Hartman wrote:

"Hannes" == Hannes Tschofenig <hannes.tschofenig@gmx.net> writes:

Hannes> Here is also a good document related to this topic:
Hannes> http://tools.ietf.org/html/draft-mrw-abfab-multihop-fed-02


The multihop federation document is somewhat out of date.
we believe that the introductory text  from that document has been
migrated to the new protocol document.

--Sam


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



-- 

Sent from my Android phone with K-9 Mail. Please excuse my brevity.
------Y1XMTFFUY8NU4W9P6DO507YZE0CG41--


From leifj@sunet.se  Wed Mar 13 06:12:54 2013
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 DC66E21F8CDB for ; Wed, 13 Mar 2013 06:12:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 9Y6B66CrwRHY for ; Wed, 13 Mar 2013 06:12:54 -0700 (PDT)
Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id 1716821F8CDA for ; Wed, 13 Mar 2013 06:12:53 -0700 (PDT)
Received: from [130.129.10.34] (dhcp-9222.meeting.ietf.org [130.129.10.34]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r2DDCmSv012908 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 13 Mar 2013 13:12:52 GMT
Message-ID: <51407B50.8050708@sunet.se>
Date: Wed, 13 Mar 2013 14:12:48 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130221 Thunderbird/17.0.3
MIME-Version: 1.0
To: "abfab@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [abfab] slides?
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, 13 Mar 2013 13:12:55 -0000

Folks,

We hope to make a lot of progress today and focus more on discussion
than on presentation but if you do have slides PLEASE send them right
now to me or Klaas.

        Cheers Leif

From gabilm@um.es  Wed Mar 13 09:39:57 2013
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 4BED721F8935 for ; Wed, 13 Mar 2013 09:39: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 ohKwcchZoH4g for ; Wed, 13 Mar 2013 09:39:56 -0700 (PDT)
Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id C35DE21F8614 for ; Wed, 13 Mar 2013 09:39:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 435D04C5B6 for ; Wed, 13 Mar 2013 17:39:54 +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 21XgyVrcl6gr for ; Wed, 13 Mar 2013 17:39:53 +0100 (CET)
Received: from [155.54.205.186] (inf-205-186.inf.um.es [155.54.205.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon12.um.es (Postfix) with ESMTPSA id 5B1A54C619 for ; Wed, 13 Mar 2013 17:39:52 +0100 (CET)
Message-ID: <5140ABDC.6080000@um.es>
Date: Wed, 13 Mar 2013 17:39:56 +0100
From: Gabriel Lopez 
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "abfab@ietf.org" 
References: <20130311222528.12212.74.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [abfab] Fwd: I-D Action: draft-howlett-abfab-trust-router-ps-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: Wed, 13 Mar 2013 16:39:57 -0000

    Hi,

    Just a few comments about the ps


Section 1. Introduction   
    - "two entities are able to verify that each other is who they think
they are" --> the term "think" is quite ambiguous here,  probably better
"two entities are able to verify that each other is who they claim they
are""

Section 2. Terminology
    - Authentication Policy Community (APC): "A set of entities that
share a common trust infrastructure" It is just a "federation"? Why the
term policy is used here? It is just for authentication not for
authorization?

    - Community of Interest (CoI): Does it refers to idPs and SPs (and
principals/clients?)
    
    - Entity: A general term for IdPs and RPs.
        In documents like
http://docs.oasis-open.org/security/saml/v2.0/saml-glossary-2.0-os.pdf,
the general term for idPs and RPs is "Provider", in fact, "Entity" is a
more general concept"

   - Trust Arbitrator: What is a "trust rating"?

    - Trust Advisor:
            - CoR is not defined
            - Agree with David, "Root of Trust" is a well known term for
that, or even "Trust Anchor"
            -
Section 3.

    3.2 - Authors remark the term "Communities of Trust", which is not
included in Section 2.
    3.2 - "and users of it typically need to pay for the service". Does
it refer to the fact of paying for trust? I usually connect to my bank
account, trust is established based on a Trust Anchor (probably
something like Verisign), but I have never paid for this trust? Or have
I misunderstood the sentence? Could you add some examples?
    3.2 - " Trust Arbitrators are less commonly seen, and are usually
found where a Trust Arbitrator stands to make financial gain" Is it this
sentence right?
    3.3 -  Does this section describe something similar to the term
"confederation" or "alliance"?
           

 Section   5.1 - Have you take into account cross-certification? Bridge
CA? etc....
            -  "Works well but only when governance and management is
done properly" --> Well I think it is true for any kind of
infrastructure/technology/scenario I can imagine ...
            - "Which it isn't, generally" -- > Agree with David. This is
a very strong sentence.
   
 Section 6 -
   
    It is still difficult to me to see the real problem to be solved. I
expected a description about how technologies like ,for example, PKI
does not fulfils the requirements of section 4. I'm not saying it does,
I'm just saying it would improve the problem statement... 

    Sorry if I'm saying nonsenses, just trying to understand the
terminology ....
   
    Regards, Gabi.



   





   
        




On 12/03/13 18:35, Rhys Smith wrote:
> Hi all,
>
> FYI, a new version of a problem statement driving the reasoning for needing trust router has been posted. There's still a lot of work needing doing on it. Compared to previous versions, this is trying to articulate the problem in a more general sense than has previously been done, to see if that helps in explaining the problem.
>
> Rhys.
>
> Begin forwarded message:
>
>> From: internet-drafts@ietf.org
>> Subject: I-D Action: draft-howlett-abfab-trust-router-ps-03.txt
>> Date: 11 March 2013 18:25:28 EDT
>> To: i-d-announce@ietf.org
>> Reply-To: internet-drafts@ietf.org
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>> 	Title           : Trust Requirements in a Federated World
>> 	Author(s)       : Josh Howlett
>>                          Rhys Smith
>>                          Margaret Wasserman
>> 	Filename        : draft-howlett-abfab-trust-router-ps-03.txt
>> 	Pages           : 14
>> 	Date            : 2013-03-11
>>
>> Abstract:
>>   TODO: This document outlines the requirements for trust in a
>>   federated environment, and enumerates the requirements for a trust
>>   infrastructure.  It also examines existing trust infrastructures
>>   given these requirements and concludes that none fulfil all of the
>>   requirements, and suggests that maybe a new one is required that
>>   does.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-howlett-abfab-trust-router-ps
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-howlett-abfab-trust-router-ps-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-howlett-abfab-trust-router-ps-03
>>
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> I-D-Announce mailing list
>> I-D-Announce@ietf.org
>> https://www.ietf.org/mailman/listinfo/i-d-announce
>> Internet-Draft directories: http://www.ietf.org/shadow.html
>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> _______________________________________________
> abfab mailing list
> abfab@ietf.org
> https://www.ietf.org/mailman/listinfo/abfab


From ietf@augustcellars.com  Wed Mar 13 18:16:36 2013
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 BC05621F8B18 for ; Wed, 13 Mar 2013 18:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 ymviAhSIwZMj for ; Wed, 13 Mar 2013 18:16:35 -0700 (PDT)
Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 471DB21F8BD5 for ; Wed, 13 Mar 2013 18:16:35 -0700 (PDT)
Received: from Philemon (ip-64-134-178-132.public.wayport.net [64.134.178.132]) (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 90A1A38F09 for ; Wed, 13 Mar 2013 18:16:32 -0700 (PDT)
From: "Jim Schaad" 
To: 
Date: Wed, 13 Mar 2013 21:15:53 -0400
Message-ID: <067201ce2051$7d76f1b0$7864d510$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0673_01CE202F.F6688600"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Ac4gT4gETKWFhUMsSCOMAK8XMmBmPQ==
Content-Language: en-us
Subject: [abfab] AAA-SAML
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, 14 Mar 2013 01:16:36 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0673_01CE202F.F6688600
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

.       Question: should we explicitly link these to the 'user' and
'machine' TLV definitions proposed by TEAP?

.       Yes we should tie this to the Identity Type code registry from the
TEAP document

 

 

.       Figure out a way to name SAML authorities (e.g., attribute
authorities) to support synchronous requests (e.g., for assertions).

.       I don't believe that this is a current requirement.  We currently
know how to  ask the IdP in a SAML query for attributes.  I cannot think of
any reason why an RP would be able to know what SAML authority to ask a
specific authority for a SAML response in a protocol.  I believe this item
can be not done.

 

.       The document currently only discusses TLS/TCP; also should mention
TLS/UDP

.       NO!!!!!!!! Doctor it hurts when I do this.  DON'T DO THIS!!!!   With
the additional overhead from DTLS, the fragmentation is going to be even
worse that otherwise.

 

.       Include a prescription that "SAML responders SHOULD return a RADIUS
state attribute" to facilitate subsequent use of the user/machine Subject
Confirmation methods

.       YES - and this is trivial

 

.       Clarify text describing use of the SAML AuthNRequest's 'AllowCreate'
attribute

.       YES - Per mailing list conversation  - Specifically what needs to be
said is this only applies if the IdP is going to return an explicit
identifier for the client and that identifier needs to be created.

 

 

Jim

 

 


------=_NextPart_000_0673_01CE202F.F6688600
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


•       =
Question: should we explicitly link these =
to the ‘user’ and ‘machine’ TLV definitions =
proposed by TEAP?
•       =
Yes we should tie this to the Identity =
Type code registry from the TEAP document
 
 
•       =
Figure out a way to name SAML authorities =
(e.g., attribute authorities) to support synchronous requests (e.g., for =
assertions).
•       =
I don’t believe that this is a =
current requirement.  We currently know how to  ask the IdP in =
a SAML query for attributes.  I cannot think of any reason why an =
RP would be able to know what SAML authority to ask a specific authority =
for a SAML response in a protocol.  I believe this item can be not =
done.
 
•       =
The document currently only discusses =
TLS/TCP; also should mention TLS/UDP
•       =
NO!!!!!!!! Doctor it hurts when I do =
this.  DON’T DO THIS!!!!   With the additional =
overhead from DTLS, the fragmentation is going to be even worse that =
otherwise.
 
•       =
Include a prescription that “SAML =
responders SHOULD return a RADIUS state attribute” to facilitate =
subsequent use of the user/machine Subject Confirmation =
methods
•       =
YES – and this is =
trivial
 
•       =
Clarify text describing use of the SAML =
AuthNRequest’s ‘AllowCreate’ =
attribute
•       =
YES - Per mailing list conversation =
 - Specifically what needs to be said is this only applies if the =
IdP is going to return an explicit identifier for the client and that =
identifier needs to be created.
 
 
Jim
 
 

------=_NextPart_000_0673_01CE202F.F6688600--


From leifj@sunet.se  Sat Mar 16 08:50:32 2013
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 8C5EC21F88D6 for ; Sat, 16 Mar 2013 08:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-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 HguDTtTkIHgS for ; Sat, 16 Mar 2013 08:50:32 -0700 (PDT)
Received: from smtp1.nordu.net (smtp1.nordu.net [IPv6:2001:948:4:6::32]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEB221F88ED for ; Sat, 16 Mar 2013 08:50:31 -0700 (PDT)
Received: from [192.168.154.211] ([98.79.94.25]) (authenticated bits=0) by smtp1.nordu.net (8.14.6/8.14.6) with ESMTP id r2GFoKpK012015 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sat, 16 Mar 2013 15:50:26 GMT
Message-ID: <514494BC.5040805@sunet.se>
Date: Sat, 16 Mar 2013 16:50:20 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: "abfab@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: [abfab] notes 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, 16 Mar 2013 15:50:32 -0000

Notes from the ABFAB meeting in Orland are online.
       
    Cheers Leif

From leifj@mnt.se  Sat Mar 16 08:56:00 2013
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 B722C21F8804 for ; Sat, 16 Mar 2013 08:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[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 ol1+heshx3ud for ; Sat, 16 Mar 2013 08:55:55 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) by ietfa.amsl.com (Postfix) with ESMTP id 4DFAC21F85CE for ; Sat, 16 Mar 2013 08:55:52 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id ia10so1956841vcb.22 for ; Sat, 16 Mar 2013 08:55:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:x-gm-message-state; bh=X6BY6z4ULzx7chBJzdspdU17YC2Sjqa6gKsZx3lnEeo=; b=ZJyR53m2n1viIZC4l4WUQjOfS52RTSs8Y/1D1FoxtZu8PHp3lSY4uvrNGRaDWPN1wL uLhnalVtK1msM5uKKhstZhk31xLoytPN5/nMkBqENvfHZr9jnZKT+rvYyYwsLJgbM/3q ryQLQjq7DcrMOgzP+NRzhcN/F5RbYayBZYv+2SgpEnRHfRSez74XCXKnJxGYGsh9BnXo JfffLgDbakQZoJeOLV6h0eapI6lkdqaYzuEiYTRPXsVfESt0deE1JFmG0oJx3EVisIKv nxBPzF6l3tpKfH4fA3YJWBytbY6vXASC6vD06VfkeZ52fe8bAOHlGotVs/UfxQORNn6L 5PWQ==
X-Received: by 10.58.151.4 with SMTP id um4mr12483466veb.12.1363449351785; Sat, 16 Mar 2013 08:55:51 -0700 (PDT)
Received: from [192.168.154.211] ([98.79.94.25]) by mx.google.com with ESMTPS id l18sm10624818vdh.10.2013.03.16.08.55.50 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Mar 2013 08:55:50 -0700 (PDT)
Message-ID: <51449605.4040409@mnt.se>
Date: Sat, 16 Mar 2013 16:55:49 +0100
From: Leif Johansson 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4
MIME-Version: 1.0
To: abfab@ietf.org
References:  <9898A2A3-702A-47A5-8C0B-E67B7A0CAFD4@yegin.org> <03779D95-AE19-414F-9563-E28EBEDC442B@nordu.net>  <6AD36CD4-55C6-4D77-93A0-8C9E95ECF226@mnt.se> <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org>
In-Reply-To: <9FDF2D6A-CC33-4011-9D92-1939FF94CA0A@yegin.org>
Content-Type: multipart/alternative; boundary="------------000005080501090506020106"
X-Gm-Message-State: ALoCoQmgf38YDXrJ8UW2RUDe8Q5L4JKCRzTv0uWGlCn+6cUmmi8wYH3/PfyFA1yqomgzajzWC8kB
Subject: Re: [abfab] Summary of proposed changes to eat applicability.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: Sat, 16 Mar 2013 15:56:00 -0000

This is a multi-part message in MIME format.
--------------000005080501090506020106
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On 03/11/2013 08:12 PM, Alper Yegin wrote:
> Here you go:
> 2.1 Retransmission
> In EAP, the authenticator is responsible for retransmission. By default
> EAP assumes that the lower layer (the application in this context) is
> unreliable. The authenticator can send a packet whenever its
> retransmission timer triggers. In this mode, applications need to be
> able to receive and process 
> EAP messages at any time during the authentication conversation.
> Alternatively, EAP permits a lower layer to set the retransmission timer
> to infinite. When this happens, the lower layer becomes responsible for
> reliable delivery of EAP messages. Applications that use a lock-step or
> client-driven authentication protocol might benefit from this approach.
> When retransmission is exclusively handled by the client-side EAP
> lower-layer, 
> an EAP message that gets silently discarded by the EAP method may
> stall the 
> EAP lower-layer state machine.  In such a case, applications MUST
> handle discarded 
> EAP messages. The specific way in which discarded messages will be handled
> depend on the characteristics of the application. Solution options
> include, 
> but are not limited to, failing the authentication at the application
> level, 
> and requesting an EAP retransmit and waiting for additional EAP input.
> Both of 
> these options require the EAP methods to notify the EAP and/or EAP
> lower-layer 
> when an EAP message is discarded.  
> Specifications of how EAP is used for application authentication MUST
> document how retransmission are handled. If the retransmissions are
> exclusively 
> handled by the client-side EAP lower-layer, then the specifications
> MUST also 
> document how message discards are handled.
>

This proposed change was discussed in Orlando and there was no
consensus in the WG to make this change.

Joe will submit a new version of the eap applicability statement
with the changed we did have consensus on based on the list
discussions and the WG meeting.

        Cheers Leif

--------------000005080501090506020106
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


  
    
  
  
    
On 03/11/2013 08:12 PM, Alper Yegin
      wrote:

    

    

      

        
Here you go:

        

        
2.1 Retransmission


In EAP, the authenticator is responsible for retransmission. By default
EAP assumes that the lower layer (the application in this context) is
unreliable. The authenticator can send a packet whenever its
retransmission timer triggers. In this mode, applications need to be able to receive and process 
EAP messages at any time during the authentication conversation.


Alternatively, EAP permits a lower layer to set the retransmission timer
to infinite. When this happens, the lower layer becomes responsible for
reliable delivery of EAP messages. Applications that use a lock-step or
client-driven authentication protocol might benefit from this approach.


When retransmission is exclusively handled by the client-side EAP lower-layer, 
an EAP message that gets silently discarded by the EAP method may stall the 
EAP lower-layer state machine.  In such a case, applications MUST handle discarded 
EAP messages. The specific way in which discarded messages will be handled
depend on the characteristics of the application. Solution options include, 
but are not limited to, failing the authentication at the application level, 
and requesting an EAP retransmit and waiting for additional EAP input. Both of 
these options require the EAP methods to notify the EAP and/or EAP lower-layer 
when an EAP message is discarded.  


Specifications of how EAP is used for application authentication MUST
document how retransmission are handled. If the retransmissions are exclusively 
handled by the client-side EAP lower-layer, then the specifications MUST also 
document how message discards are handled.

      

      

    

    

    This proposed change was discussed in Orlando and there was no

    consensus in the WG to make this change.

    

    Joe will submit a new version of the eap applicability statement 

    with the changed we did have consensus on based on the list

    discussions and the WG meeting.

    

            Cheers Leif

  


--------------000005080501090506020106--

From internet-drafts@ietf.org  Sun Mar 17 20:22:15 2013
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 9402D21F8C9D; Sun, 17 Mar 2013 20:22:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FUDTi5jnwfz; Sun, 17 Mar 2013 20:22:15 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9B321F8C77; Sun, 17 Mar 2013 20:22:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.43
Message-ID: <20130318032213.11929.19699.idtracker@ietfa.amsl.com>
Date: Sun, 17 Mar 2013 20:22:13 -0700
Cc: abfab@ietf.org
Subject: [abfab] I-D Action: draft-ietf-abfab-eapapplicability-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, 18 Mar 2013 03:22:15 -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 Access=
 Beyond web Working Group of the IETF.

	Title           : Update to the EAP Applicability Statement for ABFAB
	Author(s)       : Stefan Winter
                          Joseph Salowey
	Filename        : draft-ietf-abfab-eapapplicability-02.txt
	Pages           : 6
	Date            : 2013-03-17

Abstract:
   This document updates the Extensible Authentication Protocol (EAP)
   applicability statement from RFC3748 to reflect recent usage of the
   EAP protocol in the Application Bridging for Federated Access Beyond
   web (ABFAB) working group.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-abfab-eapapplicability

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-abfab-eapapplicability-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-eapapplicability-02


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/