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

["Tom Scavo" <[e-mail]>]

On 11/19/07, Josh Howlett <[e-mail]> 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.

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.

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

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

Tom

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