Re: [saml-dev] holder-of-key subject confirmation

["Rich.Levinson" <rich.levinson@ORACLE.COM>]

Hi Scott,

As I reread the emails a 2nd time, I find that I technically
agree with the responses that you gave, but to me the
net result of the chain of emails did not clearly explain
where the potential problems were with Tom's scenario.

I did not make any assumptions about the certificates.
As it turned out it is only when Tom introduced the
assumption that RP trusted C2 that the scenario began
to firm up.

The implicit assumptions that I think one can make as
being self-evident from the original problem description
are:

  - the IdP has a basis for trusting the user's cert, C1, because
       the IdP was willing to grant an hok assertion based on
       the user having "authenticated" to the IdP using C1 which
       is generally meant to mean the user used the private key
       to create a sig, which the IdP validated using the user's
       public key, which it presumably had available because
       it had established some prior relationship with the user.
       The "attribute" that was provided in the hok assertion
       was the user's cert, C1, which contains the user's
       subject name. No assumption is made here about C1,
       it could simply be a self-generated cert which the
       user agreed would be the user's basis of authentication
       with the IdP. Of course, a responsible IdP would make
       some effort to ensure the user's personal identification
       would match the subject in the cert, but this is a matter
       really only between the IdP and the user.

    - the RP has some kind of relationship with the IdP, which
       is why the RP "trusts" the assertion signed by the IdP.
       Again, how much the RP trusts the IdP depends on the
       terms of their agreement, but ultimately, the technical
       basis that the RP relies on is the signature of the IdP
       and the ability to verify that sig w the IdP's public key.
       Generally, the RP would expect the IdP's cert to be
       validated by a well-known public authority, which in
       some cases could be the IdP itself.

Now, if the user had used C1 as the basis for signing the message
to the RP, there would be no problem with the scenario.

However, Tom introduced C2 to the picture here, again with no
assumptions about C2.

There are 2 immediate threats I see without further qualification:

Case 1: A legitimate user and holder of key, C1, could have the
assertion they were given by IdP stolen by someone who "found"
the assertion in a log file for example. The "someone" could now
generate their own certificate, C2, copying the subject from C1,
and send a message to RP signed based on C2.

Case 2. Without further information about C1, it is conceivable that a
user could create a false identity and somehow fool the IdP into
giving the user the ability to authenticate as that false identity based
on C1. This user could now create a cert, C2, also claiming this
false identity and based on the scenario description, the RP would
be thinking they had a more secure situation than actually exists.

Neither of the above cases are possible without C2 being introduced.
Therefore, if a scenario with C2 is to be trusted by the RP, some
additional constraints need to be applied to C2 in order to tighten
things up.

The net of this is that I wondered what the motivation might be to
seemingly expose onself to these risks when on the surface it was
not necessary.

The answer that I inferred from Tom's replies was that since the
RP had a basis for trusting C2, which was new information, then
one could infer that RP's primary trust was on C2 since it was
strong authentication bound to the message content, and that f
IdP could now be viewed in an auxiliary role as providing a
second factor to firm up the subject identified in C2.

So, as I initially indicated, I do not think we disagree on the
technical details, but simply have been presenting two
perspectives of how to view the scenario and clarify its
details so that it is more substantive than the initial description
explicitly described. In particular, without applying constraints
to C2, the original description is completely unsafe, imo.

    Thanks,
    Rich


Scott Cantor wrote:

I would say the answer to this is "no". I have read all the follow-up
emails and do not think they addressed the core problem which I
will attempt to do here.
    

I would have to disagree with your argument, again on the basis that you are
assuming a particular approach to key management and interpretation of
certificates that is NOT required by any of the relevant specs.

As a SAML implementer, I am within my rights to ignore certificates as
anything other than key transport conveniences and base all decisions solely
on the public key itself. That means I am NOT required to trust certificates
at all, but can choose to rely only on the keys, and the certificates could
change without any impact on my implementation.

That isn't what Tom was asking about (it's actually kind of the opposite),
but I think it's relevant in a discussion about what somebody MUST do or MAY
do in terms of holder of key.

I think what Tom's proposing is that a PKI existing outside but related to
the SAML deployment could be used to equate certificates with the same
subject name as being equivalent (and thus their keys would be equivalent),
so that the *meaning* behind the IdP's statement remains the same.

And strictly on the basis of the specs, I think he's right. If that's a
problem for some people, then there needs to be a profile saying it's not
allowed.

  

Anyone can read the cert, C1, and create a new cert, C2 with the same
subject name etc. But no one should trust C2, because C2 was not
contained in anything signed by IdP.
    

Anyone can't just create a cert because the assumption here is that a PKI is
in place that limits who can do so and what it would contain. To put it
another way, I claim that once you do anything with certificates (and not
just keys), you are implicitly saying that the SAML alone is not your scope,
it has to include the PKI as well.

Personally, I tend to fight such approaches, but I don't think they're
"wrong".

-- Scott



---------------------------------------------------------------------
To unsubscribe, e-mail: saml-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: saml-dev-help@lists.oasis-open.org