[Sip] Event Lists: Back-End Credentials

[Adam Roach <[e-mail]>]

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