Subject: [Sip] Event List Changes

From: Adam Roach <[email-masked]>
Date: Wed, 24 Nov 2004 21:08:07 -0600

I'm revising the event list draft currently. In DC, we discussed at 
length the authentication model for situations in which the RLS and 
subscriber are in the same domain; I believe I've captured this pretty 
well (but encourage interested parties to double check my interpretation 
of consensus).

When I went to update the document, however, I found that there was 
still something of a hole for the other case -- the one we described as 
a corner case. I know that we agreed that (1) additional mechanism could 
be developed to solve this case, and (2) we didn't want to wait for 
these mechanisms before publishing the event list document. However, I 
don't remember discussing what RLS implementors can do when they receive 
a request for a list resource from a user outside their domain.

So, I came up with what seemed like the most logical solution, given the 
other discussions we had. Before I submit -07 of the document, I'd like 
to have a few people look over my proposed text; if you think this is 
the wrong direction to take it, speak up now. If I get no comments 
before the end of next week, I'll submit the draft with the following 
language.

> 7.1 Authentication
>
>    If back-end subscriptions are required to retrieve resource state
>    information, the end user is no longer the direct subscriber to the
>    state of the resource.  This means that direct authentication of the
>    user is no longer possible.
>
> 7.1.1 RLS and Subscriber in the Same Domain
>
>    It is expected that the most common deployment of RLSes entails the
>    subscribers to the RLS being in the same domain as the RLS.  When
>    this is the case, the RLS then has the ability to act as an
>    authenication service.  The role of authentication service is defined
>    in "Enhancements for Authenticated Identity Management in the Session
>    Initiation Protocol (SIP)" [7].
>
>    At a high level, under this system, the RLS authenticates the
>    subscriber, and then includes an "Identity" header field in all of
>    the back-end subscriptions performed on behalf of that authenticated
>    user; this "Identity" header field cryptographically asserts that the
>    request has been authorized to be made on behalf of the user
>    indicated in the "From" header field.
>
>    Because the ability to authenticate requests is central to the proper
>    functioning of the network, any RLS which uses SIP back-end
>    subscriptions to acquire information about the resources in a
>    resource list MUST be able to act as an authentication service as
>    defined in [7].
>
> 7.1.2 RLS and Subscriber in Different Domains
>
>    In the general case, the SIP Authenticated Identity extensions do not
>    provide a means for the RLS to securely assert that subscriptions are
>    being performed on the end user's behalf.  Specifically, when the
>    subscriber and the RLS are in different domains, the RLS will have no
>    means by which it can vouch for the user's identity.  Mechanisms by
>    which back-end subscriptions in such circumstances can be
>    authenticated are left for future study.
>
>    Until such general solutions are developed, RLSes which are in a
>    different domain than the subscriber on whose behalf they are
>    creating back-end susbcriptions SHOULD subscribe to the resources
>    using their own identity.  By doing so, the RLS will generally obtain
>    only the resource information which is made publicly available.
>
>    Absent such general solutions, implemenations of subscriber user
>    agents MAY attempt direct subscriptions to resources in the resouce
>    list when subscribing to an RLS outside of their domain (either
>    directly or by way of another resource list subscription).  The
>    resouces to be subscribed to will be those indicated in the the "uri"
>    attribute of the <resource> elements present in the RLMI document
>    returned by the RLS.  Directly subscribing to the resources allows
>    proper authentication of the user to take place, which will generally
>    authorize them to receive more complete state information.
>    Implementations which choose to perform such direct subscriptions
>    SHOULD use the data retrieved directly to the exclusion of any
>    information about the resource obtained via the list subscription.

/a

_______________________________________________
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: Hisham Khartabil <[email-masked]>
Date: Thu, 25 Nov 2004 19:22:28 +0100

What should an RLS do when it receives a list subscription from a 
different domain it has no trust relationship with, and that 
subscription has an identity-header? I think it should remove that 
header. Is this an identity draft issue or should the event list draft 
also mention it?

Regards,
Hisham

On Nov 25, 2004, at 4:08 AM, Adam Roach wrote:

> well (but encourage interested parties to double check my 
> interpretation of consensus).
>
> still something of a hole for the other case -- the one we described 
> as a corner case. I know that we agreed that (1) additional mechanism 
> could be developed to solve this case, and (2) we didn't want to wait 
> for these mechanisms before publishing the event list document. 
> However, I don't remember discussing what RLS implementors can do when 
> they receive a request for a list resource from a user outside their 
> domain.
>
> So, I came up with what seemed like the most logical solution, given 
> the other discussions we had. Before I submit -07 of the document, I'd 
> like to have a few people look over my proposed text; if you think 
> this is the wrong direction to take it, speak up now. If I get no 
> comments before the end of next week, I'll submit the draft with the 
> following language.
>
>> 7.1 Authentication
>>

---

From: Adam Roach <[email-masked]>
Date: Fri, 26 Nov 2004 16:08:38 -0600

> header. Is this an identity draft issue or should the event list draft 

Yes, this is very much an identity issue, but I think you're 
misunderstanding a couple of different things here.

First -- and this is why it's useful in the first place -- the 
"Identity" header has the means to assert identity across domains that 
have no trust relationship (except for by way of a certificate 
authority). That is its purpose.

Second, when an RLS forms a back-end subscription, it is doing exactly 
that: starting up a brand new subscription. The subscription is between 
the RLS and where it sends its SUBSCRIBE message, not the end-user's 
client and the resource. It is not passing through headers from the 
original request. It might very well generate outgoing header fields 
based on the incoming header fields, but it would be foolish to do so 
blindly. To be clear: an RLS, when forming SUBSCRIBE requests, is acting 
as a back-to-back user agent, not as a proxy. It has an obligation to 
understand everything it sends in a back-end subscription request.

So, to answer the question, "What should an RLS do when it receives a 
list subscription from a different domain it has no trust relationship 
with, and that subscription has an identity-header:" it verifies that 
the identity header is valid for the request (after retrieving the 
relevant certificate, if necessary); and, if it is, accepts that the 
requestor is authorized to assert the identity in the "From" header. 
 From a practical perspective, this means that it would be safe to feed 
that identity into policy rules associated with the subscription.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Nov 2004 09:46:06 -0500

Adam,

In general I think this is a reasonable compromise in order to make 
progress in the near term. However, I think you have been a bit heavy 
handed in the restrictions. You say:

      "any RLS which uses SIP back-end
       subscriptions to acquire information about the resources in a
       resource list MUST be able to act as an authentication service"

This means that any RLS implementation that does back-end subscriptions 
MUST be a privileged member of the domain, so that it may act as an 
authentication service.

While this may be a reasonable strategy in many cases, it still ought to 
be possible for someone to build an RLS that isn't so priviliged. One 
that isn't just won't be about to use the original subscriber's identity 
in the back-end subscriptions, and instead will have to either generate 
subscriptions with no identity, or with its own identity - same as when 
handling subscribers from outside its domain.

	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 30 Nov 2004 10:06:00 -0600

Paul Kyzivat wrote:

> This means that any RLS implementation that does back-end 
> subscriptions MUST be a privileged member of the domain, so that it 
> may act as an authentication service.

Good point. I was trying to capture the apparent consensus in DC that 
the SIP Identity draft is mandatory to implement (optional to use) in 
RLSes. As you point out, I have probably gone too far, since my phrasing 
implies certain administrative details instead of stopping at 
implementation details.

I'll re-work the language so that it applies only to implementation, and 
not to deployment.

/a