Subject: [Sip] Discussion of draft-ietf-sip-privacy-03 issues.

From: Dean Willis <[email-masked]>
Date: Tue, 29 Jan 2002 16:53:10 -0600

draft-ietf-sip-privacy-03 does several notable things.

1) It defines a Remote-Party-ID header, which provides a way to state 
the identity of participants in a dialog, as well as describe some 
things about that identity, such directionality and its stutus as a 
device or human identity.

2) It provides the RPID-privacy header, which allows the end node to 
describe the privacy policy it wishes to have applied to any 
Remote-Party-ID headers added by intermediate nodes.

3) It provides an "Anonymity" header, which may requests some 
intermediate node to route the dialog via an "anonimyzer", essentially 
a trusted B2BUA that provides additional privacy protections for the 
requesting node.

Let me start with #3, the "Anonymity" header. This appears to be the 
request for a specific routing service or feature which may or may not 
be available in a given network. I think some generalization of the 
expression is appropriate, and it may be worthwhile considering such 
alternatives as making this into a request parameter or as a specific 
service such as that targedted in RFC 2084.  In general, I propose that 
the "Anonymity" header be extracted from this document and taken into a 
seperate body of work.

#1 and #2, the Remote-Party-ID (RPID) header, and "RPID-Privacy" are 
deeply intertwingled. There is an implicit assumption in the draft that 
"the network" is a monolithic entity with a relatively homogenous trust 
fabric. This is consistent with the draft's stated goal of providing 
"NETWORK authenticated RPID", as opposed to RPIDs asserted by other 
parties, or by specific networks.

There are a couple of things that the RPID syntax as drafted does not 
do that may be worthwhile to consider.

1) Informing us as to WHO has asserted the given RPID. The draft allows 
either the user, the terminal  or "the network" to assert an RPID, but 
gives no indication as to which element has made the assertion. It 
might be useful to know which user, which network element, or even 
"which network" asserted the RPID. Such an identification may also be 
useful in selecting a decryption key, should the option of protecting 
the privacy by encrypting the asserted identity be exercised.

2) Informing us at to WHEN each assertion of RPID was made. This is a 
critical aspect for considering replay attacks, as a "stale" assertion 
seems more likley to be false. Of couse there are issues of absolute 
time and clock synchronization to consider, but there are discussions 
of using the RPID as a identity "ticket" for (ala Kerberos), and the 
value of time-awareness in ticket environments is well-understood. One 
might consider seprately the utility of indicating a duration for the 
assertion in relative-time terms.

3)  Informing us as to the dialog-context in whch the assertion of 
identity is being made. Common SIP usage identifies the session-context 
as consisting of the tuple of To:, From:, and Call-ID: headers. Without 
this context, we have no way of knowing if the dialog has undergone a 
"retargeting" transformation since the identity was asserted. As 
drafted, we can assume that the assertion was made in the current 
dialog-context, but we have no way to verify that assumption and must 
relay on transitive trust back to the currently unidentfied asserting 
party.

4) Allowing us to verify, or authenticate, each assertion of RPID. It 
seems desirable to provide an authentication-token for each RPID which 
provides the ability to match the asserted RPID with the asserting 
identity, the time of the assertion, and the context of the assertion. 
One migh propose to achieve this by hashing the conetxt (To:, From, 
Call-ID) together with the asserting identity and the time of 
theassertion, using either a secret or public key associated with the 
asserting identity.

It has been previously pointed out (MAT) that a verification token such 
as that proposed above (#4) is subject to replay. Specifically, it is 
possible for a party in possession of an RPID assertion to replay it 
for the same combination of context-determining parameters (To, From, 
Call-ID). It may be noted that time-bounding the assertion (as in #2 
above) mitigates this problem to some extent, while adding the 
requirement for some general synchronization of clocks in order to 
provide this protection. On the other hand, it can be countered that 
the utility of such a mechanism, while imperfect, is significantly 
better than the warm but vacuous feeling one might get from 
implementing the orginal proposal.

So, other than pretending I've been reading too much Dumas, I would 
like to poll the list for relevant suggestions. Should we adopt any or 
all of the four specific requirements given herein (asserting identity, 
time of assertion, context of assertion, and verification of assertion) 
into the RPID work? Should we also move the "Anonymity" header into a 
seperate draft as suggested?

Thanks,

--
Dean Willis

_______________________________________________
Sip mailing list  https://www1.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: "Tom-PT Taylor"<[email-masked]>
Date: Wed, 30 Jan 2002 08:37:56 -0500

Your points all make sense to me.  Obviously, some sort of integrity
protection has to go along with this.  I also wonder whether we have to
allow each successive service provider on the signalling path to add its bit
saying the previous certifying entity could be trusted, so a chain of trust
is built up on the fly.

-----Original Message-----
From: Dean Willis [mailto:[email-masked]]
Sent: Tuesday, January 29, 2002 5:53 PM
To: [email-masked]; [email-masked]; Flemming Andreasen
Subject: [Sip] Discussion of draft-ietf-sip-privacy-03 issues.

Thanks,

--
Dean Willis