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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-bindings message

[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