RE: Subject: PartnerID revisited

[George Robert Blakley III <blakley@us.tivoli.com>]

Here are my responses

1 - agree
2 - agree
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.
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...)
     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).
     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).

--bob

Bob Blakley (email: blakley@us.tivoli.com   phone: +1 512 436 1564)
Chief Scientist, Security and Privacy, Tivoli Systems, Inc.


Simon Godik <sgodik@crosslogix.com> on 09/26/2001 12:06:01 PM

Please respond to Simon Godik <sgodik@crosslogix.com>

To:   "'Mishra, Prateek'" <pmishra@netegrity.com>,
      "'security-bindings@lists.oasis-open.org'"
      <security-bindings@lists.oasis-open.org>
cc:
Subject:  RE: Subject: PartnerID revisited





1 - agree
2 - agree
3, 4 - with respect to 5
5 - agree

-----Original Message-----
From: Mishra, Prateek [mailto:pmishra@netegrity.com]
Sent: Tuesday, September 25, 2001 8:07 PM
To: 'security-bindings@lists.oasis-open.org'
Subject: Subject: PartnerID revisited


Following the discussion on last week's con-call here are some
voteable proposals:

(1) Proposal that the bindings group DROP further consideration of
the "modified" SAML artifact proposal, wherein the SAML artifact
contains some "bounded-size" URL which can be directly used
as the address of a artifact-to-assertion-lookup service.

Agree/Disagree

[NOTE: There appeared to be consensus on the con-call to agree with this
proposition last week, so here is your last chance to object!]



(2) Proposal that the bindings document be limited to precisely the
following
web browser profiles:

(a) SAML artifact with a "small" bounded size artifact.
     (because of URL size limitations in existing browsers)

(b) FORM post.

Agree/Disagree

[I guess this is an "obvious" corollary of (1) but its always good to
 be concrete]



(3) Each site implementing the SAML artifact profile MUST select
a "Partner ID" URL. This URL MUST be drawn from a namespace owned or
controlled by the site. There are no further requirements for this URL, it
does
not
have to be the address of a web page or a service or anything at all.


Agree/Disagree (please provide alternative and rationale)

[NOTE: This corresponds to the notion that the URL is being used to "name"
 the site only. We have given up on the notion that it stands for a "real"
resource or service]


(4) The SAML artifact be architected in the following way:

TypeCode: 0x0001
Partner ID: 20 byte SHA-1 hash of URL associated with the partner
AssertionHandle: exact format TBD but maximum size of 20 bytes.

Agree/Disagree (if you disagree please give rationale and alternative)


(5) [Bob Morgan] Proposition (4) overly constrains the PartnerID format.
Its format should be left unspecified but with a maximum size (20 bytes).
However, we would RECOMMEND that sites use the approach of (3) and (4).

[After all, why should SAML intervene if a source site chooses to negotiate
a partner ID with each of its destination sites or use some peculiar
PartnerID convention with each of its partners?]

Agree/Disagree

----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>