RE: [security-services] Drafts for review: Kerberos & SAML profiles

["Scott Cantor" <cantor.2@osu.edu>]

My suggestions inline. I'm mainly focusing on the technical design and where
I would describe the pieces, and not looking at editorial issues at this
point to save time.

Josh Howlett wrote on 2009-06-23:
> Please find attached three draft profiles.
> 
>   - Kerberos Attribute Profile 00: defines an attribute profile of
> Kerberos.

As I said on the call, what I think we want to do here is define this so
that we don't need a query profile at all, and instead rely on core
processing rules for the AttributeQuery/Response protocol. That protocol
already supports so-called "value-filtering" of attributes with a call-out
that explicitly allows attributes themselves to define their own matching
approaches. That's what we want to take advantage of.

I believe the entire Attribute Profile should be structured to define a
single attribute, representing one or more service tickets. So I would move
the relevant portions of section 7 up into section 3 and just explicitly
define the Name and NameFormat of the attribute being defined.

I would merge sections 4 and 5 such that the XML attributes being defined
are explicitly part of the AttributeValue syntax, which would be the
base64'd ticket as now, plus the servicePrincipalName/userPrincipalName
attributes. I don't know if those should be optional or required, though,
I'll leave that to you.

In turn, the xsi:type of the AttributeValue would be omitted at runtime
because it isn't a native schema type. It would be optionally fine to go
ahead and define an extension type of base64Binary that added the two XML
attributes so that the xsi:type at least *exists*. It's omitted at runtime
to avoid a dependence on the extension schema (SAML core mentions this).

Taken together, the example in section 8 would look like this:

<saml:Attribute
xmlns:k5="http://www.kerberos.org/saml/profiles/attribute";
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="http://www.kerberos.org/saml/profile/attribute/ticket";>
	<saml:AttributeValue
		k5:userPrincipalName="joe@EXAMPLE.ORG"
		k5:servicePrincipalName="http/www.example.org@EXAMPLE.ORG">
	...Base64Binary-encoded content...
	</saml:AttributeValue>
</saml:Attribute>

Of course, this is multi-valued, and each value carries a distinct ticket.

The only thing you lose is the FriendlyName convention you propose, but you
don't need it because each attribute value can carry the necessary metadata
for the ticket.

To address the query requirement, you just need to add a bit of text to the
profile that makes the actual service ticket content optional. In XSD, it's
legal for string-derived types to be empty. Normally SAML precludes that but
it can be specified as permissible when desired, like here.

Then you add language indicating that for purposes of value comparison, an
empty value is considered equivalent to a populated ticket value iff the XML
attributes match. That satisfies the need to use the existing query protocol
to request tickets based on those attributes (including multiple differing
tickets).

>   - Kerberos Attribute Query Profile 06: defines how a SAML requestor
> can obtain a SAML attribute, that contains a Kerberos ticket, from a
> SAML attribute authority.

Based on what I read, I don't think you really need this document once the
attribute profile is supplemented slightly. It's pretty much out of scope
how the SAML authority might satisfy the tickets requested, so it's not like
there's a back-end protocol to specify here anyway.

>   - Kerberos Holder-of-Key Assertion Profile 02: defines how to
> confirm an attesting entity using Kerberos.

I haven't studied this one in detail yet, but my immediate reaction to this
is to wonder if it's really beneficial to call this HoK vs. just defining a
Kerberos-specific confirmation method with an attendant syntax for the
confirmation data to specify the Kerberos principal name, as you suggest
here via KeyName.

-- Scott