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

> -----Original Message-----
> From: ext David R Oran [mailto:oran@cisco.com]
> Sent: 28.October.2004 18:17
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: adam@nostrum.com; sip@ietf.org
> Subject: Re: [Sip] Event Lists: Back-End Credentials
> 
> 
> 
> On Oct 28, 2004, at 10:35 AM, hisham.khartabil@nokia.com wrote:
> 
> > I didn't know that communication with IESG is one way only. Can the 
> > IESG member who is blocking this explain why this cannot be outside 
> > the scope of this document?
> >
> > Anyway, so how about an XCAP usage document that is carried 
> signed and 
> > encrypted to the server using HTTP. That xcap usage document can 
> > include realm, username and password for realms that the user knows 
> > will be needed by the RLS.
> >
> That's precisely the problem. Now the RLS can impersonate the 
> user and 
> do anything the user could.

I thought the problem was how to transport the secret to the RLS. Irrespective of how that is done (using XCAP or carrying it in the SUBSCRIBE request itself), you will face the same problem you describe above. So am I right in assuming that you're advocating Adam's latest suggestion on RLS doing backend subscription using its own address?

> 
> > Note that this is useful not just for backend 
> subscriptions, but also 
> > for any list usage we can think for that will result in backend 
> > requests being sent on behalf of a client.
> >
> > A server needing a secret key to use on behave of a user 
> can look in 
> > the XCAP document of that user.
> >
> Can I be your RLS server? Please? Pretty please?

Ok, but if you behave :) You would expect a trust relationship between the client and the RLS.

/Hisham

> 
> Dave.
> 
> 
> > Regards,
> > Hisham
> >
> >> -----Original Message-----
> >> From: ext Adam Roach [mailto:adam@nostrum.com]
> >> Sent: 28.October.2004 17:16
> >> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> >> Cc: sip@ietf.org
> >> Subject: Re: [Sip] Event Lists: Back-End Credentials
> >>
> >>
> >> hisham.khartabil@nokia.com wrote:
> >>
> >>> Why isn't it enough to say that the way an watcher passes
> >> the key to
> >>> the RLS is outside the scope of this document?
> >>
> >>
> >> Because that's exactly what the document says right now, 
> and the IESG
> >> won't let it pass as a result.
> >>
> >>
> >> /a
> >>
> >
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use sip-implementors@cs.columbia.edu for questions on current sip
> > Use sipping@ietf.org 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: oran@cisco.com
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip