Subject: RE: Signing RPIDS (Was: Re: [Sipping] calling number blocking at sip/isup gateway)

From: "Peterson, Jon" <[email-masked]>
Date: Tue, 29 Jan 2002 13:39:03 -0600

I will note that we included a brief statement in bis06 (21.4.2) that
'selective anonymity' might be achievable with the S/MIME 'message/sip'
tunneling mechanism.

I agree that any long-term privacy mechanism will have to be predicated at
least partially on a cryptographic signature. There are however other ways
to achieve replay protection than temporization. For example, the
'message/sip' tunneling mechanism, since it includes the dialog IDs in the
encrypted MIME body, cannot be trivially replayed.

However, the text in bis is just a mention, and an actual proposal to use
this in a serious network would require significant elaboration.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, January 29, 2002 9:05 AM
> To: Flemming Andreasen; Jonathan Rosenberg
> Cc: Christian Huitema; Juha Heinanen; [email-masked]
> Subject: Signing RPIDS (Was: Re: [Sipping] calling number blocking at
> sip/isup gateway)
> 
> 
> On Monday 28 January 2002 03:21 pm, Flemming Andreasen wrote:
> > In an almost two year old version of the draft, we had the 
> ability to
> > sign the Remote-Party-ID (rather than just having the "screen"
> > parameter), however,  it was subsequently pointed out that it was
> > subject to cut-and-past attacks as you mention, and that it really
> > was part of a much larger SIP security problem that should be solved
> > instead.
> 
> The problem is that the ability to use the RPID as an "introduced by" 
> token is contingent on being able to sign it, as well as context 
> associate it with the session being introduced. Hashing in To, From, 
> cand Call-ID headers provides context (which I believe was covered in 
> the two-year-old draft). The traditional mechanism for 
> bounding replays 
> is to apply temporal information.
> 
> I believe Michael objected to temmporizing the signing in 
> that earlier 
> draft because of the deifficulty of clock synchronization and of 
> describing durations.
> 
> However, I think that it might be worth considering what COULD be 
> gained from a time-stamped RPID signature. While one might 
> not wish to 
> use the resultant programatically as a final authenticator, the 
> information might still be useful in making a HUMAN-scale 
> interpretation of the RPID.
> 
> Opinions?
> 
> --
> Dean Willis
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP