> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Dean Willis
> Sent: Thursday, July 17, 2008 5:23 PM
> To: SIP IETF
> Subject: [Sip] Where Dean Went Wrong With Signing P-Asserted-Identity
>
>
> 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.
Like other protocols (see below), SIP needs to identify who injected
a message into the SIP network.
We can't identify who injected a message using RFC4474. As described
above, RFC4474 only identifies the most recent hop. As you point out,
the most recent hop is already known because the signaling is SIP-
over-TLS.
Identifying who injected a message into a network is the same problem
that USENET had for its posts and its cancels. For a few years you
could assume the last host in the Path: header injected the message,
but of course people started forging the Path: header when they
injected a message, causing misdirection. With USENET, you could
start asking your neighbors and eventually learn which host really
injected a certain USENET message. But this was not an appealing
solution. To authorize 3rd party cancels and identify who injected
cancels into USENET, various mechanisms to sign 'cancel' messages were
born. (Of course, USENET growth has tapered off, especially with
the recent killing of alt.coffee by the New York Attorney General).
Coming back to protocols the IETF has standardized:
Email also benefits from identifying who injected a message into the
email network, even when the message traverses alias expanders,
mailing lists, or had footers inserted ("The contents of this message
are proprietary, burn it if you aren't supposed to receive it"). DKIM
was born.
Transport protocols experience blocking and interference from
firewalls -- much like SBCs block and interfere with SIP and RTP.
Blocking ICMP is the most famous: ICMP messages are blocked by
mis-configured firewalls (if you are an IETF person) or blocked by
properly-configured firewalls (if you are a non-IETF person).
Noticing this reality, and the lack of success with TCP PMTUD
black-hole discovery in many implementations, RFC4821 was born.
Yet SIP continues to stand apart.
In Dublin we have an opportunity to drink real beer. We should
also tackle one of SIP's real problems: identity.
-d
_______________________________________________
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
