Subject: [Sip-security] FW: [Sip] review of draft-ietf-sip-refer-02

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Nov 2001 13:05:29 -0500

Recall that REFER had a mechanism for passing credentials from
the referor to the refer target that were pulled in favor of 
the common mechanisms this design team kicked out. As you can see,
I'm getting pressure to put _something_ back into the REFER draft.
(There have been more empassioned outcries against the use of
 REFER in 3GPP reported on the sipping list, because it is 
 perceived to be dangerous without some form of auth{entic|oriz)ation.

Are these common mechanisms going to spring into existance soon?
Does anyone have a roadmap for the output of this team in their
head?

RjS

-----Original Message-----
From: Miguel A. Garcia [mailto:[email-masked]]
Sent: Friday, November 16, 2001 8:13 AM
To: William Marshall
Cc: [email-masked]
Subject: Re: [Sip] review of draft-ietf-sip-refer-02

Hi Bill:

See my comments below.

William Marshall wrote:
[snip]
> 
> (3) security
> The security section is correct in the second paragraph that anyone
> can issue a request claiming that they were referred to that resource
> by an arbitrary third party.  I think the refer draft should get the
> level of security at least as high as general SIP, so that the final UAS
> can reasonably restrict access to itself.
> 
> Has 3GPP accepted REFER as the way to implement call transfer?  Security
> was a huge consideration when my proposal to use REFER in 3G was initially
> rejected last May.  My suspicion is that without a "reasonable" security
> mechanism (like comparable to HTTP digest authentication, a sufficiently
> low threshold to meet), no service provider will allow REFER.

3GPP has flows based on the REFER, but they are in stand-by, in the annex
of the specification, waiting to have a wider acceptance and to resolve
the security issues that you point out.

> 
> While a mechanism to protect header integrity is sorely needed in SIP,
> I don't believe it will solve the problems of REFER.  The UAS would
> want to authenticate the referrer (UA that initiated the REFER), not just
> the UA that initiated the refer-requested INVITE.
> 
> Consider the following as a strawman proposal:
> 
>   Agent A                Agent B                 Agent C
>      |                      |                      |
>      |---REFER------------->|                      |
>      |<--202 Accepted-------|                      |
>      |                      |---INVITE------------>|
>      |                      |<--4xx Ref Auth-(*1)--|
>      |<--NOTIFY (w/4xx)-----|---ACK--------------->|
>      |---200 OK------------>|                      |
>      |                      |                      |
>      |---REFER-(w/Auth,*2)->|                      |
>      |<--202 Accepted-------|                      |
>      |                      |---INVITE-(w/Auth)--->|
>      |                      |<--200 OK-------------|
>      |<--NOTIFY (w/200)-----|---ACK--------------->|
>      |---200 OK------------>|                      |
>      |                      |                      |
> 
> Agent C, (*1) responds to the INVITE with a Referred-By header by a new
4xx
> response code, requesting authentication by the Referred-By-entity.
> Agent C provides a challenge.  This information is passed back to Agent
> A in the NOTIFY; more than just the 4xx response code is in this
> message/sipfrag.
> 
> Agent A then re-issues the REFER with the proper authentication (*2)
> response.  This authentication information is included in the INVITE
> sent by Agent B to Agent C, who then accepts the request.
> 
> Can this use the existing "Authentication-Info" and "Authorization"
headers?
> If so, how does Agent B know whether to answer the authorization request,
> or pass it back to Agent A?  A new 4xx response code could help, but what
> if Agent C also wanted to authenticate Agent B?  Perhaps new headers
> are required for this. If so, they would seem to be REFER-specific, and
> should be included in this draft instead of in a general security
> principles and procedures document.

I agree with you that some sort of authentication mechanism is desirable.
However I think that the problem is difficult to solve. In your example,
does it mean that A and C must share some secret key in order to
authenticate
each other? 

If the answer is yes, I don't think the mechanism is valid, because it 
implies a heavy key management scheme between agents A and C in your 
example. Or are you thinking of something completely different.

/Miguel

> Bill Marshall
> [email-masked]
> 
> _______________________________________________
> Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments on the application of sip

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[email-masked]     Phone:  +358 9 299 3553
mailto:[email-masked]        Mobile: +358 40 5140002

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

_______________________________________________
Sip-security mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/sip-security