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

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 2 Sep 2002 18:03:54 -0400

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

---

From: "Sean Olson" <[email-masked]>
Date: Tue, 3 Sep 2002 18:42:01 -0700

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.

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.
> 
is
> 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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 06 Sep 2002 17:37:20 -0400

responses inline.

> states that proxy servers "MUST NOT add to, modify, or remove the message

For now, I think yes. This is a much bigger issue which we will need to 
discuss, but its broader than content indirection.

> 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.

> 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. The CSeq and 
Call-ID need to be used by the UAC in its retried request, in order for 
the signed sipfrag to match the message its carried in. So, the UAC has 
to know what the Call-ID and CSeq are, so that its request matches whats 
been signed. The Call-ID should be the same, and the CSeq should be one 
higher. Effectively, the authentication service will need to "guess" the 
CSeq that the UAC will use in its retried request. Normally, this is one 
higher. But, I can imagine cases where its not. For example, what if, 
when the client retries, it gets a 407 by an intervening proxy. When it 
tries AGAIN, the CSeq is now two higher than its first attempt, and the 
signed sipfrag no longer matches its encapsulating message! The UAC has 
to know what the CSeq and Call-ID are in the signed sipfrag in order to 
detect this condition.

This is a problem with the sip-identity draft, and is not specific to 
content indirection. Its a problem with having the client insert the 
signed body (or referencing it) in a retried request. This problem 
doesnt manifest itself in the b2bua mode described in Jon's draft.

> what degree is indirected content subject to RFC3261 16.6? 

All bodies are subject to it until the rule changes.

> And does this is

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.

-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