Re: [Sip] draft-state-sip-relay-attack-00

["Nils Ohlmeier" <[e-mail]>]

>> >>> - 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