[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [security-services] XML Sig issues w/ SAML
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC