Subject: [kitten] Fwd: New Version Notification for draft-ietf-kitten-sasl-saml-02

From: Klaas Wierenga <[email-masked]>
Date: Fri, 25 Feb 2011 16:25:55 +0100

Hi,

I have submitted a new version of the sasl-saml draft. Apart from a few
typo corrections the main change is that instead of having the
SASL-client specify the URL of the IdP it now specifies a domain. The
SASL-server is supposed to have a mapping from domain to IdP (either
static or via a lookup mechanism).
I made this change because Joe Hildebrand rightfully remarked that you
can not expect a user to know the full url of his IdP.

I welcome any comments and am happy to discuss at IETF 80.

Klaas

- -------- Original Message --------
Subject: New Version Notification for draft-ietf-kitten-sasl-saml-02
Date: Fri, 25 Feb 2011 07:20:38 -0800 (PST)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]

A new version of I-D, draft-ietf-kitten-sasl-saml-02.txt has been
successfully submitted by Klaas Wierenga and posted to the IETF repository.

Filename:	 draft-ietf-kitten-sasl-saml
Revision:	 02
Title:		 A SASL and GSS-API Mechanism for SAML
Creation_date:	 2011-02-25
WG ID:		 kitten
Number_of_pages: 26

Abstract:
Security Assertion Markup Language (SAML) has found its usage on the
Internet for Web Single Sign-On.  Simple Authentication and Security
Layer (SASL) and the Generic Security Service Application Program
Interface (GSS-API) are application frameworks to generalize
authentication.  This memo specifies a SASL mechanism and a GSS-API
mechanism for SAML 2.0 that allows the integration of existing SAML
Identity Providers with applications using SASL and GSS-API.

The IETF Secretariat.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 25 Feb 2011 15:33:02 +0000

> can not expect a user to know the full url of his IdP.

At the risk of exposing my ignorance in SAML, is there no established  
method for discovering a IdP URI given a domain?

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Josh Howlett <[email-masked]>
Date: Fri, 25 Feb 2011 15:38:27 +0000

> method for discovering a IdP URI given a domain?

Yes, through indirection by reference to a metadata document describing the IdP. See for example sec 4.2.2.2 of SAML2Meta. I think that might introduce more problems than it solves though.

Josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG

---

From: "Cantor, Scott E." <[email-masked]>
Date: Mon, 28 Feb 2011 18:51:10 +0000

> static or via a lookup mechanism).

I don't think that's going to be generally feasible, even if the majority of domains happen to have one IdP. Many have >1, and that's just not sufficient. If you want to punt on discovery, that's ok I guess, but your mechanism should have the *option* to supply the IdP's entityID directly.

If you were supplying the URL before (meaning the location), then I strongly agree that that's bad. The entityID should always be used in favor of a location, since neither is generally going to be easy for users to know, and the entityID is stable, unlike the location.

-- Scott

---

From: Klaas Wierenga <[email-masked]>
Date: Mon, 28 Feb 2011 23:02:47 +0100

On 2/28/11 7:51 PM, Cantor, Scott E. wrote:
>> I have submitted a new version of the sasl-saml draft. Apart from a
>> few typo corrections the main change is that instead of having the 
>> SASL-client specify the URL of the IdP it now specifies a domain.
>> The SASL-server is supposed to have a mapping from domain to IdP
>> (either static or via a lookup mechanism).
> 
> I don't think that's going to be generally feasible, even if the
> majority of domains happen to have one IdP. Many have >1, and that's
> just not sufficient. If you want to punt on discovery, that's ok I
> guess, but your mechanism should have the *option* to supply the
> IdP's entityID directly.

well, you could go as specific as you want, all the way to fqdn if you
wanted to, or alternatively do discovery on the limited set of IdPs for
a particular domain... I am not very keen of having an end user specify
an entityID... and if I make it optional than I need a way of indicating
the two cases...

> 
> If you were supplying the URL before (meaning the location), then I
> strongly agree that that's bad. The entityID should always be used in
> favor of a location, since neither is generally going to be easy for
> users to know, and the entityID is stable, unlike the location.

right

Klaas

---

From: "Cantor, Scott E." <[email-masked]>
Date: Mon, 28 Feb 2011 22:31:20 +0000

>an entityID... and if I make it optional than I need a way of indicating

I think it's a setup issue for the client, not something the user enters
(sort of like we do with 802.1x setup in many cases).

But let me rephrase this: what is it you expect the client to ask for the
user for to get the domain? Because users don't understand domains, and if
you ask them for email address, what you'll get is gmail.com.

-- Scott