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

From: Flemming Andreasen <[email-masked]>
Date: Fri, 01 Feb 2002 18:26:28 -0500

Dean Willis wrote:

> 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.

Sounds like a good idea.

> In general, I propose that
> the "Anonymity" header be extracted from this document and taken into a
> seperate body of work.

If you are thereby implying, that the IP address privacy problem should not
be addressed by the privacy draft, then I'm inclined to disagree. If we
don't have the actual mechanism defined in there (e.g. due to timing
constraints), then at the very least we should leave the considerations
about IP address privacy in there and preferably have some pointers to how
one might provide such a service (always hard to reference future work of
course).

>
> #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.

Are you making a distinction between asserting identity versus providing
authenticated identity ? If so, do note that the current scope specifically
only addresses network authenticated identity, whereas the problem of
actually obtaining and verifying that identity is outside the scope of the
draft. Are you proposing to change that ?

> 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.
>

That part is already covered by the draft (a "private" addr-spec contains
an identification of the encrypting entity in the hostport). Unencrypted
Remote-Party-Id's however do not contain this identification (doesn't add
much value as long as we only have transitive chain of trust and a "screen"
parameter).

>
> 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.
>

As I indiciated in another e-mail, this is a hard problem and the if
propose to relax the strength of the assertion, it's not clear how useful
it is. Also, as has been noted before, this is a special case of a more
general problem, which is why we removed it from the draft.

>
> 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.
>

Same comment as 2).

>
> 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.

Same comment as 2).

>
>
> 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.
>

On the other hand, some people argue that no security is better than
imperfect security. I'm personally of the opinion, that if you have to go
through the trouble and overhead of actually signing Remote-Party-Ids and
having the accompanying PKI structure in place to support all of this, then
you should at least get a secure solution in return.

-- Flemming

>
> 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

--
Flemming Andreasen
Cisco Systems

_______________________________________________
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