Summary of Federated Authentication BOF at IETF 77

Sam Hartman <hartmans-ietf@mit.edu> Fri, 14 May 2010 19:21 UTC

From: Sam Hartman <hartmans-ietf@mit.edu>
To: saag@mit.edu
Subject: Summary of Federated Authentication BOF at IETF 77
Date: Fri, 14 May 2010 15:19:34 -0400
Message-ID: <tslbpciqojd.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org
Precedence: list

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.

Summary of Federated Authentication BOF at IETF 77 Sam Hartman
RE: [Emu] Summary of Federated Authentication BOF… Alper Yegin