RE: [KAML] Reminder: BOF proposals to me by October 1

"Josh Howlett" <> Fri, 23 November 2007 14:49 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IvZqG-0007qN-9c; Fri, 23 Nov 2007 09:49:16 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IvZqE-0007kA-Qr for; Fri, 23 Nov 2007 09:49:14 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IvZqA-0002QW-SD for; Fri, 23 Nov 2007 09:49:14 -0500
Received: from ([]) by with esmtp (Exim 4.50) id 1IvZq4-0002bT-Kj; Fri, 23 Nov 2007 14:49:04 +0000
Received: from (localhost.localdomain []) by localhost (Email Security Appliance) with SMTP id 39A984A6B2D; Fri, 23 Nov 2007 14:44:46 +0000 (GMT)
Received: from ( []) by (Email Security Appliance) with ESMTP id 0373A4A6B0A; Fri, 23 Nov 2007 14:44:42 +0000 (GMT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [KAML] Reminder: BOF proposals to me by October 1
Date: Fri, 23 Nov 2007 14:48:45 -0000
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [KAML] Reminder: BOF proposals to me by October 1
Thread-Index: AcgtJYaR+5LwCV4zS/SUcd+xvpu7XwAK4tvg
References: <> <> <> <> <> <> <>
From: "Josh Howlett" <>
To: "Tom Scavo" <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243
Cc: Josh Howlett <>,, Paul Rabinovich <>
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussions about SAML and Kerberos intersections <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Tom Scavo wrote:
> On 11/19/07, Josh Howlett <> wrote:
> >
> > I was
> > assuming that the RP is wielding a NameID (bound to the 
> ticket) that 
> > can be used, for example, as the <Subject> of an <AuthnQuery>; the 
> > AuthN context may then be returned within an Authentication 
> Statement.
> This introduces significant new infrastructure and protocol 
> requirements.  The most widely deployed SAML implementation
> (Shibboleth) does not implement the AuthnQuery protocol, so 
> there isn't a single IdP today that could satisfy such a 
> request.  More importantly, an AuthnQuery is a query for an 
> assertion describing a previous act of authentication, so now 
> the IdP has to maintain state where none existed before.  For 
> production, stateless IdPs, this is most likely a showstopper.

If we have to work under the constraint that we can't implement an
existing protocol specification or any new infrastructure then I don't
think we're going to get a solution! Something, somewere, has to change.

I'll attempt to summarise the preceeding discussion:

 * LoA could be expressed either in terms of an AuthN or an Attribute
 * the assertion value could be pushed or pulled, but that there isn't
any value in dereferencing an artifact;
 * PUSH 
   + the advantages of pushing include:
     - no state maintenance
   + the disadvantages of pushing include:
     - significant wire protocol alterations to Kerberos
     - constrains Relying Parties to use that assertion for the lifetime
of the TGT or until renewal, effectively requiring that all Relying
Parties have a common understanding and requirement of the LoA, reducing
policy agility.
     - trust management: you probably need a proof-of-binding to avoid
substitution attacks
   + implementation considerations:
     - KDC must be able to generate SAML AuthN assertion and bind to
TGT, and TGS must be able to bind to service tickets.
 * PULL 
   + the advantages of pulling include:
     - provides Relying Parties with a greater choice of tokens to use
for LoA, allowing richer local policy
     - less significant wire protocol alterations to Kerberos
     - trust management is probably unchanged from conventional SAML
   + the disadvantages of pulling include:
     - maintenance of state
   + implementation considerations
     - the KDC needs to maintain state, and this must be exposed to the
Authentication Authority.

In response to your other points:

> You say there is a NameID bound to the ticket.  How does the 
> TGS obtain or produce a NameID that the IdP can map to the 
> correct local principal?

It's already in the TGT minted by the KDC.

>  (Note that the IdP needs a plugin 
> that can perform this mapping, yet another infrastructure 
> requirement.)  What is the Format of the NameID? Is it a 
> SAML V2.0 kerberos identifier?  If so, this rules out SAML 
> V1.1, which constitutes the bulk of today's SAML deployments.

The format just needs to be something that both the KDC and IdP both
understand. Do we need to be prescriptive about this?

> > FWIW, another reason that 'push' might be problematic is that the 
> > Ticket Granting Service may not be aware of the 
> authentication context 
> > owing to the fact that the Authentication Service (in the Kerberos 
> > context!) that the principal authenticates against may be a 
> separate 
> > entity from the TGS; how, therefore, does the TGS learn of 
> the AuthN 
> > context from the AS?
> In fact, this is exactly how a Shibboleth IdP works today.  

No, there's a big difference: an Attribute Authority or Authentication
Authority can *only* make assertions about principals affiliated with
the same IdP (and so the authN context is implicit); a TGS can issue
tickets to principals affiliated with another KDC and about whom it
knows nothing (including how they were authenticated).

This is why if you're going to push the assertion (1) it needs to be
bound to the TGT, (2) the TGS needs to understand this new protocol and
(3) live with the restrictions that I summarised above.

> > Further, if we assume that the Authentication Service is 
> issuing the 
> > Authentication Assertion (with the LoA) then some other possible 
> > issues resolve themselves; for example, we know that we can set the 
> > value of the NotOnOrAfter attribute to the expiry of the 
> principal's 
> > Kerberos TGT.
> Actually, if you embed the SAML directly in the ticket, you 
> don't even need to include a NotOnOrAfter attribute since it 
> can be inferred from the containing ticket.  There are other 
> similar such benefits of a kerberos-bound SAML token.  The 
> SAML assertion need not have all the nitpicking features 
> required by a SAML protocol since the SAML is subordinate to 
> the kerberos, in a sense.

I guess that depends how much you trust the Kerberos infrastructure.

>  No new protocols or extensive 
> infrastructure are required. the IdP, but the KDC & TGS needs to learn a few new tricks :-)

Given your experience with SAML/X509, it would be interesting to know
the reasons why 'push' turned out to be better than 'pull' in that


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 Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

KAML mailing list