From nobody Sun Nov 9 04:52:24 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 280EA1A1AA2 for ; Sun, 9 Nov 2014 04:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.005 X-Spam-Level: X-Spam-Status: No, score=0.005 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a1143TwDYUTO for ; Sun, 9 Nov 2014 04:52:20 -0800 (PST) Received: from xenon22.um.es (xenon22.um.es [155.54.212.162]) by ietfa.amsl.com (Postfix) with ESMTP id C57781A1AA0 for ; Sun, 9 Nov 2014 04:52:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon22.um.es (Postfix) with ESMTP id 137C5C841 for ; Sun, 9 Nov 2014 13:52:18 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon22.um.es Received: from xenon22.um.es ([127.0.0.1]) by localhost (xenon22.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZTbckC-9iSor for ; Sun, 9 Nov 2014 13:52:17 +0100 (CET) Received: from [31.133.142.142] (dhcp-8e8e.meeting.ietf.org [31.133.142.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon22.um.es (Postfix) with ESMTPSA id 62CA41C2C for ; Sun, 9 Nov 2014 13:52:15 +0100 (CET) Message-ID: <545F637C.1080705@um.es> Date: Sun, 09 Nov 2014 02:52:12 -1000 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: "abfab@ietf.org" References: <20141027173338.20163.8329.idtracker@ietfa.amsl.com> <544E8501.4060806@um.es> In-Reply-To: <544E8501.4060806@um.es> Content-Type: multipart/alternative; boundary="------------010108070607000004020300" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/_zzv6w7ePP9Fnfc6pqCxsvUFTd4 Subject: Re: [abfab] Fwd: New Version Notification for draft-perez-abfab-wg-arch-erp-00.txt X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 09 Nov 2014 12:52:23 -0000 This is a multi-part message in MIME format. --------------010108070607000004020300 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear all, although there will not be an ABFAB session, if any of you is interested on hearing or discussing about our ABFAB-ERP draft, we can meet during the Wednesday morning break (1130-1300). Just drop me an email, and we will look for a place to chat. If you are interested but can't make it on Wednesday, we can find another date as well. Best regards, Alejandro El 27/10/14 a las 07:46, Alejandro Perez Mendez escribi=F3: > Dear all, > > we have submitted a new draft called "ERP extensions for the ABFAB > architecture". The draft aims to define the required extensions to > make the ABFAB architecture to support the execution of ERP exchanges, > in order to provide an enhanced fast re-authentication and Single > Sign-On (SSO) support, and a better resource utilization. This I-D is > a result from our work in the GN3plus OpenCall CLASSe project > (www.um.es/classe). > > In addition to the usual mailing list discussion, and although there > will not be an ABFAB meeting in Honolulu, I will be pleased to meet > with those of you attending the meeting and want to discuss the > proposal, provide critics, comments and/or feedback. > > Regards, > Alejandro > > > > -------- Mensaje reenviado -------- > Asunto: New Version Notification for > draft-perez-abfab-wg-arch-erp-00.txt > Fecha: Mon, 27 Oct 2014 10:33:38 -0700 > De: internet-drafts@ietf.org > Para: Alejandro Perez-Mendez , Alejandro Perez-Mendez > , Rafa Marin-Lopez , Rafael Lopez > , Gabriel Lopez-Millan , Gabriel > Lopez-Millan , Fernando Pereniguez-Garcia > , Fernando Pereniguez-Garcia > > > > A new version of I-D, draft-perez-abfab-wg-arch-erp-00.txt > has been successfully submitted by Alejandro Perez-Mendez and posted to= the > IETF repository. > > Name: draft-perez-abfab-wg-arch-erp > Revision: 00 > Title: ERP extensions for the ABFAB architecture > Document date: 2014-10-27 > Group: Individual Submission > Pages: 16 > URL: http://www.ietf.org/internet-drafts/draft-perez-abfab-w= g-arch-erp-00.txt > Status: https://datatracker.ietf.org/doc/draft-perez-abfab-wg-a= rch-erp/ > Htmlized: http://tools.ietf.org/html/draft-perez-abfab-wg-arch-er= p-00 > > > Abstract: > The Application Bridging for Federated Access Beyond Web (ABFAB) > architecture [I-D.ietf-abfab-arch] allows the use of EAP to perform > access control to a wide range of applications. This document > describes the extensions required to incorporate support for the EAP= > Extensions for the EAP Re-authentication Protocol (ERP) to this > architecture, in order to provide an enhanced fast re-authentication= > and Single Sign-On (SSO) support and a better resource utilization. > Authorization aspects are also described. > > = =20 > > > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------010108070607000004020300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear all,

although there will not be an ABFAB session, if any of you is interested on hearing or discussing about our ABFAB-ERP draft, we can meet during the Wednesday morning break (1130-1300). Just drop me an email, and we will look for a place to chat.

If you are interested but can't make it on Wednesday, we can find another date as well.

Best regards,
Alejandro

El 27/10/14 a las 07:46, Alejandro Perez Mendez escribió:
Dear all,

we have submitted a new draft called "ERP extensions for the ABFAB architecture". The draft aims to define the required extensions to make the ABFAB architecture to support the execution of ERP exchanges, in order to provide an enhanced fast re-authentication and Single Sign-On (SSO) support, and a better resource utilization. This I-D is a result from our work in the GN3plus OpenCall CLASSe project (www.um.es/classe).

In addition to the usual mailing list discussion, and although there will not be an ABFAB meeting in Honolulu, I will be pleased to meet with those of you attending the meeting and want to discuss the proposal, provide critics, comments and/or feedback.

Regards,
Alejandro



-------- Mensaje reenviado --------
Asunto: New Version Notification for draft-perez-abfab-wg-arch-erp-00.txt
Fecha: Mon, 27 Oct 2014 10:33:38 -0700
De: internet-drafts@ietf.org
Para: Alejandro Perez-Mendez <alex@um.es>, Alejandro Perez-Mendez <alex@um.es>, Rafa Marin-Lopez <rafa@um.es>, Rafael Lopez <rafa@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Gabriel Lopez-Millan <gabilm@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es>, Fernando Pereniguez-Garcia <pereniguez@um.es> 


A new version of I-D, draft-perez-abfab-wg-arch-erp-00.txt
has been successfully submitted by Alejandro Perez-Mendez and posted to the
IETF repository.

Name:		draft-perez-abfab-wg-arch-erp
Revision:	00
Title:		ERP extensions for the ABFAB architecture
Document date:	2014-10-27
Group:		Individual Submission
Pages:		16
URL:            http://www.ietf.org/internet-drafts/draft-perez-abfab-wg-arch-erp-00.txt
Status:         https://datatracker.ietf.org/doc/draft-perez-abfab-wg-arch-erp/
Htmlized:       http://tools.ietf.org/html/draft-perez-abfab-wg-arch-erp-00


Abstract:
   The Application Bridging for Federated Access Beyond Web (ABFAB)
   architecture [I-D.ietf-abfab-arch] allows the use of EAP to perform
   access control to a wide range of applications.  This document
   describes the extensions required to incorporate support for the EAP
   Extensions for the EAP Re-authentication Protocol (ERP) to this
   architecture, in order to provide an enhanced fast re-authentication
   and Single Sign-On (SSO) support and a better resource utilization.
   Authorization aspects are also described.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat






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

--------------010108070607000004020300-- From nobody Wed Nov 12 18:00:24 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 782DE1A1AC5 for ; Wed, 12 Nov 2014 18:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f_whfPwNSjlM for ; Wed, 12 Nov 2014 18:00:20 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02451A1AC4 for ; Wed, 12 Nov 2014 18:00:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 2D18A20470 for ; Wed, 12 Nov 2014 20:58:02 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uN1GZTItQfmP for ; Wed, 12 Nov 2014 20:58:01 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-890c.meeting.ietf.org [31.133.137.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Wed, 12 Nov 2014 20:58:01 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 842D38148E; Wed, 12 Nov 2014 21:00:16 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Wed, 12 Nov 2014 21:00:16 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/Uf3JdK-tUjqL9UYa5ah4mUUk6pk Subject: [abfab] ABFAb and Fast Reauthentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 13 Nov 2014 02:00:22 -0000 Alejandro and I have been discussing fast-reauthentication over the last couple of days including a very useful lunch discussion today. Here's my thoughts: There are fairly easy approaches for fast reauthentication to a service you've recently talked to. The Moonshot code includes one such approach as a non-standardized extension. There are a number of common problems when you want to do fast re-authentication between services. The biggest is deciding what realm the service belongs in. In general, you cannot trust the service to help you with this. Consider. evil.com and example.com are both in a federation. Your identity will work with either. Which realm does foo.example.net belong to? Evil.com would be delighted if they could convince you that it belonged to their realm. They'd also be delighted if they could MITM your connection and tell you that it belonged to evil.com and have you believe it. Today, we go all the way back to the home server and use EAP channel binding to resolve this. It works, but involves a performance penalty. There are policy-related concerns beyond that. We've been talking about policy based on gss-acceptor-host-name as well as a currently-moonshot-specific concept called community. Community can be thought of as a sub-federation governing policy rules. Currently we've been assuming the EAP server could apply policy like this. Are we comfortable delegating all that to the visited realm? There are privacy concerns related to realm discovery. Typically when I try fast reauthentication with a service, I will expose my home realm. Indicating that you have an identity in a particular realm is a privacy-sensitive decision. It's something users often consent to, but it does have privacy implications. It also triggers another privacy disclosure. Then, the infrastructure, possibly including the home EAP server, learns that a given user chooses to access a given service. In cases where the client knows the acceptor realm name, it might be reasonable to assume that two services in the same acceptor realm are in the same realm for fast re-reauthentication. In practice, though we find clients basically never know the realm name. (gss-acceptor-realm-name specified by the client proves less useful than we anticipated when we wrote the spec in existing deployments) There are two solutions that have been discussed: Alejandro's draft on using ERP. Advantages: * Most consistent with the existing model * There's some documentation * He's working on it. Needed standardization: * Extend RFC 7055 to support ERP. He's doing that. * Extend ERP to support EAP channel bindings. This proves kind of tricky because it's not clear that you'd trust the visited domain to actually validate channel bindings. If you force ERP back to the home domain, you remove much of the value. * Add ERP RADIUS support. So far only defined for diameter Disadvantages: * RADIUS servers aren't going to support ERP today * Requires RADIUS to maintain key state on all active authentication sessions * Requires good EMSK key handling. * Not clear how to handle server authentication. Need to understand how the key hierarchy really works to evaluate this. Need to consider how this interacts with channel binding. Kerberos Approach Advantages: * An RFC 7055 implementation is likely to have an RFC 4121 implementation around. * We already have proof-of-concept code for the single server case * Kerberos lets the client maintain state; RADIUS would not need to maintain per-session state. * If you solve the realm discovery problem, Kerberos naming is close enough to ABFAb naming that you can avoid channel bindings and solve server authentication. What needs doing: * Specify the protocol * Define some sort of agent that gets the initial server its key and the user a TGT. My preferred embodyment of this is EAP preauthentication, but doing that is probably too complex for available energy * Implement the agent and expand the existing code Disadvantages: * An extra round trip over ERP. It will be a round trip entirely within the visited domain. * The agent to get the TGT is kind of tricky and might need to involve changes or software running on the KDC. * No one is working on this. I'd like to see if we can make some progress on the hard problems of realm discovery and policy that all solutions to this problem will have in common. --Sam From nobody Thu Nov 13 17:10:39 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04361A1ABB for ; Thu, 13 Nov 2014 17:10:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.595 X-Spam-Level: X-Spam-Status: No, score=-0.595 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.594] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qfnQ2Ze1xzHD for ; Thu, 13 Nov 2014 17:10:36 -0800 (PST) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE1D1A1AB2 for ; Thu, 13 Nov 2014 17:10:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5B7662045B for ; Thu, 13 Nov 2014 20:08:16 -0500 (EST) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuMPRfQnVxgd for ; Thu, 13 Nov 2014 20:08:16 -0500 (EST) Received: from carter-zimmerman.suchdamage.org (dhcp-9be0.meeting.ietf.org [31.133.155.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS for ; Thu, 13 Nov 2014 20:08:15 -0500 (EST) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 56F91804EA; Thu, 13 Nov 2014 20:10:33 -0500 (EST) From: Sam Hartman To: abfab@ietf.org Date: Thu, 13 Nov 2014 20:10:33 -0500 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/EWSv-xb3ZPuTt-Svd08YwgMLrOg Subject: [abfab] ephemeral keying document X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 14 Nov 2014 01:10:38 -0000 We seem to have dropped the ball on the ephemeral keying document. It would really be good to get that to move forward. Is anyone willing to contribute energy to it? Jim Schaad is sitting here prodding me about it. From nobody Fri Nov 14 09:22:57 2014 Return-Path: X-Original-To: abfab@ietfa.amsl.com Delivered-To: abfab@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECFF1A1A22 for ; Fri, 14 Nov 2014 09:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.794 X-Spam-Level: X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmPmKwSImZAW for ; Fri, 14 Nov 2014 09:22:41 -0800 (PST) Received: from xenon23.um.es (xenon23.um.es [155.54.212.163]) by ietfa.amsl.com (Postfix) with ESMTP id ED8CA1A1A16 for ; Fri, 14 Nov 2014 09:22:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by xenon23.um.es (Postfix) with ESMTP id 44130CD73 for ; Fri, 14 Nov 2014 18:22:39 +0100 (CET) X-Virus-Scanned: by antispam in UMU at xenon23.um.es Received: from xenon23.um.es ([127.0.0.1]) by localhost (xenon23.um.es [127.0.0.1]) (amavisd-new, port 10024) with LMTP id O6613agyHQWM for ; Fri, 14 Nov 2014 18:22:39 +0100 (CET) Received: from [31.133.147.232] (dhcp-93e8.meeting.ietf.org [31.133.147.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: alex) by xenon23.um.es (Postfix) with ESMTPSA id 68425C56 for ; Fri, 14 Nov 2014 18:22:37 +0100 (CET) Message-ID: <54663A59.2060107@um.es> Date: Fri, 14 Nov 2014 07:22:33 -1000 From: Alejandro Perez Mendez User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: abfab@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------030304090609050200060002" Archived-At: http://mailarchive.ietf.org/arch/msg/abfab/r3T0hQZbpgO08jseP3mlYFc3Jgc Subject: Re: [abfab] ABFAb and Fast Reauthentication X-BeenThere: abfab@ietf.org X-Mailman-Version: 2.1.15 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, 14 Nov 2014 17:22:52 -0000 This is a multi-part message in MIME format. --------------030304090609050200060002 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hi Sam, thanks for summarizing the discussion. We need to think about these aspects you've mentioned, and will provide feedback during the next weeks. Regarding the Kerberos-based approach, would it be possible to get a more detailed description? I think I have a good idea of how it works when it is the RP the one that generates the ST, but I'd like to know more about agent you mention, and how it would interact with the end user and the KDC to provide the former with a TGT. Finally, as a preliminary thought, ERP keys already include the RP's realm during the derivation process. That means that they should provide something similar to a channel binding, don't they? The ERP derivation process is as follows. 1. EMSK -> DSRK. Performed by end user and home AAA. It involves RP realm's name in the derivation process. 2. DSRK -> DS-rRK. Performed by end user and home AAA, and distributed to the AAA proxy. 3. DS-rRK -> rMSK. Performed by end user and AAA proxy, and distributed to the RP. It is used as the MSK. Therefore the rMSK includes the RP's realm into its derivation process. If the end user or the home AAA server differ on their view, the keys will differ as well, and the communication will fail. Regards, Alejandro El 12/11/14 a las 16:00, Sam Hartman escribió: > Alejandro and I have been discussing fast-reauthentication over the last > couple of days including a very useful lunch discussion today. > Here's my thoughts: > > There are fairly easy approaches for fast reauthentication to a service > you've recently talked to. The Moonshot code includes one such approach > as a non-standardized extension. > > > There are a number of common problems when you want to do fast > re-authentication between services. > > The biggest is deciding what realm the service belongs in. In general, > you cannot trust the service to help you with this. Consider. evil.com > and example.com are both in a federation. Your identity will work with > either. > Which realm does foo.example.net belong to? Evil.com would be delighted > if they could convince you that it belonged to their realm. They'd also > be delighted if they could MITM your connection and tell you that it > belonged to evil.com and have you believe it. > > Today, we go all the way back to the home server and use EAP channel > binding to resolve this. > It works, but involves a performance penalty. > > There are policy-related concerns beyond that. > We've been talking about policy based on gss-acceptor-host-name as well > as a currently-moonshot-specific concept called community. Community > can be thought of as a sub-federation governing policy rules. > Currently we've been assuming the EAP server could apply policy like > this. Are we comfortable delegating all that to the visited realm? > > There are privacy concerns related to realm discovery. Typically when I > try fast reauthentication with a service, I will expose my home realm. > Indicating that you have an identity in a particular realm is a > privacy-sensitive decision. It's something users often consent to, but > it does have privacy implications. It also triggers another privacy > disclosure. Then, the infrastructure, possibly including the home EAP > server, learns that a given user chooses to access a given service. > > In cases where the client knows the acceptor realm name, it might be > reasonable to assume that two services in the same acceptor realm are in > the same realm for fast re-reauthentication. > In practice, though we find clients basically never know the realm > name. (gss-acceptor-realm-name specified by the client proves less > useful than we anticipated when we wrote the spec in existing > deployments) > > > There are two solutions that have been discussed: > > Alejandro's draft on using ERP. Advantages: > > * Most consistent with the existing model > > * There's some documentation > > * He's working on it. > > Needed standardization: > > * Extend RFC 7055 to support ERP. He's doing that. > > * Extend ERP to support EAP channel bindings. This proves kind of > tricky because it's not clear that you'd trust the visited domain to > actually validate channel bindings. If you force ERP back to the home > domain, you remove much of the value. > > * Add ERP RADIUS support. So far only defined for diameter > > Disadvantages: > > * RADIUS servers aren't going to support ERP today > > * Requires RADIUS to maintain key state on all active authentication > sessions > > * Requires good EMSK key handling. > > * Not clear how to handle server authentication. Need to understand how > the key hierarchy really works to evaluate this. Need to consider how > this interacts with channel binding. > > Kerberos Approach > > Advantages: > > * An RFC 7055 implementation is likely to have an RFC 4121 > implementation around. > > * We already have proof-of-concept code for the single server case > > * Kerberos lets the client maintain state; RADIUS would not need to > maintain per-session state. > > * If you solve the realm discovery problem, Kerberos naming is close > enough to ABFAb naming that you can avoid channel bindings and solve > server authentication. > > What needs doing: > > * Specify the protocol > > * Define some sort of agent that gets the initial server its key and the > user a TGT. My preferred embodyment of this is EAP > preauthentication, but doing that is probably too complex for > available energy > > * Implement the agent and expand the existing code > > Disadvantages: > > * An extra round trip over ERP. It will be a round trip entirely within > the visited domain. > > * The agent to get the TGT is kind of tricky and might need to involve > changes or software running on the KDC. > > * No one is working on this. > > I'd like to see if we can make some progress on the hard problems of > realm discovery and policy that all solutions to this problem will have > in common. > > --Sam > > _______________________________________________ > abfab mailing list > abfab@ietf.org > https://www.ietf.org/mailman/listinfo/abfab --------------030304090609050200060002 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Hi Sam,

thanks for summarizing the discussion. We need to think about these aspects you've mentioned, and will provide feedback during the next weeks.

Regarding the Kerberos-based approach, would it be possible to get a more detailed description? I think I have a good idea of how it works when it is the RP the one that generates the ST, but I'd like to know more about agent you mention, and how it would interact with the end user and the KDC to provide the former with a TGT.

Finally, as a preliminary thought, ERP keys already include the RP's realm during the derivation process. That means that they should provide something similar to a channel binding, don't they?

The ERP derivation process is as follows.
  1. EMSK -> DSRK. Performed by end user and home AAA. It involves RP realm's name in the derivation process.
  2. DSRK -> DS-rRK. Performed by end user and home AAA, and distributed to the AAA proxy.
  3. DS-rRK -> rMSK. Performed by end user and AAA proxy, and distributed to the RP. It is used as the MSK.

Therefore the rMSK includes the RP's realm into its derivation process. If the end user or the home AAA server differ on their view, the keys will differ as well, and the communication will fail.

Regards,
Alejandro

El 12/11/14 a las 16:00, Sam Hartman escribió:
Alejandro and I have been discussing fast-reauthentication over the last
couple of days including a very useful lunch discussion today.
Here's my thoughts:

There are fairly easy approaches for fast reauthentication to a service
you've recently talked to.  The Moonshot code includes one such approach
as a non-standardized extension.


There are a number of common problems when you want to do fast
re-authentication between services.

The biggest is deciding what realm the service belongs in.  In general,
you cannot trust the service to help you with this.  Consider.  evil.com
and example.com are both in a federation.  Your identity will work with
either.
Which realm does foo.example.net belong to?  Evil.com would be delighted
if they could convince you that it belonged to their realm.  They'd also
be delighted if they could MITM your connection and tell you that it
belonged to evil.com and have you believe it.

Today, we go all the way back to the home server and use EAP channel
binding to resolve this.
It works, but involves a performance penalty.

There are policy-related concerns beyond that.
We've been talking about policy based on gss-acceptor-host-name as well
as  a currently-moonshot-specific concept called community.  Community
can be thought of as a sub-federation governing policy rules.
Currently we've been assuming the EAP server could apply policy like
this.  Are we comfortable delegating all that to the visited realm?

There are privacy concerns related to realm discovery.  Typically when I
try fast reauthentication with a service, I will expose my home realm.
Indicating that you have an identity in a particular realm is a
privacy-sensitive decision.  It's something users often consent to, but
it does have privacy implications.  It also triggers another privacy
disclosure.  Then, the infrastructure, possibly including the home EAP
server, learns that a given user chooses to access a given service.

In cases where the client knows the acceptor realm name, it might be
reasonable to assume that two services in the same acceptor realm are in
the same realm for  fast re-reauthentication.
In practice, though we find clients basically never know the realm
name.  (gss-acceptor-realm-name specified by the client proves less
useful than we anticipated when we wrote the spec in existing
deployments)


There are two solutions that have been discussed:

Alejandro's draft on using ERP.  Advantages:

* Most consistent with the existing model

* There's some documentation

* He's working on it.

Needed standardization:

* Extend RFC 7055 to support ERP.  He's doing that.

* Extend ERP to support EAP channel bindings.  This proves kind of
  tricky because it's not clear that you'd trust the visited domain to
  actually validate channel bindings.  If you force ERP back to the home
  domain, you remove much of the value.

* Add ERP RADIUS support.  So far only defined for diameter

Disadvantages:

* RADIUS servers aren't going to support ERP today

* Requires RADIUS to maintain key state on all active authentication
  sessions

* Requires good EMSK key handling.

* Not clear how to handle server authentication.  Need to understand how
  the key hierarchy really works to evaluate this.  Need to consider how
  this interacts with channel binding.

Kerberos Approach

Advantages:

* An RFC 7055 implementation is likely to have an RFC 4121
  implementation around.

* We already have proof-of-concept code for the single server case

* Kerberos lets the client maintain state; RADIUS would not need to
  maintain per-session state.

* If you solve the realm discovery problem, Kerberos naming is close
enough to ABFAb naming that you can avoid channel bindings and solve
server authentication.

What needs doing:

* Specify the protocol

* Define some sort of agent that gets the initial server its key and the
  user a TGT.    My preferred embodyment of this is EAP
  preauthentication, but doing that is probably too complex for
  available energy

* Implement the agent and expand the existing code

Disadvantages:

* An extra round trip over ERP.  It will be a round trip entirely within
  the visited domain.

* The agent to get the TGT is kind of tricky and might need to involve
  changes or software running on the KDC.

* No one is working on this.

I'd like to see if we can make some progress on the hard problems of
realm discovery and policy that all solutions to this problem will have
in common.

--Sam

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

--------------030304090609050200060002--