Subject: [Sip] submission of a new I-D: "Dialog Event foR Identity VErification"

From: "Victor Pascual Ávila" <[email-masked]>
Date: Sat, 25 Oct 2008 17:09:28 +0200

Hi all,

A new I-D, draft-kuthan-sip-derive-00, was just submitted. Your
comments are always welcome.

Filename:          draft-kuthan-sip-derive
Version:           00
Staging URL:
http://www3.ietf.org/proceedings/staging/draft-kuthan-sip-derive-00.txt
Title:             Dialog Event foR Identity VErification
Creation_date:     2008-10-25
WG ID:             Indvidual Submission
Number_of_pages: 24
Abstract:
This document provides a simple mechanism to prevent an attacker from
presenting a forged "From" header field.  It offers an end-to-end
identity assumption which does not require any previous association
or trust relationship between administrative domains or the UAs.  The
UAS verifies the "From" header by subscribing to the Dialog Event
package [RFC 4235] at the AOR in the "From" header field.  If the
entity calling is registered under this AOR, it will confirm that it
is calling by sending some valid dialog state.  In this case, the
identity of the caller is considered to be verified.

Submitter: Victor Pascual ([email-masked])

Author(s):
Jiri Kuthan, [email-masked]
Dorgham Sisalem, [email-masked]
Raphael Coeffic, [email-masked]
Victor Pascual, [email-masked]

Thanks,
-- 
Victor Pascual Ávila
_______________________________________________
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: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 26 Oct 2008 01:00:38 +0200

El Sábado, 25 de Octubre de 2008, Victor Pascual Ávila escribió:

> The

A question about caller privacy:

I hope this mechanims doesn't requiere that 'anyone' can subscribe to the call 
status of 'anyone'. This is:

   Alice    Proxy 1 (atlanta.com)    Proxy 2 (biloxi.com)    Bob

In order this draft to work, Alice must allow a SUBSCRIBE (Event: dialog) from 
Bob, but why should Alice allow Bob monitorizing *all* her calls?

So, Alice or Proxy 1 should just allow SUBSCRIBE (Event: dialog) from Bob if 
the Event header includes 'call-id' and 'to-tag' parameters, i.e:

  Event: dialog;call-id=[email-masked];to-tag=9fxced76sl

If not, Alice or Proxy 1 should deny the request with "403 Forbidden".

I know that this draft doesn't involve authorization requeriments, but in a 
real world how would the privacy mechanism be achieved? I suggest that a 
proxy should allow SUBSCRIBE (Event: dialog) for its local users just if the 
Event header includes 'call-id' and 'to-tag' parameters. Also, dialog event 
package is commonly implemented at proxy level with a presence agent instead 
of forwarding the SUBSCRIBE's to the UA's.

In this manner, a default policy in a proxy would allow this draft mechanism 
working without exposing local users privacy. Would it be the correct way?

PD: Thanks for proposing a feasible solution instead of proposing exotic 
specifications that depend on other specifications which nobody implement.

-- 
Iñaki Baz Castillo

---

From: Dean Willis <[email-masked]>
Date: Sat, 25 Oct 2008 21:59:54 -0500

> comments are always welcome.

Sounds like you have reinvented identd, which has pretty much vanished  
from the Internet because it was found to not really add any useful  
authentication.

See: http://en.wikipedia.org/wiki/Ident

So tell me, how is this operationally different from IDENT?

--
Dean

---

From: Jiri Kuthan <[email-masked]>
Date: Sun, 26 Oct 2008 04:36:58 +0100

> So tell me, how is this operationally different from IDENT?

I'm actually not sure how this comparison holds, perhaps because IDENT
vanished from the Internet before I noticed it was there. I think the
email verification is a better example in that a) it works b) it is
massively used c) it is protocol-specific as opposed to being
a universal instance.

-jiri

---

From: [email-masked] (Juha Heinanen)
Date: Sun, 26 Oct 2008 10:56:02 +0200

> specifications that depend on other specifications which nobody

i agree with this and long time ago (before presence existed) proposed a
similar (if not even simpler) solution:

- my phone receives a call from sip:foo@bar

- my phone sends a query to sip:foo@bar asking if foo@bar is trying to
  call me

in order for this to work, the phone from which sip:foo@bar is calling,
needs to be registered.

-- juha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 26 Oct 2008 11:45:19 +0100

> from the Internet because it was found to not really add any useful  

draft-kuthan-sip-derive-00 proposal is 100% SIP based instead of depending on 
other protocols. IMHO it has *nothing* to do with Identd mechanism.

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Oct 2008 02:06:11 -0500

> in order for this to work, the phone from which sip:foo@bar is  

Not only that, but it needs to deal with forking, or it needs to  
require all the calls originating @bar go through the @bar proxy/sbc.

Jonathan may be right -- perhaps we should revisit the core SIP specs  
assuming universal deployment of SBCs. It still won't be right, but at  
least we'd  get some new problems to chew on.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Mon, 27 Oct 2008 02:07:50 -0500

> other protocols. IMHO it has *nothing* to do with Identd mechanism.

But it is very much LIKE the ident mechanism, in that, in response to  
a connection attempt, the connected party does a reverse-to-host  
connection to ask "Is this from you, and which user is it from"?

You've just implemented a complicated version of a return-routability  
check.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 27 Oct 2008 09:27:54 +0200

> require all the calls originating @bar go through the @bar proxy/sbc.

when sip:foo@bar makes the call, it does not need to go through bar's
proxy.  all that is needed is that sip:foo@bar is registered with its
registrar.l

forking is needed if sip:foo@bar has currently registered from multiple
UAs, but forking is normal rfc3261 stuff.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 27 Oct 2008 09:29:37 +0200

> You've just implemented a complicated version of a return-routability  

i don't know about the dialog event solution, but what i had proposed is
VERY simple:  one request and a response to it.

-- juha

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 27 Oct 2008 21:14:40 +0100

> VERY simple:  one request and a response to it.

It's basically the same, but devices that already support Dialog event support 
(as servers) already implement this draft "Dialog Event foR Identity 
VErification" while using a new custom request/response would require devices 
supporting it as a new feature.

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 27 Oct 2008 23:14:10 +0200

Iñaki Baz Castillo writes:

 > VErification" while using a new custom request/response would require
 > devices supporting it as a new feature.

i did my proposal before presence was invented and it is still way
simpler, less messages, and lower delay.

-- juha

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Mon, 27 Oct 2008 22:25:17 +0100

> simpler, less messages, and lower delay.

I'd really appreciate if you could share it with us.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 27 Oct 2008 22:48:18 +0100

> - my phone sends a query to sip:foo@bar asking if foo@bar is trying to

Ok, but which is that request and response?

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 27 Oct 2008 18:58:14 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Dean Willis
> Sent: Monday, October 27, 2008 12:08 AM
> To: Iñaki Baz Castillo
> Cc: [email-masked]
> Subject: Re: [Sip] submission of a new I-D: "Dialog Event foR 
> IdentityVErification"
> 
> 
> You've just implemented a complicated version of a 
> return-routability check.

Here is another return routability check,
http://tools.ietf.org/html/draft-wing-sip-e164-rrc-01#section-3.1
(My I-D expired due to lack of interest.)

-d

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 08:08:52 +0200

> I'd really appreciate if you could share it with us.

i don't remember the details.  the idea was very simple:

- UAS receives a call from sip:foo@bar

- UAS sends a query (INFO, OPTIONS, whatever) to sip:foo@bar and
  includes in it relevant info about the request (call-id, from uri,
  from tag, date, to uri, ...)

- when sip:foo@bar UA receives the query, it replies with 200 ok if this
  UA is currently making the call in question

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 08:11:29 +0200

> Ok, but which is that request and response?

i don't care, whatever ietf had decided on, e.g. options, info, or
something new.  if you implement presence based version of this, UAs
need to be changed anyhow. probably you need to make changes also in
presence server in order to cope with privacy issues, i.e., who is
allowed to subscribe dialog state.

-- juha

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 28 Oct 2008 10:49:19 +0100

Hi Juha,
comments inline.

>  from tag, date, to uri, ...)

In derive, this query is a SUBSCRIBE request

>  UA is currently making the call in question

A 200 response to the subscription indicates the Caller's awareness of
the dialog
being monitored by the Callee. Otherwise (when the Caller is not aware
of the subscribed dialog) this subscription won't be accepted.

> simpler, less messages, and lower delay.

Concerning to the "lower delay", were you using any timer other than
Timer F (64*T1)?

Thanks for your comments,

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 11:55:33 +0200

> Concerning to the "lower delay", were you using any timer other than

no, i'm just comparing the number of messages that each cause some
delay. 

in case of a presence based solution, caller needs to publish its
dialog, not just send an invite, which means more messages.

when presence server receives subscribe from callee, it needs to make
xcap query, before it can reply, which in again means more delay.

-- juha

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Tue, 28 Oct 2008 11:06:45 +0100

> xcap query, before it can reply, which in again means more delay.

I'm afraid that you are assuming that a presence server is used.
Derive is an _end-to-end mechanism_ implemented in the UAs.

Cheers,

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 12:39:44 +0100

> dialog, not just send an invite, which means more messages.

That's not true.
- A calls B
- Inmediatelly B sends a SUBSCRIBE (Event:
dialog;call-id=xxx;to-tag=xxx) to A AoR (which could fork).
- The A contact in this dialog will reply 200 OK for the SUBSCRIBE.
- B already nows that the sender is verified and sends the 180 Ringig
for the INVITE...
- A also sends a NOTIFY as is mandatory for presence (but this is not
important and A doesn't require to receive it).

No PUBLISH is needed. PUBLISH appears when subscribing to an AoR calls
without specifyng "call-id" and "to-tag" parameters.

Please, review the draft flows ;)

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

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 12:41:26 +0100

2008/10/28 Juha Heinanen <[email-masked]>:
> something new.

> if you implement presence based version of this, UAs
> need to be changed anyhow.

Why? a UA supporting Dialog Event package (as a server) alreays allows
the mechanims defined in this draft.

> probably you need to make changes also in

The same would be requiered if you send any other request type, wouldn't it?

Regards.

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 12:44:17 +0100

> (My I-D expired due to lack of interest.)

It uses RFC 4474, certificates... is it really feasible in this real world?

IMHO "Dialog Event foR Identity VErification" is the more feasible
solution at the moment.

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 14:54:26 +0200

> Derive is an _end-to-end mechanism_ implemented in the UAs.

if i have configured my proxy to use presence server for local users,
how does subscribe reach the UA?

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 15:02:03 +0200

> dialog;call-id=xxx;to-tag=xxx) to A AoR (which could fork).

as i replied earlier, normally my proxy is configured to use presence
server for subscribes.  are you suggesting that i would need to
configure it somehow to make an exception on these subscribes?  if so,
how do they differ from normal ones where presence server is used?

other than that, i'm ok with the proposal.

-- juha

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 14:23:27 +0100

2008/10/28 Juha Heinanen <[email-masked]>:
> server for subscribes.

For both SIMPLE and Dialog presence?

> are you suggesting that i would need to
> configure it somehow to make an exception on these subscribes?

Not needed at all. If you are using a Event Dialog presence agent
(i.e: pua_dialoginfo) you don't need forwarding SUBSCRIBE (Event:
dialog) to UAS.

> if so,

It depends on your environment. If you use Dialgo presence implemented
in the proxy then you need a presence agent (who sends the NOTIFY to
subscribers about calls from/to an AoR). Also you have a presence
server that will receive the SUBSCRIBE (Event: dialog).
You could use this scenario with the current draft. Just one important issue:

I suppose you don't allow anyone subscribing to calls status of any
local users, but in the case of this draft you should allow any
SUBSCRIBE with:

  Event: dialog;call-id=xxxx;to-tag=xxxx
  Expires: 0

Note this subscription only involves an specific dialog. If B knows
these dialog parameters it means that he is the receptor and he is
trying to verify the sender AoR (From). In this case your presence
server should allow that SUBSCRIBE (or your proxy should allow that
SUBSCRIBE being forwarded to UAS if you don't use a dialog presence
server).

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 14:25:04 +0100

> how does subscribe reach the UA?

If you proxy includes a dialog presence server, then the SUBSCRIBE
doesn't need to reach the UA since your proxy already has the
information about dialogs of that UA.

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 16:46:00 +0200

> information about dialogs of that UA.

inaki,

now i'm confused again.  in above, you say that this is a UA thing,  now
you seem to indicate, that proxy needs to keep track of the dialogs.
so far i'm not convinced that proxy can reliable keep track of dialogs.

in openser/kamailio environment, for example, keeping track of dialogs
is implemented using dialog module, which has the history of being the
most buggies module of all.  perhaps that is due to the difficulty of
the problem, i.e., proxy is made to do something it is not really
intended for.

-- juha

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 16:11:10 +0100

> so far i'm not convinced that proxy can reliable keep track of dialogs.

There are two possibilities:

1) The SUBSCRIBE arrives to the UA location.
- A calls B.
- B sends a SUBSCRIBE (Event: dialog;acll-id=xx;to-tag=xx) to A AoR.
- The proxy responsible for A receives the SUBSCRIBE and forwards it
to A location(s). Note that the proxy allows this SUBSCRIBE since the
"Event" header is "dialog" containing "call-id" and "to-tag". It could
also check if the "Expires" equals 0. So this is not a SUBSCRIBE "for
all the calls from/to A", but a SUBSCRIBE for an spedific dialog.
- B receives the SUBSCRIBE and since B implements RFC 4235 (receiving
the SUBSCRIBE, not just publishing) it checks if that dialog exists.
If it, B replies 200 and sends a NOTIFY (mandatory).
- A receives the 200 so has verified the sender identity.
- B start ringing and so...

2) The SUBSCRIBE is handled by a proxy / presence server.
- A calls B through P1 (proxy responsible for A).
- P1 includes a dialog presence agent (as pua_dialoginfo). This agent
generates a PUBLISH that is sent to the integrated (or separate)
dialog presence server (we are not speaking about a SIMPLE presence
server). So the dialog presence server is now aware of the current
dialog between A and B.
- B sends a SUBSCRIBE (Event: dialog;acll-id=xx;to-tag=xx) to A AoR.
- The proxy responsible for A receives the SUBSCRIBE and forwards it
to its presence server. Again, the proxy allows this SUBSCRIBE since
the "Event" header is "dialog" containing "call-id" and "to-tag".
- The presence server checks the dialog data in the "Event" header of
the SUBSCRIBE (as A does in case 1). If it matches an existing dialog
if replies 200 and NOTIFY as in case 1.
- A receives the 200 so has verified the sender identity.
- B start ringing and so...

> the problem, i.e., proxy is made to do something it is not really

Probably. Anyway this draft defines a correct behaviour that can work
in environments in which the SUBSCRIBE would be sent to UA or would be
handled by a presence server.
As you say, probably dialog status shouldn't be handled by a proxy,
but that's a different issue.

---

From: Bob Penfield <[email-masked]>
Date: Tue, 28 Oct 2008 11:10:20 -0400

Juha,

Could your proxy distinguish between subscription for the presence server and those for the UA based on the Request-URI? Something like this:

For the presence server:

        SUBSCRIBE sip:ps.example.com

For the UA:

        SUBSCRIBE sip:[email-masked]

cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juha Heinanen
Sent: Tuesday, October 28, 2008 10:46 AM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [Sip] submission of a new I-D: "Dialog Event foR Identity VErification"

inaki,

-- juha

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 16:18:26 +0100

>        SUBSCRIBE sip:[email-masked]

This is incorrect. The sender of the SUBSCRIBE will always use:
  SUBSCRIBE sip:[email-masked]

Also, this sender doesn't know if its SUBSCRIBE wil be handled by A's
UA or by a presence server.

Example:

- A calls B:
    INVITE sip:[email-masked]
    From: sip:[email-masked];tag=1234
    Call-ID: abcdefg

- B generates this SUBSCRIBE:
    SUBSCRIBE sip:[email-masked] SIP/2.0
    From: [email-masked];tag=xxxxx
    To: sip:[email-masked]
    Event: dialog;call-id=abcdefg;to-tag=1234

The SUBSCRIBE sent by B *always* contains the username (A) in the RURI.

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 17:26:38 +0200

> all the calls from/to A", but a SUBSCRIBE for an spedific dialog.

ok, that kind of tests are feasible for the proxy to do.

 > server). So the dialog presence server is now aware of the current

this kind thing would be very hard to implement reliably.

in summary, i'm in favor of this draft and suggest that it will
be published as a working group document.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 17:27:20 +0200

>         SUBSCRIBE sip:[email-masked]

in this application at least, it is better to check the dialog package
and parameters.

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Oct 2008 17:24:09 +0000

Viktor,

An interesting draft addressing a known problem space. Dan Wing has already pointed out similarities with draft-wing-sip-e164-rrc (now expired). I fear the present draft will not work in the presence of B2BUAs along the path of the INVITE request, since these tend to change things like call-ID, to-tag and from-tag. Since B2BUAs, and SBCs in particular, are the main reasons why RFC 4474 will not work, any solution has to be able to work through these devices.

John 

> Behalf Of Victor Pascual Ávila
> Sent: 25 October 2008 16:09
> To: [email-masked]
> Subject: [Sip] submission of a new I-D: "Dialog Event foR 
> Identity VErification"
> 
> Hi all,
>

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 28 Oct 2008 19:42:56 +0200

Elwell, John writes:

 > An interesting draft addressing a known problem space. Dan Wing has
 > already pointed out similarities with draft-wing-sip-e164-rrc (now
 > expired). I fear the present draft will not work in the presence of
 > B2BUAs along the path of the INVITE request, since these tend to
 > change things like call-ID, to-tag and from-tag. Since B2BUAs, and
 > SBCs in particular, are the main reasons why RFC 4474 will not work,
 > any solution has to be able to work through these devices.

i don't accept that kind of requirement.  if you have problems with this
draft in B2BUAs, then you have to cope with them in your B2BUAs.  from
the point of view of this draft (and any SIP standard), B2BUAs are just
UAs.

-- juha

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Tue, 28 Oct 2008 18:52:06 +0100

> An interesting draft addressing a known problem space. Dan Wing has already pointed out similarities with draft-wing-sip-e164-rrc (now expired). I fear the present draft will not work in the presen…

Since the B2BUA has detailed info of both legs A and B, it is capable
of doing needed changes, as replacing call-id and to-tag in Event
header.
Also, the B2BUA could handle the SUBSCRIBE by its own, this is,
becoming a dialog presence server instead of forwarding the SUBSCRIBE
to the UA.
B2BUA must handle all this stuff since they are, in fact, the end
point, not the UA's behind them.

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Oct 2008 21:31:16 +0000

> Behalf Of Iñaki Baz Castillo
> Sent: 28 October 2008 17:52
> Cc: [email-masked]
> Subject: Re: [Sip] Comment on DERIVE and B2BUAs
> 
> > An interesting draft addressing a known problem space. Dan 
> Wing has already pointed out similarities with 
> draft-wing-sip-e164-rrc (now expired). I fear the present 
> draft will not work in the presence of B2BUAs along the path 
> of the INVITE request, since these tend to change things like 
> call-ID, to-tag and from-tag. Since B2BUAs, and SBCs in 
> particular, are the main reasons why RFC 4474 will not work, 
[JRE] This reduces it to transitive trust, i.e., no better than P-Asserted-Identity. The UA that receives the INVITE request has to trust its local B2BUA to confirm that the INVITE request really did come from the wherever it claimed to have come from.

John

---

From: Dean Willis <[email-masked]>
Date: Tue, 28 Oct 2008 17:32:10 -0500

> any solution has to be able to work through these devices.

Would the SBC not have to handle the SUBSCRIBE request locally? After
all, since it is a terminal UA for the call, it also knows about all the
dialog states. The end-user UA would never even see the SUBSCRIBE.

So the SBC's lack of transparency on tags, etc. is irrelevant.

---

From: Dean Willis <[email-masked]>
Date: Tue, 28 Oct 2008 17:35:43 -0500

Elwell, John wrote:
> 
> IBC said:
>> Since the B2BUA has detailed info of both legs A and B, it is
>> capable of doing needed changes, as replacing call-id and to-tag in
>> Event header. Also, the B2BUA could handle the SUBSCRIBE by its
>> own, this is, becoming a dialog presence server instead of
>> forwarding the SUBSCRIBE to the UA. B2BUA must handle all this
>> stuff since they are, in fact, the end point, not the UA's behind
>> them.
>
> [JRE] This reduces it to transitive trust, i.e., no better than
> P-Asserted-Identity. The UA that receives the INVITE request has to
> trust its local B2BUA to confirm that the INVITE request really did
> come from the wherever it claimed to have come from.
> 
>

Since the INVITE is coming from the SBC (even though the SBC was
influenced by something else to get it to send the INVITE), I don't see
a problem with this.

Otherwise said, SBCs are always transitive trust unless we have
end-to-end crypto, in which case we don't really have SBCs.

So?

--
Dean

---

From: "Nasir Khan" <[email-masked]>
Date: Tue, 28 Oct 2008 18:39:29 -0400

Yes, obviously RFC 4474s mechanisms end at a B2BUA because the B2BUA
effectively starts a new call (from the UAC side).
In fact the B2BUA cannot even provide a new Identity header if the From
header remains unchanged because the Contact would typically be specific to
the B2BUA and the private key for senders domain is unknown to this B2BUA.

It however is not as bad as it sounds because typically B2BUAs (SBCs in
particular) would be within the final UASs trust domain.

Nasir
-- 
Get the most comprehensive open source SIP testing framework at
http://sipper.agnity.com
--

-- 
Get the most comprehensive open source SIP testing framework at
http://sipper.agnity.com

---

From: Victor Grinberg <[email-masked]>
Date: Tue, 28 Oct 2008 17:49:59 -0500

On Tue, 2008-10-28 at 18:39 -0400, Nasir Khan wrote:
> In fact the B2BUA cannot even provide a new Identity header if the
> From header remains unchanged because the Contact would typically be
> specific to the B2BUA and the private key for senders domain is
> unknown to this B2BUA. 
>  
> It however is not as bad as it sounds because typically B2BUAs (SBCs
> in particular) would be within the final UASs trust domain. 
>  

In practice SBC is most likely a third-party piece of hardware/software
with it's own functionality and most likely do not have access to local
trust domain database.

--
VictorG

---

From: [email-masked]
Date: Tue, 28 Oct 2008 22:36:46 -0400 (EDT)

From: Dean Willis <[email-masked]>

Well, "Nonetheless Ident is widely used and considered useful by
some."

Ident is used to verify the other end of a TCP connection.  The
problem with Ident is that it doesn't reliably tell you more than the
identity of the host from which the connection comes from (because you
can't really trust identd at the far end), and you knew what the host
was already by looking at the packet addresses.

With SIP, you don't know that the originating UAS has the same name as
it is claiming to have, because you got the SIP message from some
nearby proxy.  DERIVE is more like doing a reverse DNS lookup to see
if the originating host has the name that it claims to have.

Dale

---

From: [email-masked]
Date: Tue, 28 Oct 2008 22:36:36 -0400 (EDT)

From: "Elwell, John" <[email-masked]>

   An interesting draft addressing a known problem space. Dan Wing has
   already pointed out similarities with draft-wing-sip-e164-rrc (now
   expired). I fear the present draft will not work in the presence of
   B2BUAs along the path of the INVITE request, since these tend to
   change things like call-ID, to-tag and from-tag. Since B2BUAs, and
   SBCs in particular, are the main reasons why RFC 4474 will not
   work, any solution has to be able to work through these devices.

However...  If we change the sequence of operations a bit, so that the
UAS sends a 183 with a Contact carrying a specific header parameter
carrying a crypto-random value, and we get B2BUAs to pass it through
(attaching it to the Contact they use in the 183 they emit on the
other side), then if the UAS does a non-filtered dialog event
SUBSCRIBE, it can check the returned NOTIFY to see if it carries the
Contact header parameter that it created.  That's a reasonably good
test that the UAC of the INVITE can be reached via the From value that
the UAS received.

Dale

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Oct 2008 20:42:51 -0700

> Sent: Tuesday, October 28, 2008 4:44 AM
> Cc: [email-masked]
> Subject: Re: [Sip] submission of a new I-D: "Dialog Event 
> foRIdentityVErification"
> 

No, it doesn't use RFC4474.  The steps merely show where an RFC4474 
signature could be performed.  If no RFC4474 signatures are
being created, or validated, those steps are the 'null operation'
(not performed).  Without those steps, it is remarkably similar
to DERIVE.

> IMHO "Dialog Event foR Identity VErification" is the more feasible

The differences are minor.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Oct 2008 20:52:02 -0700

> if the originating host has the name that it claims to have.

Yeah, that's walking the DNS tree.  It is valuable; heck, IETF's own
mailservers are doing it to reduce spam so it Must Be Good!  :-)

DERIVE is checking to see if your SIP routing takes you to the
same place that (claims to) be originating the incoming INVITE.  
It is using your *outgoing* SIP routing -- which you must already 
trust to send outbound messages -- to test the validity of the
(proported) From: address of an incoming INVITE.

Such a return routability check is probably the best SIP can do in the
presence of SBCs and the inability to get
draft-fischer-sip-e2e-sec-media-01.txt or draft-wing-sip-identity-media-03.txt
off the ground.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Oct 2008 21:05:04 -0700

> Sent: Tuesday, October 28, 2008 3:32 PM
> To: Elwell, John
> Cc: [email-masked]

If that's a problem, just use some different method that goes end to
end.  The always-loved INFO comes to mind.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 28 Oct 2008 21:16:29 -0700

> Sent: Tuesday, October 28, 2008 3:36 PM
> To: Elwell, John
> Cc: [email-masked]
> influenced by something else to get it to send the INVITE), I 
> don't see a problem with this.
> 

I trust my post office to route a package to the "To:" address 
much more than I trust the "From:" address of a package on my 
doorstep.  I expect you do, too -- or do you really believe those
letters are from Ed McMahon?

An analogy:  DERIVE (and my old RRC draft) are looking at the 
characteristics of that package on the doorstep (SIP INVITE), and 
sending a letter to the "From:" address written on the package,
asking "Did you really send that?".  The post office will route
that letter correctly, and it will be opened by the addressee,
who will say "Yes, I sent you that package", which is routed
back to me.  I will *then* pick up the package (the SIP INVITE).

For additional protection (as described in my RRC draft) from
the post office opening that letter and responding on behalf
of the addressee (which an SBC or B2BUA might be tempted to
do), we could require the addressee to use a wax seal on 
their reply letter (a signature over their reply).

-d

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 Oct 2008 06:31:18 +0000

> From: Dean Willis [mailto:[email-masked]] 
> Sent: 28 October 2008 22:36
> To: Elwell, John
> Cc: Iñaki Baz Castillo; [email-masked]
[JRE] So we need to find a way of making e2e crypto work through SBCs.

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 Oct 2008 06:37:12 +0000

> Behalf Of [email-masked]
> Sent: 29 October 2008 02:37
> To: [email-masked]
[JRE] Unless a B2BUA fails to play according to the rules and
acknowledges the SUBSCRIBE without carrying out the same test on the
next hop. That is why we really need a cryptographic solution, so that
we can see for sure which domain is asserting that the identity is
correct.

John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 29 Oct 2008 06:41:44 +0000

> Sent: 28 October 2008 22:32
> To: Elwell, John
> Cc: Victor Pascual Ávila; [email-masked]
[JRE] Then we would only achieve confirmation of identity on the first hop (or hop-by-hop, if each B2BUA did it), resulting in transitive trust - no better than PAI.

John

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 29 Oct 2008 12:15:57 +0100

Hi Dan,
Please, see my comments inline.

> The differences are minor.

The Return Routability Check (RRC) determines if a domain rightfully
'owns' an E.164 phone number, but DOES NOT prevent an attacker from
presenting a forged "From" header field.

As an example:

INVITE sip:[email-masked] SIP/2.0
From: +14085551234 <sip:[email-masked];user=phone>;tag=9fxced76sl
To: Victor <sip:[email-masked]>
Call-ID: [email-masked]
Contact: <sip:[email-masked]>
Content-Type: application/sdp
Content-Length: ...

[SDP not shown]

Where iptel.org owns the +14085551234 number.

Section 3.2:
-The SUBSCRIBE should be immediately acknowledged
-A NOTIFY should be immediately created and sent

Moreover IMO:
- it requires the use of signatures (or RFC4474): see Sections 3, 3.1 and 3.2
- it is defined to be used only with e164-based SIP URIs

In short, this is a good document but, as I mentioned before, ONLY
determines if a domain rightfully 'owns' an E.164 phone number, it
doesn't ask "are you calling me?"

Thanks a lot for your comments,

---

From: Henry Sinnreich <[email-masked]>
Date: Wed, 29 Oct 2008 09:00:36 -0500

> draft-fischer-sip-e2e-sec-media-01.txt or draft-wing-sip-identity-media-03.txt

I believe this sums it up; correct and balanced.

Henry

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Oct 2008 11:44:54 -0700

> From: Victor Pascual Ávila [mailto:[email-masked]] 
> Sent: Wednesday, October 29, 2008 4:16 AM
> To: Dan Wing
> Cc: [email-masked]
> From: +14085551234 
> <sip:[email-masked];user=phone>;tag=9fxced76sl

As I said previously:  if there is no signature service, this is the null
operation.  The UA is competely incapable of causing or forcing its domain to
generate an RFC4474 signature, anyway, so it's impossible for a UA to
'require' such a signature.

> doesn't ask "are you calling me?"

Easily added; draft-wing-sip-e164-rrc-01 currently reads:

   3.2.  Authentication Service or Calling Endpoint Operation

   The steps described in this section can be performed by the
   authentication service or by the calling endpoint.

   The authentication service or the calling endpoint, upon receiving a
   SUBSCRIBE for the return-routability event package, performs the
   following steps:

   1.   The SUBSCRIBE should be immediately acknowledged with a 200 Ok
       ^
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   INSERT "If there is another active INVITE dialog, which has not 
           received its 200 Ok, then"

       message.
                ^
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      INSERT "If there is not another active INVITE dialog, an error
        response is sent (e.g., 4xx), and processing stops."

   2.  A NOTIFY should be immediately created, containing the same
       application/return-routability-nonce copied from the SUBSCRIBE.
       This NOTIFY contains a To and Request-URI which match the From of
       the SUBSCRIBE.

   3.  This NOTIFY is sent.

   4.  The RFC4474 authentication service, operating at the domain, will
       create a signature over the NOTIFY.  This is used by the remote
       domain's verification service (see Section 3.1).

I'm not interested in having a competing proposal, though, or arguing
nits about which 4xx response code is most appropriate.

We should be arguing about larger issues, such as the value of proving 
someone is actually originating a call.  Without that, we cannot have 
reliable whitelists or reliably blacklists, which are the foundations 
for authorizing incoming SIP requests.

I support draft-kuthan-sip-derive-00, and hope the WG can devote
time and energy to improving and standardizing it to work well
across a variety of networks.

-d

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Wed, 29 Oct 2008 20:37:41 +0100

> for authorizing incoming SIP requests.

I fully agree with you.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 29 Oct 2008 23:06:44 +0100

> end.  The always-loved INFO comes to mind.

Anyway, you need to carry in the INFO body (or headers) data about the current 
dialog, but this data changes in both legs of the B2BUA, so it will fail.
It's exactly the same case as if the SUBSCRIBE is "forwarded" between B2BUA 
legs without replacing the dialog data (from leg B to leg A).

Regards.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Oct 2008 18:55:11 -0400

While I agree with what you say, this only works if the verification 
will happen in a timely way. If you want white/black lists, then the 
verification must happen even before the phone rings. Is it reasonable 
to assume that in typical deployments the time for the reverse lookup 
will be quick enough to give reasonable experience to the caller? Or 
will he have already hung up? (I don't have a good sense for the numbers 
here.)

What will the caller be hearing until this gets done? Perhaps 180 could 
be returned, which would at least give *some* feedback.

If this takes too long, then I think it ends up being info that may be 
delivered after the call is established. (Perhaps your callerid starts 
out yellow and turns green when it has been confirmed.)

	Thanks,
	Paul

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 30 Oct 2008 00:12:24 +0100

Hi Paul,

On Wed, Oct 29, 2008 at 11:55 PM, Paul Kyzivat <[email-masked]> wrote:
> While I agree with what you say, this only works if the verification will
> happen in a timely way. If you want white/black lists, then the verification
> must happen even before the phone rings. Is it reasonable to assume that in
> typical deployments the time for the reverse lookup will be quick enough to
> give reasonable experience to the caller? Or will he have already hung up?
> (I don't have a good sense for the numbers here.)

As you mention, the user (Callee) should not be alerted until the
verification process is completed. IMO the time for the reverse lookup
is typically quick enough for an acceptable user experience.

> delivered after the call is established. (Perhaps your callerid starts out
> yellow and turns green when it has been confirmed.)

This is not useful for black/white lists.

Cheers,

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 30 Oct 2008 00:36:20 +0100

> (proported) From: address of an incoming INVITE.

Shall DERIVE be extended to support non-INVITE requests (e.g. MESSAGE)?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Oct 2008 00:39:32 +0100

El Miércoles, 29 de Octubre de 2008, Paul Kyzivat escribió:
> (Perhaps your callerid starts

I like this idea.

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Oct 2008 18:40:06 -0500

> end.  The always-loved INFO comes to mind.

What makes you think that INFO goes end to end? An SBC can absorb it  
if it wants to.

But this handling is not a bug, it's a feature. Since the SBC is call- 
stateful, it knows about the outgoing call, and thus can  
authoritatively say "Yes, this call was from Dan" without having to  
congest your low-rate end-link.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Oct 2008 18:48:35 -0500

On Oct 29, 2008, at 5:55 PM, Paul Kyzivat wrote:

> verification must happen even before the phone rings. Is it  
> reasonable to assume that in typical deployments the time for the  
> reverse lookup will be quick enough to give reasonable experience to  
> the caller? Or will he have already hung up? (I don't have a good  
> sense for the numbers here.)
>

a Really Bad Case would be 5 seconds PDD, with more typical being on  
the order of 1 second.

> What will the caller be hearing until this gets done? Perhaps 180  
> could be returned, which would at least give *some* feedback.

You might hear a chime for "Return Routability Check completed".

Of course, if we were fixing this "right", it would be yet-another  
precondition.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 29 Oct 2008 18:54:12 -0500

Guys,

Instead of using a SUBSCRIBE or even INFO, it seems appropriate
to use OPTIONS.

By definition, OPTIONS is intended to be routed the same way 
as an INVITE, and therefore would be more likly to end-up at the
right place.  

> Behalf Of Dan Wing
> Sent: Tuesday, October 28, 2008 21:16
> To: 'Dean Willis'; 'Elwell, John'
> Cc: [email-masked]
> Behalf Of 
> > Dean Willis
> > influenced by something else to get it to send the INVITE), I don't 
> > see a problem with this.
> > 
> I trust my post office to route a package to the "To:" 
> address much more than I trust the "From:" address of a 
> package on my doorstep.  I expect you do, too -- or do you 
> really believe those letters are from Ed McMahon?
> 
> characteristics of that package on the doorstep (SIP INVITE), 
> and sending a letter to the "From:" address written on the 
> package, asking "Did you really send that?".  The post office 
> will route that letter correctly, and it will be opened by 
> the addressee, who will say "Yes, I sent you that package", 
> which is routed back to me.  I will *then* pick up the 
> package (the SIP INVITE).
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Oct 2008 00:46:43 +0100

> What makes you think that INFO goes end to end? An SBC can absorb it  

Also, a B2BUA handling SIP + RTP could transform the INFO request into RTP 
data as RFC2833 (DTMF in RTP).

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Thu, 30 Oct 2008 01:00:09 +0100

> as an INVITE, and therefore would be more likly to end-up at the

Do you mean including some dialog information in the OPTIONS-request
(e.g using the Target-Dialog header)?

Cheers,

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 29 Oct 2008 19:12:17 -0500

I was more thinking of a nonce as per Dan's draft. But I don't have
a strong opinion.

I am just thinking it's a more appropriate message than the others. 

> Sent: Wednesday, October 29, 2008 17:00
> To: Audet, Francois (SC100:3055)
> Cc: [email-masked]
> > Instead of using a SUBSCRIBE or even INFO, it seems 
> appropriate to use 
> > OPTIONS.
> >
> > By definition, OPTIONS is intended to be routed the same way as an 
> > INVITE, and therefore would be more likly to end-up at the right 
> > place.
> 
> Do you mean including some dialog information in the 
> OPTIONS-request (e.g using the Target-Dialog header)?
> 
> Cheers,
> --
> Victor Pascual Ávila
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 30 Oct 2008 01:14:35 +0100

> as an INVITE, and therefore would be more likly to end-up at the

Any *current* SIP device already implementing RFC 4235 already implements this 
draft. But if it would be handled by other request (i.e. OPTIONS) then no one 
of the current implementations would support this draft now, and they would 
need to be modified.

Also, why sending dialog info into an OPTIONS while a SUBSCRIBE (Event: 
dialog;call-id=xxxx;to-tag=xxx) already defines it?
Sending that info into an OPTIONS would require a new kind of headers or XML 
body.

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Oct 2008 18:42:05 -0700

> Shall DERIVE be extended to support non-INVITE requests (e.g. 

Yes, it seems suitable that DERIVE be able to support any method.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Oct 2008 18:48:44 -0700

> reasonable 
> will he have already hung up? (I don't have a good sense for 
> the numbers here.)

It's an extra round trip, yes.  So are ICE, DTLS-SRTP, connectivity
preconditions, security preconditions, QoS preconditions, Connected-
Identity, and a myriad of other things.  Why should DERIVE be viewed
with derision when SIP has already enjoyed a rich history of 
additional messages to handle important cases?  And if validating
a "From:" isn't important, I have a phone call from George W. Bush
for you..

> What will the caller be hearing until this gets done? Perhaps 
> 180 could be returned, which would at least give *some* feedback.

Sure.  Let's discuss the bigger picture, though:  do we need 
something like DERIVE.

> If this takes too long, then I think it ends up being info 
> that may be delivered after the call is established. (Perhaps 
> your callerid starts out yellow and turns green when it 
> has been confirmed.)

Yep, that is a reasonable approach, too.  If/when spoofed
>From becomes a common problem (how is everyone's daily dose
of email spam today?), this allows the called party to tighten
up their local policy to only ring the phone after the From:
is validated.

-d

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 29 Oct 2008 19:21:17 -0700

> legs without replacing the dialog data (from leg B to leg A).

And that is why there are two proposals that use something that
can't change -- the certificate fingerprint of the endpoint:

  draft-fischer-sip-e2e-sec-media (expired)
  draft-wing-sip-identity-media (expired)

They expired due to lack of interest.

Let's talk about the meta-issue:  do we want assurance of a 
"From:" over SBCs?  If so, let us please convince the ADs 
in Minneapolis and let us please get a new SIP milestone.

-d

---

From: Dean Willis <[email-masked]>
Date: Wed, 29 Oct 2008 23:53:56 -0500

> in Minneapolis and let us please get a new SIP milestone.

I'd rather charter a SIP RRC working group than put a new milestone in  
SIP.

This seems like a perfect item for a working group that could conclude  
in a reasonable and timely fashion.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 30 Oct 2008 09:14:40 +0200

> Instead of using a SUBSCRIBE or even INFO, it seems appropriate

then you are back to my pre-presence proposal (which is fine with me
too).

-- juha

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Oct 2008 08:12:00 +0000

> Sent: 30 October 2008 02:21
> To: 'Iñaki Baz Castillo'; [email-masked]
[JRE] Agreed. DERIVE (or something derived from it) would then be one of the candidates.

John

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Thu, 30 Oct 2008 11:33:54 +0100

(As WG cochair)

The group with current scope for this work is SIP. Therefore if the SIP
WG believes it can make progress in identifying valid work in the SIP
timeframe, the chairs can ask the RAI ADs for a charter milestone. The
ADs can choose to direct that milestone to some other group if they so
wish.

There is a separate RAIarea agenda slot where people can discuss their
ideas on future RAI WG structure. That discussion does not need to
impact on whether this is valid IETF work or not.

So core to the discussion is whether we feel we can get an agreement for
a suitable area of identity related work in Minneapolis based on
discussion of this draft. If the answer is no, the chairs will push it
down the priority order in allocating agenda slots. If the answer is yes
then we push it up the priority. (Note that the same applies for all the
other active identity related documents). 

Note also that we would also like to see any discussion in this area
bringing in new issues and points. There is little point in the same
people standing up at the mic and saying the same things they said in
Dublin, as presumably, we will end up with the same absence of decision.

With this in mind, the chairs welcome discussion on this list, and in
private emails, to see if something can come out of this.

Regards

Keith

> Sent: Thursday, October 30, 2008 4:54 AM
> To: Dan Wing
> Cc: [email-masked]
> > Let's talk about the meta-issue:  do we want assurance of a "From:" 
> > over SBCs?  If so, let us please convince the ADs in 
> Minneapolis and 
> > let us please get a new SIP milestone.
> 
> I'd rather charter a SIP RRC working group than put a new 
> milestone in SIP.
> 
> This seems like a perfect item for a working group that could 
> conclude in a reasonable and timely fashion.
> 
> --
> Dean
>

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 30 Oct 2008 20:43:59 +0100

> private emails, to see if something can come out of this.

I'm wondering if other WG participants would agree with me that "verifying
who is sending me this SIP request is who he claims to be in the simplest
possible way (i.e., without other protocols and infrastructures) by reverse
lookup" would be an appropriate goal.

The number of drafts and emails posted to this topic and more importantly
the problems in the field indicate this is a real and important problem.
Additionally, it seems that folks are interested in something VERY simple.

An implication of that to me is this effort is small and self-contained,
and shall stay so on purpose. From the sizing perspective, the SIP WG thus
seems more appropriate to me than more general (and bigger) fora, and also
it does not seem big enough to me for its own WG.

For sake of completeness: Many of the points raised so far appear to relate
to a solution rather than to question the problem: SUB/NOT versus OPTIONS,
"B2BUA traversal", as well as those not addressed yet much: reverse 
routability,
latency, security considerations....

-jiri

---

From: Ben Campbell <[email-masked]>
Date: Thu, 30 Oct 2008 16:11:50 -0500

On Oct 29, 2008, at 6:40 PM, Dean Willis wrote:

> But this handling is not a bug, it's a feature. Since the SBC is  
> call-stateful, it knows about the outgoing call, and thus can  

Smells a lot like the "you break it you bought it" model for SBCs and  
RFC 4474.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Oct 2008 21:37:02 +0000

> Sent: 29 October 2008 18:45
> To: 'Victor Pascual Ávila'
> Cc: [email-masked]
[JRE] I agree. This must include networks that contain B2BUAs/SBCs.

John

---

From: Dean Willis <[email-masked]>
Date: Thu, 30 Oct 2008 16:50:48 -0500

> lookup" would be an appropriate goal.

Leaving aside the question of whether the success of the DERIVE RRC  
answer's the question you've asked above (I don't think it does; it  
merely verifies that the a node reachable at the AOR to which the  
request is attributed has particular knowledge of the SIP request in  
question), let's ask if we understand the unintended consequences.

There are fundamental assumptions in this sort of RRC model that the  
node initiating the dialog request is in fact reachable by some sort  
of AOR, and that this is the AOR that will be presented in the request  
as that of its originator. This is not universally true.

Envision a presence-enabled call controller (PECC) employed by Alice.  
Alice wants to call Bob, whenever Alice and Bob are both on-line.

So PECC subscribes to Alice and Bob.

Eventually Alice and BOb are both on-line, so PECC sets up the call.

What's in the From" going to Bob? It's probably Alice's AOR, as PECC  
is working on her behalf, and there's some reason to think that Bob is  
willing to accept calls from Alice. But PECC cannot REGISTER as Alice,  
for obvious reasons.

Bob uses DERIVE, and sends a SUBSCRIBE to Alice that references the  
dialog that is between PECC and Bob.

Can Alice's UA respond appropriately? I think not.

There are other ways to construct the type of application I'm talking  
about, that might work with DERIVE. Do we want to force a redesign of  
SIP applications so that return-routability to the originating AOR is  
required? This might not be a bad thing, but I think it is a very  
primal thing, and is potentially quite disruptive to application  
scenarios. That might be OK, but we need to understand the  
consequences before we go down that road.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 30 Oct 2008 16:53:43 -0500

On Oct 30, 2008, at 4:11 PM, Ben Campbell wrote:

>> What makes you think that INFO goes end to end? An SBC can absorb  
>> it if it wants to.
>>
> Smells a lot like the "you break it you bought it" model for SBCs  
> and RFC 4474.

Which is why identity is always transitive in nature . . .

Alice's cousin Bob knows this woman Carol who is placing a call to  
Alice's friend Dave. Meanwhile, weasels have eaten our PBX.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 30 Oct 2008 23:51:25 +0100

Dean Willis wrote:
> node initiating the dialog request is in fact reachable by some sort of 
> AOR, 

Indeed -- that's a known limitation. There is a variety of reasons why
derive leaning on backwards routing for a subscription can fail:
UAC is unregistered, UAC has permanent call-forwarding set up, UAC
chose to make itself known as "anonymous", the UAC does support SUB-NOT,
tel-URI is not assignable to the originating UAC, ....

In summary, we gain a good deal of certainty in case it works and that's
it. If it does not work, we know that we don't know, like before.
Actually applicability should have been stated already in the abstract,
that's an important point -- sorry about that.

> and that this is the AOR that will be presented in the request as 
> that of its originator. This is not universally true.

Agreed too, that should be clearly stated under known limitations too.

> What's in the From" going to Bob? It's probably Alice's AOR, as PECC is 
> working on her behalf, and there's some reason to think that Bob is 

The point is DERIVE tells you here "we know that we don't know". It
can label the incoming call grey (as opposed to green if it worked)
and leave it to the callee's discretion how to handle it. (deny-all,
deny-this,answer-this,what-have-you).

The 3pcc case you are mentioning is certainly not the only one we
could add to the list of failure reasons mentioned above.

> required? 

Well -- I don't think this is about us/ietf, it is about the actual users
and deployments choosing how to put things together. In the actual
deployments I'm aware of, non-reverse-routeable URIs are not a concern
for the adopters (except tel URI), unsolicited traffic begins to be.
Obviously, in environments building upon 3pcc, derive can produce little
value.

How the balance develops between UAS users relying on derive-like
mechanisms for "trash separation", and UAC users using it to increase
the chance of their calls to get through -- difficult to say now.
DNS reverse verification has apparently taken off, even though I'm sure
there were similar limitations.

> This might not be a bad thing, but I think it is a very primal
> thing, and is potentially quite disruptive to application scenarios. 
> That might be OK, but we need to understand the consequences before we 
> go down that road.

Understanding the known limitations and applicability is for sure one
of the most important pieces here.

-jiri

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 31 Oct 2008 00:06:58 +0100

> consequences before we go down that road.

Hi,

While your explanation makes sense, it seems to conclude that the simple 
mechanism described in DERIVE should not be considered due to some "exotic" 
scenarios in which it could fail (mostly in presence of border controller).

But I'm sure that any other sender verification proposals appearing in this 
thread (as other drafts) also doesn't cover all the possible scenarios. At 
least, DERIVE seems useful in most common cases, and it just requires devices 
supporting RFC 4235.
Of course, the presence of border controllers and B2BUA's always break any 
divine topology full of proxies defined in any RFC. DERIVE is not an 
exception.

So people involved in IETF can accept a simple and feasible solution as the 
current proposal, or just drop it and wait for other proposals full of 
certificate usage, bidirectional authentication and more stuff that will be 
never feasible in the real world. But this is just my opinion. Of course you 
could be right.

Thanks.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 31 Oct 2008 00:10:38 +0100

El Viernes, 31 de Octubre de 2008, Iñaki Baz Castillo escribió:
> scenarios in which it could fail

Well, the possible scenarios in which it could fail are not so "exotic", sorry 
for that.

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 30 Oct 2008 16:50:29 -0700

> of AOR, and that this is the AOR that will be presented in 
> the request as that of its originator. This is not universally true.

Agreed.

But in order for me to get a postmark that says "San Jose", I need
to drop my mail into a San Jose post office.  And if you see my package
arrive with my San Jose address, but you see a Wasila, Alaska postmark,
you might be more suspicious about it than usual.

> willing to accept calls from Alice. But PECC cannot REGISTER 
> as Alice, for obvious reasons.
> 

You're right.

(I might wonder aloud how well all of SIP's features work with
3rd party call control.  But we know the answer is "not all".)

I will note that for RFC4474 to operate in that same scenario, 
PECC would need to be inside of Alice's domain (in order that 
Alice's domain creates the necessary RFC4474 signature over the 
[spoofed] INVITE emitted by PECC).

> There are other ways to construct the type of application I'm 
> talking about, that might work with DERIVE. Do we want to force 
> a redesign of SIP applications so that return-routability to 
> the originating AOR is required?
> This might not be a bad thing, but I think it is a very  

I'm just desiging in this email, but it may well be sufficient,
for the case you describe above (and maybe others?) if PECC were
to inform Alice of the impending automated call to Bob.  Alice
would probably want to know this, anyway.  Afterall, seeing or
hearing "Bob is online right now; initiating call" and seeing
or hearing call progress indications is more reasonable than
Alice suddenly hearing Bob's voice saying "Hi, Alice, it's good
you called me.  Let's talk about the weather."

Such a notification to Alice could be as straightforward as 
the PECC sending Alice a NOTIFY, so that when Alice receives
the RRC message (e.g., [INFO|SUBSCRIBE|OPTIONS]), she has the
necessary dialog information to respond correctly to the 
RRC.

-d

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 31 Oct 2008 08:31:22 +0200

> [JRE] I agree. This must include networks that contain B2BUAs/SBCs.

i strongly disagree.  b2bua is just an ua.  if you you build or deploy
such boxes, it is your headache, not sip wg's.  it is enough that this
work is based on rfc3261 components.

-- juha

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 31 Oct 2008 00:11:56 -0700

> Which is why identity is always transitive in nature . . .

The post office provides reliable forward routing, even 
across service providers (countries).  So do ISPs.  And 
the PSTN.

In all those cases, the only thing the recipient knows 
is the last hop:  the mail delivery person, their local
Internet access provider, or their local phone company
said "here is your [package | packet | phone call]".

If you want to verify its claimed "From:", a technology
appropirate to that communication mechanism is necessary:
A wet signature (post office), a certificate (ISPs), or 
the other person's voice (PSTN).

SIP provides reliable forward routing, too.  I don't
see a consensus forming that we want to utilize SIP's
reliable forward routing to build a verification system.
That is a shame, because the SIP working group's 
unwillingness to build a verification system for SIP will 
keep SIP locked inside of small networks instead of 
allowing SIP to grow and to run on the Internet.

-d

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Fri, 31 Oct 2008 10:15:41 +0100

> work is based on rfc3261 components.

I agree. If a B2BUA is capable of sending requests with a specific
From it's becomes in fact an UA responsible for that AoR in the From,
so it should be capable of handle incoming SUBSCRIBE for that AoR.

The most problematic case could be the following, in which the
outbound proxy Proxy responsible for domain.org forwards the request
to a B2BUA but at the same time this proxy is the resolution (RFC3263)
for domain.org, so acts also as inbound proxy. In this case
[email-masked] will know nothing about the dialog data received in the
SUBSCRIBE.

  [email-masked]   ----  Proxy (domain.org)  ----  B2BUA ----  [email-masked]
           INVITE ---------------------->
                                           INVITE ---------------------->

      INVITE ---------------------->

<------------------------------------------------ SUBSCRIBE
             <--------------------- SUBSCRIBE

But, how much common is this scenario? However there is a solution:

There are two dialogs now:
1) UA [email-masked] <-----> B2BUA
2) B2BUA [email-masked] <----> [email-masked]

So clearly alice must verify the dialog with B2BUA, so the SUBSCRIBE
must arrive to B2BUA. In order to get it, Proxy (domain.org) could
forward the SUBSCRIBE to B2BUA which will match the specified dialog
and reply 200 OK. Proxy would decide to forward this SUBSCRIBE to
B2BUA upon the presence of a "Event: dialog;call-id=xxx,to-tag=xxx"
header.

---

From: Michael Procter <[email-masked]>
Date: Fri, 31 Oct 2008 10:30:57 +0000

Victor Pascual Ávila wrote:
> Shall DERIVE be extended to support non-INVITE requests (e.g. MESSAGE)

I'm not sure it can.  RFC4235 is defined for INVITE-initiated dialog
usages only.  Yes, it could be extended, but I'm not convinced that is
necessarily the best way forward from here!

Regards,

Michael

---

From: "Iñaki Baz Castillo" <[email-masked]>
Date: Fri, 31 Oct 2008 14:03:32 +0100

> necessarily the best way forward from here!

Also note that MESSAGE doesn't establish a dialog, it just an
independent transaction.

---

From: [email-masked] (Juha Heinanen)
Date: Fri, 31 Oct 2008 15:04:05 +0200

> reliable forward routing to build a verification system.

there has not been uniform consensus on many things (especially 3gpp
rubber stamping) that this working group has decided to do.  in my
opinion there has been enough interest expressed on this mailing list to
go forward with DERIVE.  those who don't need it or are not planning to
use it, can do something else.  they should not try to prevent other
people working on DERIVE.

-- juha

---

From: "Victor Pascual Ávila" <[email-masked]>
Date: Fri, 31 Oct 2008 15:04:12 +0100

Hi Iñaki,

> Also note that MESSAGE doesn't establish a dialog, it just an

Do you mean that we should provide a reasonable assurance that the
"Caller-ID" is not misleading ONLY for dialog-forming requests?

Cheers,

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Oct 2008 12:41:23 -0500

Elwell, John wrote:
> [JRE] This reduces it to transitive trust, i.e., no better than P-Asserted-Identity. 
>
>   

Yes. Excepting cryptographic approaches: with any man-in-the-middle, 
you're at the mercy of that man-in-the-middle, regardless of whether 
their presence is an attack.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Oct 2008 12:47:23 -0500

> What makes you think that INFO goes end to end? An SBC can absorb it 

And, in any case, you can't send an INFO out of dialog. So you can't 
route it to the address in the From -- all you can do is route it back 
along the dialog path. And, of course, *that's* going to work. If it's a 
legitimate call, you'll reach the legitimate caller, who will confirm 
the call is legitimate. If it's a forged call, you'll reach the 
attacker, who will confirm the call is legitimate.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 31 Oct 2008 12:54:12 -0500

Elwell, John wrote:
> next hop.

That's kind of the point of Juri's draft, though -- semantically, the 
recipient of the SUBSCRIBE doesn't need to know that this is an identity 
check. So the B2BUA would have no obligation to do anything towards the 
calling party.

/a

---

From: Dean Willis <[email-masked]>
Date: Fri, 31 Oct 2008 17:06:35 -0500

> Also note that MESSAGE doesn't establish a dialog, it just an

So we're asking "Is this from you" rather than "Did you initiate this  
dialog"?

It still seems like it might be a useful thing to know. Of course,  
this argues that 42325 may be the wrong basis.

Now, if we'd just made SIP work with opposing pairs of two-way  
transactions for everything, instead of singular two and three-way  
transactions, we could build confirmation options into everything. But  
we didn't.

Now, from a security perspective: Who's done the analysis on whether  
DERIVE introduces new attack opportunities?

For example, is there a DOS opportunity in using the home proxy as a  
message-exploder for source-forged SUBSCRIBE requests? Seems like thre  
might be a problem there . . .

--
Dean