Re: [Sip] Event Lists: Back-End Credentials

[David R Oran <[e-mail]>]

Sigh. Delegation is hard. I frankly don't like any of these solutions 
because they allow full user impersonation by the RLS, which is a lot 
more trust that I think ought to be given it.

If we want to really tackle delegation, I'd suggest that we extend SIP 
generally to allow SIP-specific delegation capability. One way to do 
this is for the user to construct a certificate for the RLS giving it 
specific rights (e.g. Subscribe on my behalf), and then signing it 
based on a credential that would be accepted by the ultimate target of 
the request. SAML might be our friend here.

It might be worth going back and seeing what applies to REFER as well 
while we're at it since REFER has some pretty brittle security 
properties due to our needing to to get done quickly.

Dave.

On Oct 21, 2004, at 3:24 PM, Adam Roach wrote:

> During IESG review of draft-ietf-simple-event-list-05, the IESG raised 
> a concern that section 7.1 does not specify a mandatory-to-implement 
> mechanism for transfer of a secret to the RLS. This secret transfer is 
> necessary under some circumstances for the purposes of authenticating 
> on the users behalf for back-end subscriptions.
>
> There is no clear-cut solution to this problem. The options that I've 
> been able to think of -- and there are almost certainly more -- are as 
> follows:
>
>    * Make HTML forms mandatory
>
>    The current example in the draft is to send the credentials in an
>    HTML form over HTTP. Making this mandatory has the obvious drawback
>    that it requires HTML browsers in all devices that make use of event
>    lists. This is probably not an acceptable requirement.
>
>    * Disallow back-end subscriptions altogether
>
>    For this solution, the list server would pass back the resource list
>    in notifications, along with state for any locally managed states.
>    The client would be responsible for sending subscriptions for the
>    state for any resources in the list that are not managed by the RLS.
>    This defeats some of the purpose of event lists, since the client is
>    left with maintaining several subscriptions for resources -- so it's
>    really rather suboptimal.
>
>    * Add new SIP header field (or maybe method) for credential upload
>
>    One very simple solution would be to add a new header which contains
>    a triple of [realm,userid,password]. We would specify that this
>    header is disallowed except over SIPS connections. The client would
>    include one or more such headers in its SUBSCRIBE request, and the
>    RLS would use them to obtain information on the user's behalf.
>
>    To make this work, we would also add a status field to the
>    <instance> element that indicates something like "authorization
>    failed" and the realm for which credentials are needed. The user,
>    upon seeing this in the RLMI, could re-subscribe with the missing
>    credentials.
>
>    * Try to leverage ongoing work in draft-ietf-sip-identity and/or
>      draft-jennings-sipping certs
>
>    This feels like the class of problem that the ongoing identity work
>    is trying to solve, but I can't figure out how to apply the existing
>    drafts to it. The problem is that the RLS needs to change almost
>    everything that would be protected by the identity draft.
>
> Of these, I prefer the simplicity of adding a new SIP header-- but I'm 
> a bit scared of it because the obvious, most simple solution in 
> security typically ends up being the wrong solution. However, I'll 
> point out that the concern that was raised by the IESG was *not* that 
> we are passing the user's secret to a third party; it was the fact 
> that we're not defining *how* to do so.
>
> Unless I'm missing something, the RLS simply needs to be trusted to 
> act on the user's behalf to make more-or-less arbitrary SUBSCRIBE 
> requests, since the user doesn't know the contents of the list before 
> subscribing. There might be some really clever way to do this without 
> passing the user's secret over wholesale, but I don't see it.
>
> Thoughts? Ideas? Brilliant solutions?
>
> /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
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: [phone]
Email: [e-mail]


_______________________________________________
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