Re: Federated Authentication Beyond The Web: Problem Statement and Requirements

"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> Fri, 09 July 2010 17:32 UTC

Return-Path: <owner-radiusext@ops.ietf.org>
X-Original-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Delivered-To: ietfarch-radext-archive-IeZ9sae2@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44B803A6ACA for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 9 Jul 2010 10:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.721
X-Spam-Level:
X-Spam-Status: No, score=0.721 tagged_above=-999 required=5 tests=[AWL=-0.802, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RCVD_IN_BL_SPAMCOP_NET=1.96, RDNS_NONE=0.1]
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 KtaklRnyqRwU for <ietfarch-radext-archive-IeZ9sae2@core3.amsl.com>; Fri, 9 Jul 2010 10:32:44 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 03C0B3A6A7B for <radext-archive-IeZ9sae2@lists.ietf.org>; Fri, 9 Jul 2010 10:32:05 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-radiusext@ops.ietf.org>) id 1OXHPB-000Kel-8l for radiusext-data0@psg.com; Fri, 09 Jul 2010 17:30:29 +0000
Received: from [213.165.64.20] (helo=mail.gmx.net) by psg.com with smtp (Exim 4.72 (FreeBSD)) (envelope-from <Hannes.Tschofenig@gmx.net>) id 1OXHP8-000KeN-Mv for radiusext@ops.ietf.org; Fri, 09 Jul 2010 17:30:27 +0000
Received: (qmail 4906 invoked by uid 0); 9 Jul 2010 17:30:25 -0000
Received: from 213.162.68.138 by www161.gmx.net with HTTP; Fri, 09 Jul 2010 19:30:22 +0200 (CEST)
Cc: radiusext@ops.ietf.org, dime@ietf.org
Content-Type: text/plain; charset="utf-8"
Date: Fri, 09 Jul 2010 19:30:23 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
In-Reply-To: <4C330810.6010003@wierenga.net>
Message-ID: <20100709173023.107930@gmx.net>
MIME-Version: 1.0
References: <20100706091519.251510@gmx.net> <4C330810.6010003@wierenga.net>
Subject: Re: Federated Authentication Beyond The Web: Problem Statement and Requirements
To: Klaas Wierenga <klaas@wierenga.net>
X-Authenticated: #29516787
X-Flags: 0001
X-Mailer: WWW-Mail 6100 (Global Message Exchange)
X-Priority: 3
X-Provags-ID: V01U2FsdGVkX18utzlm5XYuc57u7LsFv8WbZe8Y+WFPbIE9hA5dYe 8rkUIEheBM+d0bVR/dFFpXrZl7HlGHdpxnZQ==
Content-Transfer-Encoding: 8bit
X-GMX-UID: zjBcJGB/TlI8cJsGtWlr231OU2poZRnR
X-FuHaFi: 0.54000000000000004
Sender: owner-radiusext@ops.ietf.org
Precedence: bulk
List-ID: <radiusext.ops.ietf.org>

Hi Klaas, 

sorry for the late response. 

Interesting statement. 

I agree that there are other approaches (and probably everyone would agree with that; we could even list Kerberos). 

However, the MOONSHOT BOF is (if I understood it correctly) constraint to the mentioned constraints. 

The usage of OpenID in SASL/GSS-API (like you pointed out) will be done in KITTEN independently and has different design constraints. 

Ciao
Hannes

> On 7/6/10 11:15 AM, Hannes Tschofenig wrote:
> 
> Hi Hannes,
> 
> > at the next IETF meeting we are going to have a BOF about "Federated
> Authentication Beyond The Web". In case you have not noticed the work relates
> to RADIUS and Diameter.
> >
> > I wrote this very short problem statement document to explain the
> purpose of the BOF:
> > http://www.ietf.org/internet-drafts/draft-tschofenig-moonshot-ps-00.txt
> >
> > Let me know if you find the description useful. Feedback about the BOF
> topic would also be appreciated.
> 
> I find the description useful, however I would like to challenge the 
> MUST for RADIUS and/or Diamter. There are a number of Federated 
> Authentication for applications access protocols out there, SAML, OpenID 
> and others. RADIUS and Diamter are typically associated with network 
> access. And while I do see the attractiveness of marrying the two (and 
> thus leveraging existing trust fabrics), I wonder why you want to 
> restrict a priori to just those. As an example 
> draft-cantor-ietf-sasl-saml-ec-00.txt, draft-lear-ietf-sasl-openid-00, 
> and draft-wierenga-ietf-sasl-saml-00 specify the use of federated 
> authentication in a SASL context. And services like eduroam are an 
> example of the use of just RADIUS to implement federated authentication 
> for non-web applications.
> I do understand that it is not possible nor desirable to take on 
> everything, but let's at least have this scoping discussion in the BoF.
> 
> Klaas
> 
> --
> 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/>