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] comments on (most of) core-25



Phill,

Of those you picked, only the "line 705" issue is really of major
importance (the others aren't entirely nits though). I've moved 
the 705 issue to the top to make it more likely that folks read 
about it.

Stephen.

> 705: It is a URI, therefore no syntactical possibility of a wildcard

I know this was debated some time ago and assume that "no wildcard 
resources" (e.g. no "http://foo.com/images/*.gif") reflects the 
consensus (with which I'd disagree mind you, but ignore that for
now:-). In any case, the spec doesn't say anything at all about 
this and in fact even fixing that still leaves open the interpretation 
of, at least, directory name URLs (i.e. ending in "/").

Put it this way: If the spec isn't clear on how a PEP should interpret 
an AuthorizationDecisionStatement of "allow http://foo.com/images/" 
then its broken in the simplest possible (and most unbelievable!) way 
and I'd rather you remove my name from the the document. 

Now, I'd much rather that the spec were clear and included me in the 
acks of course, but *only* if the above is properly clarified. (btw: 
if the "Contributors" section is only supposed to list people who are 
voting members, then I should be removed anyway.)

To be clear: I'm not asking that the spec say that "allow http://foo.com/images/" 
be interpreted in my favourite way - just that one of the reasonable
intrepretations be chosen and that that be clearly documented. I can think
of three intrepretations (none of which is fully developed here) for
the statement "allow http://foo.com/images/", namely:

- statement implies nothing about "http://foo.com/images/image1.gif" 
  and the PEP has to ask the PDP each and every time, however, the spec 
  still needs to say this & how the (web server specific) equivalent of 
  "http://foo.com/images/index.html" is to be handled by PEPs (presumably 
  the web server or PEP should have expanded the URL and not asked 
  the PDP about "http://foo.com/images/")
- statement implies to PEP that "allow http://foo.com/images/image1.gif" is
  also true i.e. any URL beginning-with "http://foo.com/images/" - this would
  be a rule probably specific to http URLs and so PEP has to ask again about
  "http://foo.com/imagesThatShouldBePrivate" (and we need tp define handling
  of "http://foo.com/images/public/../../private/" and similar)
- statement implies that "images/images1.gif" is ok but that PEP must ask
  about "images/private/image1.gif", i.e. rule specific to http URLs and
  where directories are handled specially and not just as the start of 
  URLs (still need specical rule for "images/.." but in this case not for
  "images/../../")

Also, since i18n has been used as an exploit and SAML mustn't re-create 
such vunlerabilities, we must make sure that the chosen rule doesn't
do so (and ideally, explain that to the reader somewhere). And even 
though case sensitivity will be addressed elsewhere, since its such a 
PITA for URLs, how that's handled should be described/referenced here 
too.

I'm sure that there're more than the three options above too. Just pick & 
*clearly* document one. There's definitely enough experience in this group 
to get this right and no excuse for getting it wrong.

> 200: Actually to be really pedantic it should be Internet DNS domain since
> there are actually non-Internet DNS domains.

Fine.

> 215: Which paragraph?

"SAML authorities...of assertions." All line numbers in my comments are 
from the pdf.

> 237: The #rwed debate, deferred

Pity. But ok for now.

> 295: Wording was carefully chosen to avoid the birthday paradox.

Shame it didn't then:-) (unless you want that IDType values MUST be 
256 bits and SHOULD be 320 bits?) 

Birthday p/dox implies that given a population of 2^64 random strings 
of length 128 bits you've a 50% probabality of a collision in the set 
(I hope:-). I interpret the current text as implying (not saying) that 
I need to use at least 256 bit strings so that even in a large (2^64) 
population, the probability of a collision is still "cryptographically" 
small.

I think the wording I suggested avoids the issue, is simpler and clearer.
However, I won't insist on you using that, but please do explicitly say 
that you want IDtype values to be at least 128 bits long since with the 
current text that only follows depending on your interpretation of how 
the birthday paradox affects this text (in particular what you think 
"randomly chosen" means:-).

Having said that, this is really a nit (since the effect of misreading the
spec is positive given that no-one will have a problem with longer-than-
expected IDtype values). So fix/not as you like.

> 603: It is an attribute, not an element so does not need to be declared
> optional.

Fair 'nuff. However , now I see and agree with the significance of Eve's 
comments on NameIdentifier being broken. 

> 664: IPv6 addresses eeek!

'Fraid so. At least state that you're only allowing IPv4 and how they should
be written (dot sep is it? what about network byte order? what if some gobsh*&$e
puts in 257.258.259.999).  That I can live with.

However, IMO its a bit late in the day for a new standard to claim that 
IPv6 is a weird unknown thing that we can safely ignore - do we want SAML 
bounced by the 3G folks for this reason? Not saying that'd happen, but
no reason to chance it, is there?

> 779: Can directly reference LDAP values via the LDAP URI. I don't think we
> should limit ourselves to LDAP though, I think we should accept the
> probability that LDAP will eventually be replaced with an XML form.

Like DSML? That's what I'd like. I can live with this being addressed 
later, but there was some support for at least demonstrating how LDAP 
attributes could be mapped to SAML attributes. I think that this was 
also agreed to be an interoperability issue (was it?), in that we don't
want there to be 9 different SAML versions of the equivalent attribute
set to inetOrgPerson in particular.
 
> 825: Moot/fixed with the anyType

ok.


-- 
____________________________________________________________
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