[Sip] Event List Changes

[Adam Roach <[e-mail]>]

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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip