[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Dime] FEDAUTH BOF request
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/>