Subject: Re: [Sipping] Some random thoughts on UA, security, and content-i ndirection

From: "Peterson, Jon" <[email-masked]>
Date: Sat, 7 Sep 2002 14:00:45 -0400

Some notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, September 06, 2002 2:37 PM
> To: Peterson, Jon
> Cc: 'Cullen Jennings'; [email-masked]
> Subject: Re: [Sipping] Some random thoughts on UA, security, and
> content-i ndirection
> 
[snip]
> 
> > 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.
> 
> I don't understand why this is necessary. I would think that the user 
> would send its request to the authentication service. The authentication 
> service would authenticate the user, and genreate a 428 response with a 
> content indirection. That indirection would resolve to a signed 
> multipart, which is the signed sipfrag generated by the authentication 
> service. Thus, there is no guesswork involved; the authentication 
> service chooses the URI. When the user retries the request, it has the 
> option of including the content indirection, or resolving the URI and 
> including the signed mime multipart itself directly.
> 
> There is also no spec violations, since the authentication service here 
> is a UAS, not a proxy.
> 

I was speaking actually to the possibility that when authentication
succeeds, the authentication service could act as a pure proxy, not as
either a redirect server nor a B2BUA. If the UAC can predict the URL where
the proxy will put the authenticated identity body, then if the
authentication service approves the request, the service could create the
authenticated identity body, make it available at the predicted URI, and
then just proxy the request along. This is an interesting possible
optimization, because it does not require the authentication service to
modify the body of the request (and hence obeys 16.6 rules for proxies) and
it does not require the extra RTT for redirection.

[snip]
> > 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?
> 
> Actually, it occurs to me that it really has to inspect it,  or at least 
> know what it will be. The reason is that (presumably?) the signed 
> content has a CSeq and Call-ID as part of the sipfrag. 

This is of course only a constraint if the authentication service acts as a
redirect server for this request.

> 
> 
> > 
> > So I guess the question for the content indirection requirements is
this: to
> > what degree is indirected content subject to RFC3261 16.6? 
> 
> All bodies are subject to it until the rule changes.

The puzzle I was trying to pose is this - what does end-to-end security mean
for indirected content at all? Can a UAC always expect to be absolutely
certain of the contents of the document that is referenced by a content
indirection URL at the time it appears at the UAS. I don't think it can. I
suspect that the content indirection requirements should at least have a
non-normative paragraph that says that this matter has been considered -
that content indirection is impactful to end-to-end security expectations,
especially when the UAC does not directly control the host that is providing
the indirection URL.

> 
> > 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?
> 
> Interestingly, my point above would argue that content-indirection 
> should be a header, so that a proxy could insert it, since the 428 
> mechanism suffers this "CSeq guessing" problem. However, that strikes me 
> as the tail wagging the dog. I firmly believe that content indirection 
> is best handled as a body, primarily because there are already existing 
> specifications that define it as such, and it would facilitate 
> signatures and other things we can do with bodies.
> 

I agree, it is best handled as a body. It is just interesting to note that
this sort of body (an indirectly referenced one) has different end-to-end
security properties.

> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 

_______________________________________________
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