From kwiereng@cisco.com Thu Nov 1 11:08:12 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BE621F8ACE for ; Thu, 1 Nov 2012 11:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 hsW5K82BtEqI for ; Thu, 1 Nov 2012 11:08:11 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id BDE5321F8884 for ; Thu, 1 Nov 2012 11:07:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6073; q=dns/txt; s=iport; t=1351793275; x=1353002875; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fuapP9K/TChNVlkAb/35eJ1Cyvul9soCu4B6MIeaslU=; b=eo2YRrVqcuwRmaTjORLUdtFmmnei2aqur2Ob+ZG863QdZKGAckyGEgf+ T7IAvqHNp7x3ysTjGNPTc4srr1Ca4ra1pAgJMK4oI1aUIEpKEh5Q3hOh6 hoy+o2EOMLCri2j8fiQrCc4+kRNJzE37lSz/TiWkDEaMKl1EvAXQGJGAm A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYGALG5klCtJV2b/2dsb2JhbABEiHayEwGGKoJAgQiCHgEBAQQSAXYCARkDAQIoBzIUBwIIAgQTFA6HZAucTKAwi3uFWmEDkkaDMoEbjT2Ba4EugUGBZA X-IronPort-AV: E=Sophos;i="4.80,695,1344211200"; d="scan'208,217";a="134848194" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 01 Nov 2012 18:07:55 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id qA1I7t3o018652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 1 Nov 2012 18:07:55 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.001; Thu, 1 Nov 2012 13:07:54 -0500 From: "Klaas Wierenga (kwiereng)" To: "" Thread-Topic: CORRECTION: Help the NomCom Thread-Index: AQHNuDCYTe4j5AHWLUyVoOtqVy1vpJfVRz6s Date: Thu, 1 Nov 2012 18:07:53 +0000 Message-ID: <99DE825C-9430-46DE-AC48-8FCC2FEE40BB@cisco.com> References: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> In-Reply-To: <20121101121722.29094.73706.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19328.001 x-tm-as-result: No--37.634700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_99DE825C943046DEAC488FCC2FEE40BBciscocom_" MIME-Version: 1.0 Subject: [abfab] Fwd: CORRECTION: Help the NomCom 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, 01 Nov 2012 18:08:12 -0000 --_000_99DE825C943046DEAC488FCC2FEE40BBciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sent from my iPad Begin forwarded message: From: NomCom Chair > Date: 1 november 2012 13:17:22 CET To: Working Group Chairs > Subject: CORRECTION: Help the NomCom I sent a message several hours ago requesting that you help and make your working group aware that the NomCom is looking for input from the community. This message had a minor error. The NomCom needs to receive community input by November 11, 2012. The full text of the corrected message is below --------------------------------------------------- The IETF Nominations Committee (NomCom) continues to seek input from the IETF Community. The NomCom would greatly appreciate any help you could provide in making members of your working group aware of ways in which they can provide valuable feedback to the NomCom. In order to ensure that your input is received in time to be useful, the NomCom needs to receive community feedback on or before Sunday, November 11= . The final list of candidates (as per RFC 5680) that the NomCom is considering for open positions can be found at: https://www.ietf.org/group/nomcom/2012/input/ The NomCom will be holding office hours during IETF 85, Monday- Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes comments on specific individuals, as well as general feedback related to any of the positions that NomCom is considering. Note: A list of leadership positions that the NomCom is considering can be found at: https://www.ietf.org/group/nomcom/2012/ If the NomCom office hours are inconvenient for you or if you cannot attend IETF 85, the NomCom is happy to take community input via email to nomcom12 at ietf.org. Additionally, the NomCom is happy= to arrange a meeting outside of office hours, just send us email and we can set something up. Comments on specific candidates can also be provided to the NomCom via the web feedback tool: https://www.ietf.org/group/nomcom/2012/input/ Thank you for your help, - Matt Lepinski nomcom-chair at ietf.org --_000_99DE825C943046DEAC488FCC2FEE40BBciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


Sent from my iPad

Begin forwarded message:

From: NomCom Chair <nomcom-chair@ietf.org>
Date: 1 november 2012 13:17:22 CET
To: Working Group Chairs <wg= chairs@ietf.org>
Subject: CORRECTION: Help the NomCom

I sent a message several hours ago requesting that you help and = make
your working group aware that the NomCom is looking for input from th= e
community. This message had a minor error. The NomCom needs to
receive community input by November 11, 2012.

The full text of the corrected message is below
---------------------------------------------------

The IETF Nominations Committee (NomCom) continues to seek input from<= /span>
the IETF Community. The NomCom would greatly appreciate any help you<= /span>
could provide in making members of your working group aware of ways i= n
which they can provide valuable feedback to the NomCom.

In order to ensure that your input is received in time to be useful, = the
NomCom needs to receive community feedback on or before Sunday, Novem= ber 11.

The final list of candidates (as per RFC 5680) that the NomCom is
considering for open positions can be found at:
https://www= .ietf.org/group/nomcom/2012/input/

The NomCom will be holding office hours during IETF 85, Monday-
Thursday from 1:00pm to 3:00pm in Room 305. The NomCom welcomes
comments on specific individuals, as well as general feedback related= to
any of the positions that NomCom is considering.

Note: A list of leadership positions that the NomCom is considering c= an be
found at: https:/= /www.ietf.org/group/nomcom/2012/

If the NomCom office hours are inconvenient for you or if you cannot =
attend IETF 85, the NomCom is happy to take community input via email=
to nomcom12 at ietf.org. Additionally= , the NomCom is happy to arrange a
meeting outside of office hours, just send us email and we can set
something up.

Comments on specific candidates can also be provided to the NomCom
via the web feedback tool:
https://www= .ietf.org/group/nomcom/2012/input/

Thank you for your help,
- Matt Lepinski
 nomcom-chair at ietf.org=
--_000_99DE825C943046DEAC488FCC2FEE40BBciscocom_-- From jimsch@augustcellars.com Thu Nov 1 17:55:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4608F21F9856 for ; Thu, 1 Nov 2012 17:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IXzN42lJwVa for ; Thu, 1 Nov 2012 17:55:54 -0700 (PDT) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 66F5B21F9853 for ; Thu, 1 Nov 2012 17:55:54 -0700 (PDT) Received: from Philemon (50-39-218-206.bvtn.or.frontiernet.net [50.39.218.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp1.pacifier.net (Postfix) with ESMTPS id CCFF22CA1C; Thu, 1 Nov 2012 17:55:53 -0700 (PDT) From: "Jim Schaad" To: Date: Thu, 1 Nov 2012 17:55:48 -0700 Message-ID: <01f401cdb894$cec80ce0$6c5826a0$@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: Ac24ZT0mn/Yi8nW8TKGxSpDaKY/jnA== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] SAML draft and naming issues 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, 02 Nov 2012 00:55:55 -0000 I really don't like the fact that the current draft says that the subject field is omitted when constructing a request. 1. It means that I cannot use my existing validating parser for this as we will no longer have schema compliant XML for the request. 2. See #1 3. I believe that one will need/want to ask questions about multiple entities involved. That is one might want to ask about both the user and the user's machine. I would propose making the following changes 1. Define a new name type that has two string values "user" and "machine". This corresponds to the current set of identity types that is defined by TEAP. This would also allow for anonymous names to be returned to the RP without any problems 2. Either define or reference a SAML name type for NAIs. I am not sure if the new and old NAIs should be done differently as there are some differences between the name matching rules. I also understand that if a proxy re-writes the identifier in the RADIUS string, this field may not be re-written as well depending on if the proxy is going to look for it. I have a small concern about pseudonymous names, at present the first time a client might see it's pseudonymous name would be when it is transmitted from the acceptor to the initiator as part of the application protocol. There is currently no provision for an IdP to send the name to the client as part of the current GSS-EAP protocol, and it is not clear to me that the client should be required to contact the IdP prior to talking to the server to setup for an anonymous name. Jim From alper.yegin@yegin.org Fri Nov 2 02:45:40 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C53E21F99B8 for ; Fri, 2 Nov 2012 02:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 dlrZKJBOyB4W for ; Fri, 2 Nov 2012 02:45:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id BAF5C21F999F for ; Fri, 2 Nov 2012 02:45:38 -0700 (PDT) Received: from [192.168.2.5] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MBEpZ-1TdsRs1rQD-00ARKE; Fri, 02 Nov 2012 05:45:30 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 2 Nov 2012 11:45:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <800882A7-45EE-4DC3-B0E2-2619A80DB464@yegin.org> References: <50819AB5.5000105@toshiba.co.jp> <5081A962.9070309@toshiba.co.jp> <5083C748.5000004@toshiba.co.jp> <5087E0FC.7090000@toshiba.co.jp> <040b01cdb327$5d166e60$17434b20$@augustcellars.com> <94257A1F-5C42-4CA8-AFFF-3A1744C16CFA@yegin.org> <508E92E2.9060702@deployingradius.com> <004c01cdb657$ce9df200$6bd9d600$@augustcellars.com> <009c01cdb6c3$dc1f9e30$945eda90$@augustcellars.com> <00a101cdb6c8$bf932b60$3eb98220$@augustcellars.com> <00bf01cdb6e7$96848420$c38d8c60$@augustcellars.com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:6s0mKKjTbP9ksTv9fiYzFX8xg1a8//9Ri2mTVxXuaWL mXy3HEOXgfz4Sej3DV5F5u4ymkTxcGsmg0DDipwxMzEPoFvUfj IosvQSZhIB3ns4YVmC0xqRzkfKrRR9isU69B0rzSJyJiYVyvxF 91Pas2c/5A7dj1gZykt3eHwviavZRmNPLpDpYixtSQt8pwTTLK 0fRJz0aPACEjtWPsAP/i3ZQu7SSNokQWIxPXUXqV9mSfFkF92D td+dWkiqu66aRHJ83Y3kzaKBbV6VJB9lfNTatxAVG1JJNGwg6y yd9EoWSZP9OdN1wprWU2t+C+pPld8CatitKTqMduJmF+BPh8qU U5d88VT4oMKMyrOFRdtQy35ol4hjKDqUYJMAQEmdBR51Z6oteH dq68/LQQrDyCA== Cc: Jim Schaad , abfab@ietf.org Subject: Re: [abfab] EAP Applicability: retransmissions 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, 02 Nov 2012 09:45:40 -0000 Hi Sam, >>>>>> "Jim" =3D=3D Jim Schaad writes: >=20 >=20 > Jim> I think he was talking about the RADIUS server not having any > Jim> EAP data to send back to the client. And that in that case = the > Jim> server SHOULD send a reject message back. >=20 > Jim> I am looking at the case of the EAP client not having any data > Jim> to send. The RADIUS server will not have an opportunity to > Jim> send a reject message, but it will still have some state data > Jim> for a while (as will the EAP server). >=20 > OK. > I'm sorry, I should not have tried to respond to mail while paying > attention to a session in a conference. >=20 >=20 > What happens here on the initiator is that the initiator needs to = return > some status other than GSS_S_CONTINUE_NEEDED. > GSS_S_COMPLETE is kind of implausible, so GSS_ERROR will be true for > that status. > The initiator then should call gss_delete_sec_context. At this point, = the initiator is done and has cleaned up state. >=20 > Alper claims that the initiator will not know that the EAP layers have > failed to produce output and are done processing the packet. I cannot > think of a plausible EAP implementation strategy with this > characteristic, so I suspect Alper is not correct for likely EAP > implementations. =20 This is not necessarily an "abort" case. We are talking about either the = EAP layer or the EAP authentication method layer dropping an incoming = message (due to various reasons, such as lack of resources, malformed = message [by rogue injection, or otherwise], etc.). Such a single packet = dropped does not always convert to "abort". The EAP Authenticator = retransmits and see what happens. This "message dropped" happening is either at the EAP layer or the EAP = authentication method layer.=20 How does it get signaled to the "EAP lower layer"? That's what you need. Is there an API that's commonly implemented by the EAP layers and EAP = authentication methods supporting this?=20 (Here's an analogy: TCP hands over a message to the application, and = application drops it for one if its own "higher layer" reasons. It's not = going to tell TCP that it tossed away the packet.) Alper > Anything that lets you examine the RFC 4137 state will > allow you to determine what's going on. Certainly anything that you = can use for implementing > GSS-EAP has the property that you'll know when it's done with a = packet. > The existing GSS C bindings are sufficiently synchronous that you'll > need that property. >=20 > After experimenting with other strategies, we've generally come to the > conclusion that applications rather than GSS mechanisms need to be > responsible for signaling initiator failure. > In some protocols you do this with a TCP close. > In some protocols such as IMAP, there's a SASL abort that you signal. >=20 > I think that the GSS mechanism could return an error token at this > point; a quick reading of RFC 2743 2.2.1 is unclear. > However, I'd recommend against changing gss-eap to permit this.=20 > I think returning an output token with an error status will confuse a > lot of applications. >=20 > I do think it would be desirable to add text to draft-ietf-abfab-arch > noting that applications SHOULD have a way to signal authentication > aborts. >=20 > --Sam From Josh.Howlett@ja.net Fri Nov 2 07:19:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CA4F21F8AAB for ; Fri, 2 Nov 2012 07:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PdFvFOZ3sLf9 for ; Fri, 2 Nov 2012 07:19:20 -0700 (PDT) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9733921F8AC2 for ; Fri, 2 Nov 2012 07:19:20 -0700 (PDT) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 773261A9AF8F_93D666B; Fri, 2 Nov 2012 14:19:18 +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 5B5EF1A9AF85_93D666F; Fri, 2 Nov 2012 14:19:18 +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; Fri, 2 Nov 2012 14:19:18 +0000 From: Josh Howlett To: Jim Schaad , "abfab@ietf.org" Thread-Topic: [abfab] SAML draft and naming issues Thread-Index: Ac24ZT0mn/Yi8nW8TKGxSpDaKY/jnAAn8s6A Date: Fri, 2 Nov 2012 14:19:18 +0000 Message-ID: In-Reply-To: <01f401cdb894$cec80ce0$6c5826a0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: <3FA91CB49AEAFA48B4A011E07C32C992@ukerna.ac.uk> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] SAML draft and naming issues 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, 02 Nov 2012 14:19:21 -0000 Jim, >I really don't like the fact that the current draft says that the subject >field is omitted when constructing a request. >1. It means that I cannot use my existing validating parser for this as >we >will no longer have schema compliant XML for the request. >2. See #1 This surprises me. The relevant bit of the schema is: What specifically is your parser saying? (I'll address the rest of your email when I return from holiday). Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From jimsch@augustcellars.com Fri Nov 2 08:14:50 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F247311E8097 for ; Fri, 2 Nov 2012 08:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcG4dbrUi7yb for ; Fri, 2 Nov 2012 08:14:49 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB7E21F8AA6 for ; Fri, 2 Nov 2012 08:14:49 -0700 (PDT) Received: from Philemon (50-39-218-206.bvtn.or.frontiernet.net [50.39.218.206]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp2.pacifier.net (Postfix) with ESMTPS id 274E92CA17; Fri, 2 Nov 2012 08:14:48 -0700 (PDT) From: "Jim Schaad" To: "'Josh Howlett'" , References: <01f401cdb894$cec80ce0$6c5826a0$@augustcellars.com> In-Reply-To: Date: Fri, 2 Nov 2012 08:14:43 -0700 Message-ID: <021501cdb90c$cb27ed30$6177c790$@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: AQE5jaoce+u9zIw+TeEp7tln6XHmB5j+/h9g Content-Language: en-us Subject: Re: [abfab] SAML draft and naming issues 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, 02 Nov 2012 15:14:50 -0000 Josh, I see it as Which does not have an optional on the subject Jim > -----Original Message----- > From: Josh Howlett [mailto:Josh.Howlett@ja.net] > Sent: Friday, November 02, 2012 7:19 AM > To: Jim Schaad; abfab@ietf.org > Subject: Re: [abfab] SAML draft and naming issues > > Jim, > > >I really don't like the fact that the current draft says that the > >subject field is omitted when constructing a request. > >1. It means that I cannot use my existing validating parser for this > >as we will no longer have schema compliant XML for the request. > >2. See #1 > > This surprises me. The relevant bit of the schema is: > > > > > What specifically is your parser saying? > > (I'll address the rest of your email when I return from holiday). > > Josh. > > > > Janet is a trading name of The JNT Association, a company limited by > guarantee which is registered in England under No. 2881024 and whose > Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, > Oxfordshire. OX11 0SG From cantor.2@osu.edu Fri Nov 2 08:24:32 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2939621F8AC6 for ; Fri, 2 Nov 2012 08:24:32 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwLCcekVioxQ for ; Fri, 2 Nov 2012 08:24:31 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id D7CF921F8A20 for ; Fri, 2 Nov 2012 08:24:30 -0700 (PDT) Received: from mail23-tx2-R.bigfish.com (10.9.14.251) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.23; Fri, 2 Nov 2012 15:24:29 +0000 Received: from mail23-tx2 (localhost [127.0.0.1]) by mail23-tx2-R.bigfish.com (Postfix) with ESMTP id B08D8480177; Fri, 2 Nov 2012 15:24:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.174; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT07.osuad.osu.edu; RD:cio-tnc-ht07.osuad.osu.edu; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zzbb2dI98dI9371I1432Izz1d77h1de0h1202h1d1ah1d2ahzz8275bhz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh1155h) Received-SPF: pass (mail23-tx2: domain of osu.edu designates 164.107.81.174 as permitted sender) client-ip=164.107.81.174; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT07.osuad.osu.edu ; suad.osu.edu ; Received: from mail23-tx2 (localhost.localdomain [127.0.0.1]) by mail23-tx2 (MessageSwitch) id 1351869867924032_23420; Fri, 2 Nov 2012 15:24:27 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.246]) by mail23-tx2.bigfish.com (Postfix) with ESMTP id DC52010007A; Fri, 2 Nov 2012 15:24:27 +0000 (UTC) Received: from CIO-TNC-HT07.osuad.osu.edu (164.107.81.174) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 2 Nov 2012 15:24:26 +0000 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0318.004; Fri, 2 Nov 2012 11:24:18 -0400 From: "Cantor, Scott" To: Jim Schaad , 'Josh Howlett' , "abfab@ietf.org" Thread-Topic: [abfab] SAML draft and naming issues Thread-Index: Ac24ZT0mn/Yi8nW8TKGxSpDaKY/jnAAn8s6AAApR+YD//7+cAA== Date: Fri, 2 Nov 2012 15:24:18 +0000 Message-ID: In-Reply-To: <021501cdb90c$cb27ed30$6177c790$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [164.107.161.117] Content-Type: text/plain; charset="us-ascii" Content-ID: <16DD8FFEB62DF24E90FAB5124043288E@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: osu.edu Subject: Re: [abfab] SAML draft and naming issues 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, 02 Nov 2012 15:24:32 -0000 On 11/2/12 11:14 AM, "Jim Schaad" wrote: >Josh, > >I see it as=20 > > I was going to ask if this was limited to AuthnRequests or included queries. If the latter, then yes, it's required. Note that this isn't a question of "nice to be valid". The schema is not a parsing tool in the spec, it's the normative description of the grammar of the standard. Validating the XML is optional, but conforming to the schema is not. However, Subject contains different options for representing identity, and there are ways to express "derive identity from context" if that's what you're after. -- Scott From stefan.winter@restena.lu Mon Nov 5 05:46:04 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEDE21F8661 for ; Mon, 5 Nov 2012 05:46:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vUmYNzPQY3O9 for ; Mon, 5 Nov 2012 05:46:03 -0800 (PST) Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 80C5221F85F5 for ; Mon, 5 Nov 2012 05:46:03 -0800 (PST) Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id E1C4D10580 for ; Mon, 5 Nov 2012 14:46:01 +0100 (CET) Received: from [IPv6:2001:a18:1:8:cd18:75f8:8272:99d3] (unknown [IPv6:2001:a18:1:8:cd18:75f8:8272:99d3]) by smtprelay.restena.lu (Postfix) with ESMTPS id D79621057E for ; Mon, 5 Nov 2012 14:46:01 +0100 (CET) Message-ID: <5097C315.5010709@restena.lu> Date: Mon, 05 Nov 2012 14:45:57 +0100 From: Stefan Winter User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2 MIME-Version: 1.0 To: abfab@ietf.org X-Enigmail-Version: 1.4.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC5F722E131D055CDE307C810" X-Virus-Scanned: ClamAV Subject: [abfab] EAP Applicability discussion X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 13:46:04 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC5F722E131D055CDE307C810 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, since I won't be at the meeting, here are a few thoughts about Sam's slides regarding the EAP Applicability draft, particularly about Authorization Lifetime, Slide 6 The original Applicability statement IMHO makes quite clear that determining the Authorization Lifetime is not a good use of EAP. It first creates a very short white-list of good uses (Network *Authentication*, and with the revision Application *authentication*) and then has a blanket statement blacklist: "Use of EAP for other purposes, [...], is NOT RECOMMENDED." One example is given, bulk data transport, but the statement is just as valid for other examples like ", such as determining authorization lifetime, " That statement has served well over the years to repel other uses of EAP (and in fact seems to be so threatening that abfab found that change of text is needed to get something new onto the whitelist). So answering the question brought up by Sam: I do not believe this needs to be documented. The generic NOT RECOMMENDED statement covers this adequately. For the other issues in the slide deck things are less clear; I'll be interested in the outcomes of the discussion. 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 --------------enigC5F722E131D055CDE307C810 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 Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCXwxkACgkQ+jm90f8eFWZR5gCdHy/0+isppi6oPce1PSILWEJc oIsAnRPrxSJGZr+1rB8e4crSedMccbTb =M0au -----END PGP SIGNATURE----- --------------enigC5F722E131D055CDE307C810-- From alper.yegin@yegin.org Mon Nov 5 07:15:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 506AB21F8549 for ; Mon, 5 Nov 2012 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 hei0mtNyx1og for ; Mon, 5 Nov 2012 07:15:01 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 8C14221F8550 for ; Mon, 5 Nov 2012 07:15:01 -0800 (PST) Received: from [192.168.2.4] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0LmKCI-1SvVL80d3i-00Zqau; Mon, 05 Nov 2012 10:14:59 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Alper Yegin In-Reply-To: <5097C315.5010709@restena.lu> Date: Mon, 5 Nov 2012 17:14:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6CED195C-C49B-4F73-B2AD-00DEC84CC6B2@yegin.org> References: <5097C315.5010709@restena.lu> To: Stefan Winter X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:0rZmWyjqBN0Lw5YbaSS5vhUGjRguRFpfUoWFrYVUhk9 5hzslb7ngCF+4sjggTNLqwfwAfVreZomIi2iC97vlupuLrBP68 bCfqw2i22y6Enal2LIBXT4LIkLf1cZOhULxX3pbb8aUK/y5DdV 4VXSqfuuh4+valFGqzTbgli+eoTP8tdRgCeq2+/I+kTHjlVxCR cDh/Y2LBi7fTqT3iffn0IJxsNAiTyoYywHZOmPLfQcOxC7avwN 9KK1X4hzgPxU0xUw8x9H8Omv40PcemC5wwSCBby6fBarajXTYL /LyfuUQkUN5FTeooEXRID/1x0zaJWzaTtxQZD3ovN+b2TB84KR Y9px1S5cr7pJ9KAeMPeAOM6JUuMSGzoZUB0UkPbwqWs5u9/b+f y1ttmIw5738VQ== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability discussion X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:15:02 -0000 I won't be there either, so here are my comments on Sam's slides: Slide 5: Please elaborate the pros and cons of re-auth. There's a = reference to some apps replacing session easily. It'd be good to have a = example of that for a better understanding. Slide 6: "Application authorization lifetime". We need to expand on the = meaning of that, or use a more precise terminology. I If this is about "authorizing the application client to use the given = application protocol", then that authorization's lifetime is dictated by = the MSK lifetime. It's the use of MSK or its derivative protecting the = application protocol that proves to the server that the client is = authorized. I.e., no key =3D> nothing to prove authorization with. If you are talking about the "state created by the use of application = protocol" which can exceed the lifetime of the MSK, that's fine. That's = more like "application is authorized to create state that can outlive = the MSK lifetime".=20 =20 On Nov 5, 2012, at 3:45 PM, Stefan Winter wrote: > Hi, >=20 > since I won't be at the meeting, here are a few thoughts about Sam's > slides regarding the EAP Applicability draft, particularly about >=20 > Authorization Lifetime, Slide 6 >=20 > The original Applicability statement IMHO makes quite clear that > determining the Authorization Lifetime is not a good use of EAP. It > first creates a very short white-list of good uses (Network > *Authentication*, and with the revision Application *authentication*) > and then has a blanket statement blacklist: >=20 > "Use of EAP for other purposes, [...], is NOT RECOMMENDED." >=20 > One example is given, bulk data transport, but the statement is just = as > valid for other examples like ", such as determining authorization > lifetime, " >=20 > That statement has served well over the years to repel other uses of = EAP > (and in fact seems to be so threatening that abfab found that change = of > text is needed to get something new onto the whitelist). >=20 > So answering the question brought up by Sam: I do not believe this = needs > to be documented. The generic NOT RECOMMENDED statement covers this > adequately. >=20 > For the other issues in the slide deck things are less clear; I'll be > interested in the outcomes of the discussion. >=20 > Greetings, >=20 > Stefan Winter >=20 > --=20 > Stefan WINTER > Ingenieur de Recherche > Fondation RESTENA - R=E9seau T=E9l=E9informatique de l'Education = Nationale et > de la Recherche > 6, rue Richard Coudenhove-Kalergi > L-1359 Luxembourg >=20 > Tel: +352 424409 1 > Fax: +352 422473 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Mon Nov 5 07:36:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E6D621F849F for ; Mon, 5 Nov 2012 07:36:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cie2o+NZ2OxE for ; Mon, 5 Nov 2012 07:36:10 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 7E56A21F9025 for ; Mon, 5 Nov 2012 07:35:44 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-933f.meeting.ietf.org [130.129.11.63]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 20C012010B; Mon, 5 Nov 2012 10:34:52 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 2843E412A; Mon, 5 Nov 2012 10:35:42 -0500 (EST) From: Sam Hartman To: Alper Yegin References: <5097C315.5010709@restena.lu> <6CED195C-C49B-4F73-B2AD-00DEC84CC6B2@yegin.org> Date: Mon, 05 Nov 2012 10:35:42 -0500 In-Reply-To: <6CED195C-C49B-4F73-B2AD-00DEC84CC6B2@yegin.org> (Alper Yegin's message of "Mon, 5 Nov 2012 17:14:41 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability discussion X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 15:36:10 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> I won't be there either, so here are my comments on Sam's Alper> slides: Slide 5: Please elaborate the pros and cons of Alper> re-auth. There's a reference to some apps replacing session Alper> easily. It'd be good to have a example of that for a better Alper> understanding. I'd appreciate help on the proes. The big pro that I see is that re-auth is necessary if you need to change security parameters and breaking down your session has consequences. It's obvious to see this in network access. Alper> Slide 6: "Application authorization lifetime". We need to Alper> expand on the meaning of that, or use a more precise Alper> terminology. I If this is about "authorizing the application Alper> client to use the given application protocol", then that Alper> authorization's lifetime is dictated by the MSK Alper> lifetime. It's the use of MSK or its derivative protecting Alper> the application protocol that proves to the server that the Alper> client is authorized. I.e., no key => nothing to prove Alper> authorization with. There are a number of cases where this is not true . For example with the GS2 sasl mechanism keying at the TLS layer is not affected by the MSK. The EAP authentication is only used for RFC 5056 channel binding. From Josh.Howlett@ja.net Mon Nov 5 08:50:42 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D03021F8531 for ; Mon, 5 Nov 2012 08:50:42 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1+iJH4W1Ih6 for ; Mon, 5 Nov 2012 08:50:41 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 632A421F8451 for ; Mon, 5 Nov 2012 08:50:41 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id 071D01A9B26E_97EE60B; Mon, 5 Nov 2012 16:50:40 +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 C7DA21A9B25D_97EE5FF; Mon, 5 Nov 2012 16:50:39 +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; Mon, 5 Nov 2012 16:50:39 +0000 From: Josh Howlett To: Jim Schaad Thread-Topic: [abfab] SAML draft and naming issues Thread-Index: Ac24ZT0mn/Yi8nW8TKGxSpDaKY/jnADEEagA Date: Mon, 5 Nov 2012 16:50:38 +0000 Message-ID: In-Reply-To: <01f401cdb894$cec80ce0$6c5826a0$@augustcellars.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] SAML draft and naming issues X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 16:50:43 -0000 > > >I would propose making the following changes > >1. Define a new name type that has two string values "user" and >"machine". >This corresponds to the current set of identity types that is defined by >TEAP. This would also allow for anonymous names to be returned to the RP >without any problems I see no problem with this in principle, but there's probably a discussion needed on a couple of points: 1. Should these get defined by Abfab, or in the place(s) where these attributes are actually going to be used? If this is a generic requirement, it should probably happen in Abfab. Conversely if you are trying to solve a specific problem (e.g., for Plasma) it might be better defined there. 2. Are these best defined as name identifiers or attributes? The answer to this probably boils down to the specifics of the use case(s). Do you have these described anywhere? (I'm not throwing these discussion points up to avoid work; from experience, defining attributes can be a slippery slope into ocean-boiling). In any case, I'll take a look at the TEAP identity types and propose some straw-man text. >2. Either define or reference a SAML name type for NAIs. I am not sure >if >the new and old NAIs should be done differently as there are some >differences between the name matching rules. I also understand that if a >proxy re-writes the identifier in the RADIUS string, this field may not be >re-written as well depending on if the proxy is going to look for it. No problem with this in principle, but again it would be helpful to determine if this is a sufficiently generic requirement that it makes sense to define within Abfab or, if application-specific, elsewhere. > I need to do multiple queries [...] I cannot serialize them, as I would > with the HTTP binding How do I deal with it here? Why do you think that you cannot serialize them? > Profiling of the different attribute query based on the content - looking > at the SAML Profile document and the namespace of the attributes that > can be used in a single query Sorry, I am having difficulty parsing this. Could you explain again? Thanks, Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From yoshihiro.ohba@toshiba.co.jp Mon Nov 5 12:00:59 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4C221F8BA8 for ; Mon, 5 Nov 2012 12:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.089 X-Spam-Level: X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 KTLoPJX4vh+A for ; Mon, 5 Nov 2012 12:00:59 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 4136621F8A0E for ; Mon, 5 Nov 2012 12:00:55 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id qA5K0reV014983 for ; Tue, 6 Nov 2012 05:00:53 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id qA5K0rcP005070 for abfab@ietf.org; Tue, 6 Nov 2012 05:00:53 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id FAA05069; Tue, 6 Nov 2012 05:00:53 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id qA5K0q6o019442 for ; Tue, 6 Nov 2012 05:00:52 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qA5K0qR3003790; Tue, 6 Nov 2012 05:00:52 +0900 (JST) Received: from [133.199.16.224] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MD100H596943Q00@mail.po.toshiba.co.jp> for abfab@ietf.org; Tue, 06 Nov 2012 05:00:52 +0900 (JST) Date: Tue, 06 Nov 2012 05:00:41 +0900 From: Yoshihiro Ohba To: abfab@ietf.org Message-id: <50981AE9.5050104@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-2022-JP Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: [abfab] EAP retransmission text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Nov 2012 20:01:00 -0000 As I spoke today, I prefer having informative text on the retransmission issue without using a requirement language such as MUST/SHOULD. This is because a lower-layer can be designed in multiple different ways to deal with silent discarsion of EAP messages, including immediate termination of the lower-layer session, and it is difficult to determine what the best way is. In general, it depends on the characteristics of the target application. For example, an application that is capabile of server-driven retransmission can simply rely on EAP-layer retransmissions to deal with this issue. In any case, I am happy to review text. Yoshihiro Ohba From alper.yegin@yegin.org Tue Nov 6 00:05:45 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708C221F8685 for ; Tue, 6 Nov 2012 00:05:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 lsnfHp9vPtEe for ; Tue, 6 Nov 2012 00:05:44 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 648A021F879B for ; Tue, 6 Nov 2012 00:05:44 -0800 (PST) Received: from [192.168.2.3] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MHHEh-1TavUh1lAJ-00EHMP; Tue, 06 Nov 2012 03:05:40 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Tue, 6 Nov 2012 10:05:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <18CD1F86-902C-4EF4-8884-C870C54A555C@yegin.org> References: <5097C315.5010709@restena.lu> <6CED195C-C49B-4F73-B2AD-00DEC84CC6B2@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:FxFFvkfU+r35ha1yxVnX3tC5tDVCxyqc//++bMfer0i tMaUSBYqeygATBjUYT96PxXkMJzBvlONRdKLgvoSCWKPlgAj4A yYbpDLvhDlQ23Hk7v+r6poa12VqCjmEGs4MH17rgpFcK5ilV1Z 5vVwb0jZqwvHH29GCwNFJWlpL9Qpk8EkWe510jTEj36V8OopqA JYrltSYMHsq6OwI3/EuHwSS1a/vVC+P8qljEdWvVvU/eC8ehva RUbM4DN1lfkGBMyOnO837BWRYR/u7cnTp/AgFjr1DP7dNzMSFO 2lcQYLt9t8ZHn2+4j/sGkg4/I63ld7X/b+NXtOQvX5jPNM6Y/o J7idQ7YVFPCSs63wBJQfSLVxMzQVhdKu+Q0R/5r9IhuoKDo1Pb SiL+XR2/glEyw== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability discussion X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 08:05:45 -0000 Sam, I see you are talking about a different way of using EAP (different then = the legacy use). In legacy use, a secure channel is created with the help of the EAP. EAP = MSK is used for setting it up. You are talking about the following: - there's already a secure channel, with integrity and replay = protection, and even possibly encryption. - but the end-point is not authenticated yet. - this is why we execute EAP over it. - but the EAP keys (MSK) is not used for securing the channel. I think it's this distinction causing potential differences in other = aspects of EAP use. Alper On Nov 5, 2012, at 5:35 PM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> I won't be there either, so here are my comments on Sam's > Alper> slides: Slide 5: Please elaborate the pros and cons of > Alper> re-auth. There's a reference to some apps replacing session > Alper> easily. It'd be good to have a example of that for a better > Alper> understanding. >=20 > I'd appreciate help on the proes. > The big pro that I see is that re-auth is necessary if you need to > change security parameters and breaking down your session has > consequences. > It's obvious to see this in network access. >=20 > Alper> Slide 6: "Application authorization lifetime". We need to > Alper> expand on the meaning of that, or use a more precise > Alper> terminology. I If this is about "authorizing the application > Alper> client to use the given application protocol", then that > Alper> authorization's lifetime is dictated by the MSK > Alper> lifetime. It's the use of MSK or its derivative protecting > Alper> the application protocol that proves to the server that the > Alper> client is authorized. I.e., no key =3D> nothing to prove > Alper> authorization with. =20 >=20 > There are a number of cases where this is not true . > For example with the GS2 sasl mechanism keying at the TLS layer is = not > affected by the MSK. > The EAP authentication is only used for RFC 5056 channel binding. From hartmans@painless-security.com Tue Nov 6 04:01:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAC5721F8883 for ; Tue, 6 Nov 2012 04:01:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVT+evb8tB5T for ; Tue, 6 Nov 2012 04:01:38 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6C22C21F886F for ; Tue, 6 Nov 2012 04:01:38 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-459e.meeting.ietf.org [130.129.69.158]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id BC6632027D; Tue, 6 Nov 2012 07:00:44 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CBA7B412A; Tue, 6 Nov 2012 07:01:34 -0500 (EST) From: Sam Hartman To: Alper Yegin References: <5097C315.5010709@restena.lu> <6CED195C-C49B-4F73-B2AD-00DEC84CC6B2@yegin.org> <18CD1F86-902C-4EF4-8884-C870C54A555C@yegin.org> Date: Tue, 06 Nov 2012 07:01:34 -0500 In-Reply-To: <18CD1F86-902C-4EF4-8884-C870C54A555C@yegin.org> (Alper Yegin's message of "Tue, 6 Nov 2012 10:05:22 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability discussion X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 12:01:39 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Sam, I see you are talking about a different way of using EAP Alper> (different then the legacy use). Alper> In legacy use, a secure channel is created with the help of Alper> the EAP. EAP MSK is used for setting it up. Actually, I'm aware of multiple lower layers that don't work this way. An easy example to look at is IKEv2. ABFAB's lower layer supports multiple modes of operation: one in which MSKs are used to set up a secure channel and one in which endpoints are authenticated over an existing channel. --Sam From hartmans@painless-security.com Wed Nov 7 06:14:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F23721F88CF for ; Wed, 7 Nov 2012 06:14:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] 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 uniZlTvVgZFd for ; Wed, 7 Nov 2012 06:14:27 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF0221F88B2 for ; Wed, 7 Nov 2012 06:14:27 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-459e.meeting.ietf.org [130.129.69.158]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 604A82026C; Wed, 7 Nov 2012 09:13:31 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E0F85412A; Wed, 7 Nov 2012 09:14:25 -0500 (EST) From: Sam Hartman To: Yoshihiro Ohba References: <50981AE9.5050104@toshiba.co.jp> Date: Wed, 07 Nov 2012 09:14:25 -0500 In-Reply-To: <50981AE9.5050104@toshiba.co.jp> (Yoshihiro Ohba's message of "Tue, 06 Nov 2012 05:00:41 +0900") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP retransmission text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:14:28 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> As I spoke today, I prefer having informative text on the Yoshihiro> retransmission issue without using a requirement language Yoshihiro> such as MUST/SHOULD. This is because a lower-layer can be Yoshihiro> designed in multiple different ways to deal with silent Yoshihiro> discarsion of EAP messages, including immediate Yoshihiro> termination of the lower-layer session, and it is Yoshihiro> difficult to determine what the best way is. In general, Yoshihiro> it depends on the characteristics of the target Yoshihiro> application. For example, an application that is capabile Yoshihiro> of server-driven retransmission can simply rely on Yoshihiro> EAP-layer retransmissions to deal with this issue. I strongly agree with the above. I'd like to use normative text in the following wway: Applications specifications SHOULD describe how they handle EAP retransmission. I think it would be undesirable to use normative language when describing which retransmission strategy applications should use. --Sam From yoshihiro.ohba@toshiba.co.jp Wed Nov 7 08:31:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EBD21F8B4D for ; Wed, 7 Nov 2012 08:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.089 X-Spam-Level: X-Spam-Status: No, score=-7.089 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_HI=-8, UNPARSEABLE_RELAY=0.001] 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 KopOS5CxwP-W for ; Wed, 7 Nov 2012 08:31:01 -0800 (PST) Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAF321F8C78 for ; Wed, 7 Nov 2012 08:31:01 -0800 (PST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by imx12.toshiba.co.jp with ESMTP id qA7GUxkL008919; Thu, 8 Nov 2012 01:30:59 +0900 (JST) Received: (from root@localhost) by arc11.toshiba.co.jp id qA7GUxQO000080; Thu, 8 Nov 2012 01:30:59 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id BAA00079; Thu, 8 Nov 2012 01:30:59 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp11.toshiba.co.jp with ESMTP id qA7GUx7m029923; Thu, 8 Nov 2012 01:30:59 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qA7GUxkv013965; Thu, 8 Nov 2012 01:30:59 +0900 (JST) Received: from [133.199.16.159] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MD4004DGLVA7WH0@mail.po.toshiba.co.jp>; Thu, 08 Nov 2012 01:30:59 +0900 (JST) Date: Thu, 08 Nov 2012 01:30:48 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <509A8CB8.7010905@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50981AE9.5050104@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] EAP retransmission text X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 16:31:02 -0000 Sam, (2012/11/07 23:14), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > Yoshihiro> As I spoke today, I prefer having informative text on the > Yoshihiro> retransmission issue without using a requirement language > Yoshihiro> such as MUST/SHOULD. This is because a lower-layer can be > Yoshihiro> designed in multiple different ways to deal with silent > Yoshihiro> discarsion of EAP messages, including immediate > Yoshihiro> termination of the lower-layer session, and it is > Yoshihiro> difficult to determine what the best way is. In general, > Yoshihiro> it depends on the characteristics of the target > Yoshihiro> application. For example, an application that is capabile > Yoshihiro> of server-driven retransmission can simply rely on > Yoshihiro> EAP-layer retransmissions to deal with this issue. > > I strongly agree with the above. > I'd like to use normative text in the following wway: > > Applications specifications SHOULD describe how they handle EAP > retransmission. Use of normative text in this way is good. On the other hand, I think there is a room to improve the text. Two comments: - I think the text is applicable not only for applications but for any EAP lower layer. - I suggest to be a bit more specific about what actually should be described. IMO, what should be described in each lower-layer specification is how to handle the case where an EAP message is siliently discarded by EAP peer or authenticator layer. Suggested text: Lower-layer specifications SHOULD describe how they handle the case where an EAP message is siliently discarded by EAP peer or authenticator layer. Regards, Yoshihiro Ohba > I think it would be undesirable to use normative language when > describing which retransmission strategy applications should use. > > --Sam > From Josh.Howlett@ja.net Thu Nov 8 07:53:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE00621F852C for ; Thu, 8 Nov 2012 07:53:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFnTsVtGjwk9 for ; Thu, 8 Nov 2012 07:53:54 -0800 (PST) Received: from egw001.ukerna.ac.uk (egw001.ukerna.ac.uk [194.82.140.74]) by ietfa.amsl.com (Postfix) with ESMTP id 23A7721F8533 for ; Thu, 8 Nov 2012 07:53:54 -0800 (PST) Received: from egw001.ukerna.ac.uk (localhost.localdomain [127.0.0.1]) by localhost (Email Security Appliance) with SMTP id BB7831A9CA1B_9BD590B; Thu, 8 Nov 2012 15:53:52 +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 622461A9C05F_9BD590F; Thu, 8 Nov 2012 15:53:52 +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; Thu, 8 Nov 2012 15:53:52 +0000 From: Josh Howlett To: "Cantor, Scott" , Jim Schaad , "abfab@ietf.org" Thread-Topic: [abfab] SAML draft and naming issues Thread-Index: Ac24ZT0mn/Yi8nW8TKGxSpDaKY/jnAAn8s6AAAHwNYAAAFWvAAEuxW6A Date: Thu, 8 Nov 2012 15:53:51 +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.2.4.120824 x-originating-ip: [194.82.140.76] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [abfab] SAML draft and naming issues 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, 08 Nov 2012 15:53:55 -0000 On 02/11/2012 15:24, "Cantor, Scott" wrote: >On 11/2/12 11:14 AM, "Jim Schaad" wrote: > >>Josh, >> >>I see it as=20 >> >> > >I was going to ask if this was limited to AuthnRequests or included >queries. If the latter, then yes, it's required. It is limited to AuthnRequests. (There is an Abfab profile that deals with queries; but this merely describes how to use the SAML 2.0 Assertion Query/Request Profile using a particular synchronous binding, RADIUS. The protocol semantics are equivalent). Josh. Janet is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024=20 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG From klaas@cisco.com Thu Nov 8 09:45:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19AEA21F8550 for ; Thu, 8 Nov 2012 09:45:47 -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 9-qT7VwcNnOE for ; Thu, 8 Nov 2012 09:45:46 -0800 (PST) Received: from out42-ams.mf.surf.net (out42-ams.mf.surf.net [145.0.1.42]) by ietfa.amsl.com (Postfix) with ESMTP id BEB5821F84FC for ; Thu, 8 Nov 2012 09:45:45 -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 qA8HjcjP032530 for ; Thu, 8 Nov 2012 18:45:39 +0100 Received: from [2001:df8:0:16:21f:5bff:fe84:dc1] by teletubbie.het.net.je with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1TWW5R-0003fV-1V for abfab@ietf.org; Thu, 08 Nov 2012 18:40:17 +0100 From: Klaas Wierenga Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 8 Nov 2012 18:45:36 +0100 Message-Id: To: abfab@ietf.org Mime-Version: 1.0 (Apple Message framework v1085) X-Mailer: Apple Mail (2.1085) 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: 0vIl5JCKS - a8d8fcb51b24 - 20121108 (trained as not-spam) X-Scanned-By: CanIt (www . roaringpenguin . com) Subject: [abfab] minutes of abfab@ietf85 available 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, 08 Nov 2012 17:45:47 -0000 Hi, Thanks to Nat for taking some great notes! They can be found at: http://www.ietf.org/proceedings/85/minutes/minutes-85-abfab Klaas From hartmans@painless-security.com Thu Nov 8 11:42:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5294A21F87F6 for ; Thu, 8 Nov 2012 11:42:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KRHAfU8sBVv for ; Thu, 8 Nov 2012 11:42:22 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4A421F85B1 for ; Thu, 8 Nov 2012 11:42:22 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-45e6.meeting.ietf.org [130.129.69.230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 9FB9E2021E; Thu, 8 Nov 2012 14:41:23 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 12BF3412A; Thu, 8 Nov 2012 14:42:19 -0500 (EST) From: Sam Hartman To: abfab@ietf.org, stephen.farrell@cs.tcd.ie Date: Thu, 08 Nov 2012 14:42:19 -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] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 19:42:23 -0000 Folks, I've been thinking about the mandatory to implement signature validation issue. The more I think about it, the more I agree with stephen and Scott that end-to-end security is important for ABFAB. It won't always be used; just as with other technologies, people will sometimes want to introduce middleboxes. However it's important to have a way of talking to the ends. However, I think SAML signatures are the wrong level to accomplish thit. The issue is that there's a lot of important stuff in ABFAB that comes in AAA not SAML. All the concerns about SAML can apply to the AAA elements. I was asking myself why Moonshot doesn't worry about this. Then I realized that we do. we're going out of our way to set up end-to-end RADSEC. We get protection of the SAML, but we also get protection of the AAA attributes. RADSEC can be used in a hop-by-hop manner. However, RADSEC is specified with a lot of thought towards enabling end-to-end uses. Multiple technologies, including the dynamic SRV-based mechanism and Moonshot's trust router are evolving to make end-to-end RADSEC easier to deploy. So, I think that RADSEC is a better MTI security technology for ABFAB than signature validation. I'd prefer to make RADSEC a MUST and SAML signature validation a SHOULD. I've run this by Alan, Josh, Scott and Jim. They seemed to like the idea, so I'm presenting it here. Note that there is a process issue with RADSEC; it's not standards-track. Let's assume for the moment that I can come up with a solution to that (I believe I have two avenues to approach) do we believe that if we can make it work that would be the right technical approach? --Sam From diego@tid.es Thu Nov 8 11:56:00 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EF0621F87F4 for ; Thu, 8 Nov 2012 11:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dk286xyvqQTR for ; Thu, 8 Nov 2012 11:55:44 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA5121F866B for ; Thu, 8 Nov 2012 11:55:42 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MD600I9OQ0T4L@tid.hi.inet> for abfab@ietf.org; Thu, 08 Nov 2012 20:55:41 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id 1E.4A.05494.C3E0C905; Thu, 08 Nov 2012 20:55:40 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MD600I9JQ0S4L@tid.hi.inet> for abfab@ietf.org; Thu, 08 Nov 2012 20:55:40 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by EX10-HTCAS6-MAD.hi.inet ([fe80::e1e3:e2fc:beda:deb9%15]) with mapi id 14.02.0318.004; Thu, 08 Nov 2012 20:55:40 +0100 Date: Thu, 08 Nov 2012 19:55:39 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: Sam Hartman Message-id: Content-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US, es-ES Thread-topic: [abfab] Proposal: mandatory radsec for draft-ietf-abfab-aaa-saml Thread-index: AQHNvekvuZW/QKTGO0yWJD978I3WM5fgSXSA X-AuditID: 0a5f4e69-b7fc06d000001576-68-509c0e3c55e3 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrOKsWRmVeSWpSXmKPExsXCFe9nqGvDNyfAoOWGicXH628YHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsapvH1NBh2zFgknPmRsYV8h0MXJySAiYSHyfPoURwhaTuHBv PVsXIxeHkMA2RonT65ZAOT8YJSa+mMQO4WxklFh28zkTSAuLgKrEyv/H2UBsNiD7UfNvoCIO DmEBX4nnWzxAwpwCahLLnv9ngtigIPHn3GMWEFtEwEBi3qtjYK3MAikS95o/gtXwCnhLNLx6 xwgRN5PYcvQ1G0RcUOLH5HssIOOZBdQlpkzJhSgRl2huvckCYStKTFvUANbKKCAr8W7+fFaI VX4Sf+HWGkl0v97IDHGOgMSSPeehbFGJl4//gdULAX1y8d9H1gmMErOQXDELyRWzEK6YheSK WUiuWMDIuopRrDipKDM9oyQ3MTMn3cBILyNTLzMvtWQTIyTmMncwLt+pcohRgINRiYf3Rsbs ACHWxLLiytxDjJIcTEqivCv+AoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8NYxzQkQ4k1JrKxK LcqHSclwcChJ8HbxAqUEi1LTUyvSMnOAiQUmzcTBCdLOA9Q+AaSGt7ggMbc4Mx0if4pRlaOx Z9FDRiGWvPy8VClxXmOQIgGQoozSPLg5rxjFgQ4W5q0DyfIAUyPchFdAw5mAhhdfmwEyvCQR ISXVwFg0V+9o7Ksr891mekQYT6+IYV4ZyvdwWUvD5eipHT90v9+3utOZOdNc3mnb5qatvRdd sye2WhpIheeuX30ycu+7h0JlBxxi3QPmLXjFF9hkoror+VDW/I2n6zKX/j+y/s7c2uc7fhpt DOkruXe+48er+x7L1oc4MzjU3EnyXzHp08UjXGqPjCKUWIozEg21mIuKEwF963ckSgMAAA== References: Cc: "" Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 19:56:00 -0000 SGksDQoNCkkgY291bGQgc2ltcGxlIHNheSB0aGUgdXN1YWwgIisxIiwgYnV0IGdpdmVuIG15IGNo YXR0eSBwZXJzb25hbGl0eSwgbGV0DQptZSBzYXkgSSBmdWxseSBzdXBwb3J0IHRoZSBpZGVhIG9m IEUyRSBSQURTRUMuDQoNCk9uIDggTm92IDIwMTIsIGF0IDE0OjQyICwgU2FtIEhhcnRtYW4gd3Jv dGU6DQoNCj4NCj4NCj4gRm9sa3MsIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCB0aGUgbWFuZGF0 b3J5IHRvIGltcGxlbWVudCBzaWduYXR1cmUNCj4gdmFsaWRhdGlvbiBpc3N1ZS4gIFRoZSBtb3Jl IEkgdGhpbmsgYWJvdXQgaXQsIHRoZSBtb3JlIEkgYWdyZWUgd2l0aA0KPiBzdGVwaGVuIGFuZCBT Y290dCB0aGF0IGVuZC10by1lbmQgc2VjdXJpdHkgaXMgaW1wb3J0YW50IGZvciBBQkZBQi4gIEl0 DQo+IHdvbid0IGFsd2F5cyBiZSB1c2VkOyBqdXN0IGFzIHdpdGggb3RoZXIgdGVjaG5vbG9naWVz LCBwZW9wbGUgd2lsbA0KPiBzb21ldGltZXMgd2FudCB0byBpbnRyb2R1Y2UgbWlkZGxlYm94ZXMu ICBIb3dldmVyIGl0J3MgaW1wb3J0YW50IHRvIGhhdmUNCj4gYSB3YXkgb2YgdGFsa2luZyB0byB0 aGUgZW5kcy4NCj4NCj4gSG93ZXZlciwgIEkgdGhpbmsgU0FNTCBzaWduYXR1cmVzIGFyZSB0aGUg d3JvbmcgbGV2ZWwgdG8gYWNjb21wbGlzaA0KPiB0aGl0Lg0KPiBUaGUgaXNzdWUgaXMgdGhhdCB0 aGVyZSdzIGEgbG90IG9mIGltcG9ydGFudCBzdHVmZiBpbiBBQkZBQiB0aGF0IGNvbWVzDQo+IGlu IEFBQSBub3QgU0FNTC4NCj4gQWxsIHRoZSBjb25jZXJucyBhYm91dCBTQU1MIGNhbiBhcHBseSB0 byB0aGUgQUFBIGVsZW1lbnRzLg0KPg0KPiBJIHdhcyBhc2tpbmcgbXlzZWxmIHdoeSBNb29uc2hv dCBkb2Vzbid0IHdvcnJ5IGFib3V0IHRoaXMuDQo+IFRoZW4gSSByZWFsaXplZCB0aGF0IHdlIGRv Lg0KPiB3ZSdyZSBnb2luZyBvdXQgb2Ygb3VyIHdheSB0byBzZXQgdXAgZW5kLXRvLWVuZCBSQURT RUMuDQo+IFdlIGdldCBwcm90ZWN0aW9uIG9mIHRoZSBTQU1MLCBidXQgd2UgYWxzbyBnZXQgcHJv dGVjdGlvbiBvZiB0aGUgIEFBQQ0KPiBhdHRyaWJ1dGVzLg0KPg0KPiBSQURTRUMgY2FuIGJlIHVz ZWQgaW4gYSBob3AtYnktaG9wIG1hbm5lci4gIEhvd2V2ZXIsIFJBRFNFQyBpcyBzcGVjaWZpZWQN Cj4gd2l0aCBhIGxvdCBvZiB0aG91Z2h0IHRvd2FyZHMgZW5hYmxpbmcgZW5kLXRvLWVuZCB1c2Vz LiAgTXVsdGlwbGUNCj4gdGVjaG5vbG9naWVzLCBpbmNsdWRpbmcgdGhlIGR5bmFtaWMgU1JWLWJh c2VkIG1lY2hhbmlzbSBhbmQgTW9vbnNob3Qncw0KPiB0cnVzdCByb3V0ZXIgYXJlIGV2b2x2aW5n IHRvIG1ha2UgZW5kLXRvLWVuZCBSQURTRUMgZWFzaWVyIHRvIGRlcGxveS4NCj4NCj4gU28sIEkg dGhpbmsgdGhhdCBSQURTRUMgaXMgYSBiZXR0ZXIgTVRJIHNlY3VyaXR5IHRlY2hub2xvZ3kgZm9y ICBBQkZBQg0KPiB0aGFuIHNpZ25hdHVyZSB2YWxpZGF0aW9uLg0KPiBJJ2QgcHJlZmVyIHRvIG1h a2UgUkFEU0VDIGEgTVVTVCBhbmQgU0FNTCBzaWduYXR1cmUgdmFsaWRhdGlvbiBhIFNIT1VMRC4N Cj4NCj4gSSd2ZSBydW4gdGhpcyBieSBBbGFuLCBKb3NoLCBTY290dCBhbmQgSmltLiAgVGhleSBz ZWVtZWQgdG8gbGlrZSB0aGUNCj4gaWRlYSwgc28gSSdtIHByZXNlbnRpbmcgaXQgaGVyZS4NCj4N Cj4gTm90ZSB0aGF0IHRoZXJlIGlzIGEgcHJvY2VzcyBpc3N1ZSB3aXRoIFJBRFNFQzsgaXQncyBu b3QNCj4gc3RhbmRhcmRzLXRyYWNrLiAgTGV0J3MgYXNzdW1lIGZvciB0aGUgbW9tZW50IHRoYXQg SSBjYW4gY29tZSB1cCB3aXRoIGENCj4gc29sdXRpb24gdG8gdGhhdCAoSSBiZWxpZXZlIEkgaGF2 ZSB0d28gYXZlbnVlcyB0byBhcHByb2FjaCkNCj4gZG8gd2UgYmVsaWV2ZSB0aGF0IGlmIHdlIGNh biBtYWtlIGl0IHdvcmsgdGhhdCB3b3VsZCBiZSB0aGUgcmlnaHQNCj4gdGVjaG5pY2FsIGFwcHJv YWNoPw0KPg0KPiAtLVNhbQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBhYmZhYiBtYWlsaW5nIGxpc3QNCj4gYWJmYWJAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYg0KDQoNCi0tDQoiRXN0YSB2 ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBMb3Bleg0K VGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1h aWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTogKzM0IDY4 MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBzZSBkaXJp Z2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRhciBudWVz dHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVjdHLDs25p Y28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBpcyBpbnRl bmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFuZCByZWNl aXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0dHA6Ly93 d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From leifj@mnt.se Thu Nov 8 12:24:03 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37221F894E for ; Thu, 8 Nov 2012 12:24:03 -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 tWa5ZiM7rtpj for ; Thu, 8 Nov 2012 12:24:02 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 81FC221F8860 for ; Thu, 8 Nov 2012 12:24:02 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id ro8so2443412pbb.31 for ; Thu, 08 Nov 2012 12:24:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=iwext6tkQkbrrVFC4niHrY6GeHMNk3prkTND7xpZ5dU=; b=MA7FtPdWB6aVuZL103XOUq6W22z9Yzbe5ik2X3ZzHhWB/zF248fzL4H6SMxOk9Aaz2 bu0+pTt+Ky+nRo0CfNRDgX4HVRh0xB1NfhxF0qYLWecw34y90wyTH0Qo//DHCnMz0CF0 MF3EKw+XeptLkJmeiMSAEHlqhXRrWgcDB2gFz/FQeVg5ZtjG10o4r5xxxNqkjXsMTlA0 1VHb0w9d7pmy1QtpeuyXKwJjosd7GzrgRzd6cCPdqSZjpOg8rNV6ifR5Qpp53YpR1NqI T+Wrzt5i7zXhVfpjVg5Gdddc87QHZzLDOGldNHVwN+FpRCRooCsQj1MFQhxrTAqEKIIS Kilg== Received: by 10.68.240.233 with SMTP id wd9mr2068034pbc.127.1352406240700; Thu, 08 Nov 2012 12:24:00 -0800 (PST) Received: from [130.129.9.70] (dhcp-9146.meeting.ietf.org. [130.129.9.70]) by mx.google.com with ESMTPS id vi9sm16429279pbc.41.2012.11.08.12.23.58 (version=SSLv3 cipher=OTHER); Thu, 08 Nov 2012 12:24:00 -0800 (PST) Message-ID: <509C14DC.70001@mnt.se> Date: Thu, 08 Nov 2012 21:23:56 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlzjHp50hohy2+g8s7aUAAfLpPpiMOcnerw1waVfmh+VGA/8qe1pox/eGn0DrynEjjIfrSh Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 20:24:03 -0000 On 11/08/2012 08:42 PM, Sam Hartman wrote: > > Folks, I've been thinking about the mandatory to implement signature > validation issue. The more I think about it, the more I agree with > stephen and Scott that end-to-end security is important for ABFAB. It > won't always be used; just as with other technologies, people will > sometimes want to introduce middleboxes. However it's important to have > a way of talking to the ends. > > However, I think SAML signatures are the wrong level to accomplish > thit. > The issue is that there's a lot of important stuff in ABFAB that comes > in AAA not SAML. > All the concerns about SAML can apply to the AAA elements. > > I was asking myself why Moonshot doesn't worry about this. > Then I realized that we do. > we're going out of our way to set up end-to-end RADSEC. > We get protection of the SAML, but we also get protection of the AAA > attributes. > > RADSEC can be used in a hop-by-hop manner. However, RADSEC is specified > with a lot of thought towards enabling end-to-end uses. Multiple > technologies, including the dynamic SRV-based mechanism and Moonshot's > trust router are evolving to make end-to-end RADSEC easier to deploy. > > So, I think that RADSEC is a better MTI security technology for ABFAB > than signature validation. > I'd prefer to make RADSEC a MUST and SAML signature validation a SHOULD. > > I've run this by Alan, Josh, Scott and Jim. They seemed to like the > idea, so I'm presenting it here. > > Note that there is a process issue with RADSEC; it's not > standards-track. Let's assume for the moment that I can come up with a > solution to that (I believe I have two avenues to approach) > do we believe that if we can make it work that would be the right > technical approach? > > Speaking as an individual I'll note that currently RADSEC depends on some form of public key management that is at least nominally no better or worse than the key management you'd need to do this using SAML. Cheers Leif From kwiereng@cisco.com Thu Nov 8 12:35:40 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 613F121F8696 for ; Thu, 8 Nov 2012 12:35:40 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUFynTfUPrPr for ; Thu, 8 Nov 2012 12:35:39 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8721F866B for ; Thu, 8 Nov 2012 12:35:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2904; q=dns/txt; s=iport; t=1352406930; x=1353616530; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=DcZc8Y27xnZ5jhwW/g86H5M0Iln4mXc1R4AaYPfO11M=; b=LyDx1Nzzuy++CV2M6EHFFMPbPxRzObtqVs2xeA+grfg0IEcsci3CTFv5 FRvkP/Q2W1eIwy3Rx6pW/kSfsML2/UBCj4Tpg4zmKh1KK8lMN++QaFlj0 XFiOW8JXTB9oOD7hKQ1S7efRZei9hV/vVPelnS5Z09hJYdfnqWSwTMYIi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAJ4WnFCtJXG9/2dsb2JhbABEw0KBCIIeAQEBAwEBAQEPASc0CwULAgEIGB4QJwslAgQOBRsHh2IGC5wMoC0EjBKFZmEDkg+DbI5YgWuCb4FdHgY X-IronPort-AV: E=Sophos;i="4.80,739,1344211200"; d="scan'208";a="140290301" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 08 Nov 2012 20:35:30 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA8KZU1a005487 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 Nov 2012 20:35:30 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.49]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.001; Thu, 8 Nov 2012 14:35:29 -0600 From: "Klaas Wierenga (kwiereng)" To: Leif Johansson Thread-Topic: [abfab] Proposal: mandatory radsec for draft-ietf-abfab-aaa-saml Thread-Index: AQHNvekvGOe2emUVukeYopMw2C5bu5fgxrcA//+eoy4= Date: Thu, 8 Nov 2012 20:35:27 +0000 Message-ID: References: ,<509C14DC.70001@mnt.se> In-Reply-To: <509C14DC.70001@mnt.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19348.005 x-tm-as-result: No--47.688300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 20:35:40 -0000 On 8 nov. 2012, at 15:24, "Leif Johansson" wrote: > On 11/08/2012 08:42 PM, Sam Hartman wrote: >>=20 >> Folks, I've been thinking about the mandatory to implement signature >> validation issue. The more I think about it, the more I agree with >> stephen and Scott that end-to-end security is important for ABFAB. It >> won't always be used; just as with other technologies, people will >> sometimes want to introduce middleboxes. However it's important to have >> a way of talking to the ends. >>=20 >> However, I think SAML signatures are the wrong level to accomplish >> thit. >> The issue is that there's a lot of important stuff in ABFAB that comes >> in AAA not SAML. >> All the concerns about SAML can apply to the AAA elements. >>=20 >> I was asking myself why Moonshot doesn't worry about this. >> Then I realized that we do. >> we're going out of our way to set up end-to-end RADSEC. >> We get protection of the SAML, but we also get protection of the AAA >> attributes. >>=20 >> RADSEC can be used in a hop-by-hop manner. However, RADSEC is specified >> with a lot of thought towards enabling end-to-end uses. Multiple >> technologies, including the dynamic SRV-based mechanism and Moonshot's >> trust router are evolving to make end-to-end RADSEC easier to deploy. >>=20 >> So, I think that RADSEC is a better MTI security technology for ABFAB >> than signature validation. >> I'd prefer to make RADSEC a MUST and SAML signature validation a SHOULD. >>=20 >> I've run this by Alan, Josh, Scott and Jim. They seemed to like the >> idea, so I'm presenting it here. >>=20 >> Note that there is a process issue with RADSEC; it's not >> standards-track. Let's assume for the moment that I can come up with a >> solution to that (I believe I have two avenues to approach) >> do we believe that if we can make it work that would be the right >> technical approach? >=20 > Speaking as an individual I'll note that currently RADSEC depends > on some form of public key management that is at least nominally > no better or worse than the key management you'd need to do this > using SAML. Also speaking as an individual. I do support the idea of using RadSec. Howe= ver, I think that one reason why one would be willing to support SAML sigs = is the simple fact that they exist today and presumably organizations might= be willing to continu to use their existing practice for end to end protec= tion. I realize that in some scenarios it will be impossible for the RP to = verify the signature, but I'd say that in the majority of cases this is not= more of a problem than it would be in RadSec (barring trust router impleme= ntations). Klaas >=20 > Cheers Leif > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Thu Nov 8 12:39:17 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EF1821F8696 for ; Thu, 8 Nov 2012 12:39:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b6kJ5FK1LaDs for ; Thu, 8 Nov 2012 12:39:16 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 80AAB21F867C for ; Thu, 8 Nov 2012 12:39:16 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-917d.meeting.ietf.org [130.129.9.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id E401B2021E; Thu, 8 Nov 2012 15:38:17 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id CFBC6412A; Thu, 8 Nov 2012 15:39:14 -0500 (EST) From: Sam Hartman To: "Klaas Wierenga \(kwiereng\)" References: <509C14DC.70001@mnt.se> Date: Thu, 08 Nov 2012 15:39:14 -0500 In-Reply-To: (Klaas Wierenga's message of "Thu, 8 Nov 2012 20:35:27 +0000") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 20:39:17 -0000 >>>>> "Klaas" == Klaas Wierenga (kwiereng) writes: Klaas> Also speaking as an individual. I do support the idea of Klaas> using RadSec. However, I think that one reason why one would Klaas> be willing to support SAML sigs is the simple fact that they Klaas> exist today and presumably organizations might be willing to Klaas> continu to use their existing practice for end to end Klaas> protection. I realize that in some scenarios it will be Klaas> impossible for the RP to verify the signature, but I'd say Klaas> that in the majority of cases this is not more of a problem Klaas> than it would be in RadSec (barring trust router Klaas> implementations). Sure, and for that reason, I think SAML sig validation implementation should be a SHOULD. But I think for an MTI mechansim we should pick something that actually protects the whole exchange. From leifj@sunet.se Thu Nov 8 12:39:37 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 992EC21F8683 for ; Thu, 8 Nov 2012 12:39:37 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvoDxHNDSD0p for ; Thu, 8 Nov 2012 12:39:37 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id C681821F867C for ; Thu, 8 Nov 2012 12:39:36 -0800 (PST) Received: from [130.129.9.70] (dhcp-9146.meeting.ietf.org [130.129.9.70]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qA8KdSLp018687 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Nov 2012 21:39:35 +0100 (CET) Message-ID: <509C187F.7020609@sunet.se> Date: Thu, 08 Nov 2012 21:39:27 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: , <509C14DC.70001@mnt.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 20:39:37 -0000 > Also speaking as an individual. I do support the idea of using RadSec. However, I think that one reason why one would be willing to support SAML sigs is the simple fact that they exist today and presumably organizations might be willing to continu to use their existing practice for end to end protection. I realize that in some scenarios it will be impossible for the RP to verify the signature, but I'd say that in the majority of cases this is not more of a problem than it would be in RadSec (barring trust router implementations). > Right (still with chair-hat off) deployability is another issue, although we shouldn't limit abfab to those that run "traditional" identity federations today, no matter how many there are of those. Cheers Leif From leifj@sunet.se Thu Nov 8 12:45:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CFA21F88FB for ; Thu, 8 Nov 2012 12:45:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EEdeM4kr-XDD for ; Thu, 8 Nov 2012 12:45:15 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 90B6021F88FA for ; Thu, 8 Nov 2012 12:45:14 -0800 (PST) Received: from [130.129.9.70] (dhcp-9146.meeting.ietf.org [130.129.9.70]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qA8Kj541018943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 8 Nov 2012 21:45:10 +0100 (CET) Message-ID: <509C19CF.5030002@sunet.se> Date: Thu, 08 Nov 2012 21:45:03 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: abfab@ietf.org References: <509C14DC.70001@mnt.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 20:45:15 -0000 On 11/08/2012 09:39 PM, Sam Hartman wrote: > > > Klaas> Also speaking as an individual. I do support the idea of > Klaas> using RadSec. However, I think that one reason why one would > Klaas> be willing to support SAML sigs is the simple fact that they > Klaas> exist today and presumably organizations might be willing to > Klaas> continu to use their existing practice for end to end > Klaas> protection. I realize that in some scenarios it will be > Klaas> impossible for the RP to verify the signature, but I'd say > Klaas> that in the majority of cases this is not more of a problem > Klaas> than it would be in RadSec (barring trust router > Klaas> implementations). > > Sure, and for that reason, I think SAML sig validation implementation > should be a SHOULD. But I think for an MTI mechansim we should pick > something that actually protects the whole exchange. Still with no hat on whatsoever... You seem to be assuming a situation where attributes are sometimes sent as AAA-attributes and sometimes as SAML-attributes. I think what we're seeing is a negative consequence of that design- choice in that it is now impossible to use existing deployments of SAML- trust infrastructure to protect all forms of attribute exchange. Please correct me if I got any of that wrong. Cheers Leif From hartmans@painless-security.com Thu Nov 8 12:49:08 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D9521F8997 for ; Thu, 8 Nov 2012 12:49:08 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id luN3vKHLNP90 for ; Thu, 8 Nov 2012 12:49:07 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id BEE8221F894E for ; Thu, 8 Nov 2012 12:49:07 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-917d.meeting.ietf.org [130.129.9.125]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 2D0A52021E; Thu, 8 Nov 2012 15:48:09 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 25C86412A; Thu, 8 Nov 2012 15:49:06 -0500 (EST) From: Sam Hartman To: Leif Johansson References: <509C14DC.70001@mnt.se> <509C19CF.5030002@sunet.se> Date: Thu, 08 Nov 2012 15:49:06 -0500 In-Reply-To: <509C19CF.5030002@sunet.se> (Leif Johansson's message of "Thu, 08 Nov 2012 21:45:03 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 20:49:08 -0000 >>>>> "Leif" == Leif Johansson writes: Leif> On 11/08/2012 09:39 PM, Sam Hartman wrote: >> > > Klaas> Also speaking as an individual. I do support the idea of Klaas> using RadSec. However, I think that one reason why one would Klaas> be willing to support SAML sigs is the simple fact that they Klaas> exist today and presumably organizations might be willing to Klaas> continu to use their existing practice for end to end Klaas> protection. I realize that in some scenarios it will be Klaas> impossible for the RP to verify the signature, but I'd say Klaas> that in the majority of cases this is not more of a problem Klaas> than it would be in RadSec (barring trust router Klaas> implementations). >> >> Sure, and for that reason, I think SAML sig validation >> implementation should be a SHOULD. But I think for an MTI >> mechansim we should pick something that actually protects the >> whole exchange. Leif> Still with no hat on whatsoever... Leif> You seem to be assuming a situation where attributes are Leif> sometimes sent as AAA-attributes and sometimes as Leif> SAML-attributes. no, I'm assuming that deployments have the flexibility as to whether to use AAA attributes or SAML attributes. Some of the use cases I'm looking at involve no SAML at all; some involve using SAML for everything. Having multiple ways to convey attributes was a fairly explicit decision here. It's true that it means attribute-container-specific security mechanisms lose value. From leifj@sunet.se Thu Nov 8 12:52:07 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73CB121F88FB for ; Thu, 8 Nov 2012 12:52:07 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPNmfw1e9bVv for ; Thu, 8 Nov 2012 12:52:07 -0800 (PST) Received: from backup-server.nordu.net (backup-server.nordu.net [IPv6:2001:948:4:1::66]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE3221F88EF for ; Thu, 8 Nov 2012 12:52:06 -0800 (PST) Received: from [130.129.9.70] (dhcp-9146.meeting.ietf.org [130.129.9.70]) (authenticated bits=0) by backup-server.nordu.net (8.14.5/8.14.3) with ESMTP id qA8Kq00M019082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 21:52:04 +0100 (CET) Message-ID: <509C1B70.1070006@sunet.se> Date: Thu, 08 Nov 2012 21:52:00 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sam Hartman References: <509C14DC.70001@mnt.se> <509C19CF.5030002@sunet.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 20:52:07 -0000 On 11/08/2012 09:49 PM, Sam Hartman wrote: >>>>>> "Leif" == Leif Johansson writes: > Leif> On 11/08/2012 09:39 PM, Sam Hartman wrote: > >> >> Klaas> Also speaking as an individual. I do support the idea of > Klaas> using RadSec. However, I think that one reason why one would > Klaas> be willing to support SAML sigs is the simple fact that they > Klaas> exist today and presumably organizations might be willing to > Klaas> continu to use their existing practice for end to end > Klaas> protection. I realize that in some scenarios it will be > Klaas> impossible for the RP to verify the signature, but I'd say > Klaas> that in the majority of cases this is not more of a problem > Klaas> than it would be in RadSec (barring trust router > Klaas> implementations). > >> > >> Sure, and for that reason, I think SAML sig validation > >> implementation should be a SHOULD. But I think for an MTI > >> mechansim we should pick something that actually protects the > >> whole exchange. > Leif> Still with no hat on whatsoever... > > Leif> You seem to be assuming a situation where attributes are > Leif> sometimes sent as AAA-attributes and sometimes as > Leif> SAML-attributes. > > no, I'm assuming that deployments have the flexibility as to whether to > use AAA attributes or SAML attributes. > Some of the use cases I'm looking at involve no SAML at all; some > involve using SAML for everything. > > Having multiple ways to convey attributes was a fairly explicit decision > here. It's true that it means attribute-container-specific security > mechanisms lose value. OK, then we're on the same page. Thx. From gabilm@um.es Thu Nov 8 14:12:58 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954B321F85BF for ; Thu, 8 Nov 2012 14:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, 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 fl5CKtWae2Bl for ; Thu, 8 Nov 2012 14:12:58 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8F821F85BB for ; Thu, 8 Nov 2012 14:12:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 495E05D61A; Thu, 8 Nov 2012 23:12:56 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id il730h9cOOAK; Thu, 8 Nov 2012 23:12:55 +0100 (CET) Received: from [192.168.1.102] (unknown [5.34.132.172]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: gabilm@um.es) by xenon13.um.es (Postfix) with ESMTPSA id DCC5D5D618; Thu, 8 Nov 2012 23:12:47 +0100 (CET) Date: Thu, 08 Nov 2012 23:14:04 +0100 Message-ID: Importance: normal From: gabilm To: leifj@sunet.se, hartmans@painless-security.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_267243372495610" Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 22:12:58 -0000 ----_com.android.email_267243372495610 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksCgpMZXRzIHRha2UgaW50byDCoGFjY291bnQgwqB0aGF0IFNBTUwgc2lnbmF0dXJlIG1lYW5z IHRoYXQgdGhlIGlkcCBkb2VzIGFzc2VydCB0aGUgYXR0cmlidXRlcyDCoGJlbG9uZ3MgdG8gYSB1 c2VyIChzdWJqZWN0KS4gUmFkc2VjIHNpZ25hdHVyZSBtZWFucyB5b3UgYXJlIGF1dGhlbnRpY2F0 aW5nIGEgcGFydHksIHRoZSBpZHAuIFNvIGl0IHNob3VsZCBiZSBjbGVhcmx5IHNwZWNpZmllZCDC oHdoZW4gd2UgY2FuIG1ha2UgdXNlIG9mIG9uZSBvciBhbm90aGVyIC4KCkJlc2lkZSwgZG9lcyBp dCBtZWFuIHdlIGZpbm5hbHkgbmVlZHMgYSBwdWJsaWMga2V5IGluZnJhc3RydWN0dXJlPwoKCkVu dmlhZG8gZGVzZGUgU2Ftc3VuZyB0YWJsZXRMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U+ IGVzY3JpYmnDszpPbiAxMS8wOC8yMDEyIDA5OjQ5IFBNLCBTYW0gSGFydG1hbiB3cm90ZToKPj4+ Pj4+ICJMZWlmIiA9PSBMZWlmIEpvaGFuc3NvbiA8bGVpZmpAc3VuZXQuc2U+IHdyaXRlczoKPsKg wqDCoMKgIExlaWY+IE9uIDExLzA4LzIwMTIgMDk6MzkgUE0sIFNhbSBIYXJ0bWFuIHdyb3RlOgo+ wqDCoMKgwqAgPj4gCj4+IEtsYWFzPiBBbHNvIHNwZWFraW5nIGFzIGFuIGluZGl2aWR1YWwuIEkg ZG8gc3VwcG9ydCB0aGUgaWRlYSBvZgo+wqDCoMKgwqAgS2xhYXM+IHVzaW5nIFJhZFNlYy4gSG93 ZXZlciwgSSB0aGluayB0aGF0IG9uZSByZWFzb24gd2h5IG9uZSB3b3VsZAo+wqDCoMKgwqAgS2xh YXM+IGJlIHdpbGxpbmcgdG8gc3VwcG9ydCBTQU1MIHNpZ3MgaXMgdGhlIHNpbXBsZSBmYWN0IHRo YXQgdGhleQo+wqDCoMKgwqAgS2xhYXM+IGV4aXN0IHRvZGF5IGFuZCBwcmVzdW1hYmx5IG9yZ2Fu aXphdGlvbnMgbWlnaHQgYmUgd2lsbGluZyB0bwo+wqDCoMKgwqAgS2xhYXM+IGNvbnRpbnUgdG8g dXNlIHRoZWlyIGV4aXN0aW5nIHByYWN0aWNlIGZvciBlbmQgdG8gZW5kCj7CoMKgwqDCoCBLbGFh cz4gcHJvdGVjdGlvbi4gSSByZWFsaXplIHRoYXQgaW4gc29tZSBzY2VuYXJpb3MgaXQgd2lsbCBi ZQo+wqDCoMKgwqAgS2xhYXM+IGltcG9zc2libGUgZm9yIHRoZSBSUCB0byB2ZXJpZnkgdGhlIHNp Z25hdHVyZSwgYnV0IEknZCBzYXkKPsKgwqDCoMKgIEtsYWFzPiB0aGF0IGluIHRoZSBtYWpvcml0 eSBvZiBjYXNlcyB0aGlzIGlzIG5vdCBtb3JlIG9mIGEgcHJvYmxlbQo+wqDCoMKgwqAgS2xhYXM+ IHRoYW4gaXQgd291bGQgYmUgaW4gUmFkU2VjIChiYXJyaW5nIHRydXN0IHJvdXRlcgo+wqDCoMKg wqAgS2xhYXM+IGltcGxlbWVudGF0aW9ucykuCj7CoMKgwqDCoCA+PiAKPsKgwqDCoMKgID4+IFN1 cmUsIGFuZCBmb3IgdGhhdCByZWFzb24sIEkgdGhpbmsgU0FNTCBzaWcgdmFsaWRhdGlvbgo+wqDC oMKgwqAgPj4gaW1wbGVtZW50YXRpb24gc2hvdWxkIGJlIGEgU0hPVUxELsKgIEJ1dCBJIHRoaW5r IGZvciBhbiBNVEkKPsKgwqDCoMKgID4+IG1lY2hhbnNpbSB3ZSBzaG91bGQgcGljayBzb21ldGhp bmcgdGhhdCBhY3R1YWxseSBwcm90ZWN0cyB0aGUKPsKgwqDCoMKgID4+IHdob2xlIGV4Y2hhbmdl Lgo+wqDCoMKgwqAgTGVpZj4gU3RpbGwgd2l0aCBubyBoYXQgb24gd2hhdHNvZXZlci4uLgo+Cj7C oMKgwqDCoCBMZWlmPiBZb3Ugc2VlbSB0byBiZSBhc3N1bWluZyBhIHNpdHVhdGlvbiB3aGVyZSBh dHRyaWJ1dGVzIGFyZQo+wqDCoMKgwqAgTGVpZj4gc29tZXRpbWVzIHNlbnQgYXMgQUFBLWF0dHJp YnV0ZXMgYW5kIHNvbWV0aW1lcyBhcwo+wqDCoMKgwqAgTGVpZj4gU0FNTC1hdHRyaWJ1dGVzLgo+ Cj4gbm8sIEknbSBhc3N1bWluZyB0aGF0IGRlcGxveW1lbnRzIGhhdmUgdGhlIGZsZXhpYmlsaXR5 IGFzIHRvIHdoZXRoZXIgdG8KPiB1c2UgQUFBIGF0dHJpYnV0ZXMgb3IgU0FNTCBhdHRyaWJ1dGVz Lgo+IFNvbWUgb2YgdGhlIHVzZSBjYXNlcyBJJ20gbG9va2luZyBhdCBpbnZvbHZlIG5vIFNBTUwg YXQgYWxsOyBzb21lCj4gaW52b2x2ZSB1c2luZyBTQU1MIGZvciBldmVyeXRoaW5nLgo+Cj4gSGF2 aW5nIG11bHRpcGxlIHdheXMgdG8gY29udmV5IGF0dHJpYnV0ZXMgd2FzIGEgZmFpcmx5IGV4cGxp Y2l0IGRlY2lzaW9uCj4gaGVyZS4gSXQncyB0cnVlIHRoYXQgaXQgbWVhbnMgYXR0cmlidXRlLWNv bnRhaW5lci1zcGVjaWZpYyBzZWN1cml0eQo+IG1lY2hhbmlzbXMgbG9zZSB2YWx1ZS4KT0ssIHRo ZW4gd2UncmUgb24gdGhlIHNhbWUgcGFnZS4gVGh4LgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwphYmZhYiBtYWlsaW5nIGxpc3QKYWJmYWJAaWV0Zi5vcmcK aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hYmZhYgo= ----_com.android.email_267243372495610 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2PkhpLDwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+TGV0cyB0YWtlIGludG8gJm5ic3A7YWNjb3VudCAmbmJzcDt0aGF0IFNBTUwg c2lnbmF0dXJlIG1lYW5zIHRoYXQgdGhlIGlkcCBkb2VzIGFzc2VydCB0aGUgYXR0cmlidXRlcyAm bmJzcDtiZWxvbmdzIHRvIGEgdXNlciAoc3ViamVjdCkuIFJhZHNlYyBzaWduYXR1cmUgbWVhbnMg eW91IGFyZSBhdXRoZW50aWNhdGluZyBhIHBhcnR5LCB0aGUgaWRwLiBTbyBpdCBzaG91bGQgYmUg Y2xlYXJseSBzcGVjaWZpZWQgJm5ic3A7d2hlbiB3ZSBjYW4gbWFrZSB1c2Ugb2Ygb25lIG9yIGFu b3RoZXIgLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+QmVzaWRlLCBkb2VzIGl0IG1lYW4gd2Ug ZmlubmFseSBuZWVkcyBhIHB1YmxpYyBrZXkgaW5mcmFzdHJ1Y3R1cmU/PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJmb250LXNpemU6MTAwJSI+RW52 aWFkbyBkZXNkZSBTYW1zdW5nIHRhYmxldDwvZGl2PjwvZGl2PiA8YnI+TGVpZiBKb2hhbnNzb24g Jmx0O2xlaWZqQHN1bmV0LnNlJmd0OyBlc2NyaWJpw7M6PGJyPk9uIDExLzA4LzIwMTIgMDk6NDkg UE0sIFNhbSBIYXJ0bWFuIHdyb3RlOjxicj4mZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgIkxlaWYi ID09IExlaWYgSm9oYW5zc29uICZsdDtsZWlmakBzdW5ldC5zZSZndDsgd3JpdGVzOjxicj4mZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlaWYmZ3Q7IE9uIDExLzA4LzIwMTIgMDk6MzkgUE0s IFNhbSBIYXJ0bWFuIHdyb3RlOjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsm Z3Q7IDxicj4mZ3Q7Jmd0OyBLbGFhcyZndDsgQWxzbyBzcGVha2luZyBhcyBhbiBpbmRpdmlkdWFs LiBJIGRvIHN1cHBvcnQgdGhlIGlkZWEgb2Y8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBLbGFhcyZndDsgdXNpbmcgUmFkU2VjLiBIb3dldmVyLCBJIHRoaW5rIHRoYXQgb25lIHJlYXNv biB3aHkgb25lIHdvdWxkPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgS2xhYXMmZ3Q7 IGJlIHdpbGxpbmcgdG8gc3VwcG9ydCBTQU1MIHNpZ3MgaXMgdGhlIHNpbXBsZSBmYWN0IHRoYXQg dGhleTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtsYWFzJmd0OyBleGlzdCB0b2Rh eSBhbmQgcHJlc3VtYWJseSBvcmdhbml6YXRpb25zIG1pZ2h0IGJlIHdpbGxpbmcgdG88YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBLbGFhcyZndDsgY29udGludSB0byB1c2UgdGhlaXIg ZXhpc3RpbmcgcHJhY3RpY2UgZm9yIGVuZCB0byBlbmQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBLbGFhcyZndDsgcHJvdGVjdGlvbi4gSSByZWFsaXplIHRoYXQgaW4gc29tZSBzY2Vu YXJpb3MgaXQgd2lsbCBiZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtsYWFzJmd0 OyBpbXBvc3NpYmxlIGZvciB0aGUgUlAgdG8gdmVyaWZ5IHRoZSBzaWduYXR1cmUsIGJ1dCBJJ2Qg c2F5PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgS2xhYXMmZ3Q7IHRoYXQgaW4gdGhl IG1ham9yaXR5IG9mIGNhc2VzIHRoaXMgaXMgbm90IG1vcmUgb2YgYSBwcm9ibGVtPGJyPiZndDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgS2xhYXMmZ3Q7IHRoYW4gaXQgd291bGQgYmUgaW4gUmFk U2VjIChiYXJyaW5nIHRydXN0IHJvdXRlcjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEtsYWFzJmd0OyBpbXBsZW1lbnRhdGlvbnMpLjxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsmZ3Q7IDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IFN1 cmUsIGFuZCBmb3IgdGhhdCByZWFzb24sIEkgdGhpbmsgU0FNTCBzaWcgdmFsaWRhdGlvbjxicj4m Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IGltcGxlbWVudGF0aW9uIHNob3Vs ZCBiZSBhIFNIT1VMRC4mbmJzcDsgQnV0IEkgdGhpbmsgZm9yIGFuIE1USTxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmZ3Q7IG1lY2hhbnNpbSB3ZSBzaG91bGQgcGljayBzb21l dGhpbmcgdGhhdCBhY3R1YWxseSBwcm90ZWN0cyB0aGU8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyAmZ3Q7Jmd0OyB3aG9sZSBleGNoYW5nZS48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyBMZWlmJmd0OyBTdGlsbCB3aXRoIG5vIGhhdCBvbiB3aGF0c29ldmVyLi4uPGJyPiZn dDs8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMZWlmJmd0OyBZb3Ugc2VlbSB0byBi ZSBhc3N1bWluZyBhIHNpdHVhdGlvbiB3aGVyZSBhdHRyaWJ1dGVzIGFyZTxicj4mZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlaWYmZ3Q7IHNvbWV0aW1lcyBzZW50IGFzIEFBQS1hdHRyaWJ1 dGVzIGFuZCBzb21ldGltZXMgYXM8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMZWlm Jmd0OyBTQU1MLWF0dHJpYnV0ZXMuPGJyPiZndDs8YnI+Jmd0OyBubywgSSdtIGFzc3VtaW5nIHRo YXQgZGVwbG95bWVudHMgaGF2ZSB0aGUgZmxleGliaWxpdHkgYXMgdG8gd2hldGhlciB0bzxicj4m Z3Q7IHVzZSBBQUEgYXR0cmlidXRlcyBvciBTQU1MIGF0dHJpYnV0ZXMuPGJyPiZndDsgU29tZSBv ZiB0aGUgdXNlIGNhc2VzIEknbSBsb29raW5nIGF0IGludm9sdmUgbm8gU0FNTCBhdCBhbGw7IHNv bWU8YnI+Jmd0OyBpbnZvbHZlIHVzaW5nIFNBTUwgZm9yIGV2ZXJ5dGhpbmcuPGJyPiZndDs8YnI+ Jmd0OyBIYXZpbmcgbXVsdGlwbGUgd2F5cyB0byBjb252ZXkgYXR0cmlidXRlcyB3YXMgYSBmYWly bHkgZXhwbGljaXQgZGVjaXNpb248YnI+Jmd0OyBoZXJlLiBJdCdzIHRydWUgdGhhdCBpdCBtZWFu cyBhdHRyaWJ1dGUtY29udGFpbmVyLXNwZWNpZmljIHNlY3VyaXR5PGJyPiZndDsgbWVjaGFuaXNt cyBsb3NlIHZhbHVlLjxicj5PSywgdGhlbiB3ZSdyZSBvbiB0aGUgc2FtZSBwYWdlLiBUaHguPGJy Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPmFiZmFi IG1haWxpbmcgbGlzdDxicj5hYmZhYkBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL2FiZmFiPGJyPiA8L2JvZHk+ ----_com.android.email_267243372495610-- From cantor.2@osu.edu Thu Nov 8 14:52:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8182021F8660 for ; Thu, 8 Nov 2012 14:52:31 -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 wgn6FcKt0sib for ; Thu, 8 Nov 2012 14:52:30 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe002.messaging.microsoft.com [216.32.180.185]) by ietfa.amsl.com (Postfix) with ESMTP id 4887521F85CB for ; Thu, 8 Nov 2012 14:52:30 -0800 (PST) Received: from mail220-co1-R.bigfish.com (10.243.78.240) by CO1EHSOBE012.bigfish.com (10.243.66.75) with Microsoft SMTP Server id 14.1.225.23; Thu, 8 Nov 2012 22:52:29 +0000 Received: from mail220-co1 (localhost [127.0.0.1]) by mail220-co1-R.bigfish.com (Postfix) with ESMTP id 6F65280986; Thu, 8 Nov 2012 22:52:29 +0000 (UTC) X-Forefront-Antispam-Report: CIP:164.107.81.174; KIP:(null); UIP:(null); IPV:NLI; H:CIO-TNC-HT07.osuad.osu.edu; RD:cio-tnc-ht07.osuad.osu.edu; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(zzbb2dI98dI9371I1432Izz1d77h1de0h1202h1d1ah1d2ahzzz2fh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0l1155h) Received-SPF: pass (mail220-co1: domain of osu.edu designates 164.107.81.174 as permitted sender) client-ip=164.107.81.174; envelope-from=cantor.2@osu.edu; helo=CIO-TNC-HT07.osuad.osu.edu ; suad.osu.edu ; Received: from mail220-co1 (localhost.localdomain [127.0.0.1]) by mail220-co1 (MessageSwitch) id 1352415147856645_7338; Thu, 8 Nov 2012 22:52:27 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.231]) by mail220-co1.bigfish.com (Postfix) with ESMTP id CF2D624004F; Thu, 8 Nov 2012 22:52:27 +0000 (UTC) Received: from CIO-TNC-HT07.osuad.osu.edu (164.107.81.174) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 8 Nov 2012 22:52:23 +0000 Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-TNC-HT07.osuad.osu.edu ([fe80::1c0f:4d2:f020:9937%12]) with mapi id 14.02.0318.004; Thu, 8 Nov 2012 17:52:21 -0500 From: "Cantor, Scott" To: gabilm , "leifj@sunet.se" , "hartmans@painless-security.com" Thread-Topic: [abfab] Proposal: mandatory radsec for draft-ietf-abfab-aaa-saml Thread-Index: AQHNvf5csiKU9Iiu6UiN+g6JfkPMC5fgi2kA Date: Thu, 8 Nov 2012 22:52:21 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.17.140] Content-Type: text/plain; charset="us-ascii" Content-ID: <513DB86C3B04ED42ADA810A47C2DE3D9@osu.edu> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: osu.edu Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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, 08 Nov 2012 22:52:31 -0000 On 11/8/12 5:14 PM, "gabilm" wrote: > >Lets take into account that SAML signature means that the idp does >assert the attributes belongs to a user (subject). Radsec signature >means you are authenticating a party, the idp. So it should be clearly >specified when we can make use of one or another. I would dispute that SAML itself dictates any explicit sort of semantic like that. In most SAML profiles, the goal is to transmit the data with origin authentication of the IdP, and that's it. There's no distinction (in SAML itself) based on whether transport protection or message protection is used, or which message layer is signed. Most relying party implementations don't make such distinctions, though of course they might let deployers make them by disabling some options or requiring others. But in SAML profiles or usage scenarios in which, for example, you don't have direct connectivity to the IdP so a signature has to be used, it doesn't follow that some kind of special legalistic semantic is in play. -- Scott From hartmans@painless-security.com Thu Nov 8 16:28:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA5C721F8957 for ; Thu, 8 Nov 2012 16:28:10 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SVvodzN3m8E for ; Thu, 8 Nov 2012 16:28:10 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9FB21F88FA for ; Thu, 8 Nov 2012 16:28:10 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-45e6.meeting.ietf.org [130.129.69.230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 793A02036E; Thu, 8 Nov 2012 19:27:11 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7B30E412A; Thu, 8 Nov 2012 19:28:08 -0500 (EST) From: Sam Hartman To: gabilm References: Date: Thu, 08 Nov 2012 19:28:08 -0500 In-Reply-To: (gabilm@um.es's message of "Thu, 08 Nov 2012 23:14:04 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Fri, 09 Nov 2012 00:28:11 -0000 >>>>> "gabilm" == gabilm writes: gabilm> Beside, does it mean we finnaly needs a public key gabilm> infrastructure? If you're going to use RADSEC with a public-key based TLS cipher or if you're going to use SAML signatures, you need the public key of the signer, yes. I think the people proposing validation of signatures as an MTI were aware that public-keys would be needed to make use of signatures. So, I think both RADSEC and SAML signatures have similar requirements for public-keys in typical deployments. A PKI is one approach for getting these public keys. From diego@tid.es Thu Nov 8 20:12:33 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D106021E803F for ; Thu, 8 Nov 2012 20:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 hO4P8zlQx2oJ for ; Thu, 8 Nov 2012 20:12:33 -0800 (PST) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 0237521E803C for ; Thu, 8 Nov 2012 20:12:32 -0800 (PST) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MD700ITED0VAT@tid.hi.inet> for abfab@ietf.org; Fri, 09 Nov 2012 05:12:31 +0100 (MET) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id DC.02.05494.FA28C905; Fri, 09 Nov 2012 05:12:31 +0100 (CET) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MD700IT4D0UAT@tid.hi.inet> for abfab@ietf.org; Fri, 09 Nov 2012 05:12:31 +0100 (MET) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.64]) by ex10-htcas4-mad.hi.inet ([::1]) with mapi id 14.02.0318.004; Fri, 09 Nov 2012 05:12:30 +0100 Date: Fri, 09 Nov 2012 04:12:30 +0000 From: "Diego R. Lopez" In-reply-to: X-Originating-IP: [10.95.64.115] To: Sam Hartman Message-id: Content-id: <4103529C4F145240B2DC71A8333A3ADC@hi.inet> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [abfab] Proposal: mandatory radsec for draft-ietf-abfab-aaa-saml Thread-index: AQHNvhEXuZW/QKTGO0yWJD978I3WM5fg0/OA X-AuditID: 0a5f4e69-b7fc06d000001576-bb-509c82af82fd X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXCFe9nqLu+aU6AwZG13BYfr79hdGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsnO/4wFd/gr5k+byNbAuIK/i5GTQ0LARKLl2yVWCFtM4sK9 9WxdjFwcQgLbGCUmTLvKCuH8YJQ4NXM+lDONUeJXdwNQGTsHi4CqxI40kGY2IOtR82/2LkYO DmEBX4nnWzxAwpwCahKXl/5kg5ivIPHn3GMWEFtEwEBi3qtjYHFmATuJc833weK8At4SbxdP h4qbSTxovMEIEReU+DH5HgvIeGYBdYkpU3IhSsQlmltvskDYihLTFjWAlTMCvfL91BomiFV+ En/h1hpJHF20ixHiHAGJJXvOM0PYohIvH/8DB4OQQJJE68lpTBMYJWYhuWIWkitmIVwxC8kV s5BcsYCRdRWjWHFSUWZ6RkluYmZOuoGRXkamXmZeaskmRki8Ze5gXL5T5RCjAAejEg9vgeWc ACHWxLLiytxDjJIcTEqivC01QCG+pPyUyozE4oz4otKc1OJDjBIczEoivHMzgXK8KYmVValF +TApGQ4OJQnejgaglGBRanpqRVpmDjCpwKSZODhB2nmA2nUbQdqLCxJzizPTIfKnGCWlxHkD QRICIImM0jy43leM4kBHCvM+AMnyANMfXNcroIFMQAOLr80AGViSiJCSamBclz99tfirlLMe mRavbxbpSobufnr934Y/Sf8nzo7/oV5lwHKUael70/TZ6mkfeTmOr667kXlXd8KCpZYcKr/r bctWiiw67qTGr34rYt2eQh3mDWc3cD48p/BhWeVXL8/jzPP4rvRH7P6ucEP1AJfNXg//aiWr krxntVpzuSZ1FsxrVQ2eK+GjxFKckWioxVxUnAgAYIQtNTwDAAA= References: Cc: "" Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Fri, 09 Nov 2012 04:12:33 -0000 DQpPbiA4IE5vdiAyMDEyLCBhdCAxOToyOCAsIFNhbSBIYXJ0bWFuIHdyb3RlOg0KPiBJZiB5b3Un cmUgZ29pbmcgdG8gdXNlIFJBRFNFQyB3aXRoIGEgcHVibGljLWtleSBiYXNlZCBUTFMgY2lwaGVy IG9yIGlmDQo+IHlvdSdyZSBnb2luZyB0byB1c2UgU0FNTCBzaWduYXR1cmVzLCB5b3UgbmVlZCB0 aGUgcHVibGljIGtleSBvZiB0aGUNCj4gc2lnbmVyLCB5ZXMuDQo+IEkgdGhpbmsgdGhlIHBlb3Bs ZSBwcm9wb3NpbmcgdmFsaWRhdGlvbiBvZiBzaWduYXR1cmVzIGFzIGFuIE1USSB3ZXJlDQo+IGF3 YXJlIHRoYXQgcHVibGljLWtleXMgd291bGQgYmUgbmVlZGVkIHRvIG1ha2UgdXNlIG9mIHNpZ25h dHVyZXMuDQo+IFNvLCBJIHRoaW5rIGJvdGggUkFEU0VDIGFuZCBTQU1MIHNpZ25hdHVyZXMgaGF2 ZSBzaW1pbGFyIHJlcXVpcmVtZW50cw0KPiBmb3IgcHVibGljLWtleXMgaW4gdHlwaWNhbCBkZXBs b3ltZW50cy4NCj4gQSBQS0kgaXMgb25lIGFwcHJvYWNoIGZvciBnZXR0aW5nIHRoZXNlIHB1Ymxp YyBrZXlzLg0KDQpSaWdodC4gSW4gYW55IGNhc2UgeW91IG5lZWQgYSBrZXkgZGlzdHJpYnV0aW9u IG1lY2hhbmlzbSwgUEtJIG9yDQp3aGF0ZXZlci4gVG8gbXkgdmlldywgdGhlIGRpZmZlcmVuY2Ug aXMgdGhhdCBpbiB0aGUgY2FzZSBvZiBSQURTRUMgeW91DQpwdXQgdGhlIHRydXN0IGZhYnJpYyBv biB0aGUgc2FtZSBBQUEgaW5mcmFzdHJ1Y3R1cmUgeW91IGFyZSB1c2luZw0KdGhyb3VnaCBBQkZB Qiwgd2hpbGUgcmVseWluZyBvbiBTQU1MIHNpZ25hdHVyZXMgcmVxdWlyZSBhIHRydXN0DQpmYWJy aWMgb24gYW4gYW5jaWxsaWFyeSBpbmZyYXN0cnVjdHVyZS4NCg0KQmUgZ29vZGUsDQoNCi0tDQoi RXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5vIg0KDQpEciBEaWVnbyBSLiBM b3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6Lw0K DQplLW1haWw6IGRpZWdvQHRpZC5lcw0KVGVsOiAgICArMzQgOTEzIDEyOSAwNDENCk1vYmlsZTog KzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSBz ZSBkaXJpZ2UgZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8uIFB1ZWRlIGNvbnN1bHRh ciBudWVzdHJhIHBvbMOtdGljYSBkZSBlbnbDrW8geSByZWNlcGNpw7NuIGRlIGNvcnJlbyBlbGVj dHLDs25pY28gZW4gZWwgZW5sYWNlIHNpdHVhZG8gbcOhcyBhYmFqby4NClRoaXMgbWVzc2FnZSBp cyBpbnRlbmRlZCBleGNsdXNpdmVseSBmb3IgaXRzIGFkZHJlc3NlZS4gV2Ugb25seSBzZW5kIGFu ZCByZWNlaXZlIGVtYWlsIG9uIHRoZSBiYXNpcyBvZiB0aGUgdGVybXMgc2V0IG91dCBhdDoNCmh0 dHA6Ly93d3cudGlkLmVzL0VTL1BBR0lOQVMvZGlzY2xhaW1lci5hc3B4DQo= From gabilm@um.es Fri Nov 9 01:46:01 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1401D21F8482 for ; Fri, 9 Nov 2012 01:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrIvS50CXM2T for ; Fri, 9 Nov 2012 01:46:00 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 2338C21F84D9 for ; Fri, 9 Nov 2012 01:45:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id C50AA5D52F; Fri, 9 Nov 2012 10:45:57 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Ug5Q92Ny8G12; Fri, 9 Nov 2012 10:45:57 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (vpn_um-194-22.inf.um.es [155.54.194.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon14.um.es (Postfix) with ESMTPSA id 465055D521; Fri, 9 Nov 2012 10:45:54 +0100 (CET) Message-ID: <509CD0D0.3050401@um.es> Date: Fri, 09 Nov 2012 10:45:52 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Cantor, Scott" References: In-Reply-To: X-Enigmail-Version: 1.4.5 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "abfab@ietf.org" Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Fri, 09 Nov 2012 09:46:01 -0000 El 08/11/12 23:52, Cantor, Scott escribió: > On 11/8/12 5:14 PM, "gabilm" wrote: >> Lets take into account that SAML signature means that the idp does >> assert the attributes belongs to a user (subject). Radsec signature >> means you are authenticating a party, the idp. So it should be clearly >> specified when we can make use of one or another. > I would dispute that SAML itself dictates any explicit sort of semantic > like that. In most SAML profiles, the goal is to transmit the data with > origin authentication of the IdP, and that's it. There's no distinction > (in SAML itself) based on whether transport protection or message > protection is used, or which message layer is signed. Most relying party > implementations don't make such distinctions, though of course they might > let deployers make them by disabling some options or requiring others. > > But in SAML profiles or usage scenarios in which, for example, you don't > have direct connectivity to the IdP so a signature has to be used, it > doesn't follow that some kind of special legalistic semantic is in play. I agree. Of course, in both cases you are authenticating the idP, my concern is that it seems SAML authentication and RadSec authentication are equivalent. For example, what does it happen if the home organization radius and idP servers are no co-located, for example, if the organization has a shibboleth idP that wants to connect to the abfab infrastructure. You could have SAML and Radsec signatures from different entities. regards, Gabi. > > -- Scott > > -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de IngenierÂ’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From gabilm@um.es Fri Nov 9 01:48:58 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618E521F84A2 for ; Fri, 9 Nov 2012 01:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.799 X-Spam-Level: X-Spam-Status: No, score=-4.799 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 MrPcVafvNmlo for ; Fri, 9 Nov 2012 01:48:57 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 8746D21F8467 for ; Fri, 9 Nov 2012 01:48:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 3BF505D607; Fri, 9 Nov 2012 10:48:56 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id us7YUC3C5y8w; Fri, 9 Nov 2012 10:48:55 +0100 (CET) Received: from MacBook-Pro-de-Gabriel-Lopez.local (vpn_um-194-22.inf.um.es [155.54.194.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPSA id 30D725D45B; Fri, 9 Nov 2012 10:48:53 +0100 (CET) Message-ID: <509CD184.4030603@um.es> Date: Fri, 09 Nov 2012 10:48:52 +0100 From: =?UTF-8?B?R2FicmllbCBMw7NwZXo=?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "Diego R. Lopez" References: In-Reply-To: X-Enigmail-Version: 1.4.5 OpenPGP: id=8D119153 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "" Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Fri, 09 Nov 2012 09:48:58 -0000 El 09/11/12 05:12, Diego R. Lopez escribió: > On 8 Nov 2012, at 19:28 , Sam Hartman wrote: >> If you're going to use RADSEC with a public-key based TLS cipher or if >> you're going to use SAML signatures, you need the public key of the >> signer, yes. >> I think the people proposing validation of signatures as an MTI were >> aware that public-keys would be needed to make use of signatures. >> So, I think both RADSEC and SAML signatures have similar requirements >> for public-keys in typical deployments. >> A PKI is one approach for getting these public keys. > Right. In any case you need a key distribution mechanism, PKI or > whatever. To my view, the difference is that in the case of RADSEC you > put the trust fabric on the same AAA infrastructure you are using > through ABFAB, while relying on SAML signatures require a trust > fabric on an ancilliary infrastructure. exactly regards, Gabi. > Be goode, > > -- > "Esta vez no fallaremos, Doctor Infierno" > > Dr Diego R. Lopez > Telefonica I+D > http://people.tid.es/diego.lopez/ > > e-mail: diego@tid.es > Tel: +34 913 129 041 > Mobile: +34 682 051 091 > ----------------------------------------- > > > ________________________________ > > Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx -- ---------------------------------------------------------------- Gabriel L—pez Mill‡n Departamento de IngenierÂ’a de la Informaci—n y las Comunicaciones University of Murcia Spain Tel: +34 868888504 Fax: +34 868884151 email: gabilm@um.es From rafa@um.es Fri Nov 9 04:51:45 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C124D21F8684 for ; Fri, 9 Nov 2012 04:51:45 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z8aG4yb1kyCf for ; Fri, 9 Nov 2012 04:51:45 -0800 (PST) Received: from xenon14.um.es (xenon14.um.es [155.54.212.168]) by ietfa.amsl.com (Postfix) with ESMTP id 5E83421F866D for ; Fri, 9 Nov 2012 04:51:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon14.um.es (Postfix) with ESMTP id 1E3395D52D; Fri, 9 Nov 2012 13:51:38 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon14.um.es Received: from xenon14.um.es ([127.0.0.1]) by localhost (xenon14.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id FtybWMva-HWi; Fri, 9 Nov 2012 13:51:37 +0100 (CET) Received: from inf-205-54.inf.um.es (inf-205-54.inf.um.es [155.54.205.54]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon14.um.es (Postfix) with ESMTPSA id C4D345D4AE; Fri, 9 Nov 2012 13:51:36 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Fri, 9 Nov 2012 13:51:37 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> References: To: Sam Hartman X-Mailer: Apple Mail (2.1283) Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Fri, 09 Nov 2012 12:51:45 -0000 Hi Sam, all: I was wondering what would happen if a current deployment is not using = radsec. Is it not too much restrictive to set MUST for radsec?. (In = fact, as you mention, it is an experimental RFC) I would say that if Radsec is available MUST be used and SAML signature = MAY be used. But if Radsec is not deployed SAML signature MUST be used. Or in general if end-to-end security is deployed SAML signature is not = required. Best regards. P.D: Perhaps, this is what you are trying to say and I misunderstood = your statement. El 08/11/2012, a las 20:42, Sam Hartman escribi=F3: >=20 >=20 > Folks, I've been thinking about the mandatory to implement signature > validation issue. The more I think about it, the more I agree with > stephen and Scott that end-to-end security is important for ABFAB. It > won't always be used; just as with other technologies, people will > sometimes want to introduce middleboxes. However it's important to = have > a way of talking to the ends. >=20 > However, I think SAML signatures are the wrong level to accomplish > thit. > The issue is that there's a lot of important stuff in ABFAB that comes > in AAA not SAML. > All the concerns about SAML can apply to the AAA elements. >=20 > I was asking myself why Moonshot doesn't worry about this. > Then I realized that we do. > we're going out of our way to set up end-to-end RADSEC. > We get protection of the SAML, but we also get protection of the AAA > attributes. >=20 > RADSEC can be used in a hop-by-hop manner. However, RADSEC is = specified > with a lot of thought towards enabling end-to-end uses. Multiple > technologies, including the dynamic SRV-based mechanism and Moonshot's > trust router are evolving to make end-to-end RADSEC easier to deploy. >=20 > So, I think that RADSEC is a better MTI security technology for ABFAB > than signature validation. > I'd prefer to make RADSEC a MUST and SAML signature validation a = SHOULD. >=20 > I've run this by Alan, Josh, Scott and Jim. They seemed to like the > idea, so I'm presenting it here. >=20 > Note that there is a process issue with RADSEC; it's not > standards-track. Let's assume for the moment that I can come up with = a > solution to that (I believe I have two avenues to approach) > do we believe that if we can make it work that would be the right > technical approach? >=20 > --Sam > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From aland@deployingradius.com Fri Nov 9 04:55:46 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86CEB21F885B for ; Fri, 9 Nov 2012 04:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOP3Y8NhzAks for ; Fri, 9 Nov 2012 04:55:45 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7675421F871C for ; Fri, 9 Nov 2012 04:55:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id DFF3D2240A2D; Fri, 9 Nov 2012 13:55:37 +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 SJt+zQi6tFMu; Fri, 9 Nov 2012 13:55:36 +0100 (CET) Received: from dhcp-42af.meeting.ietf.org (dhcp-42af.meeting.ietf.org [130.129.66.175]) by power.freeradius.org (Postfix) with ESMTPSA id 9D30C22402B5; Fri, 9 Nov 2012 13:55:35 +0100 (CET) Message-ID: <509CFD46.8060402@deployingradius.com> Date: Fri, 09 Nov 2012 07:55:34 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Rafa Marin Lopez References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> In-Reply-To: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Fri, 09 Nov 2012 12:55:46 -0000 Rafa Marin Lopez wrote: > I was wondering what would happen if a current deployment is not using radsec. Is it not too much restrictive to set MUST for radsec?. (In fact, as you mention, it is an experimental RFC) My $0.02 is that most RADIUS deployments should be moving to RadSec, or RADIUS over DTLS. The security of the RADIUS protocol requires it. If a new implementation understands SAML, it can do RadSec, too. Alan DeKok. From hartmans@painless-security.com Fri Nov 9 07:24:06 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAD421F855E for ; Fri, 9 Nov 2012 07:24:04 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D457LnXdHEis for ; Fri, 9 Nov 2012 07:24:03 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A53EE21F848D for ; Fri, 9 Nov 2012 07:23:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (dhcp-45e6.meeting.ietf.org [130.129.69.230]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 425C220355; Fri, 9 Nov 2012 10:22:57 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 632AB412A; Fri, 9 Nov 2012 10:23:55 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> <509CFD46.8060402@deployingradius.com> Date: Fri, 09 Nov 2012 10:23:55 -0500 In-Reply-To: <509CFD46.8060402@deployingradius.com> (Alan DeKok's message of "Fri, 09 Nov 2012 07:55:34 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Fri, 09 Nov 2012 15:24:06 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> Rafa Marin Lopez wrote: >> I was wondering what would happen if a current deployment is not >> using radsec. Is it not too much restrictive to set MUST for >> radsec?. (In fact, as you mention, it is an experimental RFC) Alan> My $0.02 is that most RADIUS deployments should be moving to Alan> RadSec, or RADIUS over DTLS. The security of the RADIUS Alan> protocol requires it. The Moonshot implementation of ABFAB has always supported RADSEC. I know that the UM team had an early deployment of AABFAB; I don't know if that supported RADSEC or not. From ietf@augustcellars.com Sun Nov 11 13:52:35 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22B6B21F84DA for ; Sun, 11 Nov 2012 13:52:35 -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 iyxkMFWyDWDX for ; Sun, 11 Nov 2012 13:52:34 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 790A621F84DD for ; Sun, 11 Nov 2012 13:52:34 -0800 (PST) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 237832C9F4; Sun, 11 Nov 2012 13:52:34 -0800 (PST) From: "Jim Schaad" To: Date: Sun, 11 Nov 2012 13:52:25 -0800 Message-ID: <01dd01cdc056$d69a76a0$83cf63e0$@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: Ac290mp9DVTpRKKMSjSSx3TbpP2Iyw== Content-Language: en-us Cc: abfab@ietf.org Subject: [abfab] Review - draft-ietf-abfab-aaa-saml-04 X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 21:52:35 -0000 1. Introduction para #2, Definition of binding is not well stated. I believe a better description would be: "in the SAML architecture, the description of how messages are transported is called a 'binding'." 2. Not immediately clear these are two not one from the text "specific use cases: authentication and assertion query/request." suggest "In addition to the new RADIUS attribute and the RADIUS binding, this document also creates two profiles for their use. The first profile is for the case of ABFAB authentication and the second is for assertion query/request. This is intended to promote interoperability between implementations for these common use cases." 3. Introduction - Summary points - s/An Authentication Profile/An ABFAB Authentication Profile/ 4. Section 4. Title - Look for an be more consistent about the term you are using. I prefer "RADIUS SAML-Message Attribute" to "SAML RADIUS attribute". Consistent name of the topic would be good. 5. Section 4 - I think Scott raised an interesting question in the meeting about the ability for this attribute to be deflated (optionally?) before being sent. This would tend to make the message a lot smaller. One could probably detect the deflation based on the first character in the data field (i.e. '<' vs ???) so no signaling method would be required. 6. Section 5.2 - "RADIUS can be used over multiple underlying transports;" It is unclear to me that this binding really needs to care about what the underlying transport is and why it would need to state what the transport is going to be. I have problems with trying to state what the transport should be because there is no way for the application to be able to control it. 7. Section 5.2 - Item #1 - "MAY transmit a SAML request" there is no MAY here, it just "transmits a SAML request" If it is not transmitting the request is not acting as a SAML requester and is not relevant to the document 8. Section 4.2 - Item #2 - "A SAML requester MUST NOT send a second SAML request element in a subsequent SAML request element." I think this is also an added restriction as well. 9. Section 4.2 - I don't know if this goes here or someplace else, but there may be an issue with an IdP being unable to satisfy the conditions in an AuthzContext request. Would this be returned as a SAML error and failed authentication? Note in this case no EAP would be run by the IdP. 10. Section 6 - last sentence - who is the name identifier being established for? 11. Section 6.2 - Bindings: Eliminate the first sentence and just say that it requires the SAML binding. 12. - Section 6.3.1 - The GSS Initiator not the GSS Acceptor invokes the GSS EAP mechanism. I think the language in this paragraph is being very sloppy about what is happening. 13. Section 6.3.4 - the text starting with "MAY issue" is fuzzy. a) is it may issue or the issued response may be consistent w/ the authentication result? b) the A and B and C at the end of the sentence seems to meander without a point. 14. Section 6.4.1 para #2 - Needs to say that a failure will occur if it either will not or cannot satisfy the request. MUST NOT do an access accept using different criteria than asked for. 15. Section 6.4.2 para #3 - This paragraph actually bothers me for the following reason. It allows an RP to determine if a pseudonymous identifier that is going to be specific to it will be returned or not. (say don't create and then say allow create). It is not clear to me that this is desirable behavior. 16. Section 6.4.2 - last bullet point - This is a partial address of a previous point in this mail. I think this is an incorrect statement. I think that the statement should be, if you return a response, you must have a AuthnStatement that matches the request. If you do not return a response, then you are not bound to obey any of the requested context. This set of rules would allow the RP to determine if the request has been satisfied or not. 17. Section 6.4.3 - Bullet #2 - This implies some type of re-authentication protocol. As we are not having a GSS-EAP based server re-authentication operation, does this need to be clarified here or is the text I am going to put into the architecture document suffice? Jim From gabilm@um.es Mon Nov 12 08:04:22 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB2AA21F8681 for ; Mon, 12 Nov 2012 08:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[AWL=-0.600, 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 dsIfwta2mUtX for ; Mon, 12 Nov 2012 08:04:22 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 1860F21F8669 for ; Mon, 12 Nov 2012 08:04:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id 947925D660; Mon, 12 Nov 2012 17:04:20 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 962WlVBxlYyr; Mon, 12 Nov 2012 17:04:20 +0100 (CET) Received: from [155.54.205.54] (inf-205-54.inf.um.es [155.54.205.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPSA id A6BEE5D65E; Mon, 12 Nov 2012 17:04:17 +0100 (CET) Message-ID: <50A11E01.1080404@um.es> Date: Mon, 12 Nov 2012 17:04:17 +0100 From: Gabriel Lopez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sam Hartman References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> <509CFD46.8060402@deployingradius.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Mon, 12 Nov 2012 16:04:22 -0000 On 09/11/12 16:23, Sam Hartman wrote: >>>>>> "Alan" == Alan DeKok writes: > Alan> Rafa Marin Lopez wrote: > >> I was wondering what would happen if a current deployment is not > >> using radsec. Is it not too much restrictive to set MUST for > >> radsec?. (In fact, as you mention, it is an experimental RFC) > > Alan> My $0.02 is that most RADIUS deployments should be moving to > Alan> RadSec, or RADIUS over DTLS. The security of the RADIUS > Alan> protocol requires it. > > The Moonshot implementation of ABFAB has always supported RADSEC. > > I know that the UM team had an early deployment of AABFAB; I don't know > if that supported RADSEC or not. Actually not, it runs over Radius. Although it is just a matter of implementation. regards, Gabi. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Mon Nov 12 11:33:02 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4EA21F86F3 for ; Mon, 12 Nov 2012 11:33:02 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DzIHRaasNeo for ; Mon, 12 Nov 2012 11:33:02 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id DE0D121F86EC for ; Mon, 12 Nov 2012 11:32:57 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 79DC520155; Mon, 12 Nov 2012 14:31:50 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 62E694132; Mon, 12 Nov 2012 14:32:51 -0500 (EST) From: Sam Hartman To: Gabriel Lopez References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> <509CFD46.8060402@deployingradius.com> <50A11E01.1080404@um.es> Date: Mon, 12 Nov 2012 14:32:51 -0500 In-Reply-To: <50A11E01.1080404@um.es> (Gabriel Lopez's message of "Mon, 12 Nov 2012 17:04:17 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Mon, 12 Nov 2012 19:33:02 -0000 >>>>> "Gabriel" == Gabriel Lopez writes: Gabriel> On 09/11/12 16:23, Sam Hartman wrote: >>>>>>> "Alan" == Alan DeKok writes: Alan> Rafa Marin Lopez wrote: >> >> I was wondering what would happen if a current deployment is >> not >> using radsec. Is it not too much restrictive to set MUST >> for >> radsec?. (In fact, as you mention, it is an experimental >> RFC) >> Alan> My $0.02 is that most RADIUS deployments should be moving to Alan> RadSec, or RADIUS over DTLS. The security of the RADIUS Alan> protocol requires it. >> >> The Moonshot implementation of ABFAB has always supported RADSEC. >> >> I know that the UM team had an early deployment of AABFAB; I >> don't know if that supported RADSEC or not. Gabriel> Actually not, it runs over Radius. Although it is just a Gabriel> matter of implementation. OK, so you would not be concerned about a radsec requirement on behalf of the MU implementation? From gabilm@um.es Tue Nov 13 06:16:10 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87BE21F8676 for ; Tue, 13 Nov 2012 06:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 Y9eKUFrLkaPp for ; Tue, 13 Nov 2012 06:16:10 -0800 (PST) Received: from xenon13.um.es (xenon13.um.es [155.54.212.167]) by ietfa.amsl.com (Postfix) with ESMTP id 0E26021F8651 for ; Tue, 13 Nov 2012 06:16:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon13.um.es (Postfix) with ESMTP id BB20C5D5A1; Tue, 13 Nov 2012 15:16:07 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon13.um.es Received: from xenon13.um.es ([127.0.0.1]) by localhost (xenon13.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id w919KkGyKqbm; Tue, 13 Nov 2012 15:16:07 +0100 (CET) Received: from [155.54.205.54] (inf-205-54.inf.um.es [155.54.205.54]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: gabilm) by xenon13.um.es (Postfix) with ESMTPSA id E7CAE5D52D; Tue, 13 Nov 2012 15:16:03 +0100 (CET) Message-ID: <50A25623.2000807@um.es> Date: Tue, 13 Nov 2012 15:16:03 +0100 From: Gabriel Lopez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Sam Hartman References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> <509CFD46.8060402@deployingradius.com> <50A11E01.1080404@um.es> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Tue, 13 Nov 2012 14:16:11 -0000 On 12/11/12 20:32, Sam Hartman wrote: > >> The Moonshot implementation of ABFAB has always supported RADSEC. > >> >> I know that the UM team had an early deployment of AABFAB; I >> > don't know if that supported RADSEC or not. Gabriel> Actually not, it > runs over Radius. Although it is just a Gabriel> matter of > implementation. OK, so you would not be concerned about a radsec > requirement on behalf of the MU implementation? The original UM implementation of GSS-EAP is deprecated, we are currently working with the GSS-EAP moonshot implementation. My concern is about to define RadSec mandatory for those institutions willing to deploy abfab. Let's suppose eduroam, institution A is requesting authentication to institution B, where A is abfab-aware, and B is a tipical eduroam member. Let's suppose: a) Authorization (SAML) is not required --> A and B are able to authenticate the user directly, without any modification in B side. End-to-end authentication is not possible b) Authorization (SAML) is required and B is running a SAML-idP (i.e. Shibboleth) --> minimum modification at B side (radius server requesting SAML attributes to idP). End-to-end authentication is possible by means of SAML signature. c) Authorization (SAML) is required and B is not SAML-aware --> B has to deploy current abfab solution. Easy to deploy. End-to-end authentication is possible by means of SAML signature. Why does abfab have to force institution B to deploy RadSec too?. As sent before, we strongly agree to make use of radsec, when possible. In any case, if WG members agree on that maybe I am missing/misunderstanding something regards, Gabi. From hartmans@painless-security.com Tue Nov 13 06:20:18 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF2FF21F846F for ; Tue, 13 Nov 2012 06:20:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnrdSvl71qYC for ; Tue, 13 Nov 2012 06:20:18 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id EAD8021F8450 for ; Tue, 13 Nov 2012 06:20:17 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 805C520161; Tue, 13 Nov 2012 09:19:08 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 775C54132; Tue, 13 Nov 2012 09:20:09 -0500 (EST) From: Sam Hartman To: Gabriel Lopez References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> <509CFD46.8060402@deployingradius.com> <50A11E01.1080404@um.es> <50A25623.2000807@um.es> Date: Tue, 13 Nov 2012 09:20:09 -0500 In-Reply-To: <50A25623.2000807@um.es> (Gabriel Lopez's message of "Tue, 13 Nov 2012 15:16:03 +0100") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Tue, 13 Nov 2012 14:20:18 -0000 >>>>> "Gabriel" == Gabriel Lopez writes: Gabriel> My concern is about to define RadSec mandatory for those Gabriel> institutions willing to deploy abfab. Let's suppose Gabriel> eduroam, institution A is requesting authentication to Gabriel> institution B, where A is abfab-aware, and B is a tipical Gabriel> eduroam member. Let's suppose: Ah! The IETF rarely if ever specifies what security technology you must use or deploy and I'm not proposing doing that in this case. I'm proposing that implementations of draft-ietf-abfab-aaa-saml--that is software implementing that spec--MUST be capable of using RADSEC. Whether you turn on RADSEC is up to whomever deploys the code. I absolutely agree with you that requiring people to use RADSEC in all ABFAB deployments would be inappropriate for the IETF to do. From rafa@um.es Tue Nov 13 07:14:18 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45F9921F86AA for ; Tue, 13 Nov 2012 07:14:18 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsnMJQKg+7dL for ; Tue, 13 Nov 2012 07:14:17 -0800 (PST) Received: from xenon11.um.es (xenon11.um.es [155.54.212.165]) by ietfa.amsl.com (Postfix) with ESMTP id 307C721F86A9 for ; Tue, 13 Nov 2012 07:14:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon11.um.es (Postfix) with ESMTP id 1C86853618; Tue, 13 Nov 2012 16:14:14 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon11.um.es Received: from xenon11.um.es ([127.0.0.1]) by localhost (xenon11.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PQ7RrgN-jn2x; Tue, 13 Nov 2012 16:14:09 +0100 (CET) Received: from inf-205-226.inf.um.es (inf-205-226.inf.um.es [155.54.205.226]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: rafa) by xenon11.um.es (Postfix) with ESMTPSA id C9C8B53614; Tue, 13 Nov 2012 16:14:08 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Rafa Marin Lopez In-Reply-To: Date: Tue, 13 Nov 2012 16:14:07 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <110F4034-6D7D-4A41-8482-01231B5ED867@um.es> References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> <509CFD46.8060402@deployingradius.com> <50A11E01.1080404@um.es> <50A25623.2000807@um.es> To: Sam Hartman X-Mailer: Apple Mail (2.1283) Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Tue, 13 Nov 2012 15:14:18 -0000 Hi Sam: In such a case, it sounds reasonable. No concern, at least, from my = side. Best regards. El 13/11/2012, a las 15:20, Sam Hartman escribi=F3: >>>>>> "Gabriel" =3D=3D Gabriel Lopez writes: >=20 >=20 > Gabriel> My concern is about to define RadSec mandatory for those > Gabriel> institutions willing to deploy abfab. Let's suppose > Gabriel> eduroam, institution A is requesting authentication to > Gabriel> institution B, where A is abfab-aware, and B is a tipical > Gabriel> eduroam member. Let's suppose: >=20 > Ah! The IETF rarely if ever specifies what security technology you = must > use or deploy and I'm not proposing doing that in this case. I'm > proposing that implementations of draft-ietf-abfab-aaa-saml--that is > software implementing that spec--MUST be capable of using RADSEC. > Whether you turn on RADSEC is up to whomever deploys the code. >=20 > I absolutely agree with you that requiring people to use RADSEC in all > ABFAB deployments would be inappropriate for the IETF to do. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab ------------------------------------------------------- Rafael Marin Lopez, PhD Dept. Information and Communications Engineering (DIIC) Faculty of Computer Science-University of Murcia 30100 Murcia - Spain Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es ------------------------------------------------------- From gabilm@um.es Tue Nov 13 08:40:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E7CD21F8476 for ; Tue, 13 Nov 2012 08:40:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.399 X-Spam-Level: X-Spam-Status: No, score=-5.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 RfRUC+aiXjJt for ; Tue, 13 Nov 2012 08:40:30 -0800 (PST) Received: from xenon12.um.es (xenon12.um.es [155.54.212.166]) by ietfa.amsl.com (Postfix) with ESMTP id E92D621F8475 for ; Tue, 13 Nov 2012 08:40:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon12.um.es (Postfix) with ESMTP id 8BC504BEAC; Tue, 13 Nov 2012 17:40:27 +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 SG-nDe6ORJPw; Tue, 13 Nov 2012 17:40:27 +0100 (CET) Received: from [155.54.205.54] (inf-205-54.inf.um.es [155.54.205.54]) (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 D52CB4BEA0; Tue, 13 Nov 2012 17:40:25 +0100 (CET) Message-ID: <50A277F9.8080602@um.es> Date: Tue, 13 Nov 2012 17:40:25 +0100 From: Gabriel Lopez User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121028 Thunderbird/16.0.2 MIME-Version: 1.0 To: Rafa Marin Lopez References: <5854464C-3CAD-4F03-861B-8F802136CEAA@um.es> <509CFD46.8060402@deployingradius.com> <50A11E01.1080404@um.es> <50A25623.2000807@um.es> <110F4034-6D7D-4A41-8482-01231B5ED867@um.es> In-Reply-To: <110F4034-6D7D-4A41-8482-01231B5ED867@um.es> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: abfab@ietf.org Subject: Re: [abfab] Proposal: mandatory radsec for draft-ietf-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: Tue, 13 Nov 2012 16:40:31 -0000 On 13/11/12 16:14, Rafa Marin Lopez wrote: > Hi Sam: > > In such a case, it sounds reasonable. No concern, at least, from my side. I agree. > > Best regards. > > El 13/11/2012, a las 15:20, Sam Hartman escribió: > >>>>>>> "Gabriel" == Gabriel Lopez writes: >> >> Gabriel> My concern is about to define RadSec mandatory for those >> Gabriel> institutions willing to deploy abfab. Let's suppose >> Gabriel> eduroam, institution A is requesting authentication to >> Gabriel> institution B, where A is abfab-aware, and B is a tipical >> Gabriel> eduroam member. Let's suppose: >> >> Ah! The IETF rarely if ever specifies what security technology you must >> use or deploy and I'm not proposing doing that in this case. I'm >> proposing that implementations of draft-ietf-abfab-aaa-saml--that is >> software implementing that spec--MUST be capable of using RADSEC. >> Whether you turn on RADSEC is up to whomever deploys the code. >> >> I absolutely agree with you that requiring people to use RADSEC in all >> ABFAB deployments would be inappropriate for the IETF to do. >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > ------------------------------------------------------- > Rafael Marin Lopez, PhD > Dept. Information and Communications Engineering (DIIC) > Faculty of Computer Science-University of Murcia > 30100 Murcia - Spain > Telf: +34868888501 Fax: +34868884151 e-mail: rafa@um.es > ------------------------------------------------------- > > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From alper.yegin@yegin.org Wed Nov 14 04:12:28 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2781121F84E1 for ; Wed, 14 Nov 2012 04:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=0.301, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 QyhOMg-sYu2l for ; Wed, 14 Nov 2012 04:12:21 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3BD21F84DE for ; Wed, 14 Nov 2012 04:12:21 -0800 (PST) Received: from [10.119.24.8] (prod09.i.lon.fullmeshnetworks.com [193.104.113.37]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0M6SyR-1TMiuC28z5-00ySOd; Wed, 14 Nov 2012 07:12:11 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <5087956D.3020205@toshiba.co.jp> Date: Wed, 14 Nov 2012 14:12:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> References: <5087956D.3020205@toshiba.co.jp> To: Yoshihiro Ohba X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:jGWf1OkR5yDV7dG61+OSm6SHScfXky4GCisILj8gSbx UE8+UzPmMcIM2ddWvdiCrmHn/sdZUWiLXdvPWkdOyvJh6/dl4Q fADuk5FflkgBUV+KCRkGEf28Io2uEJbJH3IKjKZmvUhUou3Iwu WEUIj6+rg6b3S7tlqix2v3MiRll2z91/HyCwD7Dn0sfEorSNS9 cK5beS+8XEegEZ9WwXoFROojJTWx5snZJbATrBCODfNSOH5E8P OJyebELBLOfsemeay3nAyUtdcJRnGi+2gkzsJs9TXhBpK8KE7K mcfRooUiqNeLfEf6aesGjfIW0ibWRlvO4IZV0SbWI+9gGoduDU UMZc2SVLELQ+1Cab2hth2dJWh23y3qQwTMT3ZQ1Q0zTACM8psv E/REVW4B/aI6A== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication 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, 14 Nov 2012 12:12:28 -0000 Furthermore, as we discussed in PCP WG there's another problem. Sam is proposing to decouple EAP security association management from = the application state. More specifically, even after the EAP session is release/timed out, = application may still be in use. What that means is, if the server has an application message that is = pending to be transmitted to the client, and if at that time there's no = security association available (see above), then the server needs to = initiate re-authentication in order to re-generate a security = association and send the app message securely. In PCP WG meeting Sam claimed he can design a solution to this problem, = and committed to sending a straw man solution.=20 I just want to make ABFAB people aware of this issue, and indicate that = we are looking forward to seeing Sam's solution proposal. Cheers, Alper On Oct 24, 2012, at 10:14 AM, Yoshihiro Ohba wrote: > RFC 5247 discusses EAP re-authentication in several sections. >=20 > Here is one part: >=20 > " > Where TSKs are derived from or are wrapped by exported EAP keying > material, compromise of that exported EAP keying material implies > compromise of TSKs. Therefore, if EAP keying material is considered > stale, not only SHOULD EAP re-authentication be initiated, but also > replacement of child keys, including TSKs. > " >=20 > Since EAP keying material can be considered stale by either peer or = authenticator, it makes sense to support both peer-initiated and = authenticator-initiated re-authentication. If an application protocol = has a design restriction that prevents from suppporting = authenticator-initiated re-authentication, then it is better to let each = application specification have some text in their Security = Considerations section to assess potential impact on the application due = to lack of the functionality. >=20 > Having said that I don't agree with having text like "applications MAY = support server-initiated re-authentication" in EAP applicability = statement. What we sould have in EAP applicability statement is that = the key management framework described in RFC 5247 is applicable to both = network access and application usage of EAP. >=20 > Regards, > Yoshihiro Ohba >=20 >=20 > (2012/10/19 22:41), Sam Hartman wrote: >> Second issue relates to EAP requirements surrounding server-initiated >> re-authentication. We've had one claim that EAP lower layers MUST >> support re-authentication initiated by the server. >>=20 >> If that's true, we have kind of a big problem with GSS-EAP. >>=20 >> As best I can tell though that's not true. RFC 3748 doesn't really = talk >> about server-initiated re-authentication. The RADIUS EAP support >> doesn't seem to support it, and the COA informational RFC explicitly >> says it cannot be used for re-authentication. The Diameter EAP >> application says that if the lower layer supports EAP = re-authentication >> then the Diameter NAS MUST support re-authentication as well. >> I have looked up citations for the above in a PCP discussion and am >> happy to dig that all up if they would help anyone here. >>=20 >> As best I can tell, the motivation for re-authentication is an >> interesting different between network access and application >> authentication. In network access, there is a significant disruption = if >> your connection drops and you have to re-authenticate before you can >> send your next packet. >> It's strongly desirable to re-authenticate before your lifetime = expires. >> (This doesn't speak to server-initiated re-auth, I realize) >>=20 >> Some applications work like that. >> However there are a lot of applications where the server can close = the >> connection and when the client wants to do the next thing, it will >> re-authenticate at that time. >> For example with SMTP, it's not going to be a big deal if the next = time >> I want to send mail it takes a bit longer because my server has = closed a >> connection to force me to reauthenticate. >>=20 >> My recommendation is that the applicability statement should discuss >> the issue of re-authentication. We should recommend that applications >> that will be disrupted by authentication expiration have a = mechanism >> to re-authenticate while the existing authentication is still live. >>=20 >> I think we need to say very little about server-initiated >> re-authentication. I think we should say that applications MAY = support >> server-initiated re-authentication. If they do, then the server can = send >> authentication packets at any time. >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >>=20 >=20 > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Wed Nov 14 06:07:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5761E21F8521 for ; Wed, 14 Nov 2012 06:07:23 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcz73vbChyR5 for ; Wed, 14 Nov 2012 06:07:22 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C597421F853A for ; Wed, 14 Nov 2012 06:07:22 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id BB2FE20178; Wed, 14 Nov 2012 09:06:11 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 067144132; Wed, 14 Nov 2012 09:07:19 -0500 (EST) From: Sam Hartman To: Alper Yegin References: <5087956D.3020205@toshiba.co.jp> <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> Date: Wed, 14 Nov 2012 09:07:18 -0500 In-Reply-To: <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> (Alper Yegin's message of "Wed, 14 Nov 2012 14:12:05 +0200") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication 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, 14 Nov 2012 14:07:23 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Furthermore, as we discussed in PCP WG there's another Alper> problem. Sam is proposing to decouple EAP security Alper> association management from the application state. More Alper> specifically, even after the EAP session is release/timed Alper> out, application may still be in use. What that means is, if Alper> the server has an application message that is pending to be Alper> transmitted to the client, and if at that time there's no Alper> security association available (see above), then the server Alper> needs to initiate re-authentication in order to re-generate a Alper> security association and send the app message securely. Hmm, that's not how I'd think about this at all. I'd describe it as follows. In a peer-to-peer protocol, you sometimes have messages you'd like to send to peers for which you have no security state. In that case you can either: 1) send an insecure message 2) establish security state. The question of whether you previously had state with a peer seems a needless complication. Regardless, I don't think this issue has much to do with the EAP applicability statement. Similar issues show up all over the place with SIP, XMPP, etc. --Sam From aland@deployingradius.com Wed Nov 14 07:09:00 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B72321F85A2 for ; Wed, 14 Nov 2012 07:09:00 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2J-Fa5ZwfESK for ; Wed, 14 Nov 2012 07:08:59 -0800 (PST) Received: from power.freeradius.org (power.freeradius.org [88.190.25.44]) by ietfa.amsl.com (Postfix) with ESMTP id 923C221F85FD for ; Wed, 14 Nov 2012 07:08:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by power.freeradius.org (Postfix) with ESMTP id 179752240860; Wed, 14 Nov 2012 16:08:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at power.freeradius.org Received: from power.freeradius.org ([127.0.0.1]) by localhost (power.freeradius.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yon4zoLQt148; Wed, 14 Nov 2012 16:07:55 +0100 (CET) Received: from Thor-2.local (206-47-94-208.dsl.ncf.ca [206.47.94.208]) by power.freeradius.org (Postfix) with ESMTPSA id 5DE0C2240689; Wed, 14 Nov 2012 16:07:55 +0100 (CET) Message-ID: <50A3B3CA.4090307@deployingradius.com> Date: Wed, 14 Nov 2012 10:07:54 -0500 From: Alan DeKok User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: Alper Yegin References: <5087956D.3020205@toshiba.co.jp> <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> In-Reply-To: <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication 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, 14 Nov 2012 15:09:00 -0000 Alper Yegin wrote: > Sam is proposing to decouple EAP security association management from the application state. > More specifically, even after the EAP session is release/timed out, application may still be in use. > What that means is, if the server has an application message that is pending to be transmitted to the client, and if at that time there's no security association available (see above), then the server needs to initiate re-authentication in order to re-generate a security association and send the app message securely. This is what's done today for 802.1X authentication. Both wired && wireless. The solution is to re-establish authentication before sending another application message. The hard part about 802.1X is that the application doesn't know there's an underlying security association. All it knows is that the network went away for a bit, and then came back. For PCP, it's reasonable that the application knows the EAP session has timed out. It can re-establish it before sending the next message. Or, if messages are rare, it can wait and re-establish it later. Alan DeKok. From hartmans@painless-security.com Wed Nov 14 07:44:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFEC21F85E7 for ; Wed, 14 Nov 2012 07:44:15 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvIcaV3aopHh for ; Wed, 14 Nov 2012 07:44:15 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17021F857D for ; Wed, 14 Nov 2012 07:44:15 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 82C0320178; Wed, 14 Nov 2012 10:43:04 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 4CADF4132; Wed, 14 Nov 2012 10:44:12 -0500 (EST) From: Sam Hartman To: Alan DeKok References: <5087956D.3020205@toshiba.co.jp> <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> <50A3B3CA.4090307@deployingradius.com> Date: Wed, 14 Nov 2012 10:44:12 -0500 In-Reply-To: <50A3B3CA.4090307@deployingradius.com> (Alan DeKok's message of "Wed, 14 Nov 2012 10:07:54 -0500") Message-ID: User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication 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, 14 Nov 2012 15:44:15 -0000 >>>>> "Alan" == Alan DeKok writes: Alan> For PCP, it's reasonable that the application knows the EAP Alan> session has timed out. It can re-establish it before sending Alan> the next message. Or, if messages are rare, it can wait and Alan> re-establish it later. Well, it's a bit tricky to re-establish the session if the next message is coming from the server but only the client can start the authentication. I think you have two general options: 1) Decide it's OK not to re-establish the session until the client wants to do so 2) Change things and let the server start an EAP session. 3) Require the client to start an EAP session whenever the old session goes away. The details as they apply to PCP are best discussed on that list. From hartmans@painless-security.com Wed Nov 14 11:37:25 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6BE21F8769 for ; Wed, 14 Nov 2012 11:37: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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqBjzqQoUIby for ; Wed, 14 Nov 2012 11:37:24 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id B070321F8721 for ; Wed, 14 Nov 2012 11:37:24 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 81B6420178 for ; Wed, 14 Nov 2012 14:36:13 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id EEA284132; Wed, 14 Nov 2012 14:37:20 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Wed, 14 Nov 2012 14:37:20 -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] Retransmission Text for EAP applicability 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, 14 Nov 2012 19:37:25 -0000 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 process EAP messages at any time during the authentication conversation. Alternatively, EAP permits a lower layer to set the retransmission timer to infinite. In this case, the lower layer is 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. 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 an EAP method discarding a message, 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 and waiting for additional EAP input, possibly after an EAP retransmit. Specifications of how EAP is used for application authentication SHOULD document how retransmission and message discards are handled. From internet-drafts@ietf.org Wed Nov 14 12:43:09 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7A21F88A8; Wed, 14 Nov 2012 12:43:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.355 X-Spam-Level: X-Spam-Status: No, score=-102.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zAKkWKQVXDtE; Wed, 14 Nov 2012 12:43:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F3F21F8877; Wed, 14 Nov 2012 12:43:08 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121114204308.14210.66976.idtracker@ietfa.amsl.com> Date: Wed, 14 Nov 2012 12:43:08 -0800 Cc: abfab@ietf.org Subject: [abfab] I-D Action: draft-ietf-abfab-gss-eap-naming-07.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, 14 Nov 2012 20:43:09 -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 : Name Attributes for the GSS-API EAP mechanism Author(s) : Sam Hartman Josh Howlett Filename : draft-ietf-abfab-gss-eap-naming-07.txt Pages : 17 Date : 2012-11-14 Abstract: The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-abfab-gss-eap-naming-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-abfab-gss-eap-naming-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Nov 15 08:07:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CC821F857C; Thu, 15 Nov 2012 08:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.548 X-Spam-Level: X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 uCE--vvKmh6z; Thu, 15 Nov 2012 08:07:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBFBB21F895A; Thu, 15 Nov 2012 08:07:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.36 Message-ID: <20121115160725.25577.45891.idtracker@ietfa.amsl.com> Date: Thu, 15 Nov 2012 08:07:25 -0800 Cc: abfab mailing list , abfab chair , RFC Editor Subject: [abfab] Protocol Action: 'Name Attributes for the GSS-API EAP mechanism' to Proposed Standard (draft-ietf-abfab-gss-eap-naming-07.txt) X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 16:07:26 -0000 The IESG has approved the following document: - 'Name Attributes for the GSS-API EAP mechanism' (draft-ietf-abfab-gss-eap-naming-07.txt) as Proposed Standard This document is the product of the Application Bridging for Federated Access Beyond web Working Group. The IESG contact persons are Stephen Farrell and Sean Turner. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-abfab-gss-eap-naming/ Technical Summary The naming extensions to the Generic Security Services Application Programming interface provide a mechanism for applications to discover authorization and personalization information associated with GSS-API names. The Extensible Authentication Protocol GSS-API mechanism allows an Authentication/Authorization/Accounting peer to provide authorization attributes along side an authentication response. It also provides mechanisms to process Security Assertion Markup Language (SAML) messages provided in the AAA response. This document describes the necessary information to use the naming extensions API to access that information. Working Group Summary There was nothing particularly rough about the consensus. All contentious points were resolved amiably. Document Quality The protocol is in use in the Moonshot project. Jim Schaad provided a very thorough review that resulted in a number of changes to the document. The document was also socialized in Kitten. Personnel Klaas Wierenga is the document shepherd Stephen Farrell is the irresponsible AD From ietf@augustcellars.com Thu Nov 15 10:03:48 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A9D021F8471 for ; Thu, 15 Nov 2012 10:03:48 -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 cejLoFJLWM8i for ; Thu, 15 Nov 2012 10:03:47 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id BF4E621F84F9 for ; Thu, 15 Nov 2012 10:03:46 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 45BF838F3B; Thu, 15 Nov 2012 10:03:46 -0800 (PST) From: "Jim Schaad" To: "'Sam Hartman'" , References: In-Reply-To: Date: Thu, 15 Nov 2012 10:03:38 -0800 Message-ID: <002e01cdc35b$8a2cbb40$9e8631c0$@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: AQGdaosVfWMHHUVVoB9yMppCMQxOPZhLzn9Q Content-Language: en-us Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 18:03:48 -0000 Some small edits that you might want to consider. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Sam Hartman > Sent: Wednesday, November 14, 2012 11:37 AM > To: abfab@ietf.org > Subject: [abfab] Retransmission Text for EAP applicability > > > In EAP, the authenticator is responsible for retransmission. By default EAP > assumes that the lower layer (the application in this context) is unreliable. s/lower layer/lower layer transport/ > The authenticator can send a packet whenever its retransmission timer s/The authenticator can send/To deal with this, the authenticator resends/ > triggers. In this mode, applications need to process EAP messages at any time s/need to process/need to be able to receive and process/ > during the authentication conversation. > > Alternatively, EAP permits a lower layer to set the retransmission timer to > infinite. In this case, the lower layer is responsible for reliable delivery of EAP s/In this case/When this happens/ s/layer is/layer becomes/ > 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. 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 an EAP method discarding a message, 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 and waiting for additional EAP input, possibly after an s/level/level, requesting an EAP retransmit/ > EAP retransmit. > > Specifications of how EAP is used for application authentication SHOULD > document how retransmission and message discards are handled. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From yoshihiro.ohba@toshiba.co.jp Thu Nov 15 11:58:39 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0643C21F8467 for ; Thu, 15 Nov 2012 11:58:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.089 X-Spam-Level: X-Spam-Status: No, score=-5.089 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 KNXh1qKoDlzI for ; Thu, 15 Nov 2012 11:58:38 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 51ED121F8430 for ; Thu, 15 Nov 2012 11:58:37 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qAFJwaQF019608 for ; Fri, 16 Nov 2012 04:58:36 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qAFJwasc006755 for abfab@ietf.org; Fri, 16 Nov 2012 04:58:36 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id EAA06754; Fri, 16 Nov 2012 04:58:36 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qAFJwaBN002348 for ; Fri, 16 Nov 2012 04:58:36 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qAFJwaAR012693; Fri, 16 Nov 2012 04:58:36 +0900 (JST) Received: from [133.199.16.233] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MDJ0086LOTA6QB0@mail.po.toshiba.co.jp> for abfab@ietf.org; Fri, 16 Nov 2012 04:58:36 +0900 (JST) Date: Fri, 16 Nov 2012 04:58:26 +0900 From: Yoshihiro Ohba In-reply-to: To: abfab@ietf.org Message-id: <50A54962.7000501@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 19:58:39 -0000 Sam, The provided text looks good, except that the text is generally applicable to any EAP lower-layer inclucing applications. Said that my suggestion is to replace "application" with "lower-layer". Thanks, Yoshihiro Ohba (2012/11/15 4:37), Sam Hartman wrote: > 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 > process EAP messages at any time during the authentication conversation. > > Alternatively, EAP permits a lower layer to set the retransmission timer > to infinite. In this case, the lower layer is 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. 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 an EAP method discarding a message, > 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 and waiting for > additional EAP input, possibly after an EAP retransmit. > > Specifications of how EAP is used for application authentication SHOULD > document how retransmission and message discards are handled. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab > From hartmans@painless-security.com Thu Nov 15 14:15:38 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6431621F89AC for ; Thu, 15 Nov 2012 14:15:38 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEUJ3t1vGbSW for ; Thu, 15 Nov 2012 14:15:37 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id C9BAA21F8993 for ; Thu, 15 Nov 2012 14:15:37 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 05CF420200; Thu, 15 Nov 2012 17:14:24 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id E7F4F4149; Thu, 15 Nov 2012 17:15:31 -0500 (EST) From: Sam Hartman To: Yoshihiro Ohba References: <50A54962.7000501@toshiba.co.jp> Date: Thu, 15 Nov 2012 17:15:31 -0500 In-Reply-To: <50A54962.7000501@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 16 Nov 2012 04:58:26 +0900") 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] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:15:38 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: Yoshihiro> Sam, The provided text looks good, except that the text Yoshihiro> is generally applicable to any EAP lower-layer inclucing Yoshihiro> applications. Said that my suggestion is to replace Yoshihiro> "application" with "lower-layer". I'm really pleased when I hear that you're happy with this direction. I tried hard to capture the points you made and I'm glad we're quite close. I actually think this advice is rather application specific. I'd say the same thing for a network access lower layer but my emphasis would be different. Also, I think giving general lower layer advice in this document is inappropriate. For those reasons, I'd be happier if we did not make that substitution. I support all of Jim's proposed edits. From yoshihiro.ohba@toshiba.co.jp Thu Nov 15 15:43:31 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 197BE1F0C72 for ; Thu, 15 Nov 2012 15:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.889 X-Spam-Level: X-Spam-Status: No, score=-4.889 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 EvucbkBk7BSL for ; Thu, 15 Nov 2012 15:43:30 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFC71F0C6E for ; Thu, 15 Nov 2012 15:43:29 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qAFNhS1L007344; Fri, 16 Nov 2012 08:43:28 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qAFNhSCS016875; Fri, 16 Nov 2012 08:43:28 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA16874; Fri, 16 Nov 2012 08:43:28 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qAFNhRUk001293; Fri, 16 Nov 2012 08:43:27 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qAFNhROG005774; Fri, 16 Nov 2012 08:43:27 +0900 (JST) Received: from [133.199.16.211] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MDJ008QLZ8D6PC0@mail.po.toshiba.co.jp>; Fri, 16 Nov 2012 08:43:27 +0900 (JST) Date: Fri, 16 Nov 2012 08:43:29 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <50A57E21.10303@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50A54962.7000501@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 23:43:31 -0000 Sam and all, (2012/11/16 7:15), Sam Hartman wrote: >>>>>> "Yoshihiro" == Yoshihiro Ohba writes: > Yoshihiro> Sam, The provided text looks good, except that the text > Yoshihiro> is generally applicable to any EAP lower-layer inclucing > Yoshihiro> applications. Said that my suggestion is to replace > Yoshihiro> "application" with "lower-layer". > > I'm really pleased when I hear that you're happy with this direction. I > tried hard to capture the points you made and I'm glad > we're quite close. > > I actually think this advice is rather application specific. Why do you think so? > I'd say the same thing for a network access lower layer but my emphasis > would be different. > Also, I think giving general lower layer advice in this document is > inappropriate. I can understand this is a scope issue, but general readers of this document would view the text in the same way as I did, because I believe it is a technical fact regardless of the scope of the document. I would like to hear from you and others whether my point is valid, and if my point is valid what the best way to capture my point would be. Regards, Yoshihiro Ohba > > For those reasons, I'd be happier if we did not make that substitution. > I support all of Jim's proposed edits. > From hartmans@painless-security.com Thu Nov 15 16:13:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3627421F8623 for ; Thu, 15 Nov 2012 16:13:54 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLm3EIHiNq4j for ; Thu, 15 Nov 2012 16:13:53 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 92FF121F84B6 for ; Thu, 15 Nov 2012 16:13:53 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 01C5B20200; Thu, 15 Nov 2012 19:12:39 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 3D5BE4149; Thu, 15 Nov 2012 19:13:48 -0500 (EST) From: Sam Hartman To: Yoshihiro Ohba References: <50A54962.7000501@toshiba.co.jp> <50A57E21.10303@toshiba.co.jp> Date: Thu, 15 Nov 2012 19:13:48 -0500 In-Reply-To: <50A57E21.10303@toshiba.co.jp> (Yoshihiro Ohba's message of "Fri, 16 Nov 2012 08:43:29 +0900") 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] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 00:13:54 -0000 >>>>> "Yoshihiro" == Yoshihiro Ohba writes: In something more general I would de-emphasize the case where the lower layer is reliable although still discuss it. I would not talk about lock-step or client-driven authentication at all. The examples I use and the emphasis would also be slightly different for the discard case. From ietf@augustcellars.com Thu Nov 15 17:05:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1031521F862D for ; Thu, 15 Nov 2012 17:05:14 -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 L+vsQ5dBtwsI for ; Thu, 15 Nov 2012 17:05:13 -0800 (PST) Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by ietfa.amsl.com (Postfix) with ESMTP id 892C421F8617 for ; Thu, 15 Nov 2012 17:05:13 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp1.pacifier.net (Postfix) with ESMTPSA id 3AC3C2CA24; Thu, 15 Nov 2012 17:05:12 -0800 (PST) From: "Jim Schaad" To: "'Yoshihiro Ohba'" , "'Sam Hartman'" References: <50A54962.7000501@toshiba.co.jp> <50A57E21.10303@toshiba.co.jp> In-Reply-To: <50A57E21.10303@toshiba.co.jp> Date: Thu, 15 Nov 2012 17:05:03 -0800 Message-ID: <006801cdc396$6ab9bac0$402d3040$@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: AQGdaosVfWMHHUVVoB9yMppCMQxOPQIaS9yIArA2Q00B6G4JbJgWvvBA Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 01:05:14 -0000 I think that the scope issue itself is an overwhelming argument not to replace application with lower-layer. Personally, I would have to think long and hard about given exactly the same advice to an arbitrary lower-layer protocol as oppose to given the advice to anyone who is writing an application protocol that is designed to work with the ABFAB (GSS-EAP) specific authentication profile. In the ABFAB case we are explicitly stating that these are requirements we are dumping on the application protocol and not keeping for the GSS-EAP lower-level protocol. Changing the term from application to lower-level would change the focus of the advice from what an application needs to do to a problem that we now need to figure out how to solve in ABFAB which we really do not want to do. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Yoshihiro Ohba > Sent: Thursday, November 15, 2012 3:43 PM > To: Sam Hartman > Cc: abfab@ietf.org > Subject: Re: [abfab] Retransmission Text for EAP applicability > > Sam and all, > > (2012/11/16 7:15), Sam Hartman wrote: > >>>>>> "Yoshihiro" == Yoshihiro Ohba > writes: > > Yoshihiro> Sam, The provided text looks good, except that the text > > Yoshihiro> is generally applicable to any EAP lower-layer inclucing > > Yoshihiro> applications. Said that my suggestion is to replace > > Yoshihiro> "application" with "lower-layer". > > > > I'm really pleased when I hear that you're happy with this direction. I > > tried hard to capture the points you made and I'm glad > > we're quite close. > > > > I actually think this advice is rather application specific. > > Why do you think so? > > > I'd say the same thing for a network access lower layer but my > > emphasis would be different. > > Also, I think giving general lower layer advice in this document is > > inappropriate. > > I can understand this is a scope issue, but general readers of this document > would view the text in the same way as I did, because I believe it is a > technical fact regardless of the scope of the document. I would like to hear > from you and others whether my point is valid, and if my point is valid what > the best way to capture my point would be. > > Regards, > Yoshihiro Ohba > > > > > > For those reasons, I'd be happier if we did not make that substitution. > > I support all of Jim's proposed edits. > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From alper.yegin@yegin.org Fri Nov 16 13:46:14 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B349721F8B06 for ; Fri, 16 Nov 2012 13:46:14 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Nb+Klguq+ET for ; Fri, 16 Nov 2012 13:46:13 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4F21721F8A71 for ; Fri, 16 Nov 2012 13:46:13 -0800 (PST) Received: from [10.119.24.8] (178-32-60-104.ovh.net [178.32.60.104]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M6B3i-1TNr411u8I-00yIpv; Fri, 16 Nov 2012 16:46:12 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <002e01cdc35b$8a2cbb40$9e8631c0$@augustcellars.com> Date: Fri, 16 Nov 2012 23:46:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <682CE44A-4C9A-49DF-BC14-DE20228BF39C@yegin.org> References: <002e01cdc35b$8a2cbb40$9e8631c0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:EjIKzxcbm9S/ihB2JRKRWuRVOg0uHjyT3mJK+acfE9y tFTSkPjTDyBSEvajpwsDk9/KDyAyAOJFpB8jBJ5g04QQDsqG2o z66LOUn23bZVygh8Nua3upZ2wTGN1kgNTXtHCgySiHuYQNoe5z riaXG56yWleCtlC/iCnqEcPlMWiv3F9O5oyWwpbEffNIZSHL80 hLGX0E8TTxROBRUVhL0JGdqHRefHrLlrHzpMi4MjJXhzzIXng1 dKodNM/8WyS8Tmx7R7wp/8dYfNEr1RjasbACDNYJma6ieU9+EH CIT4uxhAD+P+7Pj4Mzi5GDEOcu9ZCas6hhkZIV2lVaiwSzLGGA nJ9FLflh3Nlv3lsUgpTUHOEN5DLmQg4Zyyan+/2Kuc8RB9ajmU CieUReaRQNIFw== Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:46:14 -0000 >> In EAP, the authenticator is responsible for retransmission. By = default > EAP >> assumes that the lower layer (the application in this context) is > unreliable. > s/lower layer/lower layer transport/ "EAP lower layer" is a term defined in RFC 3748. I believe the text = intends to refer to that. So, we better stick with the precise term. =20 From alper.yegin@yegin.org Fri Nov 16 13:56:16 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFE5B21F8AE7 for ; Fri, 16 Nov 2012 13:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 mFBymO661Mp4 for ; Fri, 16 Nov 2012 13:56:15 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 6FF2C21F88C3 for ; Fri, 16 Nov 2012 13:56:15 -0800 (PST) Received: from [10.119.24.8] (178-32-60-104.ovh.net [178.32.60.104]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0MWlJj-1Tod5F45hT-00XxHW; Fri, 16 Nov 2012 16:56:13 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Fri, 16 Nov 2012 23:56:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> References: To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:Z69I+sU+cy+R3xoBT/JlvQJvLcvKuFM/yB9sYzpd3J4 e4SjiHBjBU2Uu+l5r3B+72kAXLrkidiWMnboOPoJO6IYil73+m KE7aY5gXVTes1eYhmlgjJbgmSGCAvqFkwfUO77+rjcKoBcYVC/ LjcePAMEdw+gcSEbmOZhEixvnjtgSco80DMObs/YouBAoVpr7n 5ZesMHQ1YEQTitbh+0a5vBUOug6Z6dhZbhYVfRxJ5tVfwz0UN0 D8JdA4SDhSjFBVytzFT5xyUao7ZasRKF+YGbqLDa+YyETxcwTr iLmRS3rFbsVScbLnd8JjymTBvxcr87Nuo0zyNyasxp0SzT4jE+ Kv6mX7GrIsHE7z6wNzO7pVHDHMYIgxMNjWpcANUpP2Y+0vD+vP lCJSZwhTjEVTg== Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 21:56:17 -0000 >=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 > process EAP messages at any time during the authentication = conversation. >=20 > Alternatively, EAP permits a lower layer to set the retransmission = timer > to infinite. In this case, the lower layer is 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. Whenever some EAP methods receive erroneous Discarding may be done at the EAP layer or the EAP method layer. I think = we need to cover for both. > 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 an EAP method discarding a message, > although the specific way in which discarded messages will be handled > depend on the characteristics of the application. Now, saying "MUST handle" and then leaving the way it's handled out-of = scope does not make sense. > Options include > failing the authentication at the application level This is problematic. If the EAP method has discarded the message, now = you need this be conveyed down the stack to the EAP lower-layer. This = does not happen today. And enforcing that requires changing existing EAP = methods, creating additional requirement on future methods. =20 > and waiting for > additional EAP input, possibly after an EAP retransmit. >=20 Who is retransmitting here? The EAP peer? If so, we need to clarify = that. And also described how the EAP peer decides to retransmit, and = what it really retransmits (the previous EAP response?). Is this text meant to cover how the EAP conversation can be made = reliable with client-driven retransmissions? I see the implications of = it, but not clear and complete description of it. Alper > Specifications of how EAP is used for application authentication = SHOULD > document how retransmission and message discards are handled. > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From hartmans@painless-security.com Fri Nov 16 14:07:19 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C7C21F8B30 for ; Fri, 16 Nov 2012 14:07:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaSQ8xJabMAf for ; Fri, 16 Nov 2012 14:07:18 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id A8ADB21F8C34 for ; Fri, 16 Nov 2012 14:07:18 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 8A0EC2003E; Fri, 16 Nov 2012 17:06:00 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 7286A4149; Fri, 16 Nov 2012 17:07:14 -0500 (EST) From: Sam Hartman To: Alper Yegin References: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> Date: Fri, 16 Nov 2012 17:07:14 -0500 In-Reply-To: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> (Alper Yegin's message of "Fri, 16 Nov 2012 23:56:12 +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] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 22:07:19 -0000 >>>>> "Alper" == Alper Yegin writes: I'm not convinced it's appropriate for an EAP layer to discard when the I'd like to see citations to discussion of discards hapeening at the EAP layer. This seems like a really bad idea in cases where the timeout is infinite. After we've reviewed any citations members can come up with I think we'll be in a better position to discuss whether there are any cases where it's appropriate for an EAP layer to discard in an application context. My inclination is that is not a good idea. We disagree on this point. >> Options include failing the authentication at the application >> level Alper> This is problematic. If the EAP method has discarded the Alper> message, now you need this be conveyed down the stack to the Alper> EAP lower-layer. This does not happen today. And enforcing Alper> that requires changing existing EAP methods, creating Alper> additional requirement on future methods. As I stated in the meeting, I claim that this does happen today with a number of common implementations. As an example, any EAP implementation designed to be used in an AAA server will make it quite apparent when a discard happens. On the peer side, you're right that you could design an EAP layer that did not make this clear. However from what I've looked at this is not an issue. --Sam From alper.yegin@yegin.org Fri Nov 16 15:14:26 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB3821F8A52 for ; Fri, 16 Nov 2012 15:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.452 X-Spam-Level: X-Spam-Status: No, score=-102.452 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 e-7Wo7QkQLnD for ; Fri, 16 Nov 2012 15:14:25 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id AD29921F8A31 for ; Fri, 16 Nov 2012 15:14:25 -0800 (PST) Received: from [10.119.24.8] (178-32-60-104.ovh.net [178.32.60.104]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LsSUS-1TB7Zp03K4-0122LK; Fri, 16 Nov 2012 18:14:20 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Sat, 17 Nov 2012 01:14:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5087956D.3020205@toshiba.co.jp> <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> <50A3B3CA.4090307@deployingradius.com> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:lFU0YR4nQ6p/Y9qXx8rXbf6mlqT5EIENsu5gkLUQZwN 5RpxyCq+wZapkXR7nIZNqgrvcEPxH47Gw8pIacAskxbZ4jq/n2 F5nZHzcwdKRTezz01FKZ7ylKVodUzZjs+Ki5n3kd0CWvAfHIuY QnF4owePq0N+RYRuayIH+6hxKBObC4Arm+/vLoAOjM6hvHgJu9 TpOlcC2h8K14nRlLoQRibEvHMJteEIfFf7l+AW6XruXK0/KYIZ Xb1jRPE15kAif+3ViZ9cg6qTazvrJ5dDfdxy2cmUEJyMWARqX5 W987l9DK7IfZGJAsFb8s4A8W7uW4z+JaiIOn1190NzyGUcc1Cy K0sCWSOy+E6qWGywQSxkgKuLuwOI8onDjPvnyxWiwkSpnMoSnh PYIKCUw62WUIw== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 23:14:26 -0000 On Nov 14, 2012, at 5:44 PM, Sam Hartman wrote: >>>>>> "Alan" =3D=3D Alan DeKok writes: >=20 > Alan> For PCP, it's reasonable that the application knows the EAP > Alan> session has timed out. It can re-establish it before sending > Alan> the next message. Or, if messages are rare, it can wait and > Alan> re-establish it later. >=20 > Well, it's a bit tricky to re-establish the session if the next = message > is coming from the server but only the client can start the > authentication. > I think you have two general options: >=20 > 1) Decide it's OK not to re-establish the session until the client = wants > to do so >=20 This does not make sense. If we are talking about securing a protocol, = that better be a complete security, not a partial security that's = uncontrollably on and off. In this case, when the server wants to send a = message, if it's lucky it'll find a live security association and send = the message securely. If it's unlucky (there is no live SA), then bad = luck -- packet is dropped w/o transmission. Because sending an unsecure = packet does not make sense, it's at best useless, at worst harmful if we = expect the clients to act on them. > 2) Change things and let the server start an EAP session. >=20 > 3) Require the client to start an EAP session whenever the old session > goes away. >=20 2&3 make sense. I'd say the protocol shall support the capabilities needed for both 2 = and 3. And leave it to the deployment to decide when to use them. > The details as they apply to PCP are best discussed on that list. Alper From alper.yegin@yegin.org Fri Nov 16 15:57:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C64421F8AE4 for ; Fri, 16 Nov 2012 15:57:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Mnc9PBbu3vKJ for ; Fri, 16 Nov 2012 15:57:54 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 7F44221F8AE2 for ; Fri, 16 Nov 2012 15:57:54 -0800 (PST) Received: from [10.119.24.8] (178-32-60-104.ovh.net [178.32.60.104]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MJjH2-1TYPrW3ssm-001Kd4; Fri, 16 Nov 2012 18:57:53 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Sat, 17 Nov 2012 01:57:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:FYnwdGwUVVI8T+Jv9n/7PvDiqMeTcfPV0DWq7yw5Gn9 IXXnuwQrfGbHOrwTOv65CHKC8z4D07rdp68j4AwiXcviRIGHks JkYh6ZxuvUnB9/fNN6uY6I4A2M07DAzLhXf5AYsRnqUHVgJ7G7 yGLQ+VRsoR0AlbaCInAB+ZXykHOKhC8n84EQMMgpeAlWGw9u4g hbL6ZKrUlCYua5YkMuoSiy3w4v8NR7LMsSkUQ4PpwP+MHNlTM6 L2eghVklZeG/fQsxh8748iiU09o6MNvGgqKyepJaNGQ1xrksqt yYvfROHTz1mZA9qPGfg2dPRj19PirBKCjE8oTmK+yPFpRlqBVr lsIymxZ+PPlBP6iiFG0gCalfk44GRMkTjkw3WhkKbOCuUiMkZM iAfOzx4IuoGbg== Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Nov 2012 23:57:55 -0000 Sam, If you search for the keyword "discard" in RFC 3748, you see lots of = instances. That's for "EAP layer discarding." As for "EAP method discarding", Yoshi had already sent two examples on = the mailing list: EAP-IKEv2, EAP-GPSK. > This seems like a really bad idea in cases where the timeout is > infinite. Like I explained before, this is not an issue "when EAP timeout is = infinity, NAS performs rexmits". It's an issue "when EAP timeout is infinity, client performs rexmits".=20= Alper On Nov 17, 2012, at 12:07 AM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 >=20 > I'm not convinced it's appropriate for an EAP layer to discard when = the >=20 > I'd like to see citations to discussion of discards hapeening at the = EAP > layer. >=20 > This seems like a really bad idea in cases where the timeout is > infinite. > After we've reviewed any citations members can come up with I think > we'll be in a better position to discuss whether there are any cases > where it's appropriate for an EAP layer to discard in an application > context. > My inclination is that is not a good idea. >=20 > We disagree on this point. >=20 >>> Options include failing the authentication at the application >>> level >=20 > Alper> This is problematic. If the EAP method has discarded the > Alper> message, now you need this be conveyed down the stack to the > Alper> EAP lower-layer. This does not happen today. And enforcing > Alper> that requires changing existing EAP methods, creating > Alper> additional requirement on future methods. >=20 > As I stated in the meeting, I claim that this does happen today with = a > number of common implementations. > As an example, any EAP implementation designed to be used in an AAA > server will make it quite apparent when a discard happens. > On the peer side, you're right that you could design an EAP layer that > did not make this clear. > However from what I've looked at this is not an issue. >=20 >=20 >=20 >=20 > --Sam From yoshihiro.ohba@toshiba.co.jp Sat Nov 17 15:35:32 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2E0D21F8466 for ; Sat, 17 Nov 2012 15:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.756 X-Spam-Level: X-Spam-Status: No, score=-4.756 tagged_above=-999 required=5 tests=[AWL=-0.667, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 mk45MySaHAJX for ; Sat, 17 Nov 2012 15:35:32 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 38BCB21F8450 for ; Sat, 17 Nov 2012 15:35:31 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qAHNZUVj008997; Sun, 18 Nov 2012 08:35:30 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qAHNZUZO023268; Sun, 18 Nov 2012 08:35:30 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA23267; Sun, 18 Nov 2012 08:35:30 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qAHNZT9x023592; Sun, 18 Nov 2012 08:35:29 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qAHNZTqU012684; Sun, 18 Nov 2012 08:35:29 +0900 (JST) Received: from [133.199.18.132] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MDN00LZOO741290@mail.po.toshiba.co.jp>; Sun, 18 Nov 2012 08:35:29 +0900 (JST) Date: Sun, 18 Nov 2012 08:35:27 +0900 From: Yoshihiro Ohba In-reply-to: To: Sam Hartman Message-id: <50A81F3F.3070400@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50A54962.7000501@toshiba.co.jp> <50A57E21.10303@toshiba.co.jp> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 17 Nov 2012 23:35:33 -0000 Sam, (2012/11/16 9:13), Sam Hartman wrote: > In something more general I would de-emphasize the case where the > lower layer is reliable although still discuss it. I would not talk > about lock-step or client-driven authentication at all. The examples I > use and the emphasis would also be slightly different for the discard > case. I don't understand the logic behind what should be emphasized or de-emphasized here because the guidelines you proposed is logically applicable to any lower-layer. Yoshihiro Ohba From yoshihiro.ohba@toshiba.co.jp Sat Nov 17 15:50:15 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0582E21F843C for ; Sat, 17 Nov 2012 15:50:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.66 X-Spam-Level: X-Spam-Status: No, score=-4.66 tagged_above=-999 required=5 tests=[AWL=-0.571, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 sJnHpYvNrvRj for ; Sat, 17 Nov 2012 15:50:10 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8605721F843B for ; Sat, 17 Nov 2012 15:50:10 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qAHNnfCJ010196; Sun, 18 Nov 2012 08:49:41 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qAHNnf0t025260; Sun, 18 Nov 2012 08:49:41 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA25259; Sun, 18 Nov 2012 08:49:40 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qAHNne2E025295; Sun, 18 Nov 2012 08:49:40 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qAHNneif020208; Sun, 18 Nov 2012 08:49:40 +0900 (JST) Received: from [133.199.17.43] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MDN00L3FOUG12A0@mail.po.toshiba.co.jp>; Sun, 18 Nov 2012 08:49:40 +0900 (JST) Date: Sun, 18 Nov 2012 08:49:28 +0900 From: Yoshihiro Ohba In-reply-to: <006801cdc396$6ab9bac0$402d3040$@augustcellars.com> To: Jim Schaad Message-id: <50A82288.1010702@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50A54962.7000501@toshiba.co.jp> <50A57E21.10303@toshiba.co.jp> <006801cdc396$6ab9bac0$402d3040$@augustcellars.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 17 Nov 2012 23:50:15 -0000 (2012/11/16 10:05), Jim Schaad wrote: > I think that the scope issue itself is an overwhelming argument not to > replace application with lower-layer. Personally, I would have to think > long and hard about given exactly the same advice to an arbitrary > lower-layer protocol as oppose to given the advice to anyone who is writing > an application protocol that is designed to work with the ABFAB (GSS-EAP) > specific authentication profile. > > In the ABFAB case we are explicitly stating that these are requirements we > are dumping on the application protocol and not keeping for the GSS-EAP > lower-level protocol. What is the exact definition of "GSS-EAP lower-level protocol"? How is it different from an application? Yoshihiro Ohba > Changing the term from application to lower-level > would change the focus of the advice from what an application needs to do to > a problem that we now need to figure out how to solve in ABFAB which we > really do not want to do. > > Jim > > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf >> Of Yoshihiro Ohba >> Sent: Thursday, November 15, 2012 3:43 PM >> To: Sam Hartman >> Cc: abfab@ietf.org >> Subject: Re: [abfab] Retransmission Text for EAP applicability >> >> Sam and all, >> >> (2012/11/16 7:15), Sam Hartman wrote: >>>>>>>> "Yoshihiro" == Yoshihiro Ohba >> writes: >>> Yoshihiro> Sam, The provided text looks good, except that the text >>> Yoshihiro> is generally applicable to any EAP lower-layer inclucing >>> Yoshihiro> applications. Said that my suggestion is to replace >>> Yoshihiro> "application" with "lower-layer". >>> >>> I'm really pleased when I hear that you're happy with this direction. I >>> tried hard to capture the points you made and I'm glad >>> we're quite close. >>> >>> I actually think this advice is rather application specific. >> Why do you think so? >> >>> I'd say the same thing for a network access lower layer but my >>> emphasis would be different. >>> Also, I think giving general lower layer advice in this document is >>> inappropriate. >> I can understand this is a scope issue, but general readers of this > document >> would view the text in the same way as I did, because I believe it is a >> technical fact regardless of the scope of the document. I would like to > hear >> from you and others whether my point is valid, and if my point is valid > what >> the best way to capture my point would be. >> >> Regards, >> Yoshihiro Ohba >> >> >>> For those reasons, I'd be happier if we did not make that substitution. >>> I support all of Jim's proposed edits. >>> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > From ietf@augustcellars.com Mon Nov 19 20:15:54 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EDC521F8803 for ; Mon, 19 Nov 2012 20:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.373, 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 mItTAw-kER4G for ; Mon, 19 Nov 2012 20:15:53 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 4F80221F8801 for ; Mon, 19 Nov 2012 20:15:53 -0800 (PST) Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id F241938EF4; Mon, 19 Nov 2012 20:15:52 -0800 (PST) From: "Jim Schaad" To: "'Alper Yegin'" References: <002e01cdc35b$8a2cbb40$9e8631c0$@augustcellars.com> <682CE44A-4C9A-49DF-BC14-DE20228BF39C@yegin.org> In-Reply-To: <682CE44A-4C9A-49DF-BC14-DE20228BF39C@yegin.org> Date: Mon, 19 Nov 2012 20:15:44 -0800 Message-ID: <005e01cdc6d5$b5f94b80$21ebe280$@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: AQGdaosVfWMHHUVVoB9yMppCMQxOPQKEg+/VAhFcedKYLicPcA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 20 Nov 2012 04:15:54 -0000 > -----Original Message----- > From: Alper Yegin [mailto:alper.yegin@yegin.org] > Sent: Friday, November 16, 2012 1:46 PM > To: Jim Schaad > Cc: 'Sam Hartman'; abfab@ietf.org > Subject: Re: [abfab] Retransmission Text for EAP applicability > > >> In EAP, the authenticator is responsible for retransmission. By default > > EAP > >> assumes that the lower layer (the application in this context) is > > unreliable. > > s/lower layer/lower layer transport/ > > "EAP lower layer" is a term defined in RFC 3748. I believe the text intends to > refer to that. So, we better stick with the precise term. > I would like having transport in there as it tells me more what is going on. However I can live without it. By your argument should the term "lower layer" always be changed to "EAP lower layer" Jim From ietf@augustcellars.com Mon Nov 19 20:37:21 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBA2321F8574 for ; Mon, 19 Nov 2012 20:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 LFB1LAcLn6Kk for ; Mon, 19 Nov 2012 20:37:21 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB0621F87F7 for ; Mon, 19 Nov 2012 20:37:21 -0800 (PST) Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id B9D0638EF3; Mon, 19 Nov 2012 20:37:20 -0800 (PST) From: "Jim Schaad" To: "'Alper Yegin'" , "'Sam Hartman'" References: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> In-Reply-To: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> Date: Mon, 19 Nov 2012 20:37:11 -0800 Message-ID: <005f01cdc6d8$b5930840$20b918c0$@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: AQGdaosVfWMHHUVVoB9yMppCMQxOPQGcauhjmEX0GwA= Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 20 Nov 2012 04:37:21 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Alper Yegin > Sent: Friday, November 16, 2012 1:56 PM > To: Sam Hartman > Cc: abfab@ietf.org > Subject: Re: [abfab] Retransmission Text for EAP applicability > > > > > > 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 > > process EAP messages at any time during the authentication conversation. > > > > Alternatively, EAP permits a lower layer to set the retransmission > > timer to infinite. In this case, the lower layer is 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. Whenever some EAP methods receive > erroneous > > Discarding may be done at the EAP layer or the EAP method layer. I think we > need to cover for both. It is true that the EAP upper lay can discard messages as well, however I am not sure that the text is going to be clearer by stating so. However I think the following change should address your concern s/Whenever/For example, whenever/ > > > 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 an EAP method discarding a message, although > > the specific way in which discarded messages will be handled depend on > > the characteristics of the application. > > Now, saying "MUST handle" and then leaving the way it's handled out-of > scope does not make sense. I think this makes perfect sense. We have just said that how it is going to happen - in fact what the correct response to happen - is going to be based on the specific application we are discussing. This means that we can't say what it should do. Some applications will assume transmission error and send the fact that the EAP packet was not processed. (I kind of expect TEAP to do this behavior). Some applications will treat it as an Access-Fail and kill the whole process. We cannot dictate what the correct behavior should be. > > > Options include > > failing the authentication at the application level > > This is problematic. If the EAP method has discarded the message, now you > need this be conveyed down the stack to the EAP lower-layer. This does not > happen today. And enforcing that requires changing existing EAP methods, > creating additional requirement on future methods. If I make a call to the EAP handler, it does not say that I got an Access-Accept or an Access-Reject, and it does not return anything for me to send back continuing the conversation. This sounds like a pretty good clue the packet was dropped on the floor given the lock-step behavior of EAP itself. I don't see any need to change either current EAP behavior or future behavior. > > > and waiting for > > additional EAP input, possibly after an EAP retransmit. > > > > Who is retransmitting here? The EAP peer? If so, we need to clarify that. And > also described how the EAP peer decides to retransmit, and what it really > retransmits (the previous EAP response?). > That is going to be application specific behavior. In part it is going to depend on who dropped the message on the floor and who actually has the ability to even try and do the resend. Without knowing your application data flow, I cannot answer this question. > > Is this text meant to cover how the EAP conversation can be made reliable > with client-driven retransmissions? I see the implications of it, but not clear > and complete description of it. No. That may be one of the things that an application may define, but it is not required in any way. > > Alper > > > > > Specifications of how EAP is used for application authentication > > SHOULD document how retransmission and message discards are handled. > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Mon Nov 19 20:42:23 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 431B321F87CA for ; Mon, 19 Nov 2012 20:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.413 X-Spam-Level: X-Spam-Status: No, score=-3.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 tJ+bu9BZw+XW for ; Mon, 19 Nov 2012 20:42:22 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6EE0221F87C9 for ; Mon, 19 Nov 2012 20:42:22 -0800 (PST) Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 83B3338EF2; Mon, 19 Nov 2012 20:42:20 -0800 (PST) From: "Jim Schaad" To: "'Alper Yegin'" , "'Sam Hartman'" References: <5087956D.3020205@toshiba.co.jp> <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> <50A3B3CA.4090307@deployingradius.com> In-Reply-To: Date: Mon, 19 Nov 2012 20:42:11 -0800 Message-ID: <006001cdc6d9$693b76c0$3bb26440$@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: AQJHTBGnHfEtOpz/3IXLPBzSowq5egKufn5iAh7v3gkBvUrNxwDdKKM/Afy+mWGWs/R/wA== Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication 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, 20 Nov 2012 04:42:23 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Alper Yegin > Sent: Friday, November 16, 2012 3:14 PM > To: Sam Hartman > Cc: abfab@ietf.org > Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication > > > On Nov 14, 2012, at 5:44 PM, Sam Hartman wrote: > > >>>>>> "Alan" == Alan DeKok writes: > > > > Alan> For PCP, it's reasonable that the application knows the EAP > > Alan> session has timed out. It can re-establish it before sending > > Alan> the next message. Or, if messages are rare, it can wait and > > Alan> re-establish it later. > > > > Well, it's a bit tricky to re-establish the session if the next > > message is coming from the server but only the client can start the > > authentication. > > I think you have two general options: > > > > 1) Decide it's OK not to re-establish the session until the client > > wants to do so > > > > This does not make sense. If we are talking about securing a protocol, that > better be a complete security, not a partial security that's uncontrollably on > and off. In this case, when the server wants to send a message, if it's lucky > it'll find a live security association and send the message securely. If it's > unlucky (there is no live SA), then bad luck -- packet is dropped w/o > transmission. Because sending an unsecure packet does not make sense, it's > at best useless, at worst harmful if we expect the clients to act on them. I find this to be a completely appropriate behavior. Before I left the e-mail group at Microsoft I had just come to the realization that I no longer believe that all email messages needed to have S/MIME signatures verified prior to showing the message to the recipient. The validation process could be deferred until one of a number of different trigger events occurred. I changed groups because the Outlook group was not interested in doing another round of changes in behavior so I never had the long discussions to get my ideas into the program. However this represents a similar behavior. As a client I get a message, would I care about the content of the message? If so then I can find out if the message is real. If I don't care about the content of the message then why should I care if it is real or spam? The act that the client is expected to do is to ask the server if the message is real (assuming it cares) before performing operations on the message. That seems to be a totally reasonable behavior. Jim > > > > 2) Change things and let the server start an EAP session. > > > > 3) Require the client to start an EAP session whenever the old session > > goes away. > > > > 2&3 make sense. > > I'd say the protocol shall support the capabilities needed for both 2 and 3. > And leave it to the deployment to decide when to use them. > > > The details as they apply to PCP are best discussed on that list. > > > Alper > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Mon Nov 19 20:44:06 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7AF21F87CB for ; Mon, 19 Nov 2012 20:44:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.45 X-Spam-Level: X-Spam-Status: No, score=-3.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoi2C0M27-ig for ; Mon, 19 Nov 2012 20:44:06 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 600B221F87CA for ; Mon, 19 Nov 2012 20:44:06 -0800 (PST) Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 394B238F07; Mon, 19 Nov 2012 20:44:06 -0800 (PST) From: "Jim Schaad" To: "'Alper Yegin'" , "'Sam Hartman'" References: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> In-Reply-To: Date: Mon, 19 Nov 2012 20:43:56 -0800 Message-ID: <006101cdc6d9$a72d0200$f5870600$@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: AQGdaosVfWMHHUVVoB9yMppCMQxOPQGcauhjAqQiH6cBpt+KHJgjooOA Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 20 Nov 2012 04:44:07 -0000 > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Alper Yegin > Sent: Friday, November 16, 2012 3:58 PM > To: Sam Hartman > Cc: abfab@ietf.org > Subject: Re: [abfab] Retransmission Text for EAP applicability > > Sam, > > If you search for the keyword "discard" in RFC 3748, you see lots of instances. > That's for "EAP layer discarding." > > As for "EAP method discarding", Yoshi had already sent two examples on the > mailing list: EAP-IKEv2, EAP-GPSK. > > > This seems like a really bad idea in cases where the timeout is > > infinite. > > Like I explained before, this is not an issue "when EAP timeout is infinity, NAS > performs rexmits". The NAS can only do a retransmit if it is involved in an async protocol. If it is in a sync protocol then the token needs to be passed back to the NAS in order for it to do the retransmit. If this does not happen then you will be in a dead-lock situation. Jim > It's an issue "when EAP timeout is infinity, client performs rexmits". > > > Alper > > > > On Nov 17, 2012, at 12:07 AM, Sam Hartman wrote: > > >>>>>> "Alper" == Alper Yegin writes: > > > > > > I'm not convinced it's appropriate for an EAP layer to discard when > > the > > > > I'd like to see citations to discussion of discards hapeening at the > > EAP layer. > > > > This seems like a really bad idea in cases where the timeout is > > infinite. > > After we've reviewed any citations members can come up with I think > > we'll be in a better position to discuss whether there are any cases > > where it's appropriate for an EAP layer to discard in an application > > context. > > My inclination is that is not a good idea. > > > > We disagree on this point. > > > >>> Options include failing the authentication at the application level > > > > Alper> This is problematic. If the EAP method has discarded the > > Alper> message, now you need this be conveyed down the stack to the > > Alper> EAP lower-layer. This does not happen today. And enforcing > > Alper> that requires changing existing EAP methods, creating > > Alper> additional requirement on future methods. > > > > As I stated in the meeting, I claim that this does happen today with > > a number of common implementations. > > As an example, any EAP implementation designed to be used in an AAA > > server will make it quite apparent when a discard happens. > > On the peer side, you're right that you could design an EAP layer that > > did not make this clear. > > However from what I've looked at this is not an issue. > > > > > > > > > > --Sam > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From ietf@augustcellars.com Mon Nov 19 20:48:41 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97F1521F87CB for ; Mon, 19 Nov 2012 20:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 qIcUP+hVTK6L for ; Mon, 19 Nov 2012 20:48:41 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id F237F21F87CA for ; Mon, 19 Nov 2012 20:48:40 -0800 (PST) Received: from Philemon (173-160-230-153-Washington.hfc.comcastbusiness.net [173.160.230.153]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id E78D938F02; Mon, 19 Nov 2012 20:48:40 -0800 (PST) From: "Jim Schaad" To: "'Yoshihiro Ohba'" , References: <50A54962.7000501@toshiba.co.jp> In-Reply-To: <50A54962.7000501@toshiba.co.jp> Date: Mon, 19 Nov 2012 20:48:31 -0800 Message-ID: <006201cdc6da$4ae27e20$e0a77a60$@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: AQGdaosVfWMHHUVVoB9yMppCMQxOPQIaS9yImEIMCAA= Content-Language: en-us Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 20 Nov 2012 04:48:41 -0000 I would be against this replacement. The application and the lower-layer may not be the same thing for a number of reasons. Looking specifically at the GSS-EAP case, the lower layer consists of both RADIUS and GSS-API. Neither of these is really the application layer. If EAP is directly built into the application, then yes the application and the lower layer are going to be the same. If there is some type of wrapper that is going on in the middle, such as using GSS-API, then they are no longer the same. The application becomes one layer lower than the lower-layer. If you look at RADIUS, RADIUS is the lower-layer independent of transport that RADIUS is operating on top of. It does not mapper if you are doing RADIUS over UDP, DTLS or TLS/IP, RADIUS is the lower-layer. At some point you say everything below this point is below the lower-layer. Jim > -----Original Message----- > From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf > Of Yoshihiro Ohba > Sent: Thursday, November 15, 2012 11:58 AM > To: abfab@ietf.org > Subject: Re: [abfab] Retransmission Text for EAP applicability > > Sam, > > The provided text looks good, except that the text is generally > applicable to any EAP lower-layer inclucing applications. Said that my > suggestion is to replace "application" with "lower-layer". > > Thanks, > Yoshihiro Ohba > > > (2012/11/15 4:37), Sam Hartman wrote: > > 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 > > process EAP messages at any time during the authentication conversation. > > > > Alternatively, EAP permits a lower layer to set the retransmission > > timer to infinite. In this case, the lower layer is 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. 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 an EAP method discarding a message, 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 and waiting for additional EAP > > input, possibly after an EAP retransmit. > > > > Specifications of how EAP is used for application authentication > > SHOULD document how retransmission and message discards are handled. > > _______________________________________________ > > abfab mailing list > > abfab@ietf.org > > https://www.ietf.org/mailman/listinfo/abfab > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab From yoshihiro.ohba@toshiba.co.jp Mon Nov 19 21:33:37 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC33821F87CA for ; Mon, 19 Nov 2012 21:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 vvzBWKMu8cVW for ; Mon, 19 Nov 2012 21:33:37 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id C7FD821F87C5 for ; Mon, 19 Nov 2012 21:33:36 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qAK5X76o017546; Tue, 20 Nov 2012 14:33:07 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qAK5X7Kn002412; Tue, 20 Nov 2012 14:33:07 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id QAA02411; Tue, 20 Nov 2012 14:33:07 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qAK5X7Km018277; Tue, 20 Nov 2012 14:33:07 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qAK5X79G001336; Tue, 20 Nov 2012 14:33:07 +0900 (JST) Received: from [133.196.20.235] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MDR00GK5U36GWG0@mail.po.toshiba.co.jp>; Tue, 20 Nov 2012 14:33:07 +0900 (JST) Date: Tue, 20 Nov 2012 14:33:10 +0900 From: Yoshihiro Ohba In-reply-to: <006201cdc6da$4ae27e20$e0a77a60$@augustcellars.com> To: Jim Schaad Message-id: <50AB1616.9090802@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50A54962.7000501@toshiba.co.jp> <006201cdc6da$4ae27e20$e0a77a60$@augustcellars.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 20 Nov 2012 05:33:37 -0000 Jim, In the context of EAP, GSS-EAP solely cannot be considered as EAP lower-layer because GSS-EAP itself does not provide in-order delivery of EAP messages. GSS-EAP requires applications to provide in-order delivery. Therefore, GSS-EAP applications must be considered as part of EAP lower layer. Yoshihiro Ohba (2012/11/20 13:48), Jim Schaad wrote: > I would be against this replacement. > > The application and the lower-layer may not be the same thing for a number > of reasons. Looking specifically at the GSS-EAP case, the lower layer > consists of both RADIUS and GSS-API. Neither of these is really the > application layer. If EAP is directly built into the application, then yes > the application and the lower layer are going to be the same. If there is > some type of wrapper that is going on in the middle, such as using GSS-API, > then they are no longer the same. The application becomes one layer lower > than the lower-layer. > > If you look at RADIUS, RADIUS is the lower-layer independent of transport > that RADIUS is operating on top of. It does not mapper if you are doing > RADIUS over UDP, DTLS or TLS/IP, RADIUS is the lower-layer. At some point > you say everything below this point is below the lower-layer. > > Jim > > >> -----Original Message----- >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On Behalf >> Of Yoshihiro Ohba >> Sent: Thursday, November 15, 2012 11:58 AM >> To: abfab@ietf.org >> Subject: Re: [abfab] Retransmission Text for EAP applicability >> >> Sam, >> >> The provided text looks good, except that the text is generally >> applicable to any EAP lower-layer inclucing applications. Said that my >> suggestion is to replace "application" with "lower-layer". >> >> Thanks, >> Yoshihiro Ohba >> >> >> (2012/11/15 4:37), Sam Hartman wrote: >>> 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 >>> process EAP messages at any time during the authentication conversation. >>> >>> Alternatively, EAP permits a lower layer to set the retransmission >>> timer to infinite. In this case, the lower layer is 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. 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 an EAP method discarding a message, 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 and waiting for additional EAP >>> input, possibly after an EAP retransmit. >>> >>> Specifications of how EAP is used for application authentication >>> SHOULD document how retransmission and message discards are handled. >>> _______________________________________________ >>> abfab mailing list >>> abfab@ietf.org >>> https://www.ietf.org/mailman/listinfo/abfab >>> >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab > From ietf@augustcellars.com Mon Nov 19 22:25:30 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1C821F8427 for ; Mon, 19 Nov 2012 22:25:30 -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 cwLt8ymLVFLr for ; Mon, 19 Nov 2012 22:25:29 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94E3221F8463 for ; Mon, 19 Nov 2012 22:25:29 -0800 (PST) Received: from Philemon (mail.augustcellars.com [50.34.17.238]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 84D9E2C9E7; Mon, 19 Nov 2012 22:25:28 -0800 (PST) From: "Jim Schaad" To: "'Yoshihiro Ohba'" References: <50A54962.7000501@toshiba.co.jp> <006201cdc6da$4ae27e20$e0a77a60$@augustcellars.com> <50AB1616.9090802@toshiba.co.jp> In-Reply-To: <50AB1616.9090802@toshiba.co.jp> Date: Mon, 19 Nov 2012 22:25:16 -0800 Message-ID: <006901cdc6e7$d0b5e8e0$7221baa0$@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: AQGdaosVfWMHHUVVoB9yMppCMQxOPQIaS9yIAgb2cLsB9QwlJJgiRnYw Content-Language: en-us Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 20 Nov 2012 06:25:30 -0000 It is more correct to say that GSS-API gets its reliability by pushing some of it down a layer, but that is no different that RADIUS saying it can have reliable transport if it requires TLS/IP as its underlying transport. Also the requirements that GSS-API imposes during the authentication phase are different than those during the normal application processing. For GSS-EAP it is a lock-step delivery during authentication. That is much stricter than just saying it is in-order delivery. However this does not change my opinion that application protocol that is using GSS-API is not part of the EAP lower-level. The requirements that GSS-API makes are independent of the use of EAP. Jim > -----Original Message----- > From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp] > Sent: Monday, November 19, 2012 9:33 PM > To: Jim Schaad > Cc: abfab@ietf.org > Subject: Re: [abfab] Retransmission Text for EAP applicability > > Jim, > > In the context of EAP, GSS-EAP solely cannot be considered as EAP lower- > layer because GSS-EAP itself does not provide in-order delivery of EAP > messages. GSS-EAP requires applications to provide in-order delivery. > Therefore, GSS-EAP applications must be considered as part of EAP lower > layer. > > Yoshihiro Ohba > > (2012/11/20 13:48), Jim Schaad wrote: > > I would be against this replacement. > > > > The application and the lower-layer may not be the same thing for a > > number of reasons. Looking specifically at the GSS-EAP case, the > > lower layer consists of both RADIUS and GSS-API. Neither of these is > > really the application layer. If EAP is directly built into the > > application, then yes the application and the lower layer are going to > > be the same. If there is some type of wrapper that is going on in the > > middle, such as using GSS-API, then they are no longer the same. The > > application becomes one layer lower than the lower-layer. > > > > If you look at RADIUS, RADIUS is the lower-layer independent of > > transport that RADIUS is operating on top of. It does not mapper if > > you are doing RADIUS over UDP, DTLS or TLS/IP, RADIUS is the > > lower-layer. At some point you say everything below this point is below > the lower-layer. > > > > Jim > > > > > >> -----Original Message----- > >> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On > >> Behalf Of Yoshihiro Ohba > >> Sent: Thursday, November 15, 2012 11:58 AM > >> To: abfab@ietf.org > >> Subject: Re: [abfab] Retransmission Text for EAP applicability > >> > >> Sam, > >> > >> The provided text looks good, except that the text is generally > >> applicable to any EAP lower-layer inclucing applications. Said that my > >> suggestion is to replace "application" with "lower-layer". > >> > >> Thanks, > >> Yoshihiro Ohba > >> > >> > >> (2012/11/15 4:37), Sam Hartman wrote: > >>> 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 process EAP messages at any time during the authentication > conversation. > >>> > >>> Alternatively, EAP permits a lower layer to set the retransmission > >>> timer to infinite. In this case, the lower layer is 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. 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 an EAP method discarding a message, > >>> 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 and > >>> waiting for additional EAP input, possibly after an EAP retransmit. > >>> > >>> Specifications of how EAP is used for application authentication > >>> SHOULD document how retransmission and message discards are > handled. > >>> _______________________________________________ > >>> abfab mailing list > >>> abfab@ietf.org > >>> https://www.ietf.org/mailman/listinfo/abfab > >>> > >> _______________________________________________ > >> abfab mailing list > >> abfab@ietf.org > >> https://www.ietf.org/mailman/listinfo/abfab > > From yoshihiro.ohba@toshiba.co.jp Tue Nov 20 15:24:55 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D27021F877A for ; Tue, 20 Nov 2012 15:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] 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 k3IZ0W6WCAhJ for ; Tue, 20 Nov 2012 15:24:54 -0800 (PST) Received: from imx2.toshiba.co.jp (inet-tsb5.toshiba.co.jp [202.33.96.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4769D21F8822 for ; Tue, 20 Nov 2012 15:24:53 -0800 (PST) Received: from arc1.toshiba.co.jp ([133.199.194.235]) by imx2.toshiba.co.jp with ESMTP id qAKNOSRm006070; Wed, 21 Nov 2012 08:24:28 +0900 (JST) Received: (from root@localhost) by arc1.toshiba.co.jp id qAKNOSC1010865; Wed, 21 Nov 2012 08:24:28 +0900 (JST) Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id JAA10862; Wed, 21 Nov 2012 08:24:27 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id qAKNORPp003682; Wed, 21 Nov 2012 08:24:27 +0900 (JST) Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id qAKNORrV001407; Wed, 21 Nov 2012 08:24:27 +0900 (JST) Received: from [133.196.20.235] by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTPSA id <0MDT00H207ORRYE0@mail.po.toshiba.co.jp>; Wed, 21 Nov 2012 08:24:27 +0900 (JST) Date: Wed, 21 Nov 2012 08:24:30 +0900 From: Yoshihiro Ohba In-reply-to: <006901cdc6e7$d0b5e8e0$7221baa0$@augustcellars.com> To: Jim Schaad Message-id: <50AC112E.2060902@toshiba.co.jp> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: <50A54962.7000501@toshiba.co.jp> <006201cdc6da$4ae27e20$e0a77a60$@augustcellars.com> <50AB1616.9090802@toshiba.co.jp> <006901cdc6e7$d0b5e8e0$7221baa0$@augustcellars.com> User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability 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, 20 Nov 2012 23:24:55 -0000 (2012/11/20 15:25), Jim Schaad wrote: > It is more correct to say that GSS-API gets its reliability by pushing some > of it down a layer, but that is no different that RADIUS saying it can have > reliable transport if it requires TLS/IP as its underlying transport. If GSS-API relies on reliability provided by its transport, then GSS-API combined with the trasnsport is considered as EAP lower layer to meet EAP lower layer requirements. Strictly speaking, RADIUS is not considered as EAP lower layer just because EAP lower layer is defined as the laywer that is responsible for transmitting and receiving EAP frames *between the peer and authenticator* (see RFC 3748). > Also the requirements that GSS-API imposes during the authentication phase > are different than those during the normal application processing. For > GSS-EAP it is a lock-step delivery during authentication. That is much > stricter than just saying it is in-order delivery. Being lock-step solely does not provide in-order delivery. EAP is lock-step protocol but it does not provide in-order delivery, because it Identifier fieled is not a sequence number and may be reused during the same EAP conversation. To provider in-order delivery, at least sequence number would be needed. Does GSS EAP token carry a sequence number? This is an important question for you to answer. Yoshihiro Ohba > > However this does not change my opinion that application protocol that is > using GSS-API is not part of the EAP lower-level. The requirements that > GSS-API makes are independent of the use of EAP. > > Jim > > >> -----Original Message----- >> From: Yoshihiro Ohba [mailto:yoshihiro.ohba@toshiba.co.jp] >> Sent: Monday, November 19, 2012 9:33 PM >> To: Jim Schaad >> Cc: abfab@ietf.org >> Subject: Re: [abfab] Retransmission Text for EAP applicability >> >> Jim, >> >> In the context of EAP, GSS-EAP solely cannot be considered as EAP lower- >> layer because GSS-EAP itself does not provide in-order delivery of EAP >> messages. GSS-EAP requires applications to provide in-order delivery. >> Therefore, GSS-EAP applications must be considered as part of EAP lower >> layer. >> >> Yoshihiro Ohba >> >> (2012/11/20 13:48), Jim Schaad wrote: >>> I would be against this replacement. >>> >>> The application and the lower-layer may not be the same thing for a >>> number of reasons. Looking specifically at the GSS-EAP case, the >>> lower layer consists of both RADIUS and GSS-API. Neither of these is >>> really the application layer. If EAP is directly built into the >>> application, then yes the application and the lower layer are going to >>> be the same. If there is some type of wrapper that is going on in the >>> middle, such as using GSS-API, then they are no longer the same. The >>> application becomes one layer lower than the lower-layer. >>> >>> If you look at RADIUS, RADIUS is the lower-layer independent of >>> transport that RADIUS is operating on top of. It does not mapper if >>> you are doing RADIUS over UDP, DTLS or TLS/IP, RADIUS is the >>> lower-layer. At some point you say everything below this point is below >> the lower-layer. >>> Jim >>> >>> >>>> -----Original Message----- >>>> From: abfab-bounces@ietf.org [mailto:abfab-bounces@ietf.org] On >>>> Behalf Of Yoshihiro Ohba >>>> Sent: Thursday, November 15, 2012 11:58 AM >>>> To: abfab@ietf.org >>>> Subject: Re: [abfab] Retransmission Text for EAP applicability >>>> >>>> Sam, >>>> >>>> The provided text looks good, except that the text is generally >>>> applicable to any EAP lower-layer inclucing applications. Said that > my >>>> suggestion is to replace "application" with "lower-layer". >>>> >>>> Thanks, >>>> Yoshihiro Ohba >>>> >>>> >>>> (2012/11/15 4:37), Sam Hartman wrote: >>>>> 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 process EAP messages at any time during the authentication >> conversation. >>>>> Alternatively, EAP permits a lower layer to set the retransmission >>>>> timer to infinite. In this case, the lower layer is 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. 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 an EAP method discarding a message, >>>>> 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 and >>>>> waiting for additional EAP input, possibly after an EAP retransmit. >>>>> >>>>> Specifications of how EAP is used for application authentication >>>>> SHOULD document how retransmission and message discards are >> handled. >>>>> _______________________________________________ >>>>> abfab mailing list >>>>> abfab@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/abfab >>>>> >>>> _______________________________________________ >>>> abfab mailing list >>>> abfab@ietf.org >>>> https://www.ietf.org/mailman/listinfo/abfab > From alper.yegin@yegin.org Thu Nov 22 01:55:57 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEB8921F854E for ; Thu, 22 Nov 2012 01:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 e9RoBLOdthML for ; Thu, 22 Nov 2012 01:55:56 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BEF2321F8502 for ; Thu, 22 Nov 2012 01:55:56 -0800 (PST) Received: from [192.168.2.9] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis) id 0LqjRS-1T74NQ1GUM-00eTak; Thu, 22 Nov 2012 04:55:55 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <005e01cdc6d5$b5f94b80$21ebe280$@augustcellars.com> Date: Thu, 22 Nov 2012 11:55:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <002e01cdc35b$8a2cbb40$9e8631c0$@augustcellars.com> <682CE44A-4C9A-49DF-BC14-DE20228BF39C@yegin.org> <005e01cdc6d5$b5f94b80$21ebe280$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:LpfYG/oIRJP2ymTr3eVKsdquWCyE2/mhEIJcNMq1ftQ lhxz6jHpdg/xAIW9V0JkeB51S4woTwvWuC4nrVdvuTsamLRjC/ iDFvXifxEDYcMw4sSwrjpoXCcbbEMaeK084ZwQARLbsz5oHOEP TBFyDNLTUk8S/Nw9a4Ri8xezYwIXrmO7+IkZVYcN0SEN5F7FHM RNz2+Tkv/bdoGKIDhKKPutNbkANX+yoJreYWFMgCWNLMPe9DZR UIJJ8DmWybTuwyAnmyU+YyUBZpni4Wy6DjoY9v6CTjHI9PzAlH ZPsYROfa1svCKIkzAQSWA/lq6bBZpIV51FVBWGJHkwwSrArpck d5SgFektETL/p3UAxo12DxlX0C7ReH4Nk4qJ/UPKhiHqY/h6BV zixhVZdvWTt/A== Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 09:55:58 -0000 >>>> In EAP, the authenticator is responsible for retransmission. By = default >>> EAP >>>> assumes that the lower layer (the application in this context) is >>> unreliable. >>> s/lower layer/lower layer transport/ >>=20 >> "EAP lower layer" is a term defined in RFC 3748. I believe the text > intends to >> refer to that. So, we better stick with the precise term. >>=20 >=20 > I would like having transport in there as it tells me more what is = going on. > However I can live without it. >=20 > By your argument should the term "lower layer" always be changed to = "EAP > lower layer" >=20 Yes, with a reference to RFC 3748. > Jim >=20 >=20 From alper.yegin@yegin.org Thu Nov 22 02:39:42 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1314821F8783 for ; Thu, 22 Nov 2012 02:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 A5-g5AAnaNQM for ; Thu, 22 Nov 2012 02:39:41 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBED21F877B for ; Thu, 22 Nov 2012 02:39:41 -0800 (PST) Received: from [192.168.2.9] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus4) with ESMTP (Nemesis) id 0MPlgA-1TfM4y3gQs-005AbP; Thu, 22 Nov 2012 05:39:40 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <005f01cdc6d8$b5930840$20b918c0$@augustcellars.com> Date: Thu, 22 Nov 2012 12:39:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> <005f01cdc6d8$b5930840$20b918c0$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:cKXgSObz62pcW72OlgAdfnXdBOBEAt96x+Sl7akdvRM ocRZqXcK89dx++OBgAyz5O8pA8gAnTxpkVPyfwefK6Z8NB23vM vUz2K12cJOYuJ4llN9uTU3DiiUELXpD8GgWpZct5TgQYpO5xbE d7NATo4Wem+9qZoUBbiS/WHi6X3mtPBPGv4vlSlMBKujaCi6w5 nYYNlJr4FH31O0Zpr54KkHpEjkubE4r1hTnxOckVfM/btcBlEB Iy1Sx/D9/2qtAj1Lbc+CyXfz8BtPYF51EXcjfvdN4Ms5gKgVUg L9/2dVEn1Zjd5S/Hr039mYmn4sIRZ5zG+tH//cmWZrFVjMoT72 4Gq3vwS8r+CBH1c1Reu8p/tpmQTtiJ3cw5gXTi/BsKHytsOkXB 3QbWPDKawoGdw== Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 10:39:42 -0000 >>> 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 an EAP method discarding a message, = although >>> the specific way in which discarded messages will be handled depend = on >>> the characteristics of the application. >>=20 >> Now, saying "MUST handle" and then leaving the way it's handled = out-of >> scope does not make sense. >=20 > I think this makes perfect sense. We have just said that how it is = going to > happen - in fact what the correct response to happen - is going to be = based > on the specific application we are discussing. This means that we = can't say > what it should do. >=20 Why would the application care what happens when an EAP-layer or EAP = method-layer message is discarded? If an EAP-layer message is discarded, it's for the EAP-layer to deal = with that. If an EAP method-layer message is discarded, it's for the EAP method = layer to deal with that. If you are designing a protocol that needs to deal with what happens at = 1 or 2 layers above, then I'd say there's an issue with this design. This is like saying, if HTTP discards a packet, then IP MUST handle = this.=20 > Some applications will assume transmission error and send the fact = that the > EAP packet was not processed. (I kind of expect TEAP to do this = behavior). >=20 > Some applications will treat it as an Access-Fail and kill the whole > process. >=20 > We cannot dictate what the correct behavior should be. >=20 Because, that's not the business of this layer. Having a MUST w/o a = clear normative text and this explanation is the indication of the = problem. Don't you think? >>=20 >>> Options include >>> failing the authentication at the application level >>=20 >> This is problematic. If the EAP method has discarded the message, now = you >> need this be conveyed down the stack to the EAP lower-layer. This = does not >> happen today. And enforcing that requires changing existing EAP = methods, >> creating additional requirement on future methods. >=20 > If I make a call to the EAP handler, it does not say that I got an > Access-Accept or an Access-Reject, and it does not return anything for = me to > send back continuing the conversation. This sounds like a pretty = good clue > the packet was dropped on the floor given the lock-step behavior of = EAP > itself. >=20 Nope. Maybe the EAP method is awaiting an input from the user. The "EAP = lower layer" cannot know what's going on at the EAP method layer. > I don't see any need to change either current EAP behavior or future > behavior. =20 >=20 >>=20 >>> and waiting for >>> additional EAP input, possibly after an EAP retransmit. >>>=20 >>=20 >> Who is retransmitting here? The EAP peer? If so, we need to clarify = that. > And >> also described how the EAP peer decides to retransmit, and what it = really >> retransmits (the previous EAP response?). >>=20 >=20 > That is going to be application specific behavior. In part it is = going to > depend on who dropped the message on the floor and who actually has = the > ability to even try and do the resend. Without knowing your = application > data flow, I cannot answer this question. >=20 The options provided by the text is ambiguous.=20 >>=20 >> Is this text meant to cover how the EAP conversation can be made = reliable >> with client-driven retransmissions? I see the implications of it, but = not > clear >> and complete description of it. >=20 > No. That may be one of the things that an application may define, but = it is > not required in any way. I'd say if this text is meant to cover that possibility, then we need to = make it very clear. Otherwise, the text is rather vague=85 Alper >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>> Specifications of how EAP is used for application authentication >>> SHOULD document how retransmission and message discards are handled. >>> _______________________________________________ >>> 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 >=20 From alper.yegin@yegin.org Thu Nov 22 02:51:00 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A97B621F8532 for ; Thu, 22 Nov 2012 02:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.453 X-Spam-Level: X-Spam-Status: No, score=-102.453 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8wQrdZofUPyQ for ; Thu, 22 Nov 2012 02:50:59 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 8F2FE21F8518 for ; Thu, 22 Nov 2012 02:50:59 -0800 (PST) Received: from [192.168.2.9] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0Lufsm-1TBKaB0c5I-010BIT; Thu, 22 Nov 2012 05:50:57 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <006001cdc6d9$693b76c0$3bb26440$@augustcellars.com> Date: Thu, 22 Nov 2012 12:50:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7E21C69B-7633-4D26-83C3-A9B7046A6C9C@yegin.org> References: <5087956D.3020205@toshiba.co.jp> <33D91EFA-2ABF-4EAB-B1B3-A7DD63998245@yegin.org> <50A3B3CA.4090307@deployingradius.com> <006001cdc6d9$693b76c0$3bb26440$@augustcellars.com> To: Jim Schaad X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:2LXs+Ua+NPRn/yNkhOY7BitQ4jtnky6U6y6BsTxf0yp 8wISpSUiWXcuFiuEPAoMFO9R6UVJhGkGK0R86RHGPhtSECCdv7 ivezSuPYp4+j43AqsLCC8nzzdNMIA7umsMoemT0rKGoCOzxZuW 8d65PtAcVFOaoaUViV/YMfPQU8whjfi/+PqRoZJsAaCacmqzrC zRcMUUaRhalgtBKQag6g7RAUrqHvyihPDwLQs068cShoNkntl8 Kb7c2kI9RLGaUonesqDPioU1zvU/x46ST8iPHsFht4P14qw942 SolDv1AfRgcPHUT6ioft1MZTZ9HbSVzv5p6MIJf/L/uwdAhZPK hJvygFtBdXgJtPCg1auk4wgFenn2f2JMHQH1hp+waTXcSTu97B WG4Hr+CHL+/PA== Cc: abfab@ietf.org Subject: Re: [abfab] EAP Applicability: server-initiated re-authentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Nov 2012 10:51:00 -0000 >>=20 >>>>>>>> "Alan" =3D=3D Alan DeKok writes: >>>=20 >>> Alan> For PCP, it's reasonable that the application knows the = EAP >>> Alan> session has timed out. It can re-establish it before = sending >>> Alan> the next message. Or, if messages are rare, it can wait and >>> Alan> re-establish it later. >>>=20 >>> Well, it's a bit tricky to re-establish the session if the next >>> message is coming from the server but only the client can start the >>> authentication. >>> I think you have two general options: >>>=20 >>> 1) Decide it's OK not to re-establish the session until the client >>> wants to do so >>>=20 >>=20 >> This does not make sense. If we are talking about securing a = protocol, > that >> better be a complete security, not a partial security that's > uncontrollably on >> and off. In this case, when the server wants to send a message, if = it's > lucky >> it'll find a live security association and send the message securely. = If > it's >> unlucky (there is no live SA), then bad luck -- packet is dropped w/o >> transmission. Because sending an unsecure packet does not make sense, = it's >> at best useless, at worst harmful if we expect the clients to act on = them. >=20 >=20 > I find this to be a completely appropriate behavior. Before I left = the > e-mail group at Microsoft I had just come to the realization that I no > longer believe that all email messages needed to have S/MIME = signatures > verified prior to showing the message to the recipient. The = validation > process could be deferred until one of a number of different trigger = events > occurred. I changed groups because the Outlook group was not = interested in > doing another round of changes in behavior so I never had the long > discussions to get my ideas into the program. >=20 > However this represents a similar behavior. As a client I get a = message, > would I care about the content of the message? If so then I can find = out if > the message is real. If I don't care about the content of the message = then > why should I care if it is real or spam? =20 >=20 > The act that the client is expected to do is to ask the server if the > message is real (assuming it cares) before performing operations on = the > message. That seems to be a totally reasonable behavior. >=20 Are there real and used examples of this approach you are describing? I think it's flawed. Following your email example, I can easily see people losing nerves = clicking the "authenticate this message, now!" button when seeing emails = like "your cat has died!" and "you are promoted to become VP!" :-) In terms of software processing, what kind of message would the receiver = not care? If it does not care, why the other end is sending that message = to it=85=20 Even for understanding if the receiver cares about the packet, it needs = to "consume" the payload. And that payload may already be altered = enroute, since the packet is not integrity-protected. That's a security = hole. Alper > Jim >=20 >>=20 >>=20 >>> 2) Change things and let the server start an EAP session. >>>=20 >>> 3) Require the client to start an EAP session whenever the old = session >>> goes away. >>>=20 >>=20 >> 2&3 make sense. >>=20 >> I'd say the protocol shall support the capabilities needed for both 2 = and > 3. >> And leave it to the deployment to decide when to use them. >>=20 >>> The details as they apply to PCP are best discussed on that list. >>=20 >>=20 >> Alper >>=20 >> _______________________________________________ >> abfab mailing list >> abfab@ietf.org >> https://www.ietf.org/mailman/listinfo/abfab >=20 From hartmans@painless-security.com Wed Nov 28 17:15:47 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77B4A21F8421 for ; Wed, 28 Nov 2012 17:15:47 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1NIQPWZYkef for ; Wed, 28 Nov 2012 17:15:47 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 019D421F849E for ; Wed, 28 Nov 2012 17:15:47 -0800 (PST) Received: from carter-zimmerman.suchdamage.org (c-98-217-126-210.hsd1.ma.comcast.net [98.217.126.210]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS id 8226220167; Wed, 28 Nov 2012 20:14:05 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 17076420E; Wed, 28 Nov 2012 20:15:45 -0500 (EST) From: Sam Hartman To: Alper Yegin References: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> Date: Wed, 28 Nov 2012 20:15:45 -0500 In-Reply-To: (Alper Yegin's message of "Sat, 17 Nov 2012 01:57:53 +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] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 01:15:47 -0000 >>>>> "Alper" == Alper Yegin writes: Alper> Sam, If you search for the keyword "discard" in RFC 3748, you Alper> see lots of instances. That's for "EAP layer discarding." BTW, thanks for this citation; it was useful. I had read most of the text in question before and was in fact even aware of the behavior, but for some reason didn't think of it as discarding.. I know, that makes no sense at all: the spec calls it discarding. I think Jim's proposed fix for this is good. I just wanted to thank you for helping me solve my confusion. --Sam From alper.yegin@yegin.org Wed Nov 28 23:44:36 2012 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A5521F89F8 for ; Wed, 28 Nov 2012 23:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.429 X-Spam-Level: X-Spam-Status: No, score=-102.429 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 Zms6Bkw2bSAF for ; Wed, 28 Nov 2012 23:44:35 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A943E21F89F1 for ; Wed, 28 Nov 2012 23:44:35 -0800 (PST) Received: from [192.168.2.7] (88.247.135.202.static.ttnet.com.tr [88.247.135.202]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MUHso-1TmKVy4Agk-00QZYa; Thu, 29 Nov 2012 02:44:32 -0500 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_566E66B2-D4D1-4615-A1BF-ABBD90D292A0" From: Alper Yegin In-Reply-To: Date: Thu, 29 Nov 2012 09:44:14 +0200 Message-Id: <60701EFE-CD95-4BC1-B9E6-2CF396CF4701@yegin.org> References: <3ABD7C0D-F040-4018-AFFC-0F7312B66AB6@yegin.org> To: Sam Hartman X-Mailer: Apple Mail (2.1278) X-Provags-ID: V02:K0:m0VaTRVr91jbDzAK+x0WuVAArT8XGsPQbutmVanwcc2 9kWWHaHJz6wTJuOiBkSAz0wZAM8xjszNHlA7N90OnnRSEma0PW xYp7ju44702UieTtV6qElJWISMv/y3RRDwCO1+0kmKFS8/Da3d VNp70GWrGM/aLvECvXfyPCUS1GHwqp4B0BXHqm9n7nQYgfOxZM 5u6N4LyGAkpvexwIo1FYqxCH4peBv9JrqTNF1s10uiZhgZWqKR BluuWofDNG1Sb1mnDG3yP5Ex4+k0C+HChJ9unWaRmFDRHy/a8x xtdpHryLi8yCiLvNrH1IYO47pSlv5SddFebOQQ2VupmV7c3RW3 lckoW/nX+pZltUz3xx1HZ/h29vFs346K1Hc0ZxSwGlh77exGJM TURLfMcC/vQxw== Cc: abfab@ietf.org Subject: Re: [abfab] Retransmission Text for EAP applicability X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Application Bridging, Federated Authentication Beyond \(the web\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 07:44:37 -0000 --Apple-Mail=_566E66B2-D4D1-4615-A1BF-ABBD90D292A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Nov 29, 2012, at 3:15 AM, Sam Hartman wrote: >>>>>> "Alper" =3D=3D Alper Yegin writes: >=20 > Alper> Sam, If you search for the keyword "discard" in RFC 3748, = you > Alper> see lots of instances. That's for "EAP layer discarding." >=20 > BTW, thanks for this citation; it was useful. I had read most of the > text in question before and was in fact even aware of the behavior, = but > for some reason didn't think of it as discarding.. I know, that makes = no > sense at all: the spec calls it discarding. >=20 > I think Jim's proposed fix for this is good. I just wanted to thank = you > for helping me solve my confusion. >=20 No problem. But I don't understand how you think the text is good. Do you care to = explain your views on the issues I raised below: Begin forwarded message: > From: Alper Yegin > Subject: Re: [abfab] Retransmission Text for EAP applicability > Date: November 22, 2012 12:39:27 PM GMT+02:00 > To: Jim Schaad > Cc: abfab@ietf.org >=20 >>>> 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 an EAP method discarding a message, = although >>>> the specific way in which discarded messages will be handled depend = on >>>> the characteristics of the application. >>>=20 >>> Now, saying "MUST handle" and then leaving the way it's handled = out-of >>> scope does not make sense. >>=20 >> I think this makes perfect sense. We have just said that how it is = going to >> happen - in fact what the correct response to happen - is going to be = based >> on the specific application we are discussing. This means that we = can't say >> what it should do. >>=20 >=20 > Why would the application care what happens when an EAP-layer or EAP = method-layer message is discarded? > If an EAP-layer message is discarded, it's for the EAP-layer to deal = with that. > If an EAP method-layer message is discarded, it's for the EAP method = layer to deal with that. >=20 > If you are designing a protocol that needs to deal with what happens = at 1 or 2 layers above, then I'd say there's an issue with this design. > This is like saying, if HTTP discards a packet, then IP MUST handle = this.=20 >=20 >=20 >> Some applications will assume transmission error and send the fact = that the >> EAP packet was not processed. (I kind of expect TEAP to do this = behavior). >>=20 >> Some applications will treat it as an Access-Fail and kill the whole >> process. >>=20 >> We cannot dictate what the correct behavior should be. >>=20 >=20 > Because, that's not the business of this layer. Having a MUST w/o a = clear normative text and this explanation is the indication of the = problem. Don't you think? >=20 >>>=20 >>>> Options include >>>> failing the authentication at the application level >>>=20 >>> This is problematic. If the EAP method has discarded the message, = now you >>> need this be conveyed down the stack to the EAP lower-layer. This = does not >>> happen today. And enforcing that requires changing existing EAP = methods, >>> creating additional requirement on future methods. >>=20 >> If I make a call to the EAP handler, it does not say that I got an >> Access-Accept or an Access-Reject, and it does not return anything = for me to >> send back continuing the conversation. This sounds like a pretty = good clue >> the packet was dropped on the floor given the lock-step behavior of = EAP >> itself. >>=20 >=20 > Nope. Maybe the EAP method is awaiting an input from the user. The = "EAP lower layer" cannot know what's going on at the EAP method layer. >=20 >> I don't see any need to change either current EAP behavior or future >> behavior. =20 >>=20 >>>=20 >>>> and waiting for >>>> additional EAP input, possibly after an EAP retransmit. >>>>=20 >>>=20 >>> Who is retransmitting here? The EAP peer? If so, we need to clarify = that. >> And >>> also described how the EAP peer decides to retransmit, and what it = really >>> retransmits (the previous EAP response?). >>>=20 >>=20 >> That is going to be application specific behavior. In part it is = going to >> depend on who dropped the message on the floor and who actually has = the >> ability to even try and do the resend. Without knowing your = application >> data flow, I cannot answer this question. >>=20 >=20 > The options provided by the text is ambiguous.=20 >=20 >=20 >>>=20 >>> Is this text meant to cover how the EAP conversation can be made = reliable >>> with client-driven retransmissions? I see the implications of it, = but not >> clear >>> and complete description of it. >>=20 >> No. That may be one of the things that an application may define, = but it is >> not required in any way. >=20 >=20 > I'd say if this text is meant to cover that possibility, then we need = to make it very clear. Otherwise, the text is rather vague=85 >=20 > Alper >=20 --Apple-Mail=_566E66B2-D4D1-4615-A1BF-ABBD90D292A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
"Alper" =3D=3D Alper Yegin = <alper.yegin@yegin.org>= = writes:

   Alper> Sam, If you search for the keyword = "discard" in RFC 3748, you
   Alper> see lots of = instances. That's for "EAP layer discarding."

BTW, thanks for = this citation; it was useful. I had read most of the
text in question = before and was in fact even aware of the behavior, but
for some = reason didn't think of it as discarding.. I know, that makes no
sense = at all: the spec calls it discarding.

I think Jim's proposed fix = for this is good. I just wanted to thank you
for helping me solve my = confusion.


No = problem.

But I don't understand how you think = the text is good. Do you care to explain your views on the issues I = raised below:

Begin forwarded = message:

Alper Yegin <alper.yegin@yegin.org>
Re: [abfab] Retransmission Text for EAP = applicability
November 22, 2012 12:39:27 PM = GMT+02:00
Jim Schaad <ietf@augustcellars.com>
<= /span>

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 an EAP method discarding a = message, although
the = specific way in which discarded messages will be handled depend = on
the = characteristics of the = application.

Now, saying "MUST handle" and = then leaving the way it's handled = out-of
scope does not make = sense.

I think this = makes perfect sense.  We have just said that how it is going = to
happen - in fact what the = correct response to happen - is going to be = based
on the specific = application we are discussing.  This means that we can't = say
what it should = do.


Why = would the application care what happens when an EAP-layer or EAP = method-layer message is discarded?
If an EAP-layer message is = discarded, it's for the EAP-layer to deal with that.
If an EAP = method-layer message is discarded, it's for the EAP method layer to deal = with that.

If you are designing a protocol that needs to deal = with what happens at 1 or 2 layers above, then I'd say there's an issue = with this design.
This is like saying, if HTTP discards a packet, = then IP MUST handle this. 


Some = applications will assume transmission error and send the fact that = the
EAP packet was not = processed.  (I kind of expect TEAP to do this = behavior).

Some = applications will treat it as an Access-Fail and kill the = whole
process.

We cannot = dictate what the correct behavior should be.


Because, that's not the business of = this layer. Having a MUST w/o a clear normative text and this = explanation is the indication of the problem. Don't you = think?


Options = include
failing = the authentication at the application = level

This is problematic. If the EAP = method has discarded the message, now = you
need this be conveyed down the stack to the EAP = lower-layer. This does not
happen today. And enforcing that = requires changing existing EAP = methods,
creating additional requirement = on future methods.

If I make a = call to the EAP handler, it does not say that I got = an
Access-Accept or an = Access-Reject, and it does not return anything for me = to
send back continuing the = conversation.   This sounds like a pretty good = clue
the packet was dropped on = the floor given the lock-step behavior of = EAP
itself.


Nope. Maybe the EAP method is = awaiting an input from the user. The "EAP lower layer" cannot know = what's going on at the EAP method layer.

I don't see any need to change either current EAP behavior = or future
behavior. =  


and = waiting for
additional EAP input, possibly after an EAP = retransmit.


Who is retransmitting here? The = EAP peer? If so, we need to clarify = that.
And
also described how the EAP peer decides to retransmit, and = what it really
retransmits (the previous EAP = response?).


That is going = to be application specific behavior.  In part it is going = to
depend on who dropped the = message on the floor and who actually has = the
ability to even try and do = the resend.    Without knowing your = application
data flow, I = cannot answer this question.


The options provided by the text is = ambiguous. 



Is this text meant to cover how = the EAP conversation can be made = reliable
with client-driven = retransmissions? I see the implications of it, but = not
clear
and complete description of = it.

No.  That = may be one of the things that an application may define, but it = is
not required in any = way.


I'd say if this text is meant to cover that = possibility, then we need to make it very clear. Otherwise, the text is = rather = vague=85

Alper


= --Apple-Mail=_566E66B2-D4D1-4615-A1BF-ABBD90D292A0--