Subject: RE: [Sipping] Some random thoughts on UA, security, and content-indirection

From: [email-masked]
Date: Wed, 4 Sep 2002 11:37:07 +0300

I don't see any huge difference between:
1. intermediary removing the body and adding a new header specifying the URL
2. intermediary removing the body and adding a new body specifying the URL.

Of course, authentication and encryption plays a role here too.

/Hisham

> -----Original Message-----
> From: ext Sean Olson [mailto:[email-masked]]
> Sent: Wednesday, September 04, 2002 4:42 AM
> To: 'Peterson, Jon'; 'Cullen Jennings'; [email-masked]
> Subject: RE: [Sipping] Some random thoughts on UA, security, and
> content-indirection
> 
> 
> My concept of content indirection was purely an end-to-end 
> one. However,
> there
> are some interesting uses of content indirection by intermediaries. We
> could get
> bogged down in the discussion of how intermediaries can or 
> cannot modify
> bodies,
> or we could follow the precedent of saying that intermediaries do this
> today and
> we shouldn't worry about it. I favor the latter. 
> 
> /sean
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Peterson, Jon
> Sent: Monday, September 02, 2002 3:04 PM
> To: 'Cullen Jennings'; [email-masked]
> Subject: RE: [Sipping] Some random thoughts on UA, security, and
> content-indirection
> 
> 
> 
> I think these issues are interesting, and that they have some 
> bearing on
> the content indirection requirements.
> 
> Is a content-indirected body subject to the rules of RFC3261 
> 16.6, which
> states that proxy servers "MUST NOT add to, modify, or remove the
> message body"?
> 
> I have always assumed that the sip-identity draft would make 
> use of the
> content-indirection mechanism; that an authentication service would be
> able to provide an authenticated identity body in a SIP message by
> reference rather than by value. I guess I also assumed that
> intermediaries would be able to specify a content indirection URL
> themselves - essentially, that a content indirection URL would be
> specified in a header.
> 
> The current content-indirection mechanism that has been put forward in
> the SIP WG to satisfy the SIPPING requirements implements
> content-indirection as a MIME body (one that specifies a 
> URL). This MIME
> body presumably cannot be changed by intermediaries, per RFC3261.
> 
> Cullen's approach below would allow a UAC to try to predict the
> content-indirected URL that will be provided by an authentication
> service - that way, an authentication service would not have a need to
> modify MIME bodies to insert URLs that it will use to provide indirect
> access to authenticated identity bodies. There could sbe some URL
> convention - like that authentication services would make 
> authenticated
> identity bodies available at a URL based on the Call-ID of the message
> (http://www.authentication-service.com/[suitably_escaped_Call-
> ID]). This
> would seem to meet the letter, if not the spirit, of RFC3261.
> 
> Because the whole point of keeping intermediaries out of 
> message bodies
> is that bodies are end-to-end. But indirected content isn't 
> necessarily
> end-to-end at all. The content may not be set by the UAC, and the UAC
> may not even have the opportunity to review that content at the time
> that it is received by the UAS. There is a concept in the sip-identity
> draft that a UAC may want to have the opportunity to inspect the
> authenticated identity body and decide whether or not to resubmit the
> request. How important a proprety is this really in light of content
> indirection?
> 
> So I guess the question for the content indirection requirements is
> this: to what degree is indirected content subject to RFC3261 
> 16.6? And
> does this is turn have any impact on whether or not a header or a body
> is a more appropriate mechanism? Is there any requirement for a UAC to
> supervise the contents of an indirect body?
> 
> Jon Peterson
> NeuStar, Inc.
> 
> > -----Original Message-----
> > From: Cullen Jennings [mailto:[email-masked]]
> > Sent: Wednesday, August 21, 2002 11:10 AM
> > To: [email-masked]
> > Subject: [Sipping] Some random thoughts on UA, security, and 
> > content-indirections`
> > 
> > 
> > 
> > I've been thinking about issues around UAs that, due to various
> constraints,
> > have very limited capabilities but still which to 
> participate in the 
> > type things that are going to require signed sipfrags.
> > 
> > I also notice an interesting property of the 
> content-indirection. When
> 
> > a
> UAC
> > puts a content indirection URL in a messages, it does not 
> need to be 
> > valid yet, however, it does need to be valid by the time it 
> arrives at
> 
> > the UAS
> and
> > the UAS goes to use it. (ok - I know it is more complex, 
> messages in 
> > the other direction, proxies could use the URL, whatever, 
> but pretend 
> > it is
> like
> > this for a second)
> > 
> > The UAC could insert content indirection URLs for all the 
> places where
> 
> > it should be doing sipfrag however it would not actually 
> generate the 
> > content any of these URL pointed to. It would then send the 
> message to
> 
> > a "Trust Agent Proxy" that the UAC trusted and had delegated all of 
> > it's signing authority too. The "Trust Agent Proxy" would 
> create, on 
> > behalf of the UAC, all the content for the signed sipfrags that the 
> > UAC should have created
> and
> > put them in the right place. It would then, acting like an outbound 
> > proxy, forward the message to the UAS which would retrieve these as 
> > normal and would be unaware that the "Trust Agent" created them on 
> > behalf of the UAC.
> > 
> > Obviously these ideas are still half baked but I think our security 
> > model
> is
> > going to make us start thinking more about delegating trust.
> > 
> > Cullen
> > 
> > 
> > 
> > _______________________________________________
> > Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip Use
> [email-masked] for new developments of core SIP
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP