Subject: [Dime] Federated Authentication Beyond The Web: Problem Statement and Requirements

From: "Hannes Tschofenig" <[email-masked]>
Date: Tue, 06 Jul 2010 11:15:19 +0200

Hi all, 

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. 

Ciao
Hannes

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Fri, 09 Jul 2010 19:30:23 +0200

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 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 [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 12 Jul 2010 13:13:14 +0200

> 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*.

I understand your thinking. I actually had the same concerns initially but a more focused discussion really helps. Additionally, nothing prevents someone else to propose another activity (either in form of a BOF, or by submitting drafts to a working group).

I am quite happy with the scope of the work as being proposed. 

Ciao
Hannes

---

From: Klaas Wierenga <[email-masked]>
Date: Tue, 06 Jul 2010 12:40:16 +0200

Hi Hannes,

Klaas

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 12 Jul 2010 13:03:30 +0200

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).
>

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.

Hope this clarifies the misunderstanding.

Klaas

> Ciao Hannes
>> 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:
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
>> 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 [email-masked]
>> with the word 'unsubscribe' in a single line as the message text
>> body. archive:<http://psg.com/lists/radiusext/>