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

From: "Josh Howlett" <[email-masked]>
Date: Thu, 15 Nov 2007 09:40:21 -0000

Tom Scavo wrote:
> On 9/25/07, Leif Johansson <[email-masked]> wrote:
> > Paul Rabinovich wrote:
> > >
> > >       IMO it's preferable to keep the LoA piece under the 
> Kerberos 
> > > WG rather than under the KAML WG since - in the short-term - 
> > > out-of-the-box SAML 2.0 seems not to be able to help with LoA. 
> > > Whatever we design, however,
> > >
> > I think you are wrong. There are at least two ways to model 
> LoA using 
> > SAML - using an AC class or using an attribute.
> 
> That's correct.  If you decide to use AuthnContext, that 
> means the Kerberos-bound SAML assertion would contain an 
> AuthnStatement.  On the other hand, an Attribute would 
> require an AttributeStatement.
> (Personally, I think AuthnContext is the way to go for LoA, 
> but the jury's still out on that issue.)

I don't think that it's desirable to prescribe either (1) what
constitutes an appropriate token for LoA or (2) that a token needs to be
bound directly to the ticket. The former *should* be a matter for local
policy, and the latter is not necessary.

Just provide a mechanism for the Relying Party to resolve the
Authentication and Attribute Authorities associated with the principal
wielding the ticket and the Relying Party can make a call-back to one or
the other, or both, depending on what its own local authorisation policy
considers an appropriate LoA token, and make the necessary Assertion
Request(s) itself.

An example mechanism that might support this: treat the principal name
as a NameID (which SAML already allows) and the Relying Party can use
SAMLMeta DNS Publication and Resolution (Sec 4.2) with the NID2U
servicefield in a NAPTR record to specify the AuthN and/or Attr
Authorities associated with it (see Sec 4.2.2.2 for an analagous
example).

	Client		TGS		Service		DNS
SAML AA (AuthN and/or Attr)

		----TKT?---->
		<---TKT------
	      -----------TKT--------->
						Validate TKT
							--Look up-->
	
NAPTR record
							<--SAML AA--
							--------SAML
Assrt Req--->
							<-------SAML
Assrt Res----
						AuthZ decision
		<-------Ok--------------
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 Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

_______________________________________________
KAML mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kaml

---

From: "Tom Scavo" <[email-masked]>
Date: Fri, 16 Nov 2007 12:10:00 -0500

On Nov 15, 2007 4:40 AM, Josh Howlett <[email-masked]> wrote:
> > > There are at least two ways to model LoA using

With regard to (1), I think you're missing the point, Josh.  How the
LoA is carried in the SAML assertion is a technical detail, not a
matter of policy.  An attribute is more general (because it works in
both SAML V1.1 and V2.0) but SAML V2.0 AuthnContext is preferred (IMO)
since it binds LoA to an AuthnStatement, which is conceptually
correct.

As far as (2) is concerned, you're right, passing additional security
information by value is not strictly necessary.  However, our own
experience integrating SAML into X.509 has clearly shown that pushing
SAML tokens by value is far easier to implement and deploy.  Moreover,
no new wire protocols are required to push X.509-bound SAML tokens.  I
suspect that the Kerberos use case will exhibit similar advantages.

Tom Scavo
NCSA

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 16 Nov 2007 22:54:46 -0000

> means the 
> > > Kerberos-bound SAML assertion would contain an 
> AuthnStatement.  On 
> > > the other hand, an Attribute would require an AttributeStatement.
> > > (Personally, I think AuthnContext is the way to go for 
> LoA, but the 
> > > jury's still out on that issue.)
> >
> > constitutes an appropriate token for LoA or (2) that a 
> token needs to 
> > be bound directly to the ticket. The former *should* be a 
> matter for 
> > local policy, and the latter is not necessary.
> 
> With regard to (1), I think you're missing the point, Josh.  
> How the LoA is carried in the SAML assertion is a technical 
> detail, not a matter of policy.

My point was that if the <LoA token> can be acquired post hoc then the
Relying Party can decide itself what is the necessary token(s), rather
than relying on the TGS to choose what it believes is appropriate. The
fire-and-forget approach does not provide room for agility.

I believe that what constitutes an appropriate <LoA token> depends on
what the Relying Party in question feels is necessary to satisfy their
policy, and so binding these semantics arbitrarily to the transport
protocol seems unnecessarily restrictive. Let them choose! AuthN
context, attribute or moon phase....

josh.

---

From: "Tom Scavo" <[email-masked]>
Date: Fri, 16 Nov 2007 19:02:31 -0500

> fire-and-forget approach does not provide room for agility.

I don't believe it works that way, Josh.  An RP that resolves a token
reference receives the same token that would otherwise be received by
value.  The act of authentication has already taken place, so there is
very little wiggle room, in fact.  You may as well push the token up
front in that case.

> context, attribute or moon phase....

I think you're mixing two separate issues:

1. How to bind an LoA token to a SAML assertion.
2. How to transmit a SAML assertion to an RP.

I don't really care how (1) plays out, and it isn't really relevant
here anyway, but I have strong opinions about (2).  It's clear to me
(YMMV of course) that pushing the security information by value is
preferred.  I've learned this after almost three years of effort
trying to integrate SAML and X.509.

Tom Scavo
NCSA

---

From: "Josh Howlett" <[email-masked]>
Date: Mon, 19 Nov 2007 11:23:11 -0000

> > > How the LoA is carried in the SAML assertion is a 
> technical detail, 
> > > not a matter of policy.
> >
> I don't believe it works that way, Josh.  An RP that resolves 
> a token reference receives the same token that would 
> otherwise be received by value.  The act of authentication 
> has already taken place, so there is very little wiggle room, 
> in fact.  You may as well push the token up front in that case.

Aaaah, I now understand how we're getting our wires crossed.

I wasn't suggesting binding an artifact to the ticket; instead, 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.

(I think that dereferencing an artifact in this context is possibly
difficult for other reasons, but that's another discussion...)

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? You could signal this in the TGT perhaps, but this is adding
complexity.

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.

josh.

---

From: "Tom Scavo" <[email-masked]>
Date: Thu, 22 Nov 2007 11:28:59 -0500

On 11/19/07, Josh Howlett <[email-masked]> wrote:
> I was

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.

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?  (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.

> AS?

In fact, this is exactly how a Shibboleth IdP works today.  An
external service authenticates the user and passes the principal name
to the IdP.  From this, the IdP formulates the SAML authn context on
its own.

In general, the LoA associated with an identity token is a function of
the strength of the identity credential used to obtain the token, the
token type, the authentication method, and the protocol used to
transmit the token to the relying party.  Only the authentication
method depends on the authentication service, and even this can be
inferred by the IdP.

> the NotOnOrAfter attribute to the expiry of the principal's Kerberos

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.  No new protocols or
extensive infrastructure are required.

Tom

---

From: "Josh Howlett" <[email-masked]>
Date: Fri, 23 Nov 2007 14:48:45 -0000

Tom Scavo wrote:
> > 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.
> 
> (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
assertion;
 * 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
considerations
   + 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.

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

...to 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
context.

josh.