Subject: [kitten] I-D Action: draft-ietf-kitten-sasl-saml-ec-00.txt

From: [email-masked]
Date: Tue, 30 Aug 2011 02:31:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation Working Group of the IETF.

	Title           : SAML Enhanced Client SASL and GSS-API Mechanisms
	Author(s)       : Scott Cantor
                          Simon Josefsson
	Filename        : draft-ietf-kitten-sasl-saml-ec-00.txt
	Pages           : 27
	Date            : 2011-08-29

   Security Assertion Markup Language (SAML) 2.0 is a generalized
   framework for the exchange of security-related information between
   asserting and relying parties.  Simple Authentication and Security
   Layer (SASL) and the Generic Security Service Application Program
   Interface (GSS-API) are application frameworks to facilitate an
   extensible authentication model.  This document specifies a SASL and
   GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
   SAML-aware &quot;enhanced client&quot; to address significant barriers to
   federated authentication in a manner that encourages reuse of
   existing SAML bindings and profiles designed for non-browser
   scenarios.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-kitten-sasl-saml-ec-00.txt

---

From: "Cantor, Scott" <[email-masked]>
Date: Wed, 31 Aug 2011 02:25:23 +0000

On 8/30/11 5:31 AM, "[email-masked]" <[email-masked]>
wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts
>directories. This draft is a work item of the Common Authentication
>Technology Next Generation Working Group of the IETF.
>

The current status of the document is that it's been slightly revised to
reference the latest SAML draft it depends on, and a non-interoperable
feature that isn't compatible with the use of channel binding was removed.
I also copied relevant text on matching TLS server identity to GSS target
name from the GSS SAML draft.

Most of the "meat" of this work is really in the SAML profile document it
references, including the bulk of the support for channel binding, and the
holder of key support.

There are a number of open issues I want to work through, probably with
Sam's and Simon's help based on past offers of assistance:

- per-message tokens, etc, currently not supported, but should be possible
with some help, and I need to do some reading of how Kerberos supports
this first

- SAML naming in GSS and alignment with ABFAB work in this area

- conformance material: in OASIS we have explicit conformance text
outlining what implementers have to support when there are options
involved; this seems to be done more informally throughout the text in
I-Ds so I need to work that material in

- a possible change to how channel binding is handled

The latter is something I realized from reading the OAuth draft. The model
I chose was to do CB by having the IdP compare authenticated copies of the
CB data supplied by the RP and the client. That only works when you get
signed requests from the RP and there's an explicit challenge/request
message from the RP. That's why I took out the option for the client to
push an unsolicited SAML response to the RP up front.

I can see that an alternative model is to just have the client pass
authenticated CB material to the IdP, have it embed that in the assertion
it issues, and then have the RP just check that against its CB data at the
end. That has some advantages, but one thing it doesn't do is prevent the
RP (or an attacker) from getting a copy of the message from the IdP, which
would include user data. It's normally encrypted, but it doesn't have to
be. Doing the CB compare at the IdP prevents anything from reaching the
attacker.

I think I prefer my way, but I thought I'd mention it.

My plan right now is to tackle the work remaining pretty soon,
particularly the parts that would impact the OASIS documents. But I really
want to do some implementation work before moving any of this towards
finality. The basics here are easy and provem, but the CB and HoK work is
new to (most) SAML code.

-- Scott