Subject: [Sip] (no subject)

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Jun 2008 12:20:04 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Dean Willis
>
> The problem that I'm trying to solve is making the task space
> manageable.
> The first thing is to distribute the chair load.

Obviously splitting/spawning WG's will do that, but I thought there was an AD resource contention issue - if we had more WG meeting slots then neither of our AD's could be in some meeting or other.  Is that not one of the issues?  It was the response I got when I and others suggested SIP Security topics (Identity/Privacy/SIPS/Certs/etc.) should be split into a separate WG a while back.

There was also some concern over not having any more RAI time slots anyway, but I think that's a red herring and overlapping some RAI WG meeting times is reasonable for certain topics.

> I think developing a SIP extension should be a Big Thing. If it's
> important enough to develop a SIP extension for, it is probably
> important enough to charter a working group to develop that extension.
> It's a Really Bad Idea to have a standing working group that sits
> around and develops SIP extensions. All that gets us is a whole lot of
> extensions. It doesn't get us any closer to a draft standard.

I agree with you in principle, but I doubt it's possible in practice.  There's some fine line there, because if you don't address an issue/need multiple people have, then they just go solve it in a proprietary fashion independently and interop still sucks.  One problem is we don't have a single cohesive "group" view and use of SIP, so we're left with the shotgun extensions approach, seeing which ones will stick.  I can't recall another successful protocol this complicated that didn't have one or two dominant vendors, which is a huge disadvantage in some ways.  It's both a blessing and a curse.

-hadriel

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Mon, 23 Jun 2008 12:02:28 -0500

On Jun 23, 2008, at 11:20 AM, Hadriel Kaplan wrote:

> Obviously splitting/spawning WG's will do that, but I thought there  
> was an AD resource contention issue - if we had more WG meeting  
> slots then neither of our AD's could be in some meeting or other.   
> Is that not one of the issues?  It was the response I got when I and  
> others suggested SIP Security topics (Identity/Privacy/SIPS/Certs/ 
> etc.) should be split into a separate WG a while back.

> There was also some concern over not having any more RAI time slots  
> anyway, but I think that's a red herring and overlapping some RAI WG  
> meeting times is reasonable for certain topics.
>

We can have four new working groups that meet for an hour each, or we  
can have one existing WG that meets for four hours. Same meeting time,  
same AD conflicts, but four times as many chairs to do the management  
work.

What we can't have is four new working groups that meet for four hours  
each. This means scope creep (and scope inflation) must be rigorously  
controlled. Hence, each charter must be tightly constrained, and each  
WG narrowly focused.

The fact is that our working groups are so big now that the chairs  
can't devote enough time to thoroughly manage individual subjects.  So  
the chairs aren't offloading enough of the work from the ADs. Doubling  
the number of chairs might not cut the ADs load in half, but it could  
certainly reduce it, although this is true if and only if the focus of  
each WG (and chair) is precise. I can't stay on top of the status of  
38 work items that go on for many years. I could probably manage four  
work items that last for no more than two years.

> I agree with you in principle, but I doubt it's possible in  
> practice.  There's some fine line there, because if you don't  
> address an issue/need multiple people have, then they just go solve  
> it in a proprietary fashion independently and interop still sucks.   
> One problem is we don't have a single cohesive "group" view and use  
> of SIP, so we're left with the shotgun extensions approach, seeing  
> which ones will stick.  I can't recall another successful protocol  
> this complicated that didn't have one or two dominant vendors, which  
> is a huge disadvantage in some ways.  It's both a blessing and a  
> curse.

I expect our "group mind" will continue to exist and evolve. But I'd  
like t have our "Do we need this sort of extension" discussions done  
as BOFs, with full cognizance of the fact that committing resources to  
a new extension is a non-trivial thing. It's far too easy for an  
eternal working group to just keep giving itself new tasks and never  
actually finish.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jun 2008 14:38:50 -0400

Four 1hr meetings does not equal one four hour meeting. With the time it 
takes for a prior group to clear a room and another group to enter, 
achieve quorum, and cover clerical details, you have lost probably 20 
minutes at a minimum. So your four one hour meetings provide 
4*(60-20)=160 minutes of useful time. A four hour meeting has 
4*60-20=220 minutes. You just lost an hour of working time.

	Paul

Dean Willis wrote:
>> was an AD resource contention issue - if we had more WG meeting slots 
>> then neither of our AD's could be in some meeting or other.  Is that 
>> not one of the issues?  It was the response I got when I and others 
>> suggested SIP Security topics (Identity/Privacy/SIPS/Certs/etc.) 
>> should be split into a separate WG a while back.
> 
> same AD conflicts, but four times as many chairs to do the management work.
> 
> controlled. Hence, each charter must be tightly constrained, and each WG 
> narrowly focused.
> 
> The fact is that our working groups are so big now that the chairs can't 
> devote enough time to thoroughly manage individual subjects.  So the 
> chairs aren't offloading enough of the work from the ADs. Doubling the 
> number of chairs might not cut the ADs load in half, but it could 
> each WG (and chair) is precise. I can't stay on top of the status of 38 
> work items that go on for many years. I could probably manage four work 
> items that last for no more than two years.
> 
>>
>> I agree with you in principle, but I doubt it's possible in practice.  
>> There's some fine line there, because if you don't address an 
>> issue/need multiple people have, then they just go solve it in a 
>> proprietary fashion independently and interop still sucks.  One 
>> problem is we don't have a single cohesive "group" view and use of 
>> SIP, so we're left with the shotgun extensions approach, seeing which 
>> ones will stick.  I can't recall another successful protocol this 
>> complicated that didn't have one or two dominant vendors, which is a 
>> huge disadvantage in some ways.  It's both a blessing and a curse.
> 
> like t have our "Do we need this sort of extension" discussions done as 
> BOFs, with full cognizance of the fact that committing resources to a 
> new extension is a non-trivial thing. It's far too easy for an eternal 
> working group to just keep giving itself new tasks and never actually 
> finish.
> 
> -- 
> Dean
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 23 Jun 2008 14:27:03 -0500

On Jun 23, 2008, at 1:38 PM, Paul Kyzivat wrote:

> Four 1hr meetings does not equal one four hour meeting. With the  
> time it takes for a prior group to clear a room and another group to  
> enter, achieve quorum, and cover clerical details, you have lost  
> probably 20 minutes at a minimum. So your four one hour meetings  
> provide 4*(60-20)=160 minutes of useful time. A four hour meeting  
> has 4*60-20=220 minutes. You just lost an hour of working time.

Personally, I gained about 4 hours of working time . . .

Seriously, I don't think the overhead is as high as you estimate, but  
it's certainly not "zero".

However:

If the 4 meetings were better run and better focused because they had  
clear scope, comprehensible agendas, and chairs with enough time to do  
the job right, I believe we'd still come out ahead over what we have  
now.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 23 Jun 2008 16:23:10 -0400

[fixed subject title, since I apparently broke it]

How about a compromise: 2 WG's of 2-hour meetings each (since today's SIP WG actually takes 2 of 2-hour meeting slots I think).
One for the general SIP stuff as today, and one for "SIP Security".

The new security group would take such things as:
draft-ietf-sip-dtls-srtp-framework
draft-ietf-sip-eku
draft-ietf-sip-media-security-requirements
draft-ietf-sip-ua-privacy
draft-ietf-sip-domain-certs
draft-ietf-sip-e2m-sec
draft-ietf-sip-saml

And it would be the venue for any new drafts/work related to Identity, Privacy, transport/media security as relates to SIP, etc.  I think this is roughly half the work in the SIP WG.  The people attending these two WG's would probably be nearly identical as today's SIP WG, and they would consume the same amount of meeting time as today's SIP WG, but it would cut your chair work in half.

It *won't* solve your eternal WG issue, but I think that problem is orthogonal and separately debatable.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dean
> Willis
> Sent: Monday, June 23, 2008 3:27 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [Sip] (no subject)
>
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 23 Jun 2008 16:22:22 -0500

On Jun 23, 2008, at 3:23 PM, Hadriel Kaplan wrote:

> How about a compromise: 2 WG's of 2-hour meetings each (since  
> today's SIP WG actually takes 2 of 2-hour meeting slots I think).

  Ah yes, two eternal working groups to replace one.

> draft-ietf-sip-dtls-srtp-framework

-- This one is arguably done, depending on what we believe about RFC  
4474 and gateways/b2buas.

> draft-ietf-sip-eku

-- EKU is basically done.

> draft-ietf-sip-media-security-requirements

-- This one is done

> draft-ietf-sip-ua-privacy

-- This one is done,

> draft-ietf-sip-domain-certs

-- This one is done

> draft-ietf-sip-e2m-sec

-- This one is done

> draft-ietf-sip-saml
-- I'm not sure this one is ever getting done.

So I'm not sure there's enough there to justify a WG.

How about an "Identity in SIP" working group that takes on fixing RFC  
4474 for gateways/b2buas and possibly considers identity/role  
assertion using SAML?

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 23 Jun 2008 14:48:23 -0700

> How about an "Identity in SIP" working group that takes on 
> fixing RFC 4474 for gateways/b2buas and possibly considers 
> identity/role assertion using SAML?

I agree we need that.  I have tried, and so far failed, to
initiate activity towards such an effort.

-d

---

From: Dean Willis <[email-masked]>
Date: Mon, 23 Jun 2008 21:00:49 -0500

> initiate activity towards such an effort.

What do you think of a charter of that size, instead of a "All of SIP  
security, forever and ever" as a charter?

--
Dean

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 24 Jun 2008 11:17:08 +0300

Many of the SIP security mechanisms share the same fate: They are far 
ahead of the actual SIP deployment. This is true for SIP Identity, SIP 
CERT, SIP SAML, End-to-End Security, etc. When we started the SAML work 
we looked at what was going on at that time in the HTTP space. Without 
doubt the entire application layer identity management space found a lot 
of excitement. There is a lot of standardization being done and also a 
lot of deployment taking place. With the SIP space that was obviously a 
bit different and deployments today focus largely on voice (and there 
not even on end-to-end SIP-based communication).

For example: Look at what is being used in XMPP. There is no 
equalivalent of SIP Identity -- folks are currently looking into 
providing certificates for server-to-server communication.

Even though they are, from a deployment point of view, ahead they are 
not even close to where we are with our documents.

Ciao
Hannes

PS: I also believe that the SIP Identity case isn't an easy one either. 
The guys that would make use of SIP Identity for a deployment where the 
two SIP proxies talk to each other there would not be a need for SIP 
Identity since you are essentially replicating what TLS provides you at 
a lower layer already. In cases where there many SIP proxies along the 
path SIP Identity would be useful since it provides protection against 
any one of them being malicious. However, the guys who favour such a 
deployment model are the onces that believe very much in the chain of 
trust (hop-by-hop security). They have no interest in using SIP Identity.

---

From: Mayumi Munakata <[email-masked]>
Date: Tue, 24 Jun 2008 19:56:36 +0900

Dean,

 >> draft-ietf-sip-ua-privacy

You might misunderstand the situation of ua-privacy,
but I am still working on that work, and will submit
a new version in a week or so.

An open issue regarding a From header
(what kind of anonymous URI to be set)
was solved in Philadelphia and now I am
studying the treatment of other headers.

Thanks,
Mayumi

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 24 Jun 2008 12:00:15 +0100

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dan Wing
> Sent: 23 June 2008 22:48
> To: 'Dean Willis'; 'Hadriel Kaplan'
> Cc: [email-masked]; 'Paul Kyzivat'
> Subject: Re: [Sip] Toward the Evolution of SIP and Related 
> Working Groups
> 
> > > draft-ietf-sip-saml

I think there are enough issues in this area - and yes, they do need
solving - to justify a separate WG, hopefully with a fairly short
lifetime.

John

---

From: Dean Willis <[email-masked]>
Date: Tue, 24 Jun 2008 11:07:42 -0500

> studying the treatment of other headers.

Ah. I had in fact thought that the From header issue was the main  
issue remaining, and that we had resolved it.

Some sort of incremental discussion of the remaining open issues to  
the mailing list would be very helpful in building us towards a  
consensus. There's no need to wait for a meeting to discuss most  
technical issues.

--
Dean

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Jun 2008 11:32:01 -0700

To summarize your email:  anybody that needs SIP security will use TLS between
their own proxies.  That does seem to be the consensus.  Perhaps how that
works should be written up -- as in, does that mean when I have a TLS
connection with boeing.com, I should only allow or only expect From: addresses
that end in @boeing.com, and not @big-airplane.boeing.com and not
@rolls-royce.com?

-d

> From: Hannes Tschofenig [mailto:[email-masked]] 
> Sent: Tuesday, June 24, 2008 1:17 AM
> To: Dan Wing
> Cc: 'Dean Willis'; 'Hadriel Kaplan'; [email-masked]; 'Paul Kyzivat'

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Jun 2008 14:43:51 -0500

Dan Wing wrote:
> To summarize your email:  anybody that needs SIP security will use
> TLS between their own proxies.  That does seem to be the consensus.
> Perhaps how that works should be written up -- as in, does that mean
> when I have a TLS connection with boeing.com, I should only allow or
> only expect From: addresses that end in @boeing.com, and not
> @big-airplane.boeing.com and not @rolls-royce.com?

Dan: I suspect you are talking of the above in the context
of SIP SAML.  Otherwise, for certificate-based authentication
between proxies, some of what you write above is discussed in
the sip-domain-certs draft.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
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: "Dan Wing" <[email-masked]>
Date: Tue, 24 Jun 2008 14:13:41 -0700

> of SIP SAML. 

That wasn't my intent.

> Otherwise, for certificate-based authentication

Yes, some of it is there.  Can that draft be extended to talk 
about validating the From of requests (and maybe responses, I'm
not sure) that come from over a TLS-authenticated connection?  Or
would that be out of scope for it?

-d

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Jun 2008 16:30:06 -0500

> That wasn't my intent.

Dan: OK; sorry.

> would that be out of scope for it?

I believe that validating the From would be out of scope as
the draft currently stands.  The draft does discuss how a
receiving proxy (i.e., the one that did the passive accept)
may authenticate the sender (see S7.4,
http://tools.ietf.org/html/draft-ietf-sip-domain-certs-00#section-7.4),
but this discussion does not normatively involve the From
header.

Furthermore, trying to match sender identity as carried in
 From to the TLS-level connection identity as carried in the
certificate does not work well in the the hop-by-hop model.
For instance, the sender's From may as well be [email-masked], but
the last upstream proxy that opened up a connection to the
recipient could be some intermediary (proxy.com) not in the
a.com domain, thus making it impossible to enforce that the
 From must match the identity of the last upstream proxy in the
certificate.

Did you have some alternate or new thoughts on this to see if
we can hash out something that would still be in the context
of the domain-certs draft?  As it stands, Scott and I are about
to submit a final post WGLC revision on it by next week.

Thanks,

- vijay

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Jun 2008 14:44:46 -0700

> From: Vijay K. Gurbani [mailto:[email-masked]] 
> Sent: Tuesday, June 24, 2008 2:30 PM
> To: Dan Wing
> Cc: [email-masked]

No worries.

> but this discussion does not normatively involve the From

Right.

> From must match the identity of the last upstream proxy in the

Agreed.

> to submit a final post WGLC revision on it by next week.

I don't think extending domain-cert's scope would be wise --
rather, I do think this is a separate problem.  The separate
problem is that with *some domains* you connect to (and do
domain-certs validation with), you trust them to claim and
use any old "From" they want -- because with those domains
you trust them to have done some validation of their previous
hop, who validated their previous hop, etc.  This is how
you would configure a SIP trunk with a service provider, for
example.

However, if you are communicating directly with another 
organization then you would not want to allow them to assert
any identity they wished, because the only identity you expect 
them to send you requests with a From that had their own 
identity (@microsoft.com, @boeing.com, etc.) -- that is, 
the identity of their own employees.  You do not expect them 
to assert the identity belonging to some other company.  You 
would not extend the transitive trust to them.

I do wish there was more interest in cryptographic end-to-end 
identity that survives through B2BUAs operated by service providers.  
It is the end goal; service provider B2BUAs/SBCs are not going 
away!

-d

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Jun 2008 16:59:24 -0500

> It is the end goal; service provider B2BUAs/SBCs are not going 

The sipsec URI (http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01).
Sorry could not resist ;-)

Though that is not a panacea either since I doubt any B2BUA
operated by the service provider will agree to behave as a
transparent bit forwarder (although there are crypto-
techniques to allow intermediaries to snoop in an encrypted
stream to look only for certain keywords.  But I doubt that work
is to a point that one can create a scalable production system
out of it.)

There is also some work on using IBE (see
http://tools.ietf.org/html/draft-kupwade-sip-iba-00); this draft
was discussed on the list before the PHL IETF.  IIRC, the
discussions centered around problems with key escrow.

Thanks,

- vijay

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 24 Jun 2008 15:08:15 -0700

> The sipsec URI 
> (http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01).

heh.  Yeah, I think SIP four-oh had a few ideas in that space,
too.

> discussions centered around problems with key escrow.

There are also http://tools.ietf.org/html/draft-wing-sip-identity-media-02 and
http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00, both of which
propose slightly different techniques that are a middleground between sipsec
and (today's) blind transitive trust.

-d

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Jun 2008 08:51:59 +0100

Dan, 

> Sent: 24 June 2008 22:45
> To: 'Vijay K. Gurbani'
[JRE] It depends. I ([email-masked]) receive a call from
[email-masked], and because I am working at home, the siemens.com proxy
forwards it to my home via a service provider. The service provider now
needs to accept [email-masked] (rather than [email-masked]) as the
source of the call. At home I would expect to receive [email-masked] as
caller ID.

John

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Jun 2008 08:05:15 -0400

> source of the call. At home I would expect to receive [email-masked] as

John,

I know that is what you would like to see on your phone.
But that doesn't mean there is a plausible way for it to happen.

We are discussing transitive trust here. Why would the SP trust 
siemens.com when it asserts a cisco.com domain? If that turns out to be 
incorrect, and you complain, you could justifiably complain that the SP 
lied to you. They put themself at risk by trusting such an assertion 
from siemens.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Jun 2008 13:39:52 +0100

Paul,

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 25 June 2008 13:05
> To: Elwell, John
> Cc: Dan Wing; Vijay K. Gurbani; [email-masked]
[JRE] I am not expecting the service provider to trust siemens.com,
because siemens.com is not making the assertion. The assertion from
cisco.com is merely being passed on by siemens.com to the service
provider. It will be the cisco.com certificate, not the siemens.com
certificate.

Of course, siemens.com also has to make an assertion, it has to assert
that it is siemens.com that is passing this request to the service
provider, and this can be done using TLS authentication. But that says
nothing about the original source of request or the caller ID. We must
not get the two layers mixed up - transport layer authentication is for
a single hop and SIP layer authentication is end-to-end (or
end-domain-to-end-domain).

John

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 25 Jun 2008 16:00:09 +0300

Consider the following scenario:

              +-----------+            +-----------+
              |SIP        |            |SIP        |
      +------>|Proxy      |<---------->|Proxy      |<------+
      |       |Server X   |   TLS      |Server Y   |       |
      |       +-----------+            +-----------+       |
      |                                                    |
      | TLS or                                      TLS or |
      | SIP Digest                              SIP Digest |
      |                                                    |
      |                                                    |
      v                                                    v
  +-----------+                                     +-----------+
  |SIP        |                                     |SIP        |
  |User Agent |          RTP                        |User Agent |
  |Alice      | <=================================> |Bob        |
  +-----------+                                     +-----------+

When there are no further proxies between X and Y then Y has the
information that Alice was authenticated by X. Proxy Y would pass that
info on to Bob. Bob trusts Y.

Obviously, the two VoIP providers may have a far more complicated
infrastructure with multiple proxies but they all belong to the same
domain and could be seen from external as just one box. 

The same would not work when there are more proxies between X and Y.
However, these guys that prefer such a deployment belong more to the
chain of trust camp rather than the end-to-end / email alike peering
camp. It is rather unlikely that you get their support for getting SIP
Identity to work in their networks.

So, do we have an indication that some folks plan to use SIP Identity
for their deployment? 

Wouldn't it be better to rely on something like SIP CERT for a better
end-to-end security mechanism (ignoring for a moment that SIP CERT also
uses SIP Identity for "simplified deployment" reasons whereby one has to
state that the usage of SIP Identity for SUBSCRIBE/NOTIFY might have
different B2BUA aspects). 

Ciao
Hannes

>Behalf Of ext Elwell, John
>Sent: 25 June, 2008 15:40
>To: Paul Kyzivat
>Cc: [email-masked]; Dan Wing
>> Subject: Re: [Sip] Toward the Evolution of SIP and Related Working 
>> Groups
>> 
>> 
>> 
>> Elwell, John wrote:
>> 
>> >> organization then you would not want to allow them to assert any 
>> >> identity they wished, because the only identity you 
>expect them to 
>> >> send you requests with a From that had their own identity 
>> >> (@microsoft.com, @boeing.com, etc.) -- that is, the identity of 
>> >> their own employees.  You do not expect them to assert 
>the identity 
>> >> belonging to some other company.  You would not extend the 
>> >> transitive trust to them.
>> siemens.com when it asserts a cisco.com domain? If that turns out to 
>> be incorrect, and you complain, you could justifiably complain that 
>> the SP lied to you. They put themself at risk by trusting such an 
>> assertion from siemens.
>[JRE] I am not expecting the service provider to trust 
>siemens.com, because siemens.com is not making the assertion. 
>The assertion from cisco.com is merely being passed on by 
>siemens.com to the service provider. It will be the cisco.com 
>certificate, not the siemens.com certificate.
>
>Of course, siemens.com also has to make an assertion, it has 
>to assert that it is siemens.com that is passing this request 
>to the service provider, and this can be done using TLS 
>authentication. But that says nothing about the original 
>source of request or the caller ID. We must not get the two 
>layers mixed up - transport layer authentication is for a 
>single hop and SIP layer authentication is end-to-end (or 
>This list is for NEW development of the core SIP Protocol Use 
>[email-masked] for questions on current sip

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 Jun 2008 08:55:22 -0700

> source of the call. At home I would expect to receive [email-masked] as

So the title of the document would be "Validating SIP From Considered
Harmful".  After writing that document, do you feel the community would
then see the need for designing a B2BUA-survivable identity mechanism??

-d

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 25 Jun 2008 10:05:28 -0700

> then see the need for designing a B2BUA-survivable identity mechanism??

No mechanism can survive with B2BUAs and intermediaries in general.
That's why we have the e2e principle on the Internet.

Henry

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Jun 2008 13:10:14 -0400

> Henry Sinnreich

That's odd, it sure looks like your email went through a bunch of intermediaries.  I wonder what it contained when it was originally sent.
;)

-hadriel

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 Jun 2008 10:17:43 -0700

> No mechanism can survive with B2BUAs and intermediaries in general.

Two I-Ds have been proposed which will survive B2BUAs and SBCs:

  http://tools.ietf.org/html/draft-fischer-sip-e2e-sec-media-00
  http://tools.ietf.org/html/draft-wing-sip-identity-media-02

> That's why we have the e2e principle on the Internet.

TLS and IPsec work through transport- and network-layer intermediaries (NATs
and NAPTs), and NAPTs destroy the e2e principle.

-d

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 25 Jun 2008 11:30:53 -0700

> Two I-Ds have been proposed which will survive B2BUAs and SBCs:

You would have to show that what is valid for identity can
be extended to any type of application.

> and NAPTs), and NAPTs destroy the e2e principle.

Same as above. Can this be generalized?
What complexity costs are involved?

This is an interesting discussion to pursue with the IAB.

Henry

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 25 Jun 2008 11:43:40 -0700

> From: Henry Sinnreich [mailto:[email-masked]] 
> Sent: Wednesday, June 25, 2008 11:31 AM
> To: Dan Wing; 'Elwell, John'; 'Vijay K. Gurbani'
> Cc: [email-masked]

So that one identity works for email, for SIP, for RTSP, for
IPsec?  That sounds like the Holy Grail.

-d

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Jun 2008 21:18:49 +0100

Hannes, 

> From: Tschofenig, Hannes (NSN - FI/Espoo) 
> [mailto:[email-masked]] 
> Sent: 25 June 2008 14:00
> To: Elwell, John; Paul Kyzivat
> Subject: RE: [Sip] Toward the Evolution of SIP and Related 
> Working Groups
> 
> 
[JRE] Well, what about enterprise via service provider to enterprise? As
an enterprise provider, I would like to be able to use SIP identity, but
a precondition is that it gets through that intermediate service
provider(s).

> different B2BUA aspects). 
[JRE] You have lost me there. What is SIP CERT? Can you point me at a
draft?

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 25 Jun 2008 21:22:34 +0100

Dan, 

> Sent: 25 June 2008 16:55
> To: Elwell, John; 'Vijay K. Gurbani'
> Cc: [email-masked]
[JRE] It's not the best starting point - rather a long train of thought
to get to the conclusion. However, it is one of the many factors in this
complicated equation.

John

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jun 2008 11:25:48 +0300

Comments inline:

> a precondition is that it gets through that intermediate service
Why would like to pick a service provider in the first place? Why are 
they deploying B2BUAs?

If you really want todo that then pick one that does not damage your 
security. You are the customer and you decide.

If you want to pick such as service provider then why does the chain of 
trust not work for you?  Hopefully you trust the provider you have chosen.

.... just trying to figure out what the typical deployment cases are and 
why we don't see any of this in XMPP.

> [JRE] You have lost me there. What is SIP CERT? Can you point me at a
http://tools.ietf.org/html/draft-ietf-sip-certs-06

Ciao
Hannes

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Jun 2008 10:10:34 +0100

Hannes,

> Sent: 26 June 2008 09:26
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Paul Kyzivat; 
> [email-masked]; Dan Wing
[JRE] I might trust my service provider, but I might not trust (or even
know of) the peer enterprise's service provider. And what if the two
service providers use indirect peering rather than direct peering? That
is the problem, there can be just too many domains along the path of a
call, particularly a call that gets forwarded. It seems too hard to
figure out for every possible scenario how to get hop-by-hop to work,
when an end-domain-to-end-domain solution would always work if there is
no interference from intermediate domains.

> http://tools.ietf.org/html/draft-ietf-sip-certs-06
[JRE] I don't understand - how does sip-certs provide end-to-end
authentication? It might help me to locate a certificate that is used in
some authentication mechanism such as Identity, but it doesn't itself
provide an authentication mechanism.

John

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 26 Jun 2008 13:26:14 +0300

> provide an authentication mechanism.

Two of the current proposals to fix SIP Identity combine it with 
DTLS-SRTP. An alternative is to use SIP CERT with DTLS-SRTP.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jun 2008 08:36:14 -0400

> trust not work for you?  Hopefully you trust the provider you have chosen.

Well, that seems obvious. If the SP is willing to trust *me*, then it is 
probably willing to trust its other customers. If I am not willing to 
trust its other customers, then I can't trust it.

	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 26 Jun 2008 13:45:40 +0100

Hannes,

> Behalf Of Hannes Tschofenig
> Sent: 26 June 2008 11:26
> To: Elwell, John
> Cc: [email-masked]; Paul Kyzivat; Dan Wing
[JRE] So you propose having certificates in the UAs, and have these
deployed using sip-certs?
I wonder whether this meets the requirement:
"R-CERTS:
         The key management protocol MUST NOT require that end-users
         obtain credentials (certificates or private keys) from a third-
         party trust anchor."
Does the credential server count as a third party trust anchor? If so,
we would not meet this requirement. But assuming the server is in the
same domain as the UAs it supplies credentials to, it is probably not
considered third party and probably meets the spirit of the requirement.

Also, I think there would need to be some adaptation of sip-certs. For
example, sip-certs explicitly says it is for use with S/MIME. Also, as
you pointed out, this too relies on RFC 4474 (but in a NOTIFY). Maybe
HTTPS would be more appropriate for this part.

If Bob has several UAs, each would receive the same private key and cert
from the credentials server. I don't know whether this has any
implications for DTLS-SRTP (c.f., self-signed certs, which would
doubtless be different in each UA).

Similarly to some of the other alternatives, this would provide an
authenticated identity for DTLS-SRTP, but not for calls that don't use
DTLS-SRTP, and also not for SIP requests not related to calls such as
MESSAGE, SUBSCRIBE, NOTIFY, and also not for mid-dialog requests that
don't include SDP (where the certificate fingerprint resides), such as
BYE, offerless UPDATE, the dreaded INFO.

Intermediate domains would need to pass SUBSCRIBE/NOTIFY requests - this
might be almost as big an ask as requiring them not to interfere with an
RFC 4474 certificate. Alternatively, perhaps enterprises etc. that
insist on intermediaries for calls might open their doors to direct
peering for SUBSCRIBE/NOTIY.

I can still see issues with the actual identity. For example, with an
E.164 number, I send [email-masked] in From or PAI, but by the time
it reaches you it has been changed to [email-masked], so your
UA would send the SUBSCRIBE request to [email-masked], and that
would somehow need to reach [email-masked].

But yes, this is an alternative approach worthy of further exploration.

John

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 26 Jun 2008 15:58:33 +0300

[changed the title since we drifted a bit away from the original
question] 

I am trying to figure out where the problems are: 

The SIPit 21 report 
http://www.ietf.org/mail-archive/web/sip/current/msg21291.html
indicated that SIP Identity was available with 12% of the
implementations. (Not sure what that actually means since one would have
to look at the details.)

The SIPit 22 report 
http://www.ietf.org/mail-archive/web/sip/current/msg23285.html
says 16% identity (But there were no Identity servers at the event)

Maybe this means that nobody showed up that has implemented the
Authentication Service but I hope that someone has implemented it
somewhere. 

~15 % is not a large number; but it's a start. 

Now, it would be interesting to hear whether these guys have actually
ever turned it on and used it. What was their experience? Did they
indeed encounter problems with certain SBC configurations? 

Would more folks use it when some of the weaknesses on the E.164 number
usage are documented?

Would more folks use it when combined with DTLS-SRTP (as proposed in two
documents)?

How would a change to the signature algorithm impact the situation?

Ciao
Hannes

>Behalf Of ext Paul Kyzivat
>Sent: 26 June, 2008 15:36
>To: Hannes Tschofenig
>Cc: [email-masked]; Elwell, John; Dan Wing
>> If you want to pick such as service provider then why does the chain 
>> of trust not work for you?  Hopefully you trust the provider 
>you have chosen.
>
>Well, that seems obvious. If the SP is willing to trust *me*, 
>then it is probably willing to trust its other customers. If I 
>am not willing to trust its other customers, then I can't trust it.
>
>	Paul

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 26 Jun 2008 08:24:26 -0700

John Elwell wrote: 

> E.164 number, I send [email-masked] in From or PAI, but 
> by the time it reaches you it has been changed to 
> [email-masked], so your

Which brings us back into draft-wing-sip-e164-rrc-01.txt territory.
(Not a bad thing, in my mind; I just wanted to point it out).

-d

---

From: Dean Willis <[email-masked]>
Date: Thu, 26 Jun 2008 12:18:08 -0500

On Jun 26, 2008, at 7:36 AM, Paul Kyzivat wrote:

>
>
> Hannes Tschofenig wrote:
>
>> If you want to pick such as service provider then why does the  
>> chain of trust not work for you?  Hopefully you trust the provider  
>> you have chosen.
>
> Well, that seems obvious. If the SP is willing to trust *me*, then  
> it is probably willing to trust its other customers. If I am not  
> willing to trust its other customers, then I can't trust it.
>

I believe that my service provider has illegally collaborated with a  
rogue government organization to turn over call records in violation  
of federal law, and that when they got caught doing it, were able to  
lobby for special protections. They enjoy a legally-protected near  
monopoly when they ought to be up against the wall for treason, having  
conspired to violate the national constitution.

I might have to do business with the, but why the heck should I trust  
them?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jun 2008 14:23:37 -0400

Amen!

	Paul

(That was legally protected religious speech - about as religious as you 
will ever get from me.)

Dean Willis wrote:
>>> of trust not work for you?  Hopefully you trust the provider you have 
>>> chosen.
>>
>> Well, that seems obvious. If the SP is willing to trust *me*, then it 
>> is probably willing to trust its other customers. If I am not willing 
>> to trust its other customers, then I can't trust it.
>>
> 
> rogue government organization to turn over call records in violation of 
> federal law, and that when they got caught doing it, were able to lobby 
> for special protections. They enjoy a legally-protected near monopoly 
> when they ought to be up against the wall for treason, having conspired 
> to violate the national constitution.
> 
> I might have to do business with the, but why the heck should I trust them?
> 
> -- 
> Dean
> 
>

---

From: "[email-masked]" <[email-masked]>
Date: Thu, 26 Jun 2008 13:58:52 -0700

Trusting service providers?

>> rogue government organization to turn over call records

Here is what happens elsewhere as well, in this instance without any
government involvement:

Germany fuming at Telekom's spy scandal
http://www.upi.com/Emerging_Threats/2008/05/27/Germany_fuming_at_Telekoms_sp
y_scandal/UPI-56191211919425/

Henry

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Jun 2008 09:05:11 -0700

Agreed.

-d

> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Friday, June 27, 2008 8:06 AM
> To: Tschofenig, Hannes (NSN - FI/Espoo); ext Paul Kyzivat; 
> Hannes Tschofenig
> Subject: RE: SIP Identity
> 
> 
> 
> Behalf Of
> > Tschofenig, Hannes (NSN - FI/Espoo)
> >
> I am fairly confident in saying that there could not be an 
> SBC that wouldn't break 4474 signatures, since it's basically 
> inherent in the definition of an SBC to modify some of the 
> things that 4474 signs. (ie, if it's not modifying them, it's 
> not really acting in an SBC "mode" anymore)
> Except of course when the SBC is the signer/verifier.
> 
> 
> I doubt it.  Plenty of weaknesses of RTP have been 
> "documented", which haven't driven SRTP's uptake.  It will 
> take actual real-world cases of abuse to drive it, IMHO.  But 
> by then it will be late.  First there's the problem of making 
> it work across already deployed infrastructure, which 4474 
> doesn't, and there can be no "flag day".  Given how long it 
> takes us to standardize things, get them into code/hardware, 
> and get people to upgrade, we're talking years.  That's why I 
> want to work on it now, just in case we need it in the next few years.
> 
> 
> By making it work across deployed infrastructure.  More and 
> more Enterprise-SP SIP Trunks are getting added every day, 
> and inter-SP peering is continually growing.  If an Identity 
> algorithm has a lot of false positives (signatures broken but 
> the request is really ok), it won't be much use and people 
> will ignore it.  No algorithm has a chance of use if legit calls fail.
> 
> -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 27 Jun 2008 14:33:41 -0400

> Why would like to pick a service provider in the first place?

Want the top 10 reasons? (in no particular order)
1) Because most of their calls still go to/from the PSTN.
2) Because most of their calls are still addressed to/from using E.164 - they have no idea it's going to end up at another SIP-enabled Enterprise.
3) Because voice means business/money for many Enterprises - if it doesn't work they want someone to go fix it, someone to yell at, someone to monitor it, etc.
4) Because the target destination Enterprise may not allow incoming calls from anyone but *their* SP.
5) Because their SP has defined qos guarantees for VoIP traffic, if it's SIP-routed through them. (in some ways one could argue SIP has accomplished what RSVP was meant to do but did not)
6) Because SIP has significant interop issues, and the Enterprise knows their stuff works with the SP.
7) Because the IT guys can justify it more easily to execs, and won't get fired if the SP screws up. (if there even *is* an IT dept.)
8) Because email has NOT been a shining example for how VoIP could work.
9) Because they have constrained-resource WAN links and want to use low-bandwidth codecs over that, but want to let the SP transcode it to whatever will work with the far end.
10) Because if it ain't broke, they don't want to fix it. (ie, if it works it works)

> Why are

Who, the SP or the Enterprise?  The answer is usually "control" ultimately, in some form or other.

> security. You are the customer and you decide.

Damage your security how, and according to who's definition of security?  You think end-end is somehow inherently secure.  But neither end trusts the other.  They trust the middles (specifically their respective next-middles) more than the other ends.  That's the rub.

> trust not work for you?  Hopefully you trust the provider you have chosen.

I trust my provider, but not their peers as much, and less their peers' peers.  If I am using myprovider.com and I get a call from them saying it's from [email-masked] I would be confident that's true.  I have much less confidence when I get a call from my provider saying the caller is [email-masked].

But this topic isn't really about me or us anyway, imho.  Most SP customers blindly trust their SP's, imo - IETF'ers are an exception not the rule.  It's about an SP wanting to live-up to the trust its customers put in it.  They'd like to know that when they get calls from one of their peer SPs, they can trust calls that didn't originate at that peer.  They essentially had that in the PSTN, because they could ferret out trouble-makers over time, there's a forced hierarchy of providers, and the cost of calls and linking into SS7 self-limited many issues.  Whether that holds true for SIP remains to be seen.  I'd like to be ready before we find otherwise.

> why we don't see any of this in XMPP.

If people only used SIP for free IM, with email-type user@domain FQDN URIs only, and had one dominant vendor implementation, I bet the deployment landscape would be quite similar to XMPP.  It's not the protocol that causes it. (Well, that's not totally true, but close enough)

-hadriel

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 27 Jun 2008 12:10:39 -0700

> 1) Because most of their calls still go to/from the PSTN.

I wonder if this may still be true:
- All employees have cell phones
- The most active talkers use the Blackberry
- Hard working folks in cubes (like myself :-)) have a desktop phone but
consider it a nuisance and never use it. I prefer to IM so as not to make
noise and to have privacy.
This leaves very few types of workers using the PSTN, probably in call
centers and those in support functions.

Does anyone have a report with numbers on this?

> 3) Because voice means business/money for many Enterprises

I wonder about this too. Except for the marketing and support folks, talking
on the phone lowers productivity. Productive employees use multimedia
communications with document/desktop sharing, document routing, etc.

Using voice at work (at some cost to the enterprise) seems to me just a bad
habit or bad legacy, and is rather the exception, not the rule.

BTW: Don't you have a plain cell phone, iPhone or Blackberry?

Henry

On 6/27/08 11:33 AM, "Hadriel Kaplan" <[email-masked]> wrote:

> 2) Because most of their calls are still addressed to/from using E.164 - they
> have no idea it's going to end up at another SIP-enabled Enterprise.
> 3) Because voice means business/money for many Enterprises - if it doesn't
> work they want someone to go fix it, someone to yell at, someone to monitor
> it, etc.
> 5) Because their SP has defined qos guarantees for VoIP traffic, if it's
> SIP-routed through them. (in some ways one could argue SIP has accomplished
> what RSVP was meant to do but did not)
> 7) Because the IT guys can justify it more easily to execs, and won't get
> fired if the SP screws up. (if there even *is* an IT dept.)
> 9) Because they have constrained-resource WAN links and want to use
> low-bandwidth codecs over that, but want to let the SP transcode it to
> whatever will work with the far end.
> Damage your security how, and according to who's definition of security?  You
> think end-end is somehow inherently secure.  But neither end trusts the other.
> They trust the middles (specifically their respective next-middles) more than
> the other ends.  That's the rub.
> 
> 
> I trust my provider, but not their peers as much, and less their peers' peers.
> If I am using myprovider.com and I get a call from them saying it's from
> [email-masked] I would be confident that's true.  I have much less
> confidence when I get a call from my provider saying the caller is
> [email-masked].
> 
> But this topic isn't really about me or us anyway, imho.  Most SP customers
> blindly trust their SP's, imo - IETF'ers are an exception not the rule.  It's
> about an SP wanting to live-up to the trust its customers put in it.  They'd
> like to know that when they get calls from one of their peer SPs, they can
> trust calls that didn't originate at that peer.  They essentially had that in
> the PSTN, because they could ferret out trouble-makers over time, there's a
> forced hierarchy of providers, and the cost of calls and linking into SS7
> self-limited many issues.  Whether that holds true for SIP remains to be seen.
> I'd like to be ready before we find otherwise.
> 
> 
> If people only used SIP for free IM, with email-type user@domain FQDN URIs
> only, and had one dominant vendor implementation, I bet the deployment
> landscape would be quite similar to XMPP.  It's not the protocol that causes
> it. (Well, that's not totally true, but close enough)
> 
> -hadriel
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 27 Jun 2008 15:31:28 -0400

> Sent: Friday, June 27, 2008 3:11 PM
> To: Hadriel Kaplan; Hannes Tschofenig; Elwell, John
> Subject: Re: [Sip] Toward the Evolution of SIP and Related Working Groups
>

All cell phones *are* on the PSTN, for all intents and purposes to which the email was about.

> I wonder about this too. Except for the marketing and support folks,

And sales, and brick-and-mortar retailers, and food delivery, and repair shops, and hotels, and restaurants, and financial trading floors, and most things found in thick yellow books or on business cards.  I'm not saying commerce doesn't happen in other ways (duh), just that it also happens over voice.  I have no idea if it's more/less than email or http or whatever (and I bet the answer to that is regionally-specific), just that it's darn big.

> BTW: Don't you have a plain cell phone, iPhone or Blackberry?

See above - cell phones *are* the PSTN, at least so far they are.

-hadriel

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 27 Jun 2008 12:54:17 -0700

> See above - cell phones *are* the PSTN, at least so far they are.

Any IMS folks here to agree with this?  :-)

Henry

On 6/27/08 12:31 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> And sales, and brick-and-mortar retailers, and food delivery, and repair
> shops, and hotels, and restaurants, and financial trading floors, and most
> things found in thick yellow books or on business cards.  I'm not saying
> commerce doesn't happen in other ways (duh), just that it also happens over
> voice.  I have no idea if it's more/less than email or http or whatever (and I
> bet the answer to that is regionally-specific), just that it's darn big.
> 
>

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Mon, 30 Jun 2008 11:59:20 +0200

In the context of the argument Hadriel is putting forward, he is
correct.

IMS deployments exist, but you can still regard what is out there as
essentially IMS islands connected by the PSTN.

For example, I suspect any Skype call you make to an IMS user is via the
PSTN.

And standards for direct interconnection of the enterprise SIP networks
to IMS are relatively new, and we are still working on the bells and
whistles.

I would also note that some of the biggest users of mobiles for both
voice and messaging are under 18, and they don't have Blackberrys, and
the messaging they use is SMS over the CS network (i.e. PSTN), not over
IP, at least in the 3GPP side of the house.

Regards

Keith 

> Behalf Of Henry Sinnreich
> Sent: Friday, June 27, 2008 8:54 PM
> >> I wonder about this too. Except for the marketing and 
> support folks, 
> >> talking
> > 
> > And sales, and brick-and-mortar retailers, and food delivery, and 
> > repair shops, and hotels, and restaurants, and financial trading 
> > floors, and most things found in thick yellow books or on business 
> > cards.  I'm not saying commerce doesn't happen in other ways (duh), 
> > just that it also happens over voice.  I have no idea if it's 
> > more/less than email or http or whatever (and I bet the 
> answer to that is regionally-specific), just that it's darn big.
> > 
> > 
> >> Using voice at work (at some cost to the enterprise) seems 
> to me just 
> >> a bad habit or bad legacy, and is rather the exception, 
> not the rule.
> >>