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

From: Adam Roach <[email-masked]>
Date: Thu, 21 Oct 2004 14:24:56 -0500

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

---

From: David R Oran <[email-masked]>
Date: Thu, 21 Oct 2004 16:00:55 -0400

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 
> necessary under some circumstances for the purposes of authenticating 
> on the users behalf for back-end subscriptions.
>
> 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.
>
David R. Oran
Cisco Fellow
Cisco Systems
7 Ladyslipper Lane
Acton, MA 01720 USA
Tel: +1 978 264 2048
Email: [email-masked]

---

From: Adam Roach <[email-masked]>
Date: Thu, 21 Oct 2004 19:40:20 -0500

> more trust that I think ought to be given it.

I'm not too crazy about them either (I'll note that suggestion #2 
doesn't have that property, but at the cost of making the protocol far 
less useful).

> the request. SAML might be our friend here.

That feels a lot like what I was trying to get at with my suggestion #4, 
albeit with a slightly different mechanism. The problem is that pursuing 
this kind of work will be very time consuming... and the event list 
document has been in limbo for over a year already. I'm not necessarily 
advocating expediency over security -- it's been so long since I started 
this work that I'm half inclined to cripple it (by removing back-end 
subscriptions) rather than wait several years for a general purpose 
solution to the delegation problem. Not that I *want* to do this -- it 
would remove most of the utility of the extension for the 3G guys -- but 
I do want to put this work to bed.

I'm not sure if it represents a reasonable compromise, but I'm not 
averse to putting in the "use this header to transfer your secret" with 
a strongly worded note indicating the implications if you do, and an 
indication that future mechanisms may define more constrained ways to 
delegate limited subsets of authority to another node (possibly for a 
constrained time period).

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Oct 2004 09:14:43 -0400

>    RLS would use them to obtain information on the user's behalf.

Dave then espressed reservations over this because it grants too much 
capability to the RLS.

I agree with Dave's concern over this, and think his suggestion to 
tackle the problem of delegation head on is the right solution in the 
long term. OTOH, it doesn't seem like we can wait that long to get 
something going for RLS.

To pursue Adam's suggestion without giving away the ranch, maybe 
presence servers could have one set of credentials that grant only 
limited access (subscription by buddies), and another for full 
permissions. This is really just an implementation technique and so we 
couldn't standardize it, but it might be a way to allow this crippled 
mechanism to be useful.

	Paul