Subject: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 16:22:55 +0200

Hi!
Coming in rather late in the discussion, I don't know if I missed the topic of security.

Having read RFC 3265 and some of the event specs, like mwi and dialog, the security sections lack a lot and in some cases are texts that are impossible for a developer to create running code from.

I think we need to write better text in 3265 biz for developers of event packages to clarify requirements.

Like

* If you specify TLS usage, be very clear on certificate matching
* If you specify S/MIME, be very clear on certificate matching and usage

Also, require some message flows.

One of these, I don't remember which one, requires S/MIME for confidentiality without specifying anything else.
If I need to encrypt, how do I get the presence server certificate? Or does the presence server need the keys for
the target URI?

Just a few thoughts, but I may be too late.

/O

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Oct 2011 10:11:58 -0500

> Coming in rather late in the discussion, I don't know if I missed the topic of security.

Thanks. It's not too late (although I certainly would have preferred 
comments back during WGLC), but I think many of the issues you identify 
are more applicable to SIP in general than SIP Events in particular.

> * If you specify S/MIME, be very clear on certificate matching and usage

These, for example, are both general SIP problems. TLS certificate 
matching is as much an issue for INVITE as it is for SUBSCRIBE. This is 
also true for S/MIME. As you know, RFC5630 takes on the issue of TLS 
handling in SIP, albeit with some of the issues you and Iñaki have 
raised on first-hop handling. I would argue that these should be 
addressed in an RFC5630bis, not as a hasty addendum to SIP Events.

As far as I know, there has been no effort to explicitly address the 
issue of S/MIME handling in SIP, although an effort similar in scope to 
RFC5630 would probably be appropriate, if we're seeing real-world 
problems in this area.

> Also, require some message flows.

Section 5.4.12 calls out a SHOULD-level normative requirement to do so. 
What would you suggest we change in that section?

> If I need to encrypt, how do I get the presence server certificate? Or does the presence server need the keys for

Presence is covered by RFC3856, which appears to be pretty clear on 
which certs to use. Section 6.7 calls out:

>    For reasons of privacy, it will frequently be necessary to encrypt
>    the contents of the notifications.  This can be accomplished using
>    S/MIME.  The encryption can be performed using the key of the
>    subscriber as identified in the From field of the SUBSCRIBE request.
>    Similarly, integrity of the notifications is important to
>    subscribers.  As such, the contents of the notifications MAY provide
>    authentication and message integrity using S/MIME.  Since the NOTIFY
>    is generated by the presence server, which may not have access to the
>    key of the user represented by the presentity, it will frequently be
>    the case that the NOTIFY is signed by a third party.  It is
>    RECOMMENDED that the signature be by an authority over the domain of
>    the presentity.  In other words, for a user pres:[email-masked],
>    the signator of the NOTIFY SHOULD be the authority for example.com.

Turning back to RFC 3265 in particular -- I'm okay with adding some very 
lightweight text along the lines of:

> 5.4.14 Confidentiality, Authentication, and Integrity
>
>   Event packages will typically convey information that requires
>   some level of security protection. This may include protecting
>   the information from eavesdropping, confirming the source of the
>   information, and/or ensuring that the information has not been
>   changed in transit. [RFC3261], as updated by [RFC5630], specifies
>   the use of S/MIME and TLS for these purposes.
>
>   Event packages that specify the use of S/MIME, TLS, or other
>   security technologies MUST include a description of the goals of
>   such a security mechanism (in terms of the three properties of
>   confidentiality, integrity, and authentication). Such event
>   packages also MUST clearly indicate which certificates are used
>   for the security mechanism, how they are acquired, and how
>   implementations verify matching certificates.
>

/a

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 17:21:56 +0200

>>  implementations verify matching certificates.

Hi Adam, IMHO all the security mechanism in SIP are fully unclear,
difficult to implement and hard to understand and interoperate, so
adding the text "this spec may use TLS or S/MIME" in every SIP RFC is
not a solution at all, because nobody undertands the core mechanism of
such security.

As previously recognized in this maillist, RFC 5630 is not a fix of
the security for SIP, but an attempt of clarification, and it does not
get it due to existing *bugs* in the security specs (clarifying a bug
is never a solution).

So we need something more, something radical and aggresive. Trying to
add patches over the existing security specs is a no-go. Olle and me
have some issues in mind (related to TLS and SIPS usage) for which
there is no solution, they are bugs in the spec. We don't need
patches, we need a complete re-work. And taking into account that
nobody uses security in SIP (or uses it in an own way without
following the standards) we can break current specs and do something
from scratch, trying to avoid all the existing bugs and issues.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Oct 2011 10:31:23 -0500

> addressed in an RFC5630bis, not as a hasty addendum to SIP Events.

Note that rfc5922 has much more to say on the contents of the X.509
certificates and matching identities in the certificate, etc.
than rfc5630 does.

Insofar as determining whether or not a certificate is valid for SIP
usage or to determine which identity to match, I suspect that rfc5922
will help.  If there are any ambiguities in rfc5922 on these fronts,
then we can, of course, rectify them.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Oct 2011 10:35:37 -0500

On 10/20/2011 10:21 AM, Iñaki Baz Castillo wrote:
> there is no solution, they are bugs in the spec.

Please take a look at rfc5922, and to a lesser extent, rfc5924 to
see if it is able to answer any of your questions related to the
contents of X.509 certificates and how to determine their usage for
SIP.

Thanks,

- vijay

---

From: Adam Roach <[email-masked]>
Date: Thu, 20 Oct 2011 10:51:42 -0500

On 10/20/11 10:21 AM, Iñaki Baz Castillo wrote:
> 2011/10/20 Adam Roach<[email-masked]>:

Send text.

/a

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 17:59:32 +0200

> Send text.

Just wait :)

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 12:15:15 -0400

I agree with Adam and Vijay here.

I'm not surprised if you are finding things unclear. It certainly isn't 
the first time. But please identify the source of the ambiguity, and if 
possible send text. Or if you don't know what text to propose, please 
spell out the difficulties you have had is as much detail as you can.

We have attempted to address the security issues in the past. What you 
see is what we were able to figure out at the time given perceived 
constraints. But its been awhile. Now there may be better insight, 
and/or a different understanding of the constraints.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 18:18:05 +0200

2011/10/20 Paul Kyzivat <[email-masked]>:
> I'm not surprised if you are finding things unclear. It certainly isn't the
> first time. But please identify the source of the ambiguity, and if possible
> send text. Or if you don't know what text to propose, please spell out the
> difficulties you have had is as much detail as you can.
>
> We have attempted to address the security issues in the past. What you see
> is what we were able to figure out at the time given perceived constraints.
> But its been awhile. Now there may be better insight, and/or a different
> understanding of the constraints.

Hi Paul, let me (and Olle) some time to write a text describing issues
on the security specs (including those that I consider bugs rather
than difficulties).

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 20 Oct 2011 18:40:31 +0200

But I agree with Adam's initial comment. RFC 3265bis is not the place to make these clarifications, at least in as far as you have identified issues at the moment.

Essentially you are talking a general SIP problem that requires updates to RFC 3261 (even if it is only the addition of references). 

RFC 3265 doesn't invent the problem of carrying bodies, RFC 3261 does.

So the fix here is to take over where RFC 5630 left off. What you need to do is an i-d to provide appropriate updates to RFC 3261 that address required changes in the text of RFC 3261.

Put the change in 3265bis and you will create something specific for event packages that misses all the other body usages in PUBLISH, REFER, MESSAGE, INVITE, INFO, etc.

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Iñaki Baz Castillo
> Sent: 20 October 2011 17:18
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04
> 
> the
> see
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Oct 2011 20:01:50 +0200

Hi,

I agree with Keith and Adam.

Unless the problem is specific to the SUB/NOT mechanism, I think it should be solved somewhere else.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of DRAGE, Keith (Keith)
Sent: 20. lokakuuta 2011 19:41
To: Iñaki Baz Castillo; Paul Kyzivat
Cc: [email-masked]
Subject: Re: [sipcore] security and draft-ietf-sipcore-rfc3265bis-04

Keith

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Iñaki Baz Castillo
> > send text. Or if you don't know what text to propose, please spell 
> > out
> the
> > But its been awhile. Now there may be better insight, and/or a 
> > different understanding of the constraints.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 20:18:24 +0200

> Unless the problem is specific to the SUB/NOT mechanism, I think it should be solved somewhere else.

I agree. But I would like to clarify whether we all confirm that "the
problem exists" or not.

Some weeks ago, I open a thread in IETF SIP in which there were
comments asserting that trying to make SIPS is unfeasible "even if you
do everything by the book":

  http://www.ietf.org/mail-archive/web/sip/current/msg27887.html

But my impression after reading responses in current thread is that
"there are not issues". So I think:

All the people use ;transport=tls, including big vendors, regardless
"tls" is not a valid URI ;transport value. And no one wants to deal
with SIPS schema, or just treats it as if it was SIP schema. IMHO
there *are* issues.

Anyhow there will be soon a text listing the existing issues in SIP security.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 21:00:28 +0200

20 okt 2011 kl. 17:11 skrev Adam Roach:

> Thanks. It's not too late (although I certainly would have preferred comments back during WGLC), but I think many of the issues you identify are more applicable to SIP in general than SIP Events in particular.
Well, we need to approach all RFCs an be more specific than now. I've been spending a few weeks going through quite a lot of 
RFCs and it's impossible to develop code from this framework. I took this chance to jump on one piece of the puzzle and try to raise the bar.

> These, for example, are both general SIP problems. TLS certificate matching is as much an issue for INVITE as it is for SUBSCRIBE.
Absolutely. But there are cases where PUBLISH/SUBSCRIBE/NOTIFY applications has special requirements and
invents new stuff, like the PUBLISH in certificate handling that bypasses SIP outbound and ob proxys to certify
the server. If one comes up with that kind of requirements in the event framework one needs to be very
specific. Yes this applies to all SIP RFCs, but that's not an excuse to not write it on the nose of this particular
reader too :-)

> This is also true for S/MIME. As you know, RFC5630 takes on the issue of TLS handling in SIP, albeit with some of the issues you and Iñaki have raised on first-hop handling. I would argue that these should be addressed in an RFC5630bis, not as a hasty addendum to SIP Events.
Agree that it's a different story. Nevertheless, after reading all the poorly specified documents I would like to raise the bar a bit,
and since it is missing from other documents and this is kind of "how to write an event package" I personally find it important to
include these instructions here.
> 
> As far as I know, there has been no effort to explicitly address the issue of S/MIME handling in SIP, although an effort similar in scope to RFC5630 would probably be appropriate, if we're seeing real-world problems in this area.
After reading the RFCs, I understand why we have no real-word problems in the area of S/MIME. I agree that we need to address that separately.
But we should not let any more event packages just add a line saying "If you need confidentiality use S/MIME". That is not helpful for anyone, and 
doesn't really work unless we are very clear which certificate's public key to use for encryption. In subscribe/notify we have the issue where we 
can have p2p subscriptions, or subscriptions handled by a server that gets updates by PUBLISH. Your quote below, that I missed and need to recheck,
addresses this issue.

> Section 5.4.12 calls out a SHOULD-level normative requirement to do so. What would you suggest we change in that section?
I'll check again.

> Presence is covered by RFC3856, which appears to be pretty clear on which certs to use. Section 6.7 calls out:
> 

THis is a good text, but only applies to the presence event package. I was using "presence" in a more generic context,
for any subscribe/notify event package. This should be used also for other event packages and maybe imported
as a generic example into this draft.

> 
> Turning back to RFC 3265 in particular -- I'm okay with adding some very lightweight text along the lines of:
> 
Sounds like an improvement.

I'll spend some more time going through this on my flight to SIPit and during SIPit next week.

Thanks for listening!

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 21:09:26 +0200

> certificates and matching identities in the certificate, etc.
RFC 5922 was a huge improvement. It focused on server domain certs
and we need to continue and take a look at the user agent certificates
and the S/MIME infrastructure. I am trying to write a "hitchhiker's overview"
of this as a starting point. 
Going through RFCs a developer gets very different messages about
requirements on SIP UA certificates for TLS, S/MIME, UA-driven Identity and MSRP.
I would like us to clarify this in a way that we did SIPS and domain certs.

This discussion is of course a separate issue from RFC3265bis.
> then we can, of course, rectify them.
Agree. There are many good drafts around that pinpoint issues with
both TLS and other security issues, so there has been a lot of good work
done in this area that we need to move forward on. 

The main problem is lack of customer requirements. Regardless I see 
more and more TLS and SRTP around, so something is changing out there. 
For those of us that still believe in open Internet federation e-mail style, we need the
security framework to build trust for this way of thinking.

Thanks for your feedback, Vijay!
/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 21:10:37 +0200

> contents of X.509 certificates and how to determine their usage for

On the topic of RFC 5924 I wonder why this is classed experimental?

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 21:16:24 +0200

> I agree with Adam and Vijay here.
I can't say I disagree. I am just looking for a bit more clear instructions for writers of event packages than what we had before.

> 
> I'm not surprised if you are finding things unclear. It certainly isn't the first time. But please identify the source of the ambiguity, and if possible send text. Or if you don't know what text to propose, please spell out the difficulties you have had is as much detail as you can.
Will try. Have never contributed text to RFCs so be nice :-)

> 
> We have attempted to address the security issues in the past. What you see is what we were able to figure out at the time given perceived constraints. But its been awhile. Now there may be better insight, and/or a different understanding of the constraints.
There's a huge difference between the nine year old RFC 3261 and the new RFCs. I clearly see a new security framework coming together, but there are still bits and pieces to complete and dots to connect. It may also be time to start considering how DNSsec/DANE can contribute.

I ranted a bit about just Subscribe/Notify RFCs and security in my blog and tried to formulate my thoughts a few days ago, before jumping in on this topic in this mailing list...

http://www.voip-forum.com/ietf/2011-10/sip-security-mess/

/O
>> then we can, of course, rectify them.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 21:36:23 +0200

> Essentially you are talking a general SIP problem that requires updates to RFC 3261 (even if it is only the addition of references). 
IN a large part yes, but as I've tried to explain in previous responses there's a specific issue in regards to Subscribe/notify that
I don't want to see in new event packages. I'll try to clarify this, based on Adam's text.

> RFC 3265 doesn't invent the problem of carrying bodies, RFC 3261 does.
Absolutely. The problem here is not that. In this case, it is unclear what the other party is when you want confidentiality. Adam's quote from the Presence event package had seen this, I missed that in dialog-info. We propably need to make that text a more generic example and merge it. Or not. I'll make up my mind at some point.

> So the fix here is to take over where RFC 5630 left off. What you need to do is an i-d to provide appropriate updates to RFC 3261 that address required changes in the text of RFC 3261.
Fully agree that we need to take over where 5630 left off. But I am kind of stubborn in that we need to raise the requirements on authors of event packages so that we'll get better quality in terms of security in these. Right now my feeling is that some, but not all, authors thought "oops, I need to add security before publishing this document, let's just say that they can use TLS and/or S/MIME if they want to." We can do better and have done better :-)
> Put the change in 3265bis and you will create something specific for event packages that misses all the other body usages in PUBLISH, REFER, MESSAGE, INVITE, INFO, etc.
We need to be careful so that we pinpoint the exact issue we want to avoid in this particular document. Then roll up the old sleaves and get to work in the direction you, Paul, Adam and Vijay has outlined in this discussion. :-)

/O

---

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Oct 2011 14:39:09 -0500

> On the topic of RFC 5924 I wonder why this is classed experimental?

You are asking me to dredge up memories that I have successfully
suppressed, and even repressed, for the last few years ;-)

Well, let me see ... IIRC, no one disagreed that using the EKU to
signal that the private key holder is a SIP proxy (versus a SIP
end point) is generally a good thing.

What caused the EKU draft (rfc5924) to go the experimental route
was that there was operational overhead involved with adding the
EKU extension to certificates.  The IESG felt that previous EKU
extensions (such as rfc4334) did not see widespread deployment,
and that the additional complexity it involves provides limited
benefit.

Furthermore, because one of the operational concerns of rfc5922
was to allow using existing certificates for SIP usage, it
is apparent that already existing certificates would not have
the SIP EKU usage specified.  Therefore, to avoid the interoperability
storm that was sure to arise, it was deemed best to make rfc5924
(the EKU draft) experimental to move the main draft (rfc5922) ahead.

Hope this helps.

Thanks,

- vijay

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 21:40:04 +0200

> suppressed, and even repressed, for the last few years ;-)
he he. My humble apologies for causing this pain :-)
> (the EKU draft) experimental to move the main draft (rfc5922) ahead.

Yes, it makes me see what happened. In trying to get the different bits
and pieces together, history helps some time.

Thank you, Vijay!

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Oct 2011 22:05:58 +0200

2011/10/20 Olle E. Johansson <[email-masked]>:
> After reading the RFCs, I understand why we have no real-word problems in the area of S/MIME.

If you are really saying that "we have NO real-word problems in the
area of S/MIME" I do know the response:

Because nobody uses S/MIME in SIP. :)

The same applies to SIPS schema. This is "Security by NO-Usage". I
think we can/should do it better.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 20 Oct 2011 22:18:14 +0200

> Because nobody uses S/MIME in SIP. :)
I am not sure that this is true. In our part of the world, I agree. But as there are implementations
out there, someone must have asked for it. Maybe it was just check-box items.

What I meant was that as a developer, I get very few guide lines for S/MIME usage and they
are not really agreeing with each other or with other usages of a SIP UA certificate. I would like to try to clarify this and it seems like
many voices in this group agrees with that. I am really happy to hear that. (Now, I did not expect anything else :-) )

> think we can/should do it better.

Regarding SIPS I think that's a long and interesting discussion, but off-topic for now. I think Keith Drage earlier clarified that there are still a lot of issues to clear up after the SIPS clarification RFC in regards to general usage of TLS in sip, such as answering "why is ;transport=tls deprecated in RFC 3261?" and "where did it come from anyway, since it doesn't show up in RFC 2543"? 

We have a lot to do, and there are a lot of good drafts discussing this topic, drafts that hasn't been pushed forward to RFC status, which indicates to me that a lot of brain power has been put on this topic. Now that we have a very different SIP framework compared with RFC 3261, I think we should at some point toss the whole issue up in the air and see what comes down when you look at SIP outbound, connection reuse, identity and gruu's and much more on top of good ol' RFC 3261. But one thing at a time.

/O

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 20 Oct 2011 16:18:24 -0400

On 10/20/11 3:16 PM, Olle E. Johansson wrote:
> I can't say I disagree. I am just looking for a bit more clear
> instructions for writers of event packages than what we had before.
>
>>
>> I'm not surprised if you are finding things unclear. It certainly
>> isn't the first time. But please identify the source of the ambiguity,
>> and if possible send text. Or if you don't know what text to propose,
>> please spell out the difficulties you have had is as much detail as
>> you can.

We have been known to be nice, on a few occasions. :-)

Usually I start out nice and get less nice as frustration builds.

> There's a huge difference between the nine year old RFC 3261 and the new
> RFCs. I clearly see a new security framework coming together, but there
> are still bits and pieces to complete and dots to connect. It may also
> be time to start considering how DNSsec/DANE can contribute.
>
> I ranted a bit about just Subscribe/Notify RFCs and security in my blog
> and tried to formulate my thoughts a few days ago, before jumping in on
> this topic in this mailing list...
>

Good stuff. You just need to introduce it into the conversation here.

	Thanks,
	Paul

>> [email-masked] <mailto:[email-masked]>
> * Olle E Johansson - [email-masked] <mailto:[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 20 Oct 2011 15:59:24 -0500

On 10/20/2011 02:40 PM, Olle E. Johansson wrote:
[...]
> and pieces together, history helps some time.

In 2005-2006 timeframe when I had started to put TLS in my SIP
stack, I encountered many gotchas and dead-ends on how to
interpret the standard (at that time, only rfc3261).  Back then,
there were precious few public resources on SIP's use of TLS and
X.509 certificates.  The TLS module in Cullen's resiprocate server
was an excellent first order resource to turn to.

I attempted to codify some ambiguities as I encountered them
in a draft; see [1] on the chance that some of this may be of
interest to you as you dig deeper.

A lot of the work in [1] was spawned off in different directions.
The URI promotion was discussed, in part, in rfc5630; the
authoritative proxy/mutual authentication/TLS site certificate work
morphed into rfc5922 and rfc5924; the test cases in the Appendix
ended up as Section 6 in rfc6216, the need for end-to-end security
was discussed in [2], etc.

Some of the meeting minutes, slides, and discussions from 2006
around the [1] and rfc5630 may also help you.  They are archived
on the IETF website.  Hope all of this institutional memory serves
you well as you plough ahead.

[1] http://tools.ietf.org/html/draft-gurbani-sip-tls-use-00
[2] http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01

Good luck!

- vijay