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

From: Boehmer Bernhard ICM Berlin <[email-masked]>
Date: Fri, 22 Oct 2004 14:35:17 +0200

Hi,
I think controlling whether an RLS (or in a general any service) 
can perform certain subscriptions or publications (in case of 
presence) should be controlled by the notifier/PUBLISH-recipient.
Thus, additionally to the control whether a certain *user* is allowed to
subscribe/publish the notifier/PUBLISH recipient should be also able
to control whether an *application* is allowed to act on behalf of the
user. Currently, the needed application authentication is under discussion
(see the SIMPLE thread 
"[Simple] Usage of Contact header in PUBLISH for application authentication?").
Mauricio also mentioned the identity draft in this thread but I haven't yet 
discovered how this drafts solves this issue.
		Bernhard

> -----Ursprüngliche Nachricht-----
> Von: David R Oran [mailto:[email-masked]] 
> Gesendet: Donnerstag, 21. Oktober 2004 22:01
> An: Adam Roach
> Cc: [email-masked]
> Betreff: Re: [Sip] Event Lists: Back-End Credentials
> 
> 
> 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 [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> >
> David R. Oran
> Cisco Fellow
> Cisco Systems
> 7 Ladyslipper Lane
> Acton, MA 01720 USA
> Tel: +1 978 264 2048
> Email: [email-masked]
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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