RE: [Dime] FEDAUTH BOF request
"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Fri, 04 June 2010 17:18 UTC
Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8459E3A694C for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 4 Jun 2010 10:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.036
X-Spam-Level:
X-Spam-Status: No, score=-9.036 tagged_above=-999 required=5 tests=[AWL=-0.541, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_HI=-8, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ExMBRwsguz8i for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 4 Jun 2010 10:18:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 14BF43A6934 for <radext-archive-IeZ9sae2@lists.ietf.org>; Fri, 4 Jun 2010 10:18:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1OKaQb-000FUy-Ky for radiusext-data0@psg.com; Fri, 04 Jun 2010 17:11:29 +0000
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.71 (FreeBSD)) (envelope-from <jsalowey@cisco.com>) id 1OKaQX-000FTv-Pe for radiusext@ops.ietf.org; Fri, 04 Jun 2010 17:11:26 +0000
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEfQCEyrRN+K/2dsb2JhbACeRnGlSJoRgl+COASDSYM5
X-IronPort-AV: E=Sophos;i="4.53,362,1272844800"; d="scan'208";a="139524287"
Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Jun 2010 17:11:23 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o54HBN6O004272; Fri, 4 Jun 2010 17:11:23 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jun 2010 10:11:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] FEDAUTH BOF request
Date: Fri, 04 Jun 2010 10:11:22 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A9EDD7D@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <BLU137-W24E56D43201C0B9EEB3A4A93D10@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] FEDAUTH BOF request
Thread-Index: AcsC3V6qlMZy6lk0TKacZwhNYrbcbgBJ7grw
References: <EDC652A26FB23C4EB6384A4584434A04022444EC@307622ANEX5.global.avaya.com>, <F3CA54ABFDD5489FAFE036ECB6EE0011@china.huawei.com> <BLU137-W24E56D43201C0B9EEB3A4A93D10@phx.gbl>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, tena@huawei.com, aaa-doctors@ietf.org, radiusext@ops.ietf.org, dime@ietf.org, dromasca@avaya.com
X-OriginalArrivalTime: 04 Jun 2010 17:11:23.0825 (UTC) FILETIME=[F5ADD210:01CB0408]
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>
I agree with a lot of what Bernard says below. For better or for worse EAP is closely associated with AAA. The fit may be odd in some cases, but deployments have found success in making it work. This is why it is attractive. I don't think that replacing EAP in AAA with some other framework, such as GSSAPI, is going to lead to better results. It is true that along the way modifications, such as RADSEC, have been deployed to make things work better. It is risky to assume that AAA and EAP can be successfully applied to any arbitrary scenario without a firm grip on the use cases. If at the end of the design you end up with something that is called EAP and AAA, but actually is completely different you will lose the perceived advantage of building on top of existing AAA and EAP infrastructure I'm not as convinced as Bernard that it can't work, but I think there needs to be a firm understanding of the use cases to determine what is required to deliver a solution and what changes may be necessary. > -----Original Message----- > From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of > Bernard Aboba > Sent: Wednesday, June 02, 2010 10:26 PM > To: tena@huawei.com; aaa-doctors@ietf.org; radiusext@ops.ietf.org; > dime@ietf.org; dromasca@avaya.com > Subject: Re: [Dime] FEDAUTH BOF request > > Let me provide a bit of context about what I think the problem is here. > > As noted by Sam in a previous conversation, the basic use case is "cloud > services", where an education institution or enterprise is making use of > hosted services. In these situations, the institution may not just want > the service provider to host an application, but may want to keep their > credentials local, rather than hosting this in the cloud as well. > > In the original Moonshot investigation, Kerberos was considered as a > potential solution. However, while Kerberos is well understood from a > security point of view, and could relatively easily be modified to support > EAP-based pre-auth (numerous proposals for this have been advanced and in > some cases implemented) Kerberos federation has not been widely deployed. > > One of the basic problems with putting a KDC on the Internet is that there > is no easy way to protect it, since both clients and other KDCs may need > to send packets to and from the KDC. For this reason if there are roaming > clients there is no easy way to filter traffic to/from the KDC. In > addition, the Kerberos protocol is vulnerable to passive attacks in the > absence of extensions such as PKINIT or Kerberos Hardening. > > In contrast, the AAA roaming model has been widely deployed, in part > because it is much easier to protect a AAA server. AAA servers only talk > to AAA clients, not to users directly. This means that it is typically > possible to filter traffic to the AAA server so that only packets > originating from legitimate AAA clients can be sent to/from the AAA > server. > > In addition to these basic security issues, the AAA delegation model is > much simpler than Kerberos. Obtaining a Kerberos TGT for a local realm > involves first obtaining a TGT from a "home" realm and then requesting a > TGT for the local realm. This involves multiple exchanges, and as noted > earlier requires both the local KDC and the home KDC to be available over > the Internet. In contrast, a AAA client implicitly delegates authority to > the AAA server for the Accept/Reject decision, so that explicit trust > relationships don't need to be configured. As long as the AAA client can > reach the AAA server via a chain of proxies the trust relationship can > succeed. > > Given these basic characteristics of Kerberos and AAA delegation, the > Moonshot team has decided that a AAA-based approach to delegation is more > likely to be widely deployed than a Kerberos-based one. My take on this > is that this assessment is probably realistic. > > Where I get lost is making the leap between the AAA delegation model and > use of EAP. As we saw with Digest authentication (RFC 5090), it is > possible to extend AAA to support application-layer authentication without > use of EAP. For example, using AAA to carry GSS-API payloads would not > require much more than defining a GSS-Message attribute. EAP has no > unique properties that make it more suitable for use with AAA. In fact, I > would argue that the fit between EAP and AAA has always been tenuous at > best -- witness the issues encountered in federated EAP authentication > that RADSEC has been needed to address. > > In particular, the problems of EAP auth (e.g. multiple round-trips, > general fragility in federated uses) become highly toxic when applied to > Realtime applications such as XMPP and SIP. As we have learned, Digest > auth (RFC 5090) has not been widely deployed, in part because of concern > about the additional latency added by a AAA exchange. For users of real- > time applications, additional latency is a basic, non-negotiable goal. If > the relatively modest number of exchanges implied by RFC 5090 were > intolerable in realtime applications, how can we expect EAP exchanges > (which can involve 4-5 times the number of roundtrips of RFC 5090) to be > deployed? The answer unfortunately, is that there is no chance at all. > [Joe] > So in summary, I believe that some aspects of the problem statement make > sense, but that a solution has been chosen prematurely. The right way to > move forward in a situation like this is to begin with a problem > statement, which should include carefully validating the uses cases. > > > > ----- Original Message ----- > > From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> > > To: <dime@ietf.org>; "radext mailing list" <radiusext@ops.ietf.org>; > > <aaa-doctors@ietf.org> > > Sent: Wednesday, June 02, 2010 10:56 PM > > Subject: FEDAUTH BOF request > > > > > > Diameter and RADIUS experts should pay attention to the request to > > hold a Federated Authentication (FEDAUTH) BOF which will be discussed > > this morning by the IAB and the IESG. > > > > The Draft Charter is available at > > http://www.project-moonshot.org/bof/charter/, and more information > > about this BOF or other BOF requests can be examined at > > http://trac.tools.ietf.org/bof/trac/ > > > > Dan > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://psg.com/lists/radiusext/> > > > > > > > > -- > > to unsubscribe send a message to radiusext-request@ops.ietf.org with > > the word 'unsubscribe' in a single line as the message text body. > > archive: <http://psg.com/lists/radiusext/> -- to unsubscribe send a message to radiusext-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/radiusext/>
- FEDAUTH BOF request Romascanu, Dan (Dan)
- Re: FEDAUTH BOF request Tina TSOU
- RE: FEDAUTH BOF request Bernard Aboba
- RE: FEDAUTH BOF request Bernard Aboba
- Re: FEDAUTH BOF request Tina TSOU
- Re: [Dime] FEDAUTH BOF request Tina TSOU
- RE: [Dime] FEDAUTH BOF request Alper Yegin
- RE: [Dime] FEDAUTH BOF request Joseph Salowey (jsalowey)
- RE: [AAA-DOCTORS] [Dime] FEDAUTH BOF request Bernard Aboba
- RE: [AAA-DOCTORS] [Dime] FEDAUTH BOF request Peter Deacon