[Sip] Re: Identity after reinvite

[Paul Kyzivat <[e-mail]>]

Jon,

I generally agree with what you say. I wasn't trying to suggest that we 
hold up identity for connected-party support. I just wanted to get a 
clear understanding of the issues remaining. It seems that they are a 
bit more than just not getting confirmation of who you connected to.

	Paul

Peterson, Jon wrote:
> 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