[Sip] RE: Identity after reinvite

["Peterson, Jon" <[e-mail]>]

Well, yes, now one begins to appreciate why we originally coupled the
request identity problem with the response identity problem. :)

In the next revision of the identity draft, which will incorporate the list
comments up to date, I do intend to include some text about dialogs. I agree
that the draft should apply to requests regardless of the dialog context.

Moreover, I don't think the problem you raise below is limited merely to
re-INVITEs within a dialog. I believe it applies equally to BYE requests
sent in the backwards direction in a dialog. Ideally, the originator of the
dialog should have some assurance that requests sent in the backwards
direction come from the same identity that positively responded to the
dialog (i.e., the sender of the 200 and any provisional responses).

In the absence of response identity, though, it is difficult for Alice to
have any such assurance. Equally, as you point out below, Bob can have no
assurance that his BYE or re-INVITE has been fielded by Alice if he is
unable to get a cryptographically-assured 200 response to his own requests.
Alice can't even be certain that she actually connected to Bob, thanks to
retargeting; this is the essence of the connected-ID/response identity
problem, and threatens to drag us back into the morass of retargeting
restrictions and so on that populated the sip-identity-02 draft.

A lack of such a strong binding of backwards-direction BYE requests to the
dialog is a significant limitation; if BYE can be spoofed, then an attacker
can terminate existing dialogs. However, I'm not sure that the situation is
so dire as you suggest below. Without identity, it is trivial for any
attacker to impersonate a dialog-forming request. It is harder, though, for
an attacker to impersonate a response or mid-dialog request; this requires
the attacker to gather dialog state through eavesdropping or some similar
means. There is a very important distinction in sophistication between an
attacker who can merely formulate a plausible dialog-forming request with an
inappropriate From header field versus an attacker who can capture
dialog-forming requests and improvise appropriate responses (with correct
tags, correct Call-ID/CSeq, etc).

Ultimately, request identity can protect against the former but not the
latter. While it is imperfect, I feel that this is an improvement over the
current situation. In cases where retargeting has not occurred, Alice will
see a re-INVITE or BYE from the expected URI (blessed, as you say); in cases
where retargeting has occurred, Alice may receive a warning from her UI that
an unexpected but assured URI has responded. Likewise, Bob will have to
trust, given the signature over the Contact header field in the
dialog-forming INVITE request, that his request in the backwards direction
is forwarded to the appropriate UA instance. In terms of what Bob's UI
should display, well, that really depends on the sophistication of attacks
you are willing to consider plausible. Personally, I don't think Bob's UI
should suggest any uncertainty about the matter.

To improve on all this, we will ultimately need to solve the response
identity problem; however, I maintain that sip-identity as it stands will
have addressed the simplest and most common variety of impersonation, the
one that does not require any eavesdropping whatsoever. Once we feel we have
the right answer to request identity, we can revisit the response identity
problem and try to eliminate the remaining attacks.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[e-mail]]
> Sent: Monday, November 15, 2004 3:58 PM
> To: Peterson, Jon; Cullen Jennings; [e-mail]
> Subject: Identity after reinvite
> 
> 
> Jon,
> 
> After the meetings last week a question came to mind re the 
> identity draft.
> 
> First, I want to double check on usage in dialogs. The draft doesn't 
> say, but I presume that every message in a dialog needs to be signed, 
> not just the one that initiates a dialog. If that is a bad assumption, 
> it would be good to hear why.
> 
> Assuming that, what happens when the initial invite was from Alice to 
> Bob, and later a reinvite is sent from Bob to Alice? Initially Bob knew 
> that Alice had called, while Alice had no assurance about who she had 
> reached with her call. The reinvite is from Bob, so if his identity is 
> blessed, then Alice will know she is talking to Bob, but Bob will no 
> longer have any assurance that he is still talking to Alice.
> 
> This could even manifest itself in the UI presented to Alice and Bob. 
> Initially Bob would have a "callerid" display showing Alice as a 
> certified caller. But after putting Alice on hold and back off hold the 
> display might stop showing Alice, or at least might show the identity as 
> suspect. (There may be strong temptations to avoid this via some sort of 
> hack.)
> 
> I don't see any good solution for this other than solving the connected 
> party id problem as well.
> 
> 	Just checking my understanding,
> 	Paul
> 

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