Subject: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 4 Mar 2009 19:28:37 -0500

Howdy,
In an effort to avoid endless thrashing, I will be updating the Session-ID draft to only be about troubleshooting use.
For dialog matching issues, I have followed Adam's advice and submitted a separate draft to update RFC 3261, linked below.
This issue will only get worse, and the code changes to do this should be fairly small for most folks, I would think.
And it's only 6 pages, so we should be able to agree on this in about 3 years.  :)

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : A Secure Call-ID for the Session Initiation Protocol (SIP)
        Author(s)       : H. Kaplan
        Filename        : draft-kaplan-sip-secure-call-id-00.txt
        Pages           : 6
        Date            : 2009-03-04

Many SIP devices generate Call-ID values which contain their system IP Address, due to examples and normative text in RFC 3261.  This has led to some middleboxes, such as SBC's, to change the Call-ID for security reasons.  This draft updates RFC 3261 to require SIP User Agents to generate benign Call-IDs, in such a manner that they can be detected as secure and not need to be changed.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-sip-secure-call-id-00.txt

-hadriel

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 05 Mar 2009 17:14:30 +0000

Hadriel,

Should we specify something that would make life easier for
proxies/B2BUAs to detect compliance with this, e.g., a magic string at
the start of the call-ID, rather than simply the absence of "@"?

John 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hadriel Kaplan
> Sent: 05 March 2009 00:29
> To: SIP
> Subject: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt
> 
> Howdy,
> In an effort to avoid endless thrashing, I will be updating 
> the Session-ID draft to only be about troubleshooting use.
> For dialog matching issues, I have followed Adam's advice and 
> submitted a separate draft to update RFC 3261, linked below.
> This issue will only get worse, and the code changes to do 
> this should be fairly small for most folks, I would think.
> Many SIP devices generate Call-ID values which contain their 
> system IP Address, due to examples and normative text in RFC 
> 3261.  This has led to some middleboxes, such as SBC's, to 
> change the Call-ID for security reasons.  This draft updates 
> RFC 3261 to require SIP User Agents to generate benign 
> Call-IDs, in such a manner that they can be detected as 
> secure and not need to be changed.
> 
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 5 Mar 2009 18:44:17 -0500

> From: Elwell, John [mailto:[email-masked]]
> Sent: Thursday, March 05, 2009 12:15 PM
>

At one point I was thinking of just making it either be an "invalid" host:
Call-ID: randomstuffheregibberish@invalid

Or a fixed-length hex-ascii type thing (like Session-ID).  But then someone pointed out to me that some devices already don't put their IP/host in it, so there's no reason to go make them change their implementation, nor replace their call-id until they do.

The thing is I think that a proxy/b2bua which cares about this for security properties, would need/want to scan the whole call-id for something which looks like a host/IP anyway, to make a dynamic decision.  So having a magic string won't help them.  And B2BUA's which change it for non-security reasons will change it no matter what, because it's not the privacy property they care about.

-hadriel

---

From: Victor Pascual Ávila <[email-masked]>
Date: Sat, 7 Mar 2009 21:44:33 +0100

> The thing is I think that a proxy/b2bua which cares about this for security properties, would need/want to scan the whole call-id for something which looks like a host/IP anyway, to make a dynamic…

IMO the UAS shall be able to know whether or not the call-id is
end-to-end (e.g. INVITE-Initiated Dialog Event Package: a B2BUA can't
fix the call-id if the return-routed subscribe request gets routed
along a different path).
-- 
Victor Pascual Ávila

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 16:08:35 -0500

> From: Victor Pascual Ávila [mailto:[email-masked]]
> Sent: Saturday, March 07, 2009 3:45 PM
>

Are you suggesting that be added to this draft's goals, or just that we should tackle that problem (separately)?

I personally don't think it should be a goal of this draft.  There's a can of worms in that goal, imho.  This draft is short and to the point, addressing one specific issue and solution.  My hope is to get it fast-tracked if people agree with it, or I'll change it to a BCP recommendation as an individual draft if people don't care.

-hadriel

---

From: Victor Pascual Ávila <[email-masked]>
Date: Sat, 7 Mar 2009 22:27:00 +0100

> Are you suggesting that be added to this draft's goals, or just that we should tackle that problem (separately)?

I was just wondering if a magic cookie could help the UAS to identify
end-to-end identifiers.
-- 
Victor Pascual Ávila

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 7 Mar 2009 17:06:27 -0500

> Sent: Saturday, March 07, 2009 4:27 PM
>

Ahh, I see.  Nope, it won't, I don't think.  If a B2BUA changes the Call-ID for reasons other than the security aspects, it would/should still create a secure-call-id format - simply so that other B2BUA's along the path don't feel compelled to as well and exacerbate the problem.  I should make that clear in the draft.

-hadriel

---

From: Dale Worley <[email-masked]>
Date: Tue, 24 Mar 2009 23:59:19 -0400

I'm not sure how much benefit comes from this idea.

On the one hand, it contains no mandate of the form "If the call-id is
of format xxxxx, then SBCs WILL NOT change it."  So there's SBC behavior
in particular that an outside agent can depend on, even if it knows that
all UAs in the system follow the I-D.  My guess is that SBCs will munge
the call-ids anyway, rather than trying to implement an algorithm to
determine compliance -- on a UAC-by-UAC basis!

The other side of this is that it makes life harder for anyone trying to
diagnose problems.  In sipX, we currently generate pseudo-random
call-ids.  Actually, the format is "s-XXXXXXXXXXX-NNN", where XXXXXXXX
is pseudo-random and NNN is a sequence number.  That way you can
mentally say "dialog 7" and "dialog 45", but still get uniqueness.  But
we've got a work item to append the host DNS name to the format so that
we can easily distinguish "dialog 45 from sipx1.example.com" and "dialog
45 from sipx2.example.com".

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Mar 2009 02:43:22 -0400

> From: Dale Worley [mailto:[email-masked]]
> Sent: Tuesday, March 24, 2009 11:59 PM
> 
> of format xxxxx, then SBCs WILL NOT change it."  

Huh, you're right.  I should add in a MUST NOT change it for security purposes.  Although realistically Call-ID's are changed by many B2BUA's other than SBC's for reasons other than security.  This draft is only trying to remove the incentive for changing them for security reasons.  There is no way to stop other B2BUA's from changing them for other reasons. (which is why I have the session-id draft)

> So there's SBC behavior

Sure, SBC's may not follow this draft.  So?  UA's and other devices may not follow any given draft/RFC.  But right now there's actually a reasonably defendable rationale for why the Call-ID's should be changed.  I'm trying to get rid of that rationale.  The owners of the SBC's will then be able to tell their vendors "go do this draft", if they find they need SIP extensions to work which rely on the Call-ID not changing.  The market will sort out if that's valuable or not.

> 45 from sipx2.example.com".

If you do that, SBC's will continue to change the Call-ID from your devices.  There's always a trade-off between revealing enough information to troubleshoot/diagnose, and revealing information that can lead to abuse.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 27 Mar 2009 13:19:55 -0700

Hadriel Kaplan wrote:
> Sure, SBC's may not follow this draft. So? UA's and other devices may 
> not follow any given draft/RFC. But right now there's actually a 
> reasonably defendable rationale for why the Call-ID's should be 
> changed. I'm trying to get rid of that rationale. The owners of the 
> SBC's will then be able to tell their vendors "go do this draft", if 
> they find they need SIP extensions to work which rely on the Call-ID 
> not changing. The market will sort out if that's valuable or not.

Which is why an informational draft explaining the problem is useful, 
while a normative document... not quite so much.

Tell UACs: "If you include machine names in your Call-IDs, B2BUAs will 
have reason to change them." There's no MUST or MUST NOT here, just an 
explanation of rationale.

Tell B2BUAs: "If a Call-ID doesn't contain an @ sign, you'll do everyone 
a favor by not changing them, because it allows proper correlation of 
related transactions an dialogs." Again, no MUST; no MUST NOT. Just 
cause and effect.

Then see if people want to play nice. The market will sort out if that's 
valuable or not.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 28 Mar 2009 01:19:24 -0400

Yeah I've been thinking about what you said the other day about this, and I think I understand your point, but I still think MUST's and an update to 3261 would be good, for the following reasons:

1) We really should want to change 3261 to say MUST NOT put an ip-address/hostname in the call-id.  Really in 20/20 hindsight I don't think it should have had one to begin with.

2) It's easier for customers to force vendors to do something if there's a MUST statement, standards-track RFC, vs. an informational recommendation/should.

3) Endpoint UAC vendors should do it *before* getting deployed and being told by customers to change after-wards.  Specifically I'm thinking about vendors who don't attend IETF and aren't that up-to-speed on all the nuances and such.  An update to 3261 with normative mandatory language is clearer, I think.

-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Friday, March 27, 2009 4:20 PM
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 28 Mar 2009 01:25:03 -0400

Howdy,
In talking with some folks about this draft afterwards, I think some of the consternation around the draft is due to the language around mandating B2BUA's not to change the Call-ID.  I thought it was clear that I only meant for the purposes of security/privacy, not for other purposes - in other words, if you have some reason you need to change the Call-ID other than privacy, then the must-not-change doesn't apply.

I think to alleviate the concern I'll just remove the language around that, and change it to more of just a discussion for that topic - with no normative requirements for B2BUA's, other than that if they do change the Call-ID, they should act as a UAC and create one that doesn't contain an ip/host portion.

Would people prefer that?

-hadriel

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Sat, 28 Mar 2009 12:28:31 -0400

I agree. Lack there of, only means the IETF does not want an
interoperable solution

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel Kaplan
Sent: Saturday, March 28, 2009 1:19 AM
To: Adam Roach
Cc: SIP
Subject: Re: [Sip] I-D Inaction: draft-kaplan-sip-secure-call-id-00.txt

Yeah I've been thinking about what you said the other day about this,
and I think I understand your point, but I still think MUST's and an
update to 3261 would be good, for the following reasons:

1) We really should want to change 3261 to say MUST NOT put an
ip-address/hostname in the call-id.  Really in 20/20 hindsight I don't
think it should have had one to begin with.

2) It's easier for customers to force vendors to do something if there's
a MUST statement, standards-track RFC, vs. an informational
recommendation/should.

3) Endpoint UAC vendors should do it *before* getting deployed and being
told by customers to change after-wards.  Specifically I'm thinking
about vendors who don't attend IETF and aren't that up-to-speed on all
the nuances and such.  An update to 3261 with normative mandatory
language is clearer, I think.

-hadriel

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sun, 29 Mar 2009 09:49:13 +0100

> Would people prefer that?

yup.

Also:

   [OPEN ISSUE: should we make this a fixed format, defined
   randomization mechanism to avoid detecting the vendor type from the
   Call-ID format?]

How about defining it to be a v5 uuid (rfc4122), which:

 - is well defined (including generating) in RFC 4122
 - has many libraries for generating and parsing
 - a v5 uuid can be detected (by looking at bits 4-7 == 0101) and thus
knows if it's secure
 - is "almost" unique across a four dimensional space-time continuum -
certainly a _very_ low chance of any collision, even when we're
communicating with alpha centauri over SIP/2.0.

 ~ Theo

Sent from: Bicester Oxfordshire United Kingdom.

---

From: Dean Willis <[email-masked]>
Date: Sun, 29 Mar 2009 22:55:39 -0500

On Mar 28, 2009, at 12:19 AM, Hadriel Kaplan wrote:

>
> Yeah I've been thinking about what you said the other day about  
> this, and I think I understand your point, but I still think MUST's  
> and an update to 3261 would be good, for the following reasons:
>
> 1) We really should want to change 3261 to say MUST NOT put an ip- 
> address/hostname in the call-id.  Really in 20/20 hindsight I don't  
> 2) It's easier for customers to force vendors to do something if  
> there's a MUST statement, standards-track RFC, vs. an informational  
> recommendation/should.
>
> 3) Endpoint UAC vendors should do it *before* getting deployed and  
> being told by customers to change after-wards.  Specifically I'm  
> thinking about vendors who don't attend IETF and aren't that up-to- 
> speed on all the nuances and such.  An update to 3261 with normative  
> mandatory language is clearer, I think.
>

I find myself in agreement with all three arguments here.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Mar 2009 12:54:47 -0400

Hadriel,

I understand your logic. BUT are we agreed that we should be making 
non-backward-compatible normative changes to 3261 (or any of the key 
RFCs) for reasons other than correcting out and out errors and 
ambiguities? Seems like that is the start of SIP/3.0.

	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Mar 2009 13:02:37 -0400

What's non-backward-compatible about it?  The text would say a UAC should generate a call-id without the IP/host (which is completely in-line with 3261), and that a UAS must continue to accept a call-id with ip/host.

I'll remove the ABNF change piece since people are worried that may affect backwards compatibility, due to a future strict-compliance parser checking for this update's ABNF and rejecting legacy 3261 ABNF.  So this update would only affect the normative text and not the ABNF.

-hadriel

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, March 30, 2009 12:55 PM
> To: Hadriel Kaplan
> Cc: Adam Roach; SIP
> address/hostname in the call-id.  Really in 20/20 hindsight I don't think
> it should have had one to begin with.
> >
> told by customers to change after-wards.  Specifically I'm thinking about
> vendors who don't attend IETF and aren't that up-to-speed on all the
> nuances and such.  An update to 3261 with normative mandatory language is
> clearer, I think.
> >
> > -hadriel
> >
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Mar 2009 16:48:28 -0400

> What's non-backward-compatible about it?  The text would say a UAC should generate a call-id without the IP/host (which is completely in-line with 3261), and that a UAS must continue to accept a ca…

OK. I thought you were proposing to go further.

What you say above here seems fine. (But of course some won't implement 
SHOULD either.)

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 31 Mar 2009 14:22:03 +0200

Hi,

I think Hadriel's proposal is fine.

Regards,

Christer 

> Behalf Of Paul Kyzivat
> Sent: 30. maaliskuuta 2009 23:48
> To: Hadriel Kaplan
> Cc: SIP; Adam Roach
> > What's non-backward-compatible about it?  The text would 
> say a UAC should generate a call-id without the IP/host 
> (which is completely in-line with 3261), and that a UAS must 
> continue to accept a call-id with ip/host.
> 
> What you say above here seems fine. (But of course some won't 
> implement SHOULD either.)
> 
> 	Thanks,
> 	Paul
> 
> > I'll remove the ABNF change piece since people are worried 
> that may affect backwards compatibility, due to a future 
> strict-compliance parser checking for this update's ABNF and 
> rejecting legacy 3261 ABNF.  So this update would only affect 
> the normative text and not the ABNF.
> > 
> > -hadriel
> > 
> >>> this,
> >>> there's
> >>> being
> >> about vendors who don't attend IETF and aren't that up-to-speed on 
> >> all the nuances and such.  An update to 3261 with 
> normative mandatory 
> >>>> Which is why an informational draft explaining the problem is 
> >>>> useful, while a normative document... not quite so much.
> >>>>
> >>>> Tell UACs: "If you include machine names in your 
> Call-IDs, B2BUAs 
> >>>> will have reason to change them." There's no MUST or 
> MUST NOT here, 
> >>>> just an explanation of rationale.
> >>>>
> >>>> a favor by not changing them, because it allows proper 
> correlation 
> >>>> of related transactions an dialogs." Again, no MUST; no 
> MUST NOT. 
> >>>> Just cause and effect.
> >>>>
> >>> This list is for NEW development of the core SIP Protocol Use 
> >>> [email-masked] for questions on current sip Use 
> >>> [email-masked] for new developments on the application of sip
> >>>
> > 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip