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


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

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

Subject: RE: [security-services] FW: Comment from: Nicolas.Williams@sun.com

Prateek wrote, excerpting: 

>>    - channel binding issues
>>       - When relying on non-SAML-based channels for
>> session security 
>> there may be security considerations issues relating
>> to the possibility 
>> that the end-points of the two channels may be
>> different -- i.e., just 
>> saying "use TLS" does not mean that there will not
>> be
>> MITMs in a SAML 
>> exchange.  Similar issues have come up at the IETF
>> w.r.t. SASL and TLS, 
>> for example.
>I am not sure of the specific change you are
>suggesting here. Is there language regarding use of
>SSL/TLS that we should change?

Use of TLS with only server-side certificates protects the client from
TLS-layer MITMs, but provides no TLS-layer authentication of the client
to the server.  Further, if the peer SAML entity isn't the same entity
named and authenticated at the TLS layer (as might happen without malice
if the SAML entity is a separate component located behind the component
that implements), TLS's authentication doesn't directly demonstrate the
authenticity of a message relative to the identified SAML peer.  I think
Sec. 6.1.6 of Security Considerations treats these issues for the SOAP
binding, with later sections considering them for other bindings and
profiles.  At lines 951-954 of sec-consider-2.0-cd-03, it seems from
context that bilateral TLS authentication may be required, but the
wording may be subject to alternate interpretations. 

>>  - Sec. Cons., section
>>    Requiring that initiators sign initial messages
>> does not necessarily 
>> significantly reduce the responder work load that
>> malicious initiators 
>> can cause since, presumably, the responder would
>> have
>> to validate the 
>> signature.
>Agreed, but the notion here is that malicious
>initiators are forced to work harder if signatures are
>required. Responders are less affected as signing is
>generally considered to be more computation-intensive
>than its validation. I believe this is precisely what
>the text states:
>"In addition to the benefits gained from client
>authentication discussed in Section, requiring
>signed request also lessens the order of the asymmetry
>between the work done by requester and
>responder. The additional work required of the
>responder to verify the signature is a relatively
>percentage of the total work required of the
>responder, while the process of calculating the
>signature represents a relatively large amount of work
>for the requester. Narrowing this asymmetry
>decreases the risk associated with a DOS attack."

Having a larger work factor for a requester than a responder is useful
in protecting against attackers that are generating large numbers of
messages in the hopes of having one or some accepted by their target.
This may not be the most likely form of DOS attack, however; if an
attacker simply wants to swamp the responder, without expecting to
generate a message that the responder will take other action upon, the
attacker can include random bits in the signature field.  This comes at
very low cost for the attacker, but could still incur greater cost on
the other side if the responder tries to verify those bits as if they
correspond to a signature. 


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