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] | [Elist Home]


Subject: Re: [security-services] Changes for Core 26



All,

> [...]Each PEP knows what its own
> internal matching rules are, and must determine the canonical form for its
> resource name BEFORE it passes the resource name to the PDP. 

The above has the consequence that either:

a) both PEP and PDP use the same c14n scheme, or,
b) we leave open security "holes"

Let me restate that another way: vendor 1's PDP has to work with both 
its own and vendor 2's PEP. Both PEPs can serve the same resource, 
that's a matter of local configuration, not for saml to decide, and
will happen (e.g. if "http://foo.com/common-stuff" is required in
different contexts or one PEP is part of an application layer
gateway like a HTTP proxy). Unless we state how its to be done, 
different PEPs will use different c14n rules (e.g. assuming that
"http://foo.com" is/isn't the same as "HTTP://foo.com"), thus 
opening up security holes.

This isn't an academic point, it has shown up as a bug, (hopefully
fixed!) already in afaik all current products. I'm not sure if it 
has been deliberately used in a live attack or not.

At least for HTTP URLs I maintain that SAML is broken, and represents
a dis-improvement to the state of the art, if it doesn't state the c14n 
scheme to apply. 

That's what I was proposing - build in knowledge of HTTP URL c14n since 
without it PDPs will say "yes" when they shouldn't on the basis that 
some initiator has gotten some PEP to ask about "Foo.com" instead of 
"foo.com". I don't care if saml wants to invent a new c14n rule for URLs,
just so long as its documented (and works!), I only proposed 2396
since it exists and doesn't seem very broken.

> Otherwise we're
> asking for a world of pain, because to avoid potential security holes we
> would need to duplicate the quirks of every PEP.

I think the pain's just there, with no way to avoid it (we can OTOH
pretend we've avoided it at the cost of being obviously insecure;-).

Stephen.

PS: c14n = canonicalization (just in case)

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com


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


Powered by eList eXpress LLC