RE: review of draft-wierenga-ietf-sasl-saml-00

"Scott Cantor" <> Wed, 26 May 2010 15:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F2F73A683F for <>; Wed, 26 May 2010 08:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RM9PpE0SufR3 for <>; Wed, 26 May 2010 08:08:37 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9901B3A6359 for <>; Wed, 26 May 2010 08:08:37 -0700 (PDT)
X-Authority-Analysis: v=1.1 cv=Pm0qIGCwx3bIEOZlSg1a56K3RSwKBTW9sPEb+DFvEKk= c=1 sm=0 a=FNPjm8h7-gQA:10 a=0qYQvVkOOIcA:10 a=kj9zAlcOel0A:10 a=/Wh0N9815gtYTLoiNwER9g==:17 a=ZVL_7Xqr5YMxoD93R1wA:9 a=8kaPJNggRd5kbjln-7IA:7 a=x-tPcLOtnoXcFznNn-55bZjQSZoA:4 a=CjuIK1q_8ugA:10 a=rjC1WpulEXHb2dl-:21 a=GYJa4N8imfAWlNCz:21 a=/Wh0N9815gtYTLoiNwER9g==:117
X-Cloudmark-Score: 0
Received: from [] ([] helo=SNOWDOG) by (envelope-from <>) (ecelerity r()) with ESMTP id AC/CC-23859-B693DFB4; Wed, 26 May 2010 15:08:28 +0000
From: Scott Cantor <>
To: 'Klaas Wierenga' <>
References: <> <077001cafc4b$603f0510$20bd0f30$> <>
In-Reply-To: <>
Subject: RE: review of draft-wierenga-ietf-sasl-saml-00
Date: Wed, 26 May 2010 11:08:29 -0400
Organization: The Ohio State University
Message-ID: <07e801cafce5$4cf7f7b0$e6e7e710$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQLRbl7pt5nj/GkkimyEmmW8RXcC0wEhdeLrAhdHfmaQPSUmgA==
Content-Language: en-us
Cc:,, 'Sam Hartman' <>,
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 May 2010 15:08:38 -0000

> I am assuming you refer to the ECP profile. How different would this be
> from the SASL point of view? I.e. what difference would it make on the
> "SASL wire"?

Significantly different from yours, since there's no empty response and no
callback communication between the SP and the IdP, but I believe it can be
compatible with SAML ECP on the IdP side, and is essentially a direct
mapping from using HTTP as a "container" for the SP/client SOAP envelopes to
using the SASL messages.

It suffers the same MITM issues that Sam mentioned, since that's what
happens if you punt that to TLS without any channel bindings. I'm not in a
position to address that without help, I just believe there's a better
non-web flow here. It also creates a much more flexible field for phishing
to be addressed, since the client/IdP exchange is not a browser and a web

The only issue to address in translating the profile over to SASL is the
fact that in a non-web case there's no real "responseURL" involved, which is
something that's baked into the standard ECP profile, but I think it can be
"emulated" with no particular effort in the interest of compatibility, or
removed at the cost of same.
> There is no compelling argument other than that this is the way it is
> done in most identity federations today and I wanted to stay as close as
> possible to today's implementations and not fall into the trap of trying
> to introduce something new and at the same time try to fix all other
> problems in the world.

This makes sense if you're remaining compatible with something people *want*
to deal with, but IdP discovery is the last thing anybody operating an SP
*wants* to deal with. It's a gigantic usability problem, and arguably the
biggest reason why federation has scaling issues.

Anyway, it's on me to produce the draft, which I've started on (using yours
as a starting point, which I hope is ok).

-- Scott