[security-services] XML Sig issues w/ SAML

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

A bit late, but I took an action item to summarize a pair of issues with
the use of the XML Signature spec in SAML. I welcome any corrections
from those more directly involved with the Signature specification, as
this is mostly from my own readings, and answers I got (and am
interpreting so don't blame him ;) from the author of the Apache XML
Security implementation.

1. Canonicalization (C14N)

Right now, we have a mandate for SAML implementers to provide support
for signing SAML with the original "inclusive" XML C14N spec. The
purpose of C14N is to convert an XLM input "node set" to an octet stream
to be fed into the digest computation. The algorithm used in a signing
operation is included in the ds:Signature content, so all that matters
in terms of security is that both sides support the algorithm.

The potential issue is that when using "inclusive" C14N [1], namespace
declarations "bleed" into the resulting XML from the surrounding
content. As an example, consider a signed SAML assertion placed into a
SOAP message. If it was signed before insertion into the SOAP, it's C14N
will include only the namespaces it declared internally. The SOAP
consumer may attempt to verify the signature in-place, at which point
the SOAP namespace(s) will most likely be declared in the envelope
context and will appear in the C14N of the SAML assertion, thus breaking
the signature.

One solution to this is to recommend that SAML signatures be verified
only after removing the message from its context, if any. Another is to
recommend or eventually mandate support for the new exclusive C14N
algorithm [2], which is designed to deal with this problem. When using
it instead, by default only the namespaces actually referenced in
element and attribute names in the SAML are declared, leaving it
context-independent.

The exclusive algorithm is a proposed REC at this time, and is supported
by most or all Signature packages, including open source versions.

In general, I think the SAML spec should avoid mandating the use of any
particular algorithm, and simply suggest use of exclusive C14N or at
least highlight the potential problems.


2. How to verify what's been signed?

The other more immediate issue relates to the fact that in XML
Signature, it's critical to know what's actually been signed. Verifying
the signature itself is straightforward, but that provides no security
guarantee until you evaluate whether or not the right XML has been
signed. In SAML, we specify that all of the content within the message
must be signed, which means everything within the Assertion, Response,
or Request elements.

In the simple case, one could simply use the Enveloped Signature
Transform with a Reference URI of "" to specify that everything in the
XML minus the signature itself is to be signed. This is very easy to
check on the verifying side. This is also sufficient for signing the
Response in the POST profile, which is the only specific use of
signatures in SAML 1.0's profiles and bindings.

However, most toolkits (including mine) would be written more generally
to support future signing requirements, and would therefore want to be
more explicit in isolating the signed content whether or not it was
placed into a context. For example, I want to support signing an
assertion that is itself inside a Response. In that case, I can't
specify "" as the Reference URI, because that refers to the Response,
not just the Assertion.

The way to do this is to add additional Transform elements that use some
kind of XPath expression to isolate what is to be signed. There are two
primary ways to do this, the original XPath transform [3], which is kind
of "weird" and can be inefficient to use, and the new XPath Filter 2.0
transform [4], which is in last call.

As an example, my library implements the following Transform alongside
the Enveloped Signature transform, using the original XPath version,
when signing an assertion:

"ancestor-or-self::node() = here()/ancestor::saml:Assertion[1]"

That tells the signing library to include only the Assertion that
contains the Signature being created. Response and Request signing look
similar. The new XPath Filter should allow a more streamlined expression
that's more efficient.

What would also help would be for SAML to add support for the XML ID
attribute, which would let us reference the outer signed element using
XLink directly. Eve raised that option a while back, I think.

Anyway, the issue is that on the consumer end, I have to verify that the
"right" stuff got signed. There are three apparent ways to do this [5]:

1. Dictate what the Signature's Transforms MUST be. For example, adopt
an XLink strategy, or the new XPath Filter 2.0, or the ugly one above.
Specify it in SAML, and then SAML consumers just extract the Transform
elements and check them over. In the short term, I plan to do this in my
code to protect my applications, while sacrificing some interop. Longer
term, proper SAML libraries would need to do one of the other options as
things currently stand.

2. Perform the Transforms you receive and do Node Set evaluations
against what you expect, to insure that everything that must be signed
was in fact signed. This is certainly possible, but somewhat code
intensive.

3. Reparse the octet stream that results from C14N back into XML and use
that as your library's source for the "signed" data. This is inefficient
(two parse steps), but it works.

While option 1 may seem kind of undesirable, it really does simplify the
job of implementers, and I'd be happy to see SAML do that, probably by
adding ID support, since XLink is a very clean way to identify the
content to sign. The second choice would be the new XPath Filter, which
is much faster than the old one.

If people object to that idea, we should probably include some text that
at least makes implementers aware that they can't just verify the
signature and declare victory.

-- Scott

References:
[1] http://www.w3.org/TR/xml-c14n
[2] http://www.w3.org/TR/xml-exc-c14n
[3] http://www.w3.org/TR/xmldsig-core/#sec-XPath
[4] http://www.w3.org/TR/xmldsig-filter2/
[5]
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002AprJun/0290.htm
l