Subject: [Emu] Summary of Federated Authentication BOF at IETF 77

From: Sam Hartman <[email-masked]>
Date: Fri, 14 May 2010 15:19:34 -0400

I'm told there were around 30 people in the room.  That seemed like a
good turn out for Thursday at 9 PM.

Many of the participants had already read some or all of the proposed
documents.
I presented a problem statement based on providing federated
authentication  for non-web applications.
Two solutions were presented.  I presented work on Moonshot, a
technology that combines EAP, GSS-API, RADIUS and SAML to solve the
problem.  Eliot Lear and Klaas Wierenga presented a simpler solution
that uses browser-based SAML and Open ID.

The sense of the room was that these solutions compliment each other.
Moonshot requires more infrastructure and client configuration but
provides several advantages.  The browser-based solutions are something
that requires fewer client changes.

Volunteers were collected from the EAP, GSS and RADIUS communities who
would be interested in working on these problems.  Some of the work
discussed, possibly especially including the Open ID and SAML
browser-based solutions may be able to progress in kitten.  I and I
believe several of the other Moonshot proponents would prefer to focus
the Moonshot work in one working group.  Other solutions could also be
progressed in that group, although we should be careful not to slow down
work that could progress quickly in kitten by moving it into an
as-yet-unchartered group.

There seemed to be strong support for going forward.  However, several
things to address in a BOF were raised with regard to the Moonshot work.

* Steve Bellovin pointed out that we need to be very aware of the
  operational impact and how this fits with the operational model of the
  technologies that are used/extended.

* Klaas pointed out that Moonshot involves changes to a lot of different
  components.  We need to make sure that there are incremental
  advantages to each of these changes so they will be deployed: a system
  where there is no benefit until the end when all the peaces fall
  together is much harder to deploy.

* Klaas pointed out that we need to consider  the operational security
  around how RADIUS federations are deployed.  If network access is not
  considered sensitive today, people may be more lax in the security
  surrounding their RADIUS infrastructure.  If we use that
  infrastructure to secure more sensitive resources we need to have
  practices that tighten up the security of the infrastructure
  sufficiently.

* Someone brought up that this is another one of those authentication
  proposals where user-interface is critical.  While we should not lay
  out dialogues in the IETF, we're going to need to describe the
  usability aspects of this enough to increase the probability of a good
  security solution.

People specifically asked to look at the following:
* Complexity
* What can't be handled with simpler solutions
* Is Moonshot broad enough in scope?
* The UI questions

Since the bar BOF, there has been a lot of traffic on the list and work
continues.
We're definitely going to put together a BOF request for IETF 78.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 20 May 2010 17:18:03 +0300

Hello,

I have a comment about use of EAP in this context.

Folks might remember the ICOS BoF held during IETF 62. Discussions at that
meeting, around that era, and since then have been always pointing to the
applicability statement of EAP and more-or-less blocking the use of EAP for
anything other than network access.

EAP RFC 3748:

   EAP was designed for use in network access authentication, where IP
   layer connectivity may not be available.  Use of EAP for other
   purposes, such as bulk data transport, is NOT RECOMMENDED.

See the meeting notes at http://www.ietf.org/proceedings/62/icos.html,
especially Sam's (SEC AD at that time):

	Sam: Although having a lot of EAP methods is complicated, deploying
new credentials 
	is also hard. I think the uses of EAP that were discussed here are
close enough to 
	network access that I could see the connection. But when EAP was
expaned from PPP 
	to other uses, a lot of new work was required; if we expand EAP to
services in general, 
	we need at least the same amount of work. We might want to check
that there are 
	no better solutions. So if you're using EAP for something totally
else than 
	network access authentication, please talk to me earlier rather than
later.

I'm not against using EAP for arbitrary applications. If this is where we
are getting at in IETF, I'm hoping this gets proper consideration bridging
where we were 5 years ago and today. 

Was this discussed? Is there a proposal to expand the applicability
statement of EAP now? Where do we draw the new line now?

Thanks in advance.

Alper

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Sam Hartman
> Sent: Friday, May 14, 2010 10:20 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Emu] Summary of Federated Authentication BOF at IETF 77
> 
> 
> 
> _______________________________________________
> Emu mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/emu

---

From: Sam Hartman <[email-masked]>
Date: Thu, 20 May 2010 11:42:24 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    Alper> Was this discussed? Is there a proposal to expand the
    Alper> applicability statement of EAP now? Where do we draw the new
    Alper> line now?

I've certainly been thinking about it.

Quoting http://www.painless-security.com/blog/2010/02/12/moonshot1:

>Itùs interesting that Iùm advocating EAP for application layer
>authentication. When I was a Security AD, I made a strong statement
>that EAP must only be used for network access. Iùve been fairly
>consistent about that since then. I think there are two huge problems
>with using EAP for application authentication. The first is that EAP
>only authenticates the home realm; it does not authenticate what
>service youùre going to. So you might try to connect to your
>e-mail and end up giving something access to your stored files and
>pictures instead. That is, EAP has aphishing exposure in the
>federated context. If the only thing you can get by using EAP is
>network access, that exposure is only moderate. However in a fully
>federated environment that is a huge exposure. Moonshot will address
>thisproblem by using EAP channel binding and by doing the necessary
>work to make that a viable solution. The second concern is that
>interoperability is reduced when you have multiple authentication
>approaches for the same problem. If EAP is going to be used for
>application authentication, we need to understand how it relates to
>the rest of the application authentication metasystem. Moonshot
>proposes such a relationship, addressing my objection.

In addition, if you take look at the work proposed for standardization
spelled out in the feasibility analysis,I propose that we need to
revise the applicability statement for EAP.
Quoting draft-howlett-eap-gss-00:

8.  Applicability Considerations

   Section 1.3 of RFC 3748 provides the applicability statement for EAP.
   Among other constraints, EAP is scoped for use in network access.
   This specification anticipates using EAP beyond its current scope.
   The assumption is that some other document will discuss the issues
   surrounding the use of EAP for application authentication and expand
   EAP's applicability.  That document will likely enumerate
   considerations that a specific use of EAP for application
   authentication needs to handle.  Examples of such considerations
   might include the multi-layer negotiation issue, deciding when EAP or
   some other mechanism should be used, and so forth.  This section
   serves as a placeholder to discuss any such issues with regard to the
   use of EAP and GSS-API.

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 21 May 2010 15:12:52 +0300

> >that EAP must only be used for network access. 

That's right. 

> > Iùve been fairly
> >thisproblem by using EAP channel binding 

"Channel binding" is a term that is specific to the network access
application. 
For generic applications, we need something else. Basically we are talking
about "authorization parameters." App server has verified that you are Joe,
and you are allowed to use X, Y, Z apps/resources. This "authorization"
aspect goes beyond "authentication" (as in extensible "authentication"
protocol). This aspect may not be easy to stick in the EAP. 

and by doing the necessary
> >proposes such a relationship, addressing my objection.

Not sure I understand. EAP-based scheme will still appear as N+1st method. 

>    EAP's applicability.  That document will likely enumerate

Is this document available?

---

From: Sam Hartman <[email-masked]>
Date: Fri, 21 May 2010 11:37:57 -0400

>>>>> "Alper" == Alper Yegin <[email-masked]> writes:

    >> authentication. The first is that EAP >only authenticates the
    >> home realm; it does not authenticate what >service youùre
    >> going to. So you might try to connect to your >e-mail and end up
    >> giving something access to your stored files and >pictures
    >> instead. That is, EAP has aphishing exposure in the >federated
    >> context. If the only thing you can get by using EAP is >network
    >> access, that exposure is only moderate. However in a fully
    >> >federated environment that is a huge exposure. Moonshot will
    >> address >thisproblem by using EAP channel binding

    Alper> "Channel binding" is a term that is specific to the network
    Alper> access application.  For generic applications, we need
    Alper> something else. Basically we are talking about "authorization
    Alper> parameters." App server has verified that you are Joe, and
    Alper> you are allowed to use X, Y, Z apps/resources. This
    Alper> "authorization" aspect goes beyond "authentication" (as in
    Alper> extensible "authentication" protocol). This aspect may not be
    Alper> easy to stick in the EAP.

When I'm speaking of channel binding, I am not speaking of that sort of
authorization.
i'm speaking of giving the peer (not the NAS) confidence  that the peer
has connected to the NAS that the peer intended to connect to.
I argue that when you generalize the NAS so that the NAS is a mail
server, web server, or other app server, the question of which
generalized NAS you're talking to is far more important than in the
network access application.
I believe that both RFC 3748 and draft-ietf-emu-chbind define this
problem as channel binding.

At one level, I don't care what we call it: we need to solve it.

    Alper> and by doing the necessary
    >> >interoperability is reduced when you have multiple
    >> authentication >approaches for the same problem. If EAP is going
    >> to be used for >application authentication, we need to understand
    >> how it relates to >the rest of the application authentication
    >> metasystem. Moonshot >proposes such a relationship, addressing my
    >> objection.

    Alper> Not sure I understand. EAP-based scheme will still appear as
    Alper> N+1st method.

I don't understand your comment here.
It may be something better discussed over the phone or something,
although I'm happy to keep e-mailing on this.

    >> Section 1.3 of RFC 3748 provides the applicability statement for
    >> EAP.  Among other constraints, EAP is scoped for use in network
    >> access.  This specification anticipates using EAP beyond its
    >> current scope.  The assumption is that some other document will
    >> discuss the issues surrounding the use of EAP for application
    >> authentication and expand EAP's applicability.  That document
    >> will likely enumerate

    Alper> Is this document available?

Which document?  The proposed applicability statement for EAP?  No, I'm
hoping that we can work on that in the WG we charter; would you be
interested in helping with that document?  Or are you talking about
draft-howlett-eap-gss?  If so, yes, that is in the ID repository?  Or
were you talking about the feasability analysis?  If so, there is a link
from www.painless-security.com/blog and will soon be a link from
www.project-moonshot.org .

I'd definitely be interested in a discussion with you about these
issues.