[wsf-dev] signing questions

[Scott Cantor]

> Wow. Not confusing in the least!!

Kerberos and symmetric keys have their appeal.

> ok.  Given a WSC "c" and a WSP "p".    For Peer, there must be
> ClientTLS established, meaning mutual TLS.   This requires that both c
> and p have private keys.   Does p tell c to use a specific private key
> that c has and p knows about?

I couldn't tell you for certain, I think it probably depends on the exact
mechanism. In a pure TLS model with no assertion involved, it's often
implicit what key to use. I don't know if the EPR can actually identify the
key. (I would think it could, Conor would know. But my bet is it wouldn't
normally.)

In a SAML HoK + ClientTLS model, it's obviously possible to identify the key
from the confirmation data. (That doesn't mean the WSC is looking at it,
just that it could.)

The SAML + ClientTLS model is not any different in terms of these issues
from the SAML + Signing model. Initiating TLS with a key vs. signing with a
key is not really that different, at least conceptually.

> ugg.. So as a WSC, the SAML Assertion given to me would specify that I
> use a specific private key for the TLS?

Or for signing, same issue.

It does in some fashion, because it has to tell the RP (WSP) which key had
to be used to satisfy HoK. The trick is that KeyInfo is wide open so there's
no rule saying *how* it tells the RP that.

Whether the WSC is looking at that also is an implementation issue. I know
from past conversations that many implementers wouldn't, they prefer to
remain ignorant of the token. It seems to me that implies you have to guess
(or just know) the key to use. That's a nice theory, but in practice the use
of PKI all over tends to lead to deployments wielding multiple certificates,
sometimes with different keys. That may or may not imply that the WSC ends
up having to look at the assertion.

We have layers of code responsible for mapping a KeyInfo into the credential
store(s) to find the right key. This is one place I would use it, and
another is for decryption (the sender tells me which of my keys he used to
encrypt the bulk encryption key under).

> I see.  So what I am currently doing, which is signing an outgoing
> message with my very own key, paying no heed to the SAML Assertion,
> would be acceptable, but has no relationship to the TLS:SAMLV2 sech
> mech.

Well, no. If the assertion is HoK, then you MUST sign and you'd better guess
right about which key to sign with. And the SAMLV2 mech in Liberty implies
HoK, that's part of the profile. Bearer implies, well, Bearer.

And to correct myself again (ok, my original message was a winner, too much
caffeine)...I forgot that the second to last field can be TLS or ClientTLS.
TLS alone just means server side TLS. So the one I was trying to point out
in that original note was ClientTLS:peerSAMLV2. I felt it needed to be
mentioned because I don't think much of XML Signature, and I think ClientTLS
is often a much more reliable means of addressing that requirement.

Summing up (corrections welcome and no doubt forthcoming):

TLS:SAMLV2 means the server uses TLS, the client signs and has a HoK
assertion.

TLS:Bearer means the server uses TLS, the client just attaches a Bearer
assertion.

ClientTLS:Bearer combines mutual TLS with a Bearer assertion, giving you
some additional flexibility to identify a user in the token.

ClientTLS:peerSAMLV2 is where you do mutual TLS, have a HoK assertion, but
don't sign.

The edge case is ClientTLS:SAMLV2, which is an outlier.

> Rather it is signed TLS:Bearer with the Bearer Token being a
> SAML assertion.

See above. That wouldn't have to involve you signing. It *could* if you
wanted to, but isn't part of the assumed behavior in the spec.

> I am relying on the party that I am communicating
> with to already trust me (and trust that I've kept my key safe and not
> checked it in to an open source svn repo) and have my public key
> available.

Any place you're not using a SAML HoK token to "broker" your key, then the
trust model in use between you and the WSP for any use of a key by the WSC
is out of scope. Necessary, just not specified.

> I get it now.  So this could potentially save a high traffic end point
> a great deal of pain by hinting at the proper cert.

That's the idea, yeah. You don't want to waste time doing RSA math using the
wrong key. If you can guess right, you can handle things like key rollover
where you run with two keys for a time without hurting performance.

The point of all this I'm saying is that you can talk all day about the
"normal" way to do all this stuff with KeyInfo, but at the end of the day,
nothing requires it. The challenge is decoding how far to go handling all
the options. Some of them are just plain stupid, IMNSHO, and others have
reasonable justifications.

> 1. SAML Authority issues a HoK Assertion to the WSC (through some auth
> process).  The WSP has a trust relationship with the SAML Authority
> 
> 2. WSC signs a request with its private key and sends request to WSP
> over SSL (using the WSPs cert).  WSP already has or is supplied with
> the WSCs public key

In a HoK case, the WSP doesn't need the WSC's key in advance (or even any
way to trust it directly).
 
> 3. WSP signs message with its private key and sends response encrypted
> with the key provided in the HoK Assertion.  WSC already has the
> server's public key.

Well, you're saying TLS/SSL, so in that case I doubt the WSP would encrypt
its response, the channel handles that for you. If it did encrypt, yeah, it
could certainly do it with that key from the assertion, it's being told that
the requester owns that key.

> How does the WSC decrypt the response?   Step 3 is a little fuzzy to me.

Because it isn't really typical. If you took out the SSL though, sure, you
could encrypt the messages with XML. You're asking about the mechanics of
that, that's a whole other thread. In brief, with a PK model, you randomly
generate a symmetric key for the encryption, then you encrypt/wrap *that*
key with the recipient's public key. The WSC would decrypt the encryption
key with its private key and then decrypt the data.

(And oh yeah, all those decrypt steps involve KeyInfo to identify *your* key
to use to decrypt with.)

> So as a WSC my life is relatively simple, unless I want to do
> verification of a WSPs responses.

Yes, this is by design in ID-WSF. (I'd note that it isn't as simple when you
wield multiple keys and certs though.) And I realize that's what you were
asking about, but the full stack has to deal with the whole picture. It's
important to understand it (even if it takes me three tries to correct my
own mistakes and undoubtedly more input from others to correct many more).

-- Scott