OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] Groups - WSS-SAML-09.pdf uploaded



Replies interspersed below (this discussion gets
quite detailed, but I have made a sincere effort to
try to stay on point and narrow rather than broaden
the scope):

Again, I think the bottom line is that using a BST to
contain the attester cert in the sender-vouches scenario
is a better (cleaner and simpler) option than using a 2nd 
saml assertion to contain the attester cert.

> -----Original Message-----
> From: Ron Monzillo [mailto:Ronald.Monzillo@Sun.COM] 
> Sent: Friday, January 30, 2004 12:49 PM
> To: Levinson, Richard
> Cc: wss@lists.oasis-open.org
> Subject: Re: [wss] Groups - WSS-SAML-09.pdf uploaded
> 
> 
> 
> Levinson, Richard wrote:
> 


> >Ron,
> >
> >First I will recount where I think we are in this discussion 
> and what 
> >the potential outstanding issues are and then I provide a suggestion 
> >for addressing the situation.
> >
> >(bottom line (to avoid reading all the details): suggestion
> >is to have STR2 point to a BinarySecurityToken with the attester 
> >cert (similar to section 3.3.2 of the X.509 profile, except in 
> >our case the sig ref points to the assertion and the sig keyinfo
> >points to the BST):
> >


> Rich,
> 
> Unless I am misunderstanding you,
> This is what the example in the spec currently does, except 
> STR2 points to a SAML assertion acting as the attester cert, 
> and the sig ref points to the subject assertion and the sig 
> keyinfo points to STR2, and thus the attester cert. Other 
> than the example using only SAML ST's, I think it analogous 
> to what you propose. Maybe you are focusing on the token 
> combination we should demonstrate by interop.
> 

Yes, functionally I guess it is equivalent. I was a little
confused with the actual "sender-vouches" assertion not
being shown because it is externally accessed, and the
on message assertion being holder-of-key. I understand it
now but think that readers who are not intimately familiar
with all the options may have difficulty with it.

And you are correct that I am focussing on putting together
a self-contained scenario for the interop, and I think that
having the signature point to a 2nd saml assertion is not
necessary since the recipient is trusting the public key
of the signer/attester, not the fact that the public key is 
obtained in an assertion backed up by a trusted saml authority.
My sense is that recipients will probably populate their 
key stores with certificates from well known issuers rather than
self-generated certificates backed up by saml assertions.
So, for the interop, I think I am going to go with the 
BinarySecurityToken as the holder of the attester cert.

> Anyway, I think there is a problem with the existing 
> approach, especially when STR 2 does not either have a 
> "usage" attribute to inform the actions of the receiver. 
> Without such a cue, The receiver has to recognize that this 
> is a SAML profile msg, as aposed to an X509 profile msg, to 
> be able to properly determine the authentication identity 
> that should be associated with the msg.
> 

If we use a BinarySecurityToken here, I think things are 
simplified since there is no ambiguity about identity of
the attester. I think the main point of saml sender-vouches
is that the attester is vouching for the subject of the 
saml assertion, and there is not really a need for the
attester to also be represented by a saml assertion, and
as you have shown that leads to issues regarding whether the
requester is depending on the signer of the message or the
authority that issued the saml assertion that contains
the cert the attester used to sign the message. i.e. it
seems to be implicitly forcing a chaining mechanism to
be defined for saml assertions similar to certs which is
not currently a practice to my knowledge.

> To do this, the receievr has to infer from the fact that a 
> SAML assertion was signed, and that its confirmation method 
> was satisfied, that the identity of the signed assertion 
> should be applied to the msg, as apposed to the identity 
> bound to the attester's security token; which if refactored 
> as you suggest would be an x509 cert.  Such messages will 
> look a lot like conventional x509 confirmed msgs. The fact 
> that this is  an impersonation scenario is not easy to recognize.
> 

I'm not sure if I totally follow you here, especially the phrase
"the identity of the signed assertion should be applied to the msg".
I think what you are saying is from the receiver's point of view,
who is actually accountable for this message. If that is the case,
then the receiver needs to have a way to recognize the attester,
and this would be thru the attester's signing cert, which the 
receiver would have in a key store and can be used to verify
the signature on the message components. As I indicated above,
if this cert is backed by a saml assertion rather than conventional
PKI then we have kind of a new use case that I think is outside
of the current scope of common practice even in the saml domain.
So, from that point of view I don't think we would want the
attester identity to be defined by the saml assertion but
by the attester cert.


> >    Recount of discussion:
> >
> >I believe we are in agreement on the "unsigned assertion"
> >case where the attester signs both the assertion and the 
> message body 
> >and the basis of trust from the receiver perspective is the 
> public key 
> >of the attester with which the attester may verify the signature 
> >covering both the body and the assertion and based on the 
> recipient's 
> >trust in the attester's certificate all the relevant information
> >is trusted.
> >
> >In addition, in the above case we put the attester's 
> certificate in the 
> >saml:SubjectConfirmation/saml:SubjectConfirmationData/
> >ds:KeyInfo element using the SCD element to contain the 
> KeyInfo rather 
> >than the SC element which is intended for the subject 
> certificate info.
> >  
> >


> I was suggesting somnething like what you describe above, 
> leaving aside for the moment the ConfirmationData vs KeyInfo 
> distinction you have since  made, as an alternative to what 
> is ]currently being done in the spec. I don't think we would 
> do both. This is sort of a backpointer to the cert of the 
> attesting entity, since 
> the front
> pointer in the signature keyinfo is to the attester's cert. 
> The problem as I see it, is it is difficult for the receiver 
> to know when to apply SAML token profile semantics, unless 
> the front pointer points to a SAML assertion.
> 
> At a high level, I was proposing that the KeyInfo reference 
> in the Signature point to a Subject assertion because it 
> would make it easy for the receiver to recognize that the 
> message was signed using the SAML token profile, and that the 
> indended authentication entity was the Subject of the 
> Assertion. This is already how we profile hold-of-key.
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]