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

"Alper Yegin" <alper.yegin@yegin.org> Thu, 20 May 2010 14:21 UTC

Return-Path: <alper.yegin@yegin.org>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BCC13A6C1F; Thu, 20 May 2010 07:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.841
X-Spam-Level: **
X-Spam-Status: No, score=2.841 tagged_above=-999 required=5 tests=[AWL=1.391, BAYES_50=0.001, MSGID_MULTIPLE_AT=1.449]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ERZqeqb0nKo; Thu, 20 May 2010 07:21:01 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 089CB3A6D1E; Thu, 20 May 2010 07:18:30 -0700 (PDT)
Received: from ibm (dsl.static.85-105-43069.ttnet.net.tr [85.105.168.61]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0McV0i-1NxRCR26oS-00ILjz; Thu, 20 May 2010 10:18:22 -0400
From: Alper Yegin <alper.yegin@yegin.org>
To: 'Sam Hartman' <hartmans-ietf@mit.edu>, saag@mit.edu
References: <tslbpciqojd.fsf@mit.edu>
In-Reply-To: <tslbpciqojd.fsf@mit.edu>
Subject: RE: [Emu] Summary of Federated Authentication BOF at IETF 77
Date: Thu, 20 May 2010 17:18:03 +0300
Message-ID: <005901caf827$47550e50$d5ff2af0$@yegin>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Content-language: en-us
Thread-index: AcrzmpQtoe7feQCCSLaIZxkt3D10hAEieX7w
X-Provags-ID: V01U2FsdGVkX1/mPFLphe2SPqjXDe021MnJkKkCUHZ4nAOUMrP hcVHFt1DfioBapz3SkNWtYt3RKfmiyWn3ctaColu6AsYd3FSTY 6mwrQ9uPvVE9jy5zfh44BntHk+wCvXY
X-Mailman-Approved-At: Thu, 20 May 2010 09:15:19 -0700
Cc: kitten@ietf.org, moonshot-community@jiscmail.ac.uk, emu@ietf.org
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2010 14:21:03 -0000

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: emu-bounces@ietf.org [mailto:emu-bounces@ietf.org] On Behalf Of
> Sam Hartman
> Sent: Friday, May 14, 2010 10:20 PM
> To: saag@mit.edu
> Cc: kitten@ietf.org; moonshot-community@jiscmail.ac.uk; emu@ietf.org
> Subject: [Emu] Summary of Federated Authentication BOF at IETF 77
> 
> 
> 
> 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.
> _______________________________________________
> Emu mailing list
> Emu@ietf.org
> https://www.ietf.org/mailman/listinfo/emu