[kitten] comments on draft-ietf-kitten-sasl-saml-ec

[Sam Hartman <[e-mail]>]

I've reviewed the SAML EC draft.
It was easy to read, and I appreciate the work that has gone into it.
I would prefer to wait  for responses to these comments prior to issuing a WG LC.

I request review of these comments from the Kerberos community as well as the SAML EC community.

I have not closely read the SAML and SAML ECP specifications, and as a
result I cannot provide sufficient review of the overall security and
interoperability of this mechanism.  We will need review of that from
folks other than the authors prior to progressing the specification.

I cannot promise doing that additional review in a timely manner.


Section 1:

A reference to the discovery/WAYF problem would be desirable but is not
required.


Section 3:
In this mechanism, the client does not send the response to the RP at a
location of the IDP's choosing but instead sends to a location of the
client's choosing through SASL.
What are the implications of this?

I guess one is the attack Jim brought up and we discussed in ABFAB.


In the section on interactions with the IDP, there is no
mandatory-to-implement mechanism specified for finding an IDP.  I'd
appreciate comments from the WG on whether this lack is a problem in
terms of guaranteeing that two implementations of this mechanism will be
interoperable.
Should we require something like support for static configuration of an
IDP?

Section 5:

SASL has an idea of mutual authentication.
It seems like the same checks that apply to GSS-API should apply to SASL
mutual auth too.

The checks in section 5 seem inadequate.  In particular, it seems like
it should matter what identity is used to digitally sign the request,
and  the validity of the signature should matter.

>         If the mutual_state flag is not requested, or is not set, then the
>	    security layer managed by the application outside of the GSS-API
>	       mechanism is responsible for authenticating the acceptor.  In this
>	          case, applications MUST match the server identity from the existing
>		     security layer with the target name.  For TLS, this matching MUST be
>		        performed as discussed in [RFC6125].  For SSH, this matching MUST be
>			   performed as discussed in [RFC4462].
			   

This text places normative requirements on applications using this mechanism.
That's not reasonable because applications may have no knowledge of this mechanism.
What happens if these checks are not performed?

Section 5.1 seems applicable to SASL as well.

It doesn't sound like section 5.1 provides enough guidance to provide interoperability between multiple implementations of delegation to me.

Section 5.3 is inconsistent with the claim in the introduction that no integrity and confidentiality layer is provided.


Section 5.3.  I note that this is the first time I'm aware of where
RFC 3961 enctypes' names are used in a protocol.  I'd like explicit
review of this from the Kerberos community.  Everything we have so far uses numbers.

Section 5.3.1:

I think encryption needs to be a MUST here.
Even if CB is used there's no confidence that the channel provides confidentiality.
Consider for example a TLS cipher without confidentiality, an IPsec channel for ESP-null, etc.


Section 5.4: RFc 4121 has multiple keys it can use: the session key, the subsession key, and the acceptor subsession key.
The text in 5.4 is insufficiently detailed for interoperability.


Section 5.6.2:

1) I am not sure that the guidance here is sufficient for interoperability and security.

2) This section appears to place normative requirements on the IDP even though   the specification claims not to place normative requirements on the IDP.

3) This section seems to apply to SASL.