Subject: RE: REFER and third party authorization (was: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt)

From: Robert Sparks <[email-masked]>
Date: Wed, 2 Jan 2002 15:29:19 -0500

> From: Michael Thomas [mailto:[email-masked]]
> 
> 
> My tenous understanding of REFER got a bit better
> after reading Robert's cc-transfer draft. I
> believe that what we are witnessing here is
> perhaps a new twist on an old requirement for SIP
> security. That is, we'd like to have the ability
> for a trusted third party vouch for somebody (eg
> the screener vouches for the caller) which needs
> to be transported across sessions. I say twist
> because we already have a requirement via
> remote-party-id that we must be able to provide a
> means for the voucher to prove their identity.
> What is missing is a companion requirement that
> that identity may also be cut from one SIP message
> and pasted into another, which is essentially what
> referred-by needs (eg, the screener needs to send
> something to the caller which the callee can
> determine was legitimately created by the
> screener).

Be careful with this model - it is only one instance
of the Tranferor/Transferee/Transfer-Target relationships.
Transfer will be used in other scenarios besides screening.

> 
> There are obvious replay issues here since we do
> not want to create an immortal authorization blob,
> so there needs to be some means of placing a
> lifetime, or some other means. I think we could
> deal with this in a crypto-system dependent manner
> though (eg, each style of crypto system needs to
> address this requirement in some way).
> 
> My suspicion is that Referred-by is just one
> instance of a larger desire to have trusted third
> party authorization, thus it would probably be
> prudent to generalize this beyond just referred-by
> to anything which would like to assert identity
> and authorization for a third party. Maybe a
> better name, in fact, would be "approved-by" since
> that's really what the screener seems to be doing.

I follow your point for the screener case, and I think
it generalizes, but there are traps in this name-game
to watch out for - "approval" (authorization) is a
function of more than one participant/set of policies
in the general case.

Here's what I see the system needing to support 
when A REFERs B to C given the model we've been working
with to date (assume the REFERence is for
a SIP INVITE).

*) B needs to Authenticate A (should be baseline SIP)
*) C needs to Authenticate B (should be baseline SIP)
*) B must prove to C two things: (this is what's new)
   1) This is the request B was asked to make
   2) The identity of the originator of the REFER was A

The original proposal had A hand B a blob that B forwarded
to C. This blob contained the essential properties of the
triggered request, a timestamp and was signed (PGP at the time)
by A. C got the two proofs it needed when B included the blob
in the request. Is this the kind of thing you mean when you
say 3rd party authorization? 

> 
> A few more comments inline:
> 
> William Marshall writes:
>  > Mike Thomas wrote, in part: (complete message quoted below)
>  > > 		 We currently don't have a way to
>  > > authenticate RPI either, and though we intend to
>  > > get around to fixing that eventually, it doesn't
>  > > seem to be a burning need. 
>  > 
>  > Agreed that it is not done in the general case, but is
>  > done for a large number of useful cases -- with a trusted
>  > proxy forwarding requests to the UAS over TLS/IPsec and the
>  > UAS accepting only requests from this trusted proxy.  Requests
>  > that come over other connections can be appropriately flagged
>  > by the UAS, or rejected.  Sufficient mechanism exists today
>  > to do this.
> 
> I'm not sure I find this persuasive. RPI depends
> on a particular model and a whole set of
> assumptions, namely that the only ones who
> participate are service providers who all trust
> each other (at least on this account). This is an
> acceptible assumption in the current PSTN, but
> given how easy it is go around the service
> provider with SIP, I'm not sure I'd count on RPI
> or anything else being especially trustworthy that
> depends on transitive trust. An analogous
> situation is with source spoofed IP addresses: we
> want operators to perform RPF checks to make it
> harder, but it you really, really care on the
> server end, you better not count on it.
> 
> The upside, however, is that I think we can do a
> pretty decent job -- possibly including a weak
> test -- for both RPI and referred-by in a
> generalized SIP security solution.
> 
>  > I assume there is sufficient mechanism defined in bis-05 to do SIP 
>  > security and what is missing is the recommendations on 
> what mechanisms 
>  > or combination of mechanisms should be used to achieve a 
> secure system 
>  > (and it is important for the SIP security group to validate this 
>  > assumption prior to publication of bis).
> 
> I don't think there is any way to do a "secure"
> job of either RPI or Referred-by with bis.
> 
>  > My main concern is that there is not enough mechanism 
> defined in the 
>  > refer draft to do the job.  There is no mechamism defined 
> for the recipient
>  > of an INVITE-containing-Referred-By to get any credentials from
>  > the party that initiated the REFER.  It can't send a 401/407,
>  > because that only goes back to the party that initiated the
>  > INVITE-containing-Referred-By.  So there is a tool missing from
>  > the toolkit, and that is the troubling part.
> 
> Yes, but I think that what is missing is just
> a variation on the general tool we need.

Just to make sure we're all on the same page:

Bill is asking for an interactive proof between A and C (challenge
based credentialling), something the original proposal for REFER
didn't support - it only allowed static proofs. Are you suggesting
a 3rd-party auth/auth mechanism that would allow this to be interactive
or are you claiming that static proofs are sufficient?

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