Re: [Sipping] Exploders drafts

[Miguel Garcia <[e-mail]>]

Cullen Jennings wrote:

> On draft-garcia-sipping-message-exploder-00.txt
> 
> The embedded headers in the URI are nice but raise lots of issues. For
> example, if I insert a P-Asserted-Identity header with a fake name, will it
> be used? Or perhaps a Route header that caused the message to go to someone
> that had not agreed to receive exploded messages.

First, this issue is applicable not only to the MESSAGE exploder draft, 
but to any other exploder document. It can happen with INVITE, SUBSCRIBE 
  or REFER as well.

Second, the exploder implements a SIP UA functionality, meaning that if 
implements RFC 3325, it is able to distinguish when the 
P-Asserted-Identity is trusted or not, as required by the RFC. Based on 
this trustness of the asserted identity, the exploder may implement 
local policy to pass the header to the other side or not.

> 
> The " The MESSAGE exploder MUST NOT copy any security body (such as an
>       S/MIME signed body) addressed to the MESSAGE exploder to the
>       outgoing MESSAGE request.  This includes, e.g., security bodies
>       signed with the public key of the exploder."
> This confuses me. If it was signed, it would be signed with the public key
> of the UA sending the request to the exploder? I'm just not sure what you
> are getting at with this. Is this the exploder must not relay any S/MIME
> body? 

This is obviously wrong. The text shold speak about an "encrypted body" 
and "bodies encrypted with the public key of the explodr".

The idea is very simple: if the exploder is able to decrypt an encrypted 
body, it should not copy that encrypted body to the outgoing request, 
since the receiver will not be able to decrypted.

> 
> In the security section - last paragraph. Not sure what you are proposing
> here. If I wanted to send an encrypted message to A and B, what would I do.
> I assume encrypt the List A,B with the public key of the exploder then
> provide a copy of the message that was encrypted with a content encryption
> key (call it the CEK) then encrypt the CEK with the public key of A and
> separately with B then bundle this all up somehow and send it.  

Yes, that is how it should be done. I conquer that the text is not clear 
enough, we will clarify it.

> You mention
> integrity protection with S/MIME too - are you assuming that the exploder
> knows the public key of the UA sending the request?

That is the assumption.
> 
> If the exploder has authenticated the sender, perhaps it should put the
> identity of the sender in the From of the messages it sends. This raises
> issues with trying to be Anonymous and user an exploder but perhaps this is
> a feature not a bug.

I don't think that the decision point is whether the user is 
authenticated or not. I belive the decision point is the user 
requirements expressed in the Privacy header. That will determine 
whether to populate the From header with the user ID or something else

> I don't feel strongly about these drafts one way or another so I hope these
> comments get somewhat discounted as casual passer by - I know others have
> thought about it much more. Perhaps the amplification issue in this B2BUA
> based solution can be justified as no worse than the alternative solution to
> the problem using compression with a proxy.
> 
> Cullen 
> 
> 
> 
-- 
Miguel A. Garcia           tel:[phone]
Nokia Research Center      Helsinki, Finland


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP