On Jul 16, 2008, at 2:36 PM, Dean Willis wrote:
I've been informed that despite what I incorrectly thought,
transitive signing doesn't require any modification to RFC 4474.
The 4474 spec requires that the subject of the cert used to sign
correspond to the domain of the From. This is different from
requiring that the common names match. So any SBC can re-sign
anything at any time and break nothing, at the expense of some
crypto work.
So, let's say [EMAIL PROTECTED] calls [EMAIL PROTECTED] Nostrum's AS
might sign Adam's INVITE. Cisco's SBC might verify the signature,
munge the fields, mint itself a cert with a subject of
"nostrum.com" (using its well-known Nostrum CA key to sign that
cert!) , and then sign the request (replacing the Nostrum
signature) using the new cert. Then [EMAIL PROTECTED] would verify
Cisco's signature, and transitive trust is created. Of course this
doesn't say anything about why Michael should trust that signature,
although in this simplest case the rationale is obvious. But for a
3rd service provider "in the middle", it is much less obvious.
Having beaten a new version of the truth out of myself (assisted by
questions from Hadriel and Cullen), I now know that what I meant to
say was subtly but critically different:
-------
I've been informed that despite what I incorrectly thought,
transitive signing doesn't require any modification to RFC 4474.
The 4474 spec requires that the subject of the cert used to sign
correspond to the domain of the From. This is different from
requiring that the common names match. So any SBC can re-sign
anything at any time and break nothing, at the expense of some crypto
work.
So, let's say [EMAIL PROTECTED] calls [EMAIL PROTECTED] Nostrum's AS
might sign Adam's INVITE. Cisco's SBC might verify the signature,
munge the fields, mint itself a cert with a subject of
"nostrum.com" (using its well-known Cisco CA key to sign that
cert!) , and then sign the request (replacing the Nostrum signature)
using the new cert. Then [EMAIL PROTECTED] would verify Cisco's
signature, and transitive trust is created. Of course this doesn't
say anything about why Michael should trust that signature, although
in this simplest case the rationale is obvious. But for a 3rd service
provider "in the middle", it is much less obvious.
------
I hastily typed "using its well known Nostrum CA key" instead of
"using its well known Cisco CA key" in the last paragraph. I knew what
I meant, I just typed the wrong word. Sorry.
This (as corrected) AFAIK cryptographically works. But it doesn't work
any better than P-Asserted-Identity and TLS. It still lacks a
reversible chain-of-trust that is visible to the end user.
I suppose the advantage is that, in the absence of an evil crypto-
mangling SBC, you'd still get the benefit of end-to-end (or at least
authentication server to verifier) RFC 4474, which MIGHT involve less
transitive trust. But that doesn't seem too useful to me. I think it
would be much better to just patch RFC 4474 to work through the SBC.
Another option would be to have each rewrite take the old request and
wrap it in a a sipfrag body, then sign that request as part of the re-
siging process. That way the final verifier would be able to work
backwards through the chain of rewrites and verify each and every one
of them. Of course, it one of the re-signing SBCs were more evil than
usual, they'd still be able to lie to us about what was happening. But
we'd be able to debug which SBC had "broken", from a diagnostic
perspective.
--
Dean
--
Dean
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
