Subject: [kitten] comments/questions on draft-ietf-kitten-sasl-saml-ec-00

From: Jim Basney <[email-masked]>
Date: Tue, 21 Feb 2012 14:24:06 -0600

Hi,

We're working on a GSS-API mechanism implementation according to
draft-ietf-kitten-sasl-saml-ec-00, and so far the following
comments/questions have come up:

What should gss_accept_sec_context() return for src_name (initiator's
identity)? Is there a particular SAML attribute value our GSS-API
mechanism should be looking for to indicate the user's identity?

What should gss_context_time() return? GSS_C_INDEFINITE? Or should we
look in the SAML assertion for NotBefore/NotOnOrAfter times?

The SAML ECP spec says that the “service provider MUST return an HTTP
error status" on errors, but there's no HTTP between the GSS initiator
and acceptor, and we assume errors are indicated by GSS status
codes. A clarifying statement in draft-ietf-kitten-sasl-saml-ec that the
"MUST return an HTTP error status" requirement doesn't apply to GSS-API
would be helpful. If you agree, I'm willing to propose text.

Section 5 says "applications MUST match the TLS server identity with the
target name" which introduces a TLS requirement that I think is not
intended. I suggest the following changes. In Section 1, change
"existing security layers, such as Transport Layer Security (TLS)" to
"existing security layers, such as Transport Layer Security (TLS) or
Secure Shell (SSH)" just to give at least one TLS alternative example.
Then in Section 5, update "The mutual authentication property..."
paragraph as follows: "The mutual authentication property of this
mechanism relies on successfully comparing the server identity from the
existing security layer (TLS, SSH, etc.) with the negotiated target
name. Since the existing security layer is managed by the application
outside of the GSS-API mechanism, the mechanism itself is unable to
confirm the name. For this reason, applications MUST match the server
identity from the existing security layer with the target name. For TLS,
this matching MUST be perfored as discussed in [RFC6125]. For SSH, this
matching MUST be performed as discussed in [RFC4462]. Applications may
rely on the GSS-API mechanism to perform this matching by passing the
server identity as targ_name to GSS_Init_sec_context()."

As you can probably guess from the above, our initial target application
for this GSS-API mechanism is SSH (RFC 4462).

Thanks,
Jim

---

From: "Cantor, Scott" <[email-masked]>
Date: Tue, 21 Feb 2012 20:35:34 +0000

>mechanism should be looking for to indicate the user's identity?

I think the plan was to align this with other drafts in this territory,
such as the other SAML draft, the EAP/ABFAB mech, etc. I don't know what
the status of those drafts is with respect to this issue.

I would say that in isolation, I would rather not overload the mechanism
with responsibility for mapping SAML attributes to identity, and stick to
either the NameID or a stand-in constant of some kind in the case that
none is present.

But what application compatibility considerations exist? I suspect this
has something to do with discussions about mapping federated identity into
local identity that I've seen go by.

>look in the SAML assertion for NotBefore/NotOnOrAfter times?

I think the appropriate thing would be to apply some local policy, capped
by SessionNotOnOrAfter, to match the semantics used with HTTP scenarios.
That could be made more explicit, but in general SAML leaves that up to
the RP.

>The SAML ECP spec says that the ³service provider MUST return an HTTP

One of the challenges is expressing normative dependency on SAML ECP
without actually normatively depending on the whole thing. I don't think I
have language implying that dependency is total, but that may not be clear
at this point. I agree that it's not intended, certainly. The intent was
that the RFC would note exactly the sections and portions of the document
that are normatively reused as they are referenced.

>intended.

Barring disagreement from those with more experience, I would say your
changes seem correct to me and I can put them in the queue for an updated
draft.

-- Scott