Subject: [dispatch] New I-D: Referencing and Validating User Attributes for SIP

From: Kumiko Ono <[email-masked]>
Date: Thu, 20 Oct 2011 22:26:23 -0400

Hi all,

We've just submitted an I-D which proposes a simple mechanism for 
referencing and validating user attributes in SIP communication.
You'll find the html version at 
http://tools.ietf.org/html/draft-ono-dispatch-attribute-validation-00 .

We're trying to see whether there is sufficient community interest in 
this work at DISPATCH or related WGs.

Your interest, comments, and other feedback are appreciated.

Thanks,
Kumiko

-----------
From: [email-masked]
To: [email-masked]
Reply-to: [email-masked]
Subject: I-D Action: draft-ono-dispatch-attribute-validation-00.txt
X-RSN: 1/0/935/39411/42796

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

Title : Referencing and Validating User Attributes
Author(s) : Kumiko Ono Henning Schulzrinne
Filename : draft-ono-dispatch-attribute-validation-00.txt
Pages : 21
Date : 2011-10-20

This document describes a mechanism for referencing and validating
user attributes in SIP communication. User attributes, such as an
organizational affiliation and role, are helpful for the recipients
of a communication request to decide whether or not to grant the
sender access to the recipient's resources, especially when the
sender identity is unknown to the recipients. This mechanism allows
the sender to claim her attributes to recipients using an attribute
reference identifier without needing to prove the sender identity.
This document defines a new SIP "Sender-References" header field to
convey one or more attribute reference identifiers. This mechanism
satisfies all the requirements for trait-based authorization defined
in RFC 4484, except that it provides only one assertion scheme.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ono-dispatch-attribute-validation-00.txt 

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ono-dispatch-attribute-validation-00.txt 

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 21 Oct 2011 13:41:08 -0400

The problem is interesting, but the draft needs some improvement.

First, there is a problem of terminology.  The term "contact address"
is used in many places.  I think the meaning is what in SIP we would
call "recipient's AOR", whereas in SIP, the term "Contact address"
means the address in the Contact header, which is a transient address.

There is also the term "caller ID", which is a term I've not heard
used in a SIP context.  I think you mean the "From URI" of the
message.

It looks like the ARID contains the caller's identity and the
recipient's AOR, but nothing binding it to the specific dialog.  The
recipeint can steal the ARID, but can only use it to call one of the
recipeint AORs in the ARID.  This isn't a threat if the AOR is that of
an individual, but is if the AOR is an organizational role (e.g.,
<sip:[email-masked]>, or if there are multiple AORs.

That threat could be reduced if the ARID was bound to a nonce provided
by the recipient of the call.  The to-tag of a 1xx response (sent
reliably) would be a good choice for the nonce.  The ARID could then
be sent in an UPDATE.  That approach does require the caller to have
real-time access to the AVS while the call is "ringing", but this
mechanism requires real-time access to the AVS already.

Dale

---

From: Michael Hammer <[email-masked]>
Date: Fri, 21 Oct 2011 14:10:03 -0400

Dale,

>From header???  for caller ID?
That is not so trustworthy.
Would the P-Asserted-ID be better?

Mike

On Fri, Oct 21, 2011 at 1:41 PM, Worley, Dale R (Dale) <[email-masked]>wrote:

> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Kumiko Ono <[email-masked]>
Date: Fri, 21 Oct 2011 17:10:09 -0400

Hi Dale,

Thanks for your interest.

> used in a SIP context.  I think you mean the "From URI" of the

I used both terms "contact address" and "caller ID" as generic terms.
A user's contact address in SIP is an AOR to be used to reach the user. 
The caller ID is a URI found in the From or P-Asserted-Identity header.
To avoid confusion, I'll clarify/fix these terms in the next version.

> recipient's AOR, but nothing binding it to the specific dialog.

The ARID is generated by encoding the caller's identity issued in an 
organization, the recipient's AOR, and the timestamp. But as you pointed 
out, there is no tight binding to the specific dialog.

> The

That's a good point. Forwarding attacks among legitimate recipients 
involved in the same dialog is possible. However, it would happen only 
when a dialog has multiple recipients using a forking 
proxy/conference/list service/PBX service, despite the caller's intention.

Although your suggestion below could make this mechanism more secure, I 
don't think the UAC can receive all 1xx responses sent from the 
recipients. Thus, we rather rely on limiting the ARID's lifetime to 
mitigate the damage from such attacks. Additionally, although there is a 
trade-off between service applicability and security, we can limit the 
number of times an ARID can be used to one.

Thanks,
Kumiko

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 22 Oct 2011 13:40:48 -0400

Dale,

also my thanks for your comments. Some quick remarks inline below, mainly asking for clarification.

On Oct 21, 2011, at 5:10 PM, Kumiko Ono wrote:

> The ARID is generated by encoding the caller's identity issued in an organization, the recipient's AOR, and the timestamp. But as you pointed out, there is no tight binding to the specific dialog.

I'm curious what the advantage of such a binding would be. My concern is that B2BUAs may destroy end-to-end dialog continuity, so that this would make the mechanism less likely to work in practice.

>> <sip:[email-masked]>, or if there are multiple AORs.

What would you see as the threat in that model? If I address a call to customer-service, I presumably trust any agent of that designation to obtain my credentials. After all, even a standard residential phone number resolves to multiple devices and people (members of the family).

> 
> That's a good point. Forwarding attacks among legitimate recipients involved in the same dialog is possible. However, it would happen only when a dialog has multiple recipients using a forking proxy/conference/list service/PBX service, despite the caller's intention.
> 
> Although your suggestion below could make this mechanism more secure, I don't think the UAC can receive all 1xx responses sent from the recipients. Thus, we rather rely on limiting the ARID's lifetime to mitigate the damage from such attacks. Additionally, although there is a trade-off between service applicability and security, we can limit the number of times an ARID can be used to one.
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 24 Oct 2011 16:04:00 -0400

> From: Henning Schulzrinne [[email-masked]]
> 
> > organization, the recipient's AOR, and the timestamp. But as you
> > pointed out, there is no tight binding to the specific dialog.
> 
> I'm curious what the advantage of such a binding would be. My concern
> is that B2BUAs may destroy end-to-end dialog continuity, so that this
> would make the mechanism less likely to work in practice.

I haven't spent nearly enough time to fully digest the security
implications of ARID (and I'm not likely to), but initially I am
highly suspect of any authentication mehcanism that is not bound to
the dialog which is being authenticated.

> What would you see as the threat in that model? If I address a call to
> customer-service, I presumably trust any agent of that designation to
> obtain my credentials. After all, even a standard residential phone
> number resolves to multiple devices and people (members of the
> family).

If I address a call to customer-service, I do *not* trust an agent of
the organization to be able to call the organization's
customer-service line *pretending to be me*.

Dale