[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Subject: PartnerID revisited
Bob, Some comments: >[Bob] > >3 - agree provisionally. Are there more requirements, like that the >partner ID URL should be "unique-ish" -- i.e. > not duplicated or an alias for something else used for another >purpose >etc...? And what does > "drawn from a namespace...." mean exactly? Does it mean "the base >URL >for the site must be > a prefix of the Partner ID URL"? If so, that's what we should say, >so >that interpretations don't differ. Agreed. This was my intent. I will circulate a modified text for (3) wherein it is explicit that "the base URL for the site must be a prefix of the Partner ID URL". >4 - ooohhh... don't know: > > Type Code 0x0001 is OK > Partner ID = SHA-1 hash of partner URL is NOT OK, unless: > namespaces from which partner URLs are drawn have >distinct >roots, so that > attackers can't induce collisions (i.e. if the meaning of >"drawn from a namespace..." > is as I speculate in response to #3, AND if the base URL >for >the site always begins > with an administered DNS name, then we're OK as long as >no >one can spoof DNS. > Otherwise, we're in trouble...) I think with the change in language above, we are in agreement here. There is no change needed to the language of 4 (right?). DNS spoofing, I am afraid, we are stuck with (for some time at least). >Exact format of assertion handle is of course very important and I >owe >further dialog with Prateek on > this. >5 - agree "sort of" with RLBob's concern. > I believe that Partner ID in fact SHOULD be strictly specified >(because otherwise we can't guarantee > proof against ID spoofing via inducing collisions). Here you are actually disagreeing with 5. RL Bob's point was that requiring a partner ID in a certain format is not entailed by SAML requirements (e.g., interoperability). We are not providing any protection against spoofing anyway --- the SAML artifact isn't signed so an attacker can just guess a SAML artifact and hand it off to a destination site and play all kinds of tricks. Of course, when the destination site calls back the source site it must provide an appropriate assertion handle, so things will usually end at that point. It is a separate matter that arranging for Partner IDs in some ad hoc manner will probably get a source site into trouble anyway. Hence, the suggestion we RECOMMEND the above partner id format. If people insist on doing their own thing, good luck to them... > However, I believe that we should NOT strictly specify the >assertion >handle format (since it's always > consumed by the same implementation which produces it, >specifying it strictly is > an improper imposition on the freedom of implementors.) >However I think we SHOULD > include a format which we believe to be resistant to the >attacks we think will occur, > and we SHOULD recommend this format (i.e. we SHOULD use >SHOULD to > encourage implementors to use our format, but we SHOULD >NOT >use MUST > to require them to do so). Agreed, I have no issue with your formulation. - prateek
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC