>> >>> - I never unterstood why a proxy should pass through the >> authentication >> >>> request from a foreign domain. >> >> Because this is how it is specified in section 22.3 of RFC3261. >> > >> > And it would have to continue to do so. There are actual use-cases >> for >> this. >> >> Could you please share one of these use-cases with me. > > Well, the 3GPP roaming case, for one. > A pictorial version: http://www.tech-invite.com/Ti-ims-regflow-1.html
Well you are right, I was just thinking about the "typical" proxy/registrar combination. But there are outbound or travesering proxyies which don't do authentication at all. To stay at your 3GPP romain case: I don't think this attack would be possible if the S-CSCF does not pass through "unknown" auth requests. Right? The P-CSCF has to forward REGISTERs to non-local S-CSCF which then will authenticate the registration with "unknown"/non-local realms. But as soon as the UA is registered the P-CSCF should only accept terminating INVITE requests for that UA from the S-CSCF where the user is registered to. And again the S-CSCF of the user/UA has in my opinion no need to forward "foreign" authentication requests, or?! BTW as you pointed out already earlier debating this attack for IMS is only hypothetical, because IMS allows calls only from registered UAs. And from a more general perspective: I believe that such a transitive proxy which does not do authentication by himself should only accept auth requests from the serving/registrar proxy (or however you call the element which does the authentication part). Furthermore this transitive proxy should not allow dialogs over "just transitive proxys" (which have now clue about authentication) only (because that would allow the attacker again to send a challenge). >> > I think there's even a reasonable use-case for challenging in-dialog >> requests: connected-identity, for example. >> > >> > But you don't even need to challenge in-dialog requests for this form >> of >> attack: if the victim calls you, then you can challenge the initial >> INVITE. >> >> Sorry, but how is this going to work in world without a SBC which knows >> my credentials? > > SBC's don't usually know your credentials, even now. They don't need to. > > But anyway, I'm not sure what you mean by the question. How is what going > to work? Stopping INVITE-based authentication relay-attacks? You don't > need an SBC-type box to stop that. Just disconnect the cable. :) > Or, use the counter-measures in the draft. Or change the protocol, or at > least the authentication mechanism. My fault. I mis-read your original point. Cheers Nils _______________________________________________ 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
