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

From: William Marshall <[email-masked]>
Date: Wed, 2 Jan 2002 07:49:58 -0500 (EST)

Mike Thomas wrote, in part: (complete message quoted below)
> 		...	I wonder whether
> there's anything *really* serious that could be
> abused here. It seems to me that it might be able
> defeat screening, but how serious a problem is
> that?

Opinions differ on how serious something is before it
is *really* serious.  From a service-provider perspective,
being unable to effectively screen calls to a company's
CEO will likely result in loss of the contract, and that
is *really* serious.

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

> 			Also: is this something
> that really needs to be dealt with by the refer
> draft? Could it, say, be dealt with as a
> requirement for SIP security?

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

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.

Bill Marshall
[email-masked]

-----original message-----
From: Michael Thomas <[email-masked]>
To: William Marshall <[email-masked]>
Cc: [email-masked]
Subject: Re: [Sip] SIP WG - 5 - Last Call Open Discussion - draft-ietf-sip-refer-02.txt

William Marshall writes:
 > 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.

Bill,

Are there real life threats which would cause C to
act in a harmful manner? I mean, I understand the
potential for attack, but I guess I wonder whether
there's anything *really* serious that could be
abused here. It seems to me that it might be able
defeat screening, but how serious a problem is
that? 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. Also: is this something
that really needs to be dealt with by the refer
draft? Could it, say, be dealt with as a
requirement for SIP security?

		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

---

From: Michael Thomas <[email-masked]>
Date: Wed, 2 Jan 2002 11:51:25 -0800 (PST)

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

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.

A few more comments inline:

 > by the UAS, or rejected.  Sufficient mechanism exists today

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.

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

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

	    Mike

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 2 Jan 2002 14:29:06 -0600

I believe Michael has squarely impacted the driving surface of the piercing
metallic friction fastener, forcing into the visible tip of the iceberg
pointed about by Bill . . .

There is indeed a general problem to be solved in third-party approval. It
applies to referrals, transitive gateway authorizations (call me at this
gateway using these credentials), idenitification vouching,  media
authorization, operator services, and so on. There is probably some
applicability to privacy, especially in the authority-to-override
department. It could probably also apply in two-party (auth and auth) cases.

The requirements as I see it are:

1) Describe the approving distinguished entity.
2) Describe precisely what is being approved (and maintain the integrity of
that information).
3) Describe for what duration the approval persists.
4) Provide for verification of the approval.
5) Prevent replay of the approval.
6) Seperability from the underlying cryptographic model(s).

Is this a tractable problem?

I can envision tackling it using a certificate model, and some sort of
element-signing mechanism, but the result is likely to be bulky. It also
begins to sound much like xml-signing . . .

--
Dean

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
. . . >