Subject: [Sip] Poll: expert review of draft-garcia-sip-associated-uri

From: "Dean Willis" <[email-masked]>
Date: Fri, 24 May 2002 14:27:32 -0500

I'd like to request feedback on the expert review of
draft-garcia-sip-associated URI:

Option:

   Yeah
   Nay
   Or Needs More Work

And of course, details on what and why . . .

Anybody out there have a Strong Opinion One Way or Another?

Thanks,

--
Dean Willis

_______________________________________________
Sip mailing list  https://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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 03:06:04 -0400

> draft-garcia-sip-associated URI:

I think the draft is generally OK, but needs a bit more work. My main
area of concern is the applicability statement. It really just repeats
the semantics of the header. Really, the scope of applicability is more
something like this:

"This specification is applicable in SIP networks where the SIP provider
is attempting to restrict the set of identities that a user can claim
(in headers like the From field) in requests that it generates. It
furthermore assumes that the provider knows the entire set of identities
that a user can legitimately claim, and that the user is willing to
restrict its claimed identities to that set. In normal SIP usage, the
>From field is explicitly an end-user specified field. Effectively, this
specification attempts to make it an end-user-specified and provider
approved field.

This specification also assumes a closed network model. The restriction
of the From field (and other fields) to be among the list of approved
values is enforced by a proxy in the domain of the caller. The
specification provides no way to indicate or verify to downstream
proxies or to the UAS that these fields have been limited in scope. As a
result, this specification will only be useful in closed networks where
elements know through configuration or administration that the fields
have been restricted."

I also think the security considerations section deserves some more
attention. For one thing, I think that the information in this header is
very sensitive. It exposes many additional identities for a user, which
they might not otherwise want to divulge to everyone. For example, if
the URI I register is sip:[email-masked], and everyone also has a valid
URI which is their full name - sip:[email-masked] -
eavesdropping the registrations will allow someone to learn my name. The
draft alludes to this problem in the second paragraph, but it needs to
strengthen the discussion and give specific examples like the one above.

On an unrelated note, I must admit being baffled about why this is
useful in a subscribe response. It seems like the associated URI are
closely related to registrations, not subscriptions.

Some minor points:

1. the syntax does not permit an empty value for the P-Associated-URI.
What happens if there are no associated URI? If you simply omit the
header altogetrher, how does the UA distinguish the case where the
registrar doesn't support the extension, as opposed to the registrar has
no associated URIs?

2. Is there an implicit assumption that the registrar will register the
associated URI? I believe this is true in the 3gpp case. A UA probably
needs to know whether they have been registered or not. I would not want
to put a URI into a Reply-To header unless I knew it was a valid URI for
receiving incoming calls....

3. you write:

> The registrar inserts the P-Associated-URI header into the 200 OK
>    response to a REGISTER request. The header is populated with a list of
>    URIs that are associated to the registered URI.

probably "address-of-record" is better than "registered URI" in the
above.

4. you write:

> populate the From header value, or any other SIP header value that
>    provides information of the identity of the calling party, in a
>    subsequent dialog.

s/subsequent dialog/subsequent request

5. you should probably have an explicit definition of associated URI.

6. you write:

> 5.3 Procedures at the proxy
> 
>    This memo does not define any procedures at the proxy.
> 

Well, presumably some proxy will enforce the list of associated-URI, and
reject requests that have a value in the From field not amongst the
allowed set? Is there a new response code for that?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Tue, 28 May 2002 13:18:19 +0300

Hi Jonathan:

Thanks for your comments. See my answers inline.

> elements know through configuration or administration that the fields

So far so good.

> strengthen the discussion and give specific examples like the one above.

I will add this discussion to the security considerations.

> closely related to registrations, not subscriptions.

And in fact, the only usage in 3GPP is in registrations. But I got
some comments that this may be useful in subscriptions as well. If nobody
shouts, I will remove the usage of the header in subscriptions and restrict
the scope to REGISTER only.

> registrar doesn't support the extension, as opposed to the registrar has

Do we need to make a distinction between both cases? Either case, the
user knows that no other identities are associated by the registrar,
and therefore, explicit actions (e.g., REGISTER) has to be taken by
the UAC.

I am open to include an empty header, if it is needed. But I thought
the consequences at the UAC are the same.

> receiving incoming calls....

No, this is not the case. The "reg" event will provide such information.
But the semantics of this header is just to provide a set of IDs that the
user has associated to the address-of-record. They may or may not be registered,
the user will know this information by other means (subscription to the 
registration event package). The user knows that he can initiate registration
of any of the returned IDs, or it can populate the From with any of those
IDs as well. That's it.

We can clarify this if it is not clear enough.

> probably "address-of-record" is better than "registered URI" in the

Sure.

> s/subsequent dialog/subsequent request

Done.

> 5. you should probably have an explicit definition of associated URI.

yeap. I'll add that.

> allowed set? Is there a new response code for that?

Yes, the proxy will send a 403 Forbidden. However, I don't think this is 
part of the scope of this I-D. I understand that the title "Procedures at
the proxy" are procedures related to the extension (the header in this case).
The idea in this I-D is to convey to the UA the list of URIs that he can use 
in subsequent requests, not how to police them. Therefore, there are not
procedures at the proxy related to the P-Associated-URI header.

Thanks a lot for your comments,

      Miguel

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

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 May 2002 06:31:35 -0700 (PDT)

So, I have a really dumb question. Why don't you
limit the number of assertable identities by
cryptographic means? That is, if I can't prove
that I own an identity binding, it gets dumped
on the floor?

	Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 12:23:21 -0400

> that I own an identity binding, it gets dumped

Sure; I think the issue (Miguel can correct me if I'm wrong), is that
the UA needs to be configured with the set of identities it can claim in
the first place. The same credentials would allow the user to assert any
one of those, but the phone needs to know which it should present to the
user to use.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 12:30:41 -0400

"Miguel A. Garcia" wrote:

> the scope to REGISTER only.

Yes, please. I think we should strive to limit scope for P-headers, not
the other way around. This is especially true when the motivating need
is not even clear.

> and therefore, explicit actions (e.g., REGISTER) has to be taken by

I thought you indicated below that this extension did not imply the
registration of the associated identities...

That aside, it does make a difference. The UA needs to know whether it
can put any identity it likes in the From field (since the network is
not trying to impose restrictions on the set), or whether it can't put
any identity except the one it registered (since the network is imposing
restrictions, and there is just one valid identity). 

> of any of the returned IDs, or it can populate the From with any of

Presumably the UA will need to make sure that they are registered; you
should probably note in the draft that there is no assumption that the
associated URI are registered, and that if the UA wants that, it should
check and perform the registrations if needed.

> procedures at the proxy related to the P-Associated-URI header.

Well, its all intertwined. The associated-URI list is the only way a UA
has to retry if it should get this error, since it conveys the allowed
URI in the first place. Actually, 403 is really NOT the right response.
If it gets this, how does the UA recover? It needs to know that the
problem was a disallowed From value, and it needs to know which ones are
OK. I would argue that the way to deal with this is a new response code
that would contain in it the Associated-URI header indicating which ones
are allowed.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 May 2002 14:23:13 -0500

Miguel said:
> Jonathan said:
> > Well, presumably some proxy will enforce the list of 
> associated-URI, 
> > and reject requests that have a value in the From field not amongst 
> > the allowed set? Is there a new response code for that?
> 
> part of the scope of this I-D. I understand that the title 
> "Procedures at the proxy" are procedures related to the 
> extension (the header in this case). The idea in this I-D is 
> to convey to the UA the list of URIs that he can use 
> in subsequent requests, not how to police them. Therefore, 
> there are not procedures at the proxy related to the 
> P-Associated-URI header.

Actually, this policy enforcement is being made by the
3GPP-specific-back-to-back-user-agent-that-sometimes-acts-kindof-like-a-
proxy called the P-CSCF. Documenting the behavior of this rather
specalized node is probably far outside the scope of an IETF effort.
Proxies, in general, are not expected to restrict the range of identity
expression allowed to a user based on some sort of P-header. In fact,
one might argue that proxies in general are PROHIBITED from doing this
sort of thing . . .

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 May 2002 14:23:13 -0500

> Sure; I think the issue (Miguel can correct me if I'm wrong), 
> is that the UA needs to be configured with the set of 
> identities it can claim in the first place. The same 
> credentials would allow the user to assert any one of those, 
> but the phone needs to know which it should present to the 
> user to use.

It goes a little further than this. We're also informing the UA of a
number of extisting "aliases". The UA can expect to see calls "To:" any
of these aliases, and needs to delivery them appropriately to the user
as direct calls rather than as calls targeted originally to some other
user that have just been forwarded here. This might interact with
distinctive-ringing features, for example.

So there is applicability in both "UA-originated" and UA-terminated"
scenarios, and there is no requirement that the client be able to
cryptographically assert the identity associated with an inbound alias.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 15:31:26 -0400

> one might argue that proxies in general are PROHIBITED from doing this

Well, that enforcement IS being done, and I thought was core to the
entire concept here. Indeed, this is the essence of what I suggested for
the new applicability statement. My point is, if you are doing such
restrictions, you need to have a response code appropriate for this
error case.

I will also note that of all things proxies are doing these days,
rejecting a call because the From is not authorized is the least evil.
Indeed, one might argue that this is equivalent to sip level ingress
address filtering (RFC 2827), and is possibly a very good thing to do.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 28 May 2002 15:31:59 -0400

> distinctive-ringing features, for example.

This isn't documented in the draft either, and needs to be.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 May 2002 16:45:24 -0500

> Well, that enforcement IS being done, and I thought was core 
> to the entire concept here. Indeed, this is the essence of 
> what I suggested for the new applicability statement. My 
> point is, if you are doing such restrictions, you need to 
> have a response code appropriate for this error case.
> 
> I will also note that of all things proxies are doing these 
> days, rejecting a call because the From is not authorized is 
> the least evil. Indeed, one might argue that this is 
> equivalent to sip level ingress address filtering (RFC 2827), 
> and is possibly a very good thing to do.

I'm not saying that proxies can't do ingress filtering, just that
standardizing this behavior based on a P-header seems a  bit iffy from a
"SIP Change Process" perspective.

--
Dean

---

From: Michael Thomas <[email-masked]>
Date: Tue, 28 May 2002 15:39:22 -0700 (PDT)

> cryptographically assert the identity associated with an inbound alias.

Ok, I guess my next dumb question is whether we
really want to go down the slippery slope of
turning SIP into a provisioning protocol. As in,
why stop here and what delimits this case with, oh
say, sending down which distinctive ringing tone
to associate with which identity? In your example,
the UA wouldn't have any clue how to do what you
said unless it had that binding...

	      Mike

---

From: "Dean Willis" <[email-masked]>
Date: Tue, 28 May 2002 18:10:34 -0500

> said unless it had that binding...

That, my friend, is why it's a P-header and not a standard extension. 

The assosiated-URI's-associated-ringing-tone-selector idea is pretty
clever. Why don't you write up a P-header draft and submit it? Odds are
it makes it into Release-6 :-) (I smile, but do not jest).

--
Dean

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 29 May 2002 15:31:20 +0300

> the other way around. This is especially true when the motivating need

Miguel-> Fine. I fixed that.

> restrictions, and there is just one valid identity).

Miguel-> Fine. I added some text explaining this situation.

> check and perform the registrations if needed.

Miguel-> Done. I some text referencing the registration event package,
as the mechanism to guess whether the associated URIs are registered or not.
 
> that would contain in it the Associated-URI header indicating which ones

There are two issues to solve here, namely:
1) Does the UAC need to know there was something wrong with one of the
   headers? I would say, yes. And I agree that the proxy should return
   the list of allowed IDs in the form of a P-Associated-URI.
2) Is 403 the best response code? I don't see why 403 is not a right
   response code *if we add the P-Associated-URI* to the response in
   the 403. Once must notice also that P- headers can't add a new 
   response code.

So my proposal: the policy enforcement proxy returns a 403 response
in case the URI in the From header or any other SIP header value that 
provides information of the identity of the calling party is not 
populated with any of the allowable URIs. The proxy adds a 
P-Associated-URI header with the complete list of allowable URIs to
the user. Is this correct?

/Miguel

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 29 May 2002 13:48:45 +0300

> one of those, but the phone needs to know which it should present to the

Jonathan, I must correct you. This is the story in 3GPP: there may be cases
where the user has one identity configured in a special SIM card called the
IMS SIM (ISIM). The network may have allocated other identities to the user, 
and those IDs arepreconfigured in the network, but not in the terminal nor 
in the ISIM. The user will register with the ID configured in the ISIM and 
will get back the others allocated to him.

There are other cases where the user may not even have an ISIM. It has only
a UMTS SIM, USIM (let's say, the old card). In this case, there is nothing
related to SIP configured in his SIM card, becuase that card was developped 
before SIP was introduced in 3GPP. The terminal will derive certain SIP 
identites from the USIM, it will register to his home network, and get back
"the real" SIP identities.

Summarizing, there are cases where the user does not even know who he is.
So no, we can't take the assumption that the UA is aware of all the 
identities allocated to him.

/Miguel

---

From: "Miguel A. Garcia" <[email-masked]>
Date: Wed, 29 May 2002 15:39:07 +0300

> distinctive-ringing features, for example.

I don't know where did you get this information, but as far as I know,
what you are saying is not within the scope of the draft. You are 
assuming an implicit 3rd party registration of all the associated URIs.
And I have just added some text to the draft to clarify that this is 
not the case. The associated URIs, in the general case, are not
implicitly registered. The UAC should use other mechanism, such as
a subscription to its own registration event to guess it.
 
In 3GPP some of the associated-URIs are implicitly registered by the
registrar, but that is not even the general case for the 
P-Associated-URI.

/Miguel

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 29 May 2002 12:43:23 -0500

> > > > 2. Is there an implicit assumption that the registrar will 
> > > > register
> > > the
> > > > associated URI? I believe this is true in the 3gpp case. A UA 
> > > > probably needs to know whether they have been 
> registered or not. I 
> > > > would not
> > > want
> > > > to put a URI into a Reply-To header unless I knew it 
> was a valid 
> > > > URI
> > > for
> > > No, this is not the case. The "reg" event will provide such 
> > > information. But the semantics of this header is just to 
> provide a 
> > > set of IDs that the user has associated to the address-of-record. 
> > > They may or may not be registered,
> > > of any of the returned IDs, or it can populate the From 
> with any of
> > > those
> > > IDs as well. That's it.
> > 
> > associated URI are registered, and that if the UA wants that, it 
> > should check and perform the registrations if needed.
> 

I think there's some confusion about what "registered" means for an
associated URI. URIs often work without anyone having sent a REGISTER
message associating a contact with them. For example, in my office,
[email-masked] is configured in my home server to forward to
[email-masked]. So,  [email-masked] is an
"associated URI" that might be included in the P-Associated-URI response
when [email-masked] registers.

The question of "does inclusion in a P-Associated-URI header mean that
the registrar registered that URI" is orthogonal to this draft and
completely out of scope. There may or may not be one or more
regisistations for each associated URI -- it just doesn't matter as far
as this draft is concerned.

I think from some of the comments that people are reading the draft
BACKWARDS.  This is not a mechanism by which a UA requests registratio
of additional URIs. This is a technique by which a registrar informs a
UA of aliases known to the registrar which will be forwarded to the UA.

> > > and
> > > > reject requests that have a value in the From field not amongst 
> > > "Procedures at the proxy" are procedures related to the extension 
> > > (the header in this case).
> > > The idea in this I-D is to convey to the UA the list of 
> URIs that he can
> > > use
> > Well, its all intertwined. The associated-URI list is the 
> only way a 
> > UA has to retry if it should get this error, since it conveys the 
> > allowed URI in the first place. Actually, 403 is really NOT 
> the right 
> > response. If it gets this, how does the UA recover? It 
> needs to know 
> > that the problem was a disallowed From value, and it needs to know 
> > which ones are OK. I would argue that the way to deal with 
> this is a 
> > new response code that would contain in it the 
> Associated-URI header 
> > indicating which ones are allowed.

Actually, we're doing identity filtering, not From filtering. The UA
would presumbaly use a P-Asserted-Identity header to assert one of the
associated URIs on a new request.

We need to evaluate the following proposal in that context.
 
> So my proposal: the policy enforcement proxy returns a 403 
> response in case the URI in the From header or any other SIP 
> header value that 
> P-Associated-URI header with the complete list of allowable 
> URIs to the user. Is this correct?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 29 May 2002 15:44:15 -0400

> > as the mechanism to guess whether the associated URIs are

Miguel - there is no need to use the registration event package for
this. You can simply send a REGISTER request with the associated URI in
the To field, and the registrar will return any registerd contacts. 

> UA of aliases known to the registrar which will be forwarded to the UA.

Whether the forwarding is created as a result of a binding to another
URI, or through an implicit registration (whcih is really the same thing
anyway), I thought Miguel was saying that there was no assumption about
this URI being usable to receive requests. 

> We need to evaluate the following proposal in that context.

I don't see how that changes anything.

Anyway, I am not going to push it in the interests of limitng the scope
of p-headers. If everyone says that the ability to reject isn't needed,
its not needed, and so be it.

-Jonathan R.

---

From: "Dean Willis" <[email-masked]>
Date: Wed, 29 May 2002 15:42:03 -0500

> -----Original Message-----
> From: Miguel A. Garcia [mailto:[email-masked]] 
> Sent: Wednesday, May 29, 2002 7:39 AM
> To: Dean Willis
> Cc: 'Jonathan Rosenberg'; 'Michael Thomas'; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: [Sip] Poll: expert review of 
> draft-garcia-sip-associated-uri
> 
> 
> Dean Willis wrote:
> > 
> > > Michael Thomas wrote:
> > > >
> cryptographic means? 
> > > > That is, if I can't prove that I own an identity 
> binding, it gets 
> > > > dumped on the floor?
> > >
> > > Sure; I think the issue (Miguel can correct me if I'm wrong), is 
> > > that the UA needs to be configured with the set of 
> identities it can 
> > > claim in the first place. The same credentials would 
> allow the user 
> > > to assert any one of those, but the phone needs to know which it 
> > > should present to the user to use.
> > 
> > number of extisting "aliases". The UA can expect to see calls "To:" 
> > any of these aliases, and needs to delivery them 
> appropriately to the 
> > user as direct calls rather than as calls targeted 
> originally to some 
> > other user that have just been forwarded here. This might interact 
> > with distinctive-ringing features, for example.
> 
> I don't know where did you get this information, but as far 
> as I know, what you are saying is not within the scope of the 
> draft. You are 
> assuming an implicit 3rd party registration of all the 
> associated URIs. And I have just added some text to the draft 
> to clarify that this is 
> not the case. The associated URIs, in the general case, are 
> not implicitly registered. The UAC should use other 
> mechanism, such as a subscription to its own registration 
> event to guess it.

No. I'm assuming that any issue of registering an associated URI is
completely outside of the scope of this draft. The fact that an
associated URI is returned by a registrar has NO INDICATION WHATSOEVER
on the registration state of an associated URI. All that is being
claimed is that the given URI is associated with the tAOR of the
registration request.

The UA might assert an associated URI in making a new request.

The associate URI might be used to make a new request to the UA.

Both of these uses are outside the scope of this draft.

Incidentally, I don't believe that subscribing to the registration state
of a specific AOR will return anything about the registration state of
other AORs that have the first AOR as a Contact or have the same Contact
as that first AOR. Instead, I think you actually need to subscribe to
the registration state of the AOR in question.

--
Dean