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

[William Marshall <[e-mail]>]

Robert Sparks wrote in part:
> I _don't_ believe we need to block REFER on the output of the
> security team work, as long as we leave the plumbing Referred-By
> gives us.

Agreed that this is the key point.  

REFER depends on bis.  Bis depends on the output of the security 
team work.  So effectively, it already is.

If the security team determines that additional mechanisms are
needed in SIP, then definitions would be added to the bis draft.
If additional mechanisms are needed to support REFER, they need
a place.

What I'm really asking is that any additional mechanisms needed
to support security of REFER be added to the refer draft.  In
terms of procedures, I think this means the last call period for
draft-ietf-sip-refer-02 needs to be extended until the security
team has finished their work and determined whether sufficient
mechanisms exists or whether additional mechanisms need to be
defined.

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: Fri, 28 Dec 2001 14:15:53 -0500


> -----Original Message-----
> From: William Marshall [mailto:[e-mail]]
> Sent: Friday, December 28, 2001 12:18 PM
> To: [e-mail]
> Subject: RE: [Sip] SIP WG - 5 - Last Call Open Discussion -
> draft-ietf-sip-refer-02.txt
> 
> 
> 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".
> 

Well, you don't see it because its not there yet.
This was what was being discussed at the SIPPING meeting -
the transfer draft is going to have to discuss securing Transfer
and add some more example cases before we can push it up.

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

Protection from malicious REFER should be achieved through the same
mechanism that protection from malicious INVITE/reINVITEs is achieved,
and the REFER draft is not the place to specify that. 

Protection from malicious Referred-By header values is the only thing
that could be discussed in the REFER draft, and please remember that
at one point, the draft _did_ provide one concrete mechanism (using a
PGP-based signature scheme). The group directed me to pull that out,
leaving the syntactic-components that would allow a generalized approach
to be used once it was specified. What I think your question boils down
to is "Is it ok to advance REFER before that generalized approach has
been specified?". Sufficient plumbing is in place to use that approach
whenever it becomes available (and other future approaches that may come
around).

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

That's not necessarily the full scope of the kinds of mechanisms
the transfer draft could discuss. The full range of candidates for
security mechanisms could be brought to bear, from policy based on
presence of secured transport to pushing around S/MIME bodies based
on public keys. And this gets to the variant of the question above
"Is it ok to run ahead of the security subteam and specify some
 form of security usage in the Transfer draft, or do we block
 Transfer on their output?"

I think those two questions are framed correctly - in particular,
I _don't_ believe we need to block REFER on the output of the
security team work, as long as we leave the plumbing Referred-By
gives us.

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

_______________________________________________
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