Note on Digital Signing in SAML (was RE: The XML Security Gap (wa sRe: XML Encryption Working Draft))

["Mishra, Prateek" <pmishra@netegrity.com>]

Evan,

Does this not fall within the "security considerations" charter?

Here is a short note to get things moving:


A. Role of Digital Signatures in SAML
-------------------------------------

The following SAML entities: SAML Assertions, Request and Response messages
may be signed, with the following benefits:

(1) Mandatory elements in an Assertion signed by the issuer (AP). This
supports (1) message integrity and (2) authentication of the issuer to a
relying party. If the signature is based on the issuer's public-private key
pair, then it also provides for non-repudiation of origin. 

(2) Mandatory elements in a request or response message
signed by the message originator. This supports (1) message integrity and
(2) authentication of message origin to a destination. If the signature is
based on the originator's public-private key pair, then it also provides for
non-repudiation of origin.

SAML documents may be the subject of signatures from in many
different packaging contexts. [SIG] provides a framework for
signing in XML and is the framework of choice. However, signing may also
take place in the context of S/MIME or Java objects
that contain SAML documents. One goal is to ensure compatibility
with this type of "foreign" digital signing. 

B. Contexts within SAML Requiring Digital Signature
---------------------------------------

It is useful to characterize situations 
when a digital signature is NOT required in SAML. 

(a) assertions: asserting party has provided the assertion to the relying
party and authenticated by means other than digital signature. In other
words, the RP has obtained the assertion from 
the AP directly(no intermediaries) and the AP has authenticated to the RP.

(b) Request/Response messages: the originator has authenticated
to the destination and the destination has obtained the 
assertion directly from the originator (no intermediaries).

Many different techniques are available for "direct" authentication
between two parties. The list includes SSL, HMAC, password-based
login etc. [QUESTION: Do we need to constrain this list further?]

All other contexts require the use of digital signature for
assertions and request and response messages. Specifically:

(1) An assertion obtained by a relying party from an entity
other than the asserting party MUST be signed by the issuer.

(2) SAML message obtained arriving at a destination from an
entity other than the originating site MUST be signed by
the origin site.


C. SAML Profile for [SIG]
-------------------------

The [SIG] specification calls out a general XML syntax for
signing data with many flexibilities and choices. 
We may choose to constrain these facilities so that
SAML processors do not have to deal with the full generality
of [SIG] processing.

(a) Signing formats: [SIG] describes three signing formats:
enveloped, enveloping and detached. Which formats are acceptable
for use with SAML assertions, requests and responses? 

(b) KeyInfo: This element supports very general forms of communication about
the key (secret, public) used for signing. 
Which forms must SAML processors support? (e.g., should we support PGPData
or SPKIData?)

D. Super-Signatures and Sub-Messages
------------------------------------

SAML assertions may be embedded within request or response
messages or other XML messages which may be signed. 
Request or response messages may themselves be contained 
within other messages which are based on other XML messaging frameworks
(e.g., SOAP) and the composite object may be the 
subject of a signature. Another possibility is that SAML
assertions or request/response messages are embedded within
a non-XML messaging object (e.g., MIME package) and signed.

In such a case, the SAML sub-message (Assertion, request, response)
may be viewed as inheriting a signature from the "super-signature" over the
enclosing object, provided certain constraints are met. 

(1) An assertion may be viewed as inheriting a signature from
a super signature, provided that the super signature applies
all of the mandatory elements within the assertion.

(2) A SAML request or response may be viewed as inheriting
a signature from a super signature, provided that the super
signature applies to all of the mandatory elements within the
response.

References:
-----------

[SIG] XML-Signature Syntax and Processing, 
W3C Candidate Recommendation 19-April-2001

----------------------------------------------------------

This is a first cut and comments are
invited; I guess I should work it up
to a formal submission to the document archive.


- prateek



R>>
>>>>>>> "HL" == Hal Lockhart <hal.lockhart@entegrity.com> writes:
>>
>>    HL> Considering that the current proposals do not even cover
>>    HL> signatures, which we surely want, [...]
>>
>>This brings up a good point: the current core architecture proposals
>>have little or no mention of digital signatures. I've always thought
>>of this as part of the definition of assertions and messages, but Phil
>>remarked during the F2F that he considered it a bindings issue.
>>
>>It appears that XML signatures are falling into the gap between
>>assertions and messages on one side, and bindings on the other. We can
>>probably debate until the cows come home whether use of XML Security*
>>is a "binding", part of "core", or something else entirely.
>>
>>How can we address this? 
>>
>>I suggest that maybe we should commission YASC (Yet Another
>>Sub-Committee) to defray the effort of doing this work. I think there
>>-is- some work that needs to be done.
>>
>>~ESP
>>
>>* I realize that this is a confusing term, but it seems to be the one
>>  used by the W3C for the aggregate of XML Signature and XML
>>  Encryption, so I'm borrowing it here. If it helps, I can send out a
>>  sed script that subs the string "XML Signature and XML Encryption"
>>  for "XML Security" to interested parties.
>>
>>-- 
>>Evan Prodromou, Senior Architect        eprodromou@securant.com
>>Securant Technologies, Inc.             415-856-9551
>>