John, >So don'tlet the absence of success with this discourage you from submitting >other ideas.
I beg to differ. In an Internet environment or in SIP VoIP networks that have little PSTN heritage constraints and/or long chains of interemediaries, Derive is very useful. I would suggest therefore Derive to be published as an informational RFC and to state in what type of networks it is most effective. Thanks, Henry On 11/21/08 5:16 AM, "Elwell, John" <[EMAIL PROTECTED]> wrote: Jiri, Well, you could argue that P-Asserted-Identity is btn security - you simply have to trust the chain of SIP intermediaries without having visibility of who exactly is in that chain. I am not convinced that DERIVE, either in its current documented form or taking into account the many helpful suggestions during the last couple of weeks, can really claim to add very much. The fact that the mechanism can yield a significant number of "false positives" (or perhaps "false negatives" is the right term) means the mechanism, as it stands, fails to provide a safe means by which I can decline or ignore calls I don't want, or send them to voicemail if I don't want them right now. I think this limits its applicability. One particularly appealing aspect of DERIVE as documented is that it tries to avoid special behaviour at the calling side, as noted during the meeting. So I would still appreciate any further ideas that have this same property. I appreciate your efforts on this and, believe me, I really want to explore all possible ideas for solving this identity problem. So don't let the absence of success with this discourage you from submitting other ideas. John > -----Original Message----- > From: Jiri Kuthan [mailto:[EMAIL PROTECTED] > Sent: 20 November 2008 14:28 > To: Elwell, John > Cc: IETF SIP List > Subject: Re: [Sip] Another possible limitation of DERIVE > > Hi John > > actually I think this concern has been indirectly articulated -- IMO, > it falls in the better-than-nothing category: any man-in-the-middle > including those who are legitimately in the path (sitting on > DNS servers, > sitting on proxy servers) can provide misleading assertions. > > A "honest B2BUA" should here IMO really not answer with 200 until it > propagated the DERIVE test to the other side, unless it has the > knowledge of DERIVE test. (say by having it completed on its own) > > The key point is however, that we just can't neither prevent nor > detect man-in-the-middle misconduct with better-than-nothing security. > If a B2BUA decides to play dishonestly (in addition to "mechanical" > side-effects such as destroyed callid, which we may possible fix), > we can neither prevent nor detect it with better-than-nothing > security. > > Which I think turns us to the DERIVE question: are we interested > in better than nothing security? > > -jiri > > Elwell, John wrote: > > Suppose, for the sake of argument, we go with Hadriel's draft and > > OPTIONS, e.g., global call ID in INVITE request, sent back > in OPTIONS > > request with global call ID to URI obtained from receive From. > > > > Now suppose the initial From URI is > sip:[EMAIL PROTECTED];user=phone > > and this gets modified by callee's service provider to > > sip:[EMAIL PROTECTED];user=phone. Callee UA sends OPTIONS > request to the > > latter URI. B2BUA in sp.net acts as UAS for the OPTIONS request and > > returns 200 OK, on basis that it recognises the global call ID. What > > does this give me? Basically that the call arrived via my service > > provider, which I know anyway if it arrives over a TLS > connection for > > which I have authenticated the service provider. The > problem is, I don't > > know that sp.net has terminated the OPTIONS request. Even > if the service > > provider has not acted in this way and the OPTIONS request > has gone all > > the way back to the caller UA (or at least to its domain > proxy/B2BUA), I > > have no evidence that this is so. > > > > Now contrast this with RFC 4474. With RFC 4474, sp.net can > change the > > URI as above and re-sign (insert a new Identity header > field). At least > > my UA can see that the only guarantee I have is that the > call arrived > > via sp.net. > > On the other hand, if sp.net has not intervened in this way > > I can see where the call has really come from (subject to B2BUAs not > > breaking the signature). > > In attempt to make your point a bit "compressed" -- the > concern is that > someone along the path is answering on the end party behalf, right? > > In which case the answers above would relate: with better-than-nothing > security we really neither can detect nor prevent MitM providing > misleading answers. IF a B2BUA decides to lie, pretend, answer without > knowing, etc., we can't do anything about it. IF a domain (as > identified > by its DNS name) decides to deploy such a vehicle, it is its choice. > (probably not best for its reputation) > > > In other words, RFC 4474 tells me who is > > asserting that it sent the INVITE request, whereas DERIVE > just tells me > > that someone is asserting that it sent the INVITE request. > > A way to see it is in both cases the DNS domain owners are > the verification > instance, that provide some assertions using the vehicles they have. > With 4474 you additionally know that the DNS domain owner is > really him > on the grounds of the trust relationship you established with > a CA. Both > mechanisms can provide you with misleading assertions about the URI > (username can be lied-unverified-whatever, or the whole From > could have > been completely different before signing). IMO the added value 4474 > gives you > is a trusted party assertion that you are blaming the right > DNS owner > for not > playing fair about From HF. > > -jiri > > > > > John > > > > _______________________________________________ > > Sip mailing list https://www.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use [EMAIL PROTECTED] for questions on current sip > > Use [EMAIL PROTECTED] for new developments on the application of sip > > > _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
