Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements
Klaas Wierenga <klaas@wierenga.net> Mon, 12 July 2010 11:03 UTC
Return-Path: <klaas@wierenga.net>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5801A3A6991 for <dime@core3.amsl.com>; Mon, 12 Jul 2010 04:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level:
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599]
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 vEoh06mlRwo5 for <dime@core3.amsl.com>; Mon, 12 Jul 2010 04:03:28 -0700 (PDT)
Received: from teletubbie.het.net.je (teletubbie.het.net.je [IPv6:2001:610:508:110:192:87:110:29]) by core3.amsl.com (Postfix) with ESMTP id 9DA003A6B3B for <dime@ietf.org>; Mon, 12 Jul 2010 04:03:25 -0700 (PDT)
Received: from 64-103-25-233.cisco.com ([64.103.25.233] helo=macmini.wierenga.net) by teletubbie.het.net.je with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from <klaas@wierenga.net>) id 1OYGn9-0009Jm-LT; Mon, 12 Jul 2010 13:03:19 +0200
Message-ID: <4C3AF682.3080507@wierenga.net>
Date: Mon, 12 Jul 2010 13:03:30 +0200
From: Klaas Wierenga <klaas@wierenga.net>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-GB; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <20100706091519.251510@gmx.net> <4C330810.6010003@wierenga.net> <20100709173023.107930@gmx.net>
In-Reply-To: <20100709173023.107930@gmx.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Antivirus: no malware found
X-Mailman-Approved-At: Tue, 20 Jul 2010 04:41:54 -0700
Cc: Moonshot community list <MOONSHOT-COMMUNITY@JISCMAIL.AC.UK>, dime@ietf.org, radiusext@ops.ietf.org
Subject: Re: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Jul 2010 11:03:29 -0000
On 7/9/10 7:30 PM, Hannes Tschofenig wrote: Hi Hannes, > sorry for the late response. np > > 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. hmm, afaik it is a federated authentication BoF, not a Moonshot BoF > > The usage of OpenID in SASL/GSS-API (like you pointed out) will be > done in KITTEN independently and has different design constraints. I think there is a bit of misunderstanding, I gave those just as an example because I happen to be familiar with them. I am happy with those drafts being in KITTEN, if only to speed things up. So that is not the point. My point is that I'd like the BoF to start open-minded. I believe federated authentication for non-Web is a large and interesting area. I would like to make sure that we don't rule out beforehand alternative approaches. I am happy with a charter as outcome that specifies that the WG is going to take the Moonshot approach, but imo that should be the *result* of the BoF, not a *precondition*. Hope this clarifies the misunderstanding. Klaas > > 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/>
- [Dime] Federated Authentication Beyond The Web: P… Hannes Tschofenig
- Re: [Dime] Federated Authentication Beyond The We… Hannes Tschofenig
- Re: [Dime] Federated Authentication Beyond The We… Hannes Tschofenig
- Re: [Dime] Federated Authentication Beyond The We… Klaas Wierenga
- Re: [Dime] Federated Authentication Beyond The We… Klaas Wierenga