RE: [wss] Action item : Move Consolidated Issue 24-25 to list

["Hallam-Baker, Phillip" <pbaker@verisign.com>]

Hi all,

On this topic, had conversations today regarding XrML, now renamed
REL with the XrML people. Also spoke to Anthony Nadalin on this action 
item.

As a result I think we now have a clearer idea of how the tokens fit in.
In particular we considered the following design goals.

1. The security tokens may fill different roles
   *	A Kerberos token provides services for authentication and
confidentiality,
	namely a derrived key.
   *	An X.509 certificate may either provide an authentication or 
	a confidentiality service with respect to a particular message
(if the
	signing public key is the encryption public key something wierd
is
	happening.
   *	A SAML token may provide an Authentication service or an
Authorization 
	service (lumping Attribute and Authz assertions together, it is
input
	to an Authorization process in both cases
   *	An XrML/REL token provides an Authorization function

2. Eliminate unnecessary path discovery
	A particular WS-Security message may have several tokens, say a 
	Kerb ticket for authentication, an XrML token, plus a few SAML
	Attribute statements. In cases where the application generating
	the message knows how these relate the relationship should be
	preserved wherever possible.

	In other words we don't want to have fuzzy chaining code being 
	required.

3. Avoid multiple options for placing the tokens.
	The verification code should not need 6 code paths for playing
	hunt the security token

4. Avoid repeated placement of the tokens
	Should not need to repeat a Kerb ticket in the encryption
	and signature header.


In addition we observed the following:

* It is realy authentication, not proof of possession
* The KeyInfo element defines a mechanism for linking to a security
	token by reference.

So the proposal is to modify the profiles to consider the following
possible uses:

1 Derriving Confidentiality Key Information
	For X509 this is specified by XEncryption
		[Except that the token should be referenced using the 
		retrieval info pointer]
	For Kerberos this may need some extra info

2 Derriving Authentication Key Information
	For X509 this is as specified in XML Signature
		[Except that the token should be referenced using the 
		retrieval info pointer]
	For Kerberos this may need some extra info
	For SAML this is specified in the SAML documents

3 Derriving Authorization Data (Decisions, Policy, Attributes)
	There is a fuzzy line here, any system that can specify any
one of these can be used to specify all three, even though the issues
are actually different.

	SAML and XrML can both be used to specify this type of
information.
	In the case of SAML it would be Auth Decision and Attribute
	Assertions.

	Since management of the Authorization information is always 
policy driven and can always be overriden in practice by the enforcement
point the specs here need to be worded accordingly.



			Phill


> -----Original Message-----
> From: ronald monzillo [mailto:ronald.monzillo@sun.com]
> Sent: Monday, November 04, 2002 3:47 PM
> To: wss@lists.oasis-open.org
> Subject: [wss] Action item : Move Consolidated Issue 24-25 to list
> 
> 
> The purpose of this msg is to address the action item I took in
> our last teleconf, to move issues 24-25 onto the discussion list.
> 
> 24. Why is it necessary to treat XML Signature elements
> as other than security tokens?
> 
> 25. Given the current core specification, how can a signature
> element occuring outside of the header be referenced (as in,
> identified for validation) from within a wsse header?
> 
> --------
> 
> The ws-security spec defined security tokens (STs) and security
> token reference (STRs). STRs are used to cause STs that "reside
> somewhere else" to be pulled by the receiving application or to
> reference STs (presumably containing signing keys) from XML
> DSIG elements.
> 
> The questions captured by issue 24-25 arose from a consideration
> of how ws-security could be used to support a use case where
> persistent, document centric signatures enveloped within a
> SOAP body or attachment, could be referenced for validation from
> a wsse header.
> 
> To be referencable by an STR such signatures would need
> to be considered a ST, and more importantly would need to be
> identifiable by STR.
> 
> If signatures should be considered STs, it should be possible
> to extend the STR paradigm to reference them. If they are not
> STs then referencing them would likely require that another
> artifact be added to the model.
> 
> One thing to consider would be how signature references
> would be secured, although I think reference integrity will
> also be an issue where STRs are used to pull STs.
> 
> Since the last teleconf, Tony and I have had one discussion
> on this topic, in the context of the larger issue set (3,4,5
> 19,and 23) that includes consideration of reference forms,
> token labeling, and more formal treatment of proofs. 
> 
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>

Attachment: smime.p7s
Description: application/pkcs7-signature