Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted

From: "Elwell, John" <[email-masked]>
Date: Thu, 1 Oct 2009 09:34:32 +0200

Cullen,

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 30 September 2009 23:58
> To: Elwell, John
> Cc: [email-masked]
> Subject: Re: [dispatch] draft-elwell-dispatch-identity-reqs-00 posted
> 
> 
> John,
> 
> I think this is going the right direction, but few comments.
> 
> Req 5 is too vague to be of any use. If this was replaced with  
> something like "The solution must allow for media steering", that  
> would make sense to me
[JRE] There is also a note that says "the precise identification of elements of a SIP message that must be allowed to change is for further study, but is expected to include at least those parts of SDP that are changed in order to accomplish media steering."
However, I think we can delete the note and change the requirement to say:
"The solution MUST work when a call traverses multiple domains, including cases where domains perform media steering."
If folks consider there are other aspects of traversing intermediate domains that need to be accommodated, they should identify them and get them explicitly put into the requirement.

> 
> On Req 4 - I don't think it is just the sink/source of the media. It  
> seems that just about anything that is meant to be end to end 
> you want  
> bound to the identity. Imagine an page mode IM. In that case the  
> "media" is the message and you want that bound to the caller id.
[JRE] This document focuses on caller identification (see abstract), as distinct from sender identification (see 4th/5th paragraphs of Intro), because that is where SIP Identity suffers deployment difficulties. Caller identification does need to be linked to sensitive end-to-end information sent by the caller during a call, even if it is sent in SIP messages rather than as media, and to this end I plan to add:
"REQx - It MUST be possible to bind sensitive end-to-end information sent by the calling UA in call-related SIP messages to an asserted caller identification."
(and of course existing REQ6 covers the corresponding connected identification case).

This leaves call-unrelated messages (e.g., for page mode IM), and this isn't really addressed by the I-D at all. I will add to the start of the Requirements section the following statement:
"These requirements are not intended to replace any existing sender identification requirements for SIP messages outside the context of a call (e.g., using the MESSAGE method)."

When I spoke to you privately recently, you indicated that you would like to see the requirements expressed at a higher level, e.g., in terms of confidentiality, integrity protection, etc.. To address this, I was planning to insert three new requirements in front of the existing requirements, along the lines of:
"    <t>REQ1 - It MUST be possible to ensure that sensitive information sent and received during a call cannot be eavesdropped by a third party (confidentiality) and assert such a property to a caller or called user.</t>
    <t>REQ2 - It MUST be possible to ensure that information sent and received during a call is not inserted, modified or deleted by a third party (integrity) and assert such a property to a caller or called user.</t>
    <t>REQ3 - It MUST be possible to provide a called user with verified information identifying the party to which information is sent and from which information is received during a call (authenticated caller identification).</t>"

If you still have such a concern, would the above additional requirements go some way towards satisfying it?

Thanks,

John

---

From: Victor Pascual Avila <[email-masked]>
Date: Wed, 14 Oct 2009 11:58:03 +0200

Hi,

> If you still have such a concern, would the above additional requirements go some way towards satisfying it?

Following are the resulting requirements (included in -01 [1]) for
secure caller identification (PSTN interworking and 3PCC are not
included):

REQ1 - It MUST be possible to ensure that sensitive information sent
and received during a call cannot be eavesdropped by a third party
(confidentiality) and assert such a property to a caller or called
user.

REQ2 - It MUST be possible to ensure that information sent and
received during a call is not inserted, modified or deleted by a third
party (integrity) and assert such a property to a caller or called
user.

REQ3 - It MUST be possible to provide a called user with verified
information identifying the party to which information is sent and
from which information is received during a call (authenticated caller
identification).

REQ4 - It MUST be possible for a called user to receive caller
identification that includes the calling user's domain and the calling
user's name or telephone number within that domain.

REQ5 - It MUST be possible for a called UA to receive an assertion
from the calling user's domain that the call originates in that domain
and that caller identification is correct, based on that domain having
authenticated the calling UA.

REQ6 - It MUST be possible for a called UA to verify such an assertion
based on a trust anchor, such as a CA certificate.

REQ7 - It MUST be possible to bind the source and sink of secure media
(e.g., using SRTP or TLS) to an asserted caller identification.

REQ8 - It MUST be possible to bind sensitive end-to-end information
sent by the calling UA in call-related SIP messages to an asserted
caller identification.

REQ9 - The solution MUST work when a call traverses multiple domains,
including cases where domains perform media steering.

REQ10 - It MUST be possible for a calling user to receive connected
user identification meeting corresponding requirements to those above
for caller identification.

REQ11 - The resulting mechanisms MUST be backward compatible with [RFC3261].

Comments are appreciated.

[1] http://tools.ietf.org/html/draft-elwell-dispatch-identity-reqs-01

Cheers,
-- 
Victor Pascual Ávila