RE: [security-services] Comments on Attribute Sharing Profile for X.509 Authentication-Ba sed Systems (draft 10)

Title: RE: [security-services] Comments on Attribute Sharing Profile for X.509 Authentication-Ba sed Systems (draft 10)

Tom, sounds good.

I agree with your other email from 7/9/2006.

Tom.

> -----Original Message-----

> From: Tom Scavo [mailto:] 

> Sent: Monday, July 10, 2006 10:07 PM

> To: Thomas Wisniewski

> Cc: OASIS SSTC

> Subject: Re: [security-services] Comments on Attribute 

> Sharing Profile for X.509 Authentication-Ba sed Systems (draft 10)

> 

> 

> On 7/7/06, Thomas Wisniewski <> wrote:

> >

> > 5. line 481-486  Add the following thought somehow. Basically, 

> > transport-level security alone will not provide SAML message 

> > authentication of the sending party. I.e., a receiver can 

> authenticate 

> > any requesting party it trusts and that will provide 

> confidentiality 

> > and message integrity. However, it does not satisfy the requirement 

> > that the message (SAML xml

> > content) sent is in fact coming from the authenticated 

> requester. For

> > example if the receiver trusts requester A and requester B. What if

> > requester A sends a SAML message stating that its 

> IssuerName is that of

> > requester B. Strictly tranport-level security would not 

> suffice. So either

> > XML signatures is required or SAML message authentication 

> is required.

> > So for Enhanced Mode, transport level security would not suffice in

> > single-hop scenarios (the current text implies it would be 

> ok -- and the

> > need for dig signatures is really because of the 

> possibilitly of multi-hop

> > scenarios).

> 

> Tom, you're right, and this has consequences beyond the lines 

> cited. For instance, I should rewrite the introduction to 

> section 2 in light of your remarks.  Also, some of my 

> outstanding comments (not implemented in draft-10) are 

> irrelevant as well.  Good catch!

> 

> What I believe is true is the observation that multi-hop 

> scenarios heighten the need for Enhanced Mode.  That said, I 

> can't come up with a very satisfying multi-hop scenario, so I 

> think I'll drop the notion altogether.  I will also rewrite 

> the text to be more in line with your comments above.

> 

> Thanks, Tom.

> 

> Tom

>