Subject: [stir] Canonicalization vs. Comparison

From: Richard Barnes <[email-masked]>
Date: Mon, 3 Mar 2014 10:31:53 +0000

Just wanted to start a thread on this with an explanation of what I mean by
canonicalization vs. comparison approaches.  This message has a neutral
explanation of the idea, without discussion of pros and cons.  (I'm sure
we'll get to that soon :) )

In bullet point form:

Canonicalize:
-- Signer receives SIP message
-- Signer constructs "golden object" from information in SIP message
-- Signer computes signature over golden object
-- Signer inserts signature into SIP message
-- ...
-- Verifier receives SIP message
-- Verifier reconstructs golden object from information in SIP message
-- Verifier verifies signature over reconstructed golden object

Compare:
-- Signer receives SIP message
-- Signer constructs "golden object" describing information in SIP object
-- Signer computes signature over golden object
-- Signer inserts golden object and signature into SIP message
-- ...
-- Verifier extracts golden object and signature from SIP message
-- Verifier verifies signature over golden object
-- Verifier verifies that SIP message matches golden object

So for one example, suppose the signing algorithm defined a signature over
a string of the following form (following the format of the current draft):

  +12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT|

We'll call this string the "golden object", in the sense that it describes
the signer's view of how the message should look.   In the canonicalization
context, the signer would build the golden object based on a SIP message,
sign it, and insert the signature into an Identity header

  Identity: "cQhGRmuh8M...YgyQxv7NdyXz"

The verifier, on receiving the SIP message, would reconstruct the golden
object based on the received SIP message, and verify the signature over the
reconstructed golden object.  If the signature is valid, then the verifier
knows that the reconstructed golden object is the same as the signed golden
object, and thus the call matches the signer's description.  If the
signature is invalid, the verifier knows that the reconstructed golden
object is different from the signed one, but does not know what the
difference is.

In the comparison context, the signer constructs the golden object and
signature in the same way, but instead of inserting just the signature into
the SIP message, inserts both the golden object and the signature.

  Identity: "+12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03
GMT|" "cQhGRmuh8M...YgyQxv7NdyXz"

When the verifier receives the SIP message, he first verifies that the
Identity header is good, by verifying the signature over the golden object
in the header.  If the signature is invalid, there is no basis for
authenticating the call, so authentication fails.  If the signature is
valid, then the verifier compares the information in the golden object to
the corresponding information in the SIP message.  If the information
matches, then the call is authenticated; if not, not.

(Note: The syntax above is entirely illustrative and notional.)

Hope this helps,
--Richard

---

From: Brian Rosen <[email-masked]>
Date: Mon, 3 Mar 2014 10:41:48 +0000

This looks pretty much like what Hadriel proposed.  I worry that the forces that cause intermediaries to change From will want to change the “golden object”.  
I think we should have this be optional.  

Brian
On Mar 3, 2014, at 10:31 AM, Richard Barnes <[email-masked]> wrote:

> Just wanted to start a thread on this with an explanation of what I mean by canonicalization vs. comparison approaches.  This message has a neutral explanation of the idea, without discussion of pros and cons.  (I'm sure we'll get to that soon :) )
> 
> In bullet point form:
> 
> Canonicalize:
> So for one example, suppose the signing algorithm defined a signature over a string of the following form (following the format of the current draft): 
> 
> We'll call this string the "golden object", in the sense that it describes the signer's view of how the message should look.   In the canonicalization context, the signer would build the golden object based on a SIP message, sign it, and insert the signature into an Identity header
> 
> The verifier, on receiving the SIP message, would reconstruct the golden object based on the received SIP message, and verify the signature over the reconstructed golden object.  If the signature is valid, then the verifier knows that the reconstructed golden object is the same as the signed golden object, and thus the call matches the signer's description.  If the signature is invalid, the verifier knows that the reconstructed golden object is different from the signed one, but does not know what the difference is.
> 
> In the comparison context, the signer constructs the golden object and signature in the same way, but instead of inserting just the signature into the SIP message, inserts both the golden object and the signature.
> 
>   Identity: "+12125551212|+12025551212|INVITE|Thu, 21 Feb 2002 13:02:03 GMT|" "cQhGRmuh8M...YgyQxv7NdyXz"
> 
> When the verifier receives the SIP message, he first verifies that the Identity header is good, by verifying the signature over the golden object in the header.  If the signature is invalid, there is no basis for authenticating the call, so authentication fails.  If the signature is valid, then the verifier compares the information in the golden object to the corresponding information in the SIP message.  If the information matches, then the call is authenticated; if not, not.
> 
> _______________________________________________
> stir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stir

---

From: "DOLLY, MARTIN C" <[email-masked]>
Date: Mon, 3 Mar 2014 11:15:32 +0000

To be clear (yet another time), you need to sign in a matter that our SBC's will not change. To that end, a separate SIP header is the cleanest approach.

This is because certain individuals are not trustworthy, WRT the type of information communicated.

:)
-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, March 03, 2014 5:42 AM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison

This looks pretty much like what Hadriel proposed.  I worry that the forces that cause intermediaries to change From will want to change the "golden object".  
I think we should have this be optional.  

Brian

---

From: Michael Hammer <[email-masked]>
Date: Mon, 3 Mar 2014 14:50:31 +0000

Richard,

The inclusion of the golden object in the message is a waste, since the
receiver must re-generate it anyway.
The receiver cannot rely on just the golden object, since that could be
spoofed.
It can rely only on the one it generates itself, and can pretty much ignore
the one in the message.
So, this really devolves to just one case.
Also, there is a danger that someone takes a short cut and does not validate
the included golden object.

Mike

________________________________
Michael Hammer
Principal Engineer
[email-masked]
Mobile: +1 408 202 9291
542 Gibraltar Drive
Milpitas, CA 95035 USA
www.yaanatech.com

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Monday, March 03, 2014 6:16 AM
To: Brian Rosen; Richard Barnes
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison

To be clear (yet another time), you need to sign in a matter that our SBC's
will not change. To that end, a separate SIP header is the cleanest
approach.

This is because certain individuals are not trustworthy, WRT the type of
information communicated.

:)
-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, March 03, 2014 5:42 AM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison

This looks pretty much like what Hadriel proposed.  I worry that the forces
that cause intermediaries to change From will want to change the "golden
object".  
I think we should have this be optional.  

Brian
On Mar 3, 2014, at 10:31 AM, Richard Barnes <[email-masked]> wrote:

> Just wanted to start a thread on this with an explanation of what I mean
by canonicalization vs. comparison approaches.  This message has a neutral
explanation of the idea, without discussion of pros and cons.  (I'm sure
we'll get to that soon :) )

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 Mar 2014 14:08:43 -0500

> So, this really devolves to just one case.

Actually there were three benefits to it, identified in draft-kaplan-stir-ikes-out-00:

1) It lets the verifier perform a very quick fail check using just strcmp(). In other words, if the golden object it generates from the To/From don't string-match the one in the Identity-X header, then it can go ahead and fail the verification immediately without bothering to get the cert, do the crypto, etc.  IF the strings match, then it has to keep doing the rest of the work to verify it.

2) It helps debug problems for the folks running the systems.

3) It provides a way to do a "if-then-else" conditional, in case there are multiple potential golden objects. I raised that at the mic today, but kinda forgot when exactly that might happen; I just re-read the IKES draft and it points out that in call-forwarding scenarios the verifier may well have multiple To/From canonical numbers to choose from.

> the included golden object.

Yup.  The implementor has to follow the MUSTs.  Not much we can do about them not doing so. :(

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 3 Mar 2014 14:20:27 -0500

> This looks pretty much like what Hadriel proposed.  I worry that the forces that cause intermediaries to change From will want to change the “golden object”.  

If you mean change the copy in the Identity-X, I don't think they'll do that.  All that would accomplish is to fail the verification, and if they want to do that they can just reject the message themselves; and if they just wanted to avoid verification (Rather than fail it), they can simply remove all Identity-* headers.

The reason they change the To/From user portions today is to make calls *SUCCEED*. (there are other reasons they change the other portions of the To/From URIs, but we're really only talking about the user portion here)

> I think we should have this be optional.  

I think it should be optional to use/check the received golden-copy (or whatever we call the copy in the Identity-X header), but not optional to send it.

Imho, debugging and proof-of-failure is going to be really important, if we ever hope to actually reject failed call requests.

-hadriel

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 4 Mar 2014 12:06:56 -0500

+1  

-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of DOLLY, MARTIN C
Sent: Monday, March 03, 2014 6:16 AM
To: Brian Rosen; Richard Barnes
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison

:)
-----Original Message-----
From: stir [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: Monday, March 03, 2014 5:42 AM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [stir] Canonicalization vs. Comparison

Brian

---

From: "Mishra, Sanjay" <[email-masked]>
Date: Tue, 4 Mar 2014 13:11:59 -0500

Jon -- In the certificates for STIR presentation, on slide 3, the last bullet is "Proof of possession"; would this be, in any way, can be abused? That is, illegally obtained and then used?

Thanks
Sanjay

---

From: Anton Baskov <[email-masked]>
Date: Wed, 12 Mar 2014 09:44:25 +0200

Agree with Hadriel,
inclusion of golden object in a message is very useful, mostly in case of multiple To/From to choose because we have approximately 4*(N To)*(N From) variants of golden object (4 – because each To/From can appear in golden object in canonized or not canonized form).

Anton

On Mon, 3 Mar 2014 14:08:43 -0500
Hadriel Kaplan <[email-masked]> wrote:

> 3) It provides a way to do a "if-then-else" conditional, in case there are multiple potential golden objects. I raised that at the mic today, but kinda forgot when exactly that might happen; I just re-read the IKES draft and it points out that in call-forwarding scenarios the verifier may well have multiple To/From canonical numbers to choose from.Agree with Hadriel, inclusion of golden object in a message is very useful, mostly in case of multiple To/From to choose because we have approximately 4*(N To)*(N From) variants of golden object (4 – because each To/From field can be canonized or not).
> 
> 

-- 
Anton Baskov <[email-masked]>
+7 (911) 254-77-92, +7 (916) 716-89-46