[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