RE: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt

[William Marshall <[e-mail]>]

Robert Sparks wrote, in part:
> 			... The current proposal
> is to leave REFER as is, and specify usage of the parameters available
> on the Referred-By header to get exactly the protection you describe for
> the transfer application. 

I've looked through draft-ietf-sip-cc-transfer-05 again, and don't see
it.  What I see in the transfer draft is more of a "transferree/
transfer-target just do exactly as they are told, don't question
anything, and it will work".

The transferee and transfer target need some way to protect themselves
from malicious REFER requests, and from malicious INVITES that contain
Referred-By values.  I'm afraid that if the restricted usage is
documented in the transfer draft, then deployed implementations
will accept ONLY the combinations of parameters given in the transfer 
draft, effectively cutting off new and different services.  I feel
a generic method is needed in the refer draft that achieves some level 
of  protection against bogus and replayed requests, which can then
be used (at the recipient's option) in all the flows appearing in
call-control drafts.

If the usage restrictions were to be included in the transfer draft,
they would be something like: accept a REFER only within an active
dialog; accept an INVITE with a Replaces header only if the Call-ID
in the Replaces header matches an active dialog and the Referred-by
header matches either From or To of the same dialog, etc.  But
these kind of restrictions kill the blind transfer case (6.1).
But the transfer-target needs to know that the INVITE in step 9 is 
not a replay of an ancient REFER (step 7).  If all the flows in
the transfer draft were to be allowed, there would be no restrictions
at all.  Hardly a workable end state.

Bill Marshall
[e-mail]

-----original message-----
From: Robert Sparks <[e-mail]>
To: "'William Marshall'" <[e-mail]>, [e-mail]
Subject: RE: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip
	-refer-02.txt
Date: Thu, 27 Dec 2001 16:05:04 -0500


> -----Original Message-----
> From: William Marshall [mailto:[e-mail]]
> Sent: Thursday, December 27, 2001 10:50 AM
> To: [e-mail]
> Subject: Re: [Sip] SIP WG - 5 - Last Call Open Discussion -
> draft-ietf-sip-refer-02.txt
> 
> 
> I don't believe there has been any conclusion posted about security
> aspects of the Referred-By header, which I raised as issues in my
> initial review of this draft.
> 
> Without an adequate mechanism to verify the information in 
> the Referred-By
> header, and to verify the timeliness of that information, the 
> header is
> worse than useless.  It should be removed from the draft.
> 
> To repeat the problem, consider three parties, A, B, and C, where
> A sends a REFER to B, causing B to send an INVITE to C.  Procedures
> exist whereby B can authenticate A; procedures also exist whereby
> C can authenticate B.  
> 
> However, nothing prevents B from including a bogus Referred-By header 
> in its INVITE request to C.  Nothing prevents B from including a
> previously-valid-but-expired Referred-By header in its INVITE (i.e. 
> a form of replay attack).  Anything done by C based on information
> in the Referred-By header may be incorrect or harmful.

Anything done by C based on information in the Referred-By header
would be determined by the application using the primative. The first
application we're talking about is Transfer. The current proposal
is to leave REFER as is, and specify usage of the parameters available
on the Referred-By header to get exactly the protection you describe for
the transfer application. 

Are you objecting to this approach? If we actually remove the header,
we will be left without a conduit between the REFER and the triggered
action to include such procection mechanisms...

RjS

_______________________________________________
Sip mailing list  http://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