|
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. 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/> |