Subject: FEDAUTH BOF request

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 2 Jun 2010 16:56:17 +0200

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Tina TSOU <[email-masked]>
Date: Thu, 03 Jun 2010 12:02:46 +0800

Comments are below.
1. This might be of interest to ngHLR (Unified Subscriber Center) kind of 
solutions who provide Identity Management services
2. From protocol side, I think it may be more interesting for RADIUS as I 
doubt the suitability of Diameter for this.

B. R.
Tina
http://tinatsou.weebly.com/contact.html

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>; "radext mailing list" <[email-masked]>; 
<[email-masked]>
Sent: Wednesday, June 02, 2010 10:56 PM
Subject: FEDAUTH BOF request

Dan

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jun 2010 22:03:16 -0700

Tina said: 

> 2. From protocol side, I think it may be more interesting for RADIUS as I  doubt the suitability of Diameter for this.

Not sure why RADIUS would be more suitable than Diameter for carrying large payloads such as SAML assertions.  The 4096 octet RADIUS PDU limit is not transport-specific -- that is, transporting the RADIUS payload over TCP does not solve the problem.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Jun 2010 22:26:26 -0700

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.

---

From: Tina TSOU <[email-masked]>
Date: Thu, 03 Jun 2010 21:54:28 +0800

Hi Bernard,
Comments are in line.

B. R.
Tina
  ----- Original Message ----- 
  From: Bernard Aboba 
  To: [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] ; [email-masked] 
  Sent: Thursday, June 03, 2010 1:03 PM
  Subject: RE: FEDAUTH BOF request

  [Tina: You are also right from the aspect you raised.
  Diameter roaming model is well established (in use cases like WLAN-3GPP interworking) without the use of EAP or SAML. I fail to see what would be the benefits of using EAP or SAML with Diameter which the current roaming model does not already have.
  Everything has pros and cons, as you said in another email, let's begin with a problem statement, and then protocols.]

---

From: Tina TSOU <[email-masked]>
Date: Thu, 03 Jun 2010 21:57:56 +0800

Hi Wolfgang and Hannes,
You are also right from the good nature of Diameter.
I just mentioned one possible interesting point in my previous email 
replying to Bernard et al.

B. R.
Tina

----- Original Message ----- 
From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>; <[email-masked]>; 
<[email-masked]>
Sent: Thursday, June 03, 2010 3:18 PM
Subject: RE: [Dime] FEDAUTH BOF request

Looking forward to hear that answer as well :-)

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of ext [email-masked]
>Sent: 03 June, 2010 10:16
>To: [email-masked]; [email-masked];
>[email-masked]; [email-masked]; [email-masked]
>Subject: Re: [Dime] FEDAUTH BOF request
>
>Hello Tina,
>
>what assumption let you think RADIUS is more suitable then
>DIAMETER? DIAMETER is much more developed, is a peer to peer
>protocol, designed to transport also structured data, not as
>limited on payload and therefore much better suitable for the
>purpose of IdM.
>
>Best Regards
>
> Wolfgang
>
>-----Ursprüngliche Nachricht-----
>Von: [email-masked] [mailto:[email-masked]] Im
>Auftrag von Tina TSOU
>Gesendet: Donnerstag, 3. Juni 2010 06:03
>An: [email-masked]; radext mailing list; [email-masked];
>Romascanu, Dan (Dan)
>Betreff: Re: [Dime] FEDAUTH BOF request
>
>Comments are below.
>1. This might be of interest to ngHLR (Unified Subscriber
>Center) kind of solutions who provide Identity Management
>services 2. From protocol side, I think it may be more
>interesting for RADIUS as I doubt the suitability of Diameter for this.
>
>B. R.
>Tina
>To: <[email-masked]>; "radext mailing list"
><[email-masked]>; <[email-masked]>
>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.
>
>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
>[email-masked] with the word 'unsubscribe' in
>a single line as the message text body.
>_______________________________________________
>DiME mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>_______________________________________________
>DiME mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dime
>

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 4 Jun 2010 10:30:58 +0300

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.  

Alper> I agree. 

Alper> Anyone who was around the ICOS BoF in IETF 62 would remember that the
community was convinced(!) that using EAP for anything other than network
access was a no-no. Now before we embark on marching in  180-degree opposite
direction, I'd say the community needs to be "unconvinced" first. I'm not
saying this is not doable, but something we need to go through first.

Alper

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Fri, 4 Jun 2010 10:11:22 -0700

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.  

> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Bernard Aboba
> Sent: Wednesday, June 02, 2010 10:26 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 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] 
> move forward in a situation like this is to begin with a problem
> statement, which should include carefully validating the uses cases.
> 
> 
> > 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.
> >
> > http://www.project-moonshot.org/bof/charter/, and more information
> > about this BOF or other BOF requests can be examined at

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 6 Jun 2010 09:13:19 -0700

Previous tests have shown problems with use of RADIUS/EAP over UDP in
federated scenarios:

http://www.cesnet.cz/doc/techzpravy/2008/eduroam-authentication-over-jammed-
network/

As noted in the above paper, once packet loss is introduced, completing the
multiple roundtrips of EAP authentication becomes increasingly difficult. 

RADIUS over TCP holds up much better until a threshold is reached, and then
authentication success fractions fall dramatically.   

Due to the transport issues and RADIUS packet size limitation of 4096 (which
may impact the ability to transport SAML assertions), it seems like Diameter
would be more suitable.  

 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alper Yegin
Sent: Friday, June 04, 2010 12:31 AM
To: 'Bernard Aboba'; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [AAA-DOCTORS] [Dime] FEDAUTH BOF request

 

Alper> I agree. 

Alper

---

From: Peter Deacon <[email-masked]>
Date: Sun, 6 Jun 2010 14:04:39 -0700 (Pacific Daylight Time)

> multiple roundtrips of EAP authentication becomes increasingly difficult.

This paper has some crazy figures.. look at the data for packet loss.

40% packet loss (client to server) = 78% success rate for PEAP-MSCHAPv2
40% packet loss (server to client) = 20% success rate for PEAP-MSCHAPv2

There is a footnote on this issue "The more favorable results for 
client-to-server jamming are caused by the aggressive packet re-sending 
strategy of wpa_supplicant compared to the behavior of Radiator."

If the server did not receive client request or client did not receive 
server response the knowledge available and avenue for response by the 
client is the same in either case.  The figures appear to reflect a 
substantial implementation artifact in the servers tx side retransmit.

regards,
Peter