Subject: [SIP] FW: [Sip-implementors] Message integrity with digest

From: Carmelo Zaccone <[email-masked]>
Date: Mon, 09 Apr 2001 11:53:05 +0200

>                Hi all,

>        As you know, the 'qop=auth-int' alternative that the 
>        digest scheme defines, offers a mechanism to have
>        the message integrity security feature in our 
>        transactions. 
>
>        As it is currently defined, the spec just takes 
>        the message body into consideration for the digest 
>        scheme.
>
>        This provides us with a certain level of protection,
>        but we may easily extend it to a higher level of 
>        protection. That, more or less, can be compared 
>        to the one provided by the PGP security scheme.
>
>        As defined in the spec, the PGP scheme does not only
>        take the body for its response calculation but also
>        everything that follows the Authorization/ 
>        ProxyAuthorization headers.
>
>        This level of protection is obviously better as we 
>        may also protect headers.
>
>        e.g. think of an unprotected subject header combined with the 
>        currently defined digest message integrity mechanisms ...
>        Messages may be valid from an authentication point of view but
>        a third party between the SIP peers may have changed the
>        subject, maybe leading the communication to a completely 
>        different meaning.
>
>        So, in SIP I would propose extending the way we use the digest 
>        integrity mechanims to map the PGP message integrity coverage.
>       i.e. extending the entity body signification by defining it as
>        everything that follows the Authorization/ProxyAuthorization
>        headers as defined in chapt. 14.1.2 for the pgp-signature.
>        
>        NB1: As the digest already covers the realm and SIP request METHOD, 
>        we could avoid taking them into consideration
>
>        NB2: Obviously, in scenarios where multiples Authorization/
>        ProxyAuthorization headers have to be present, the order in which 
>        an entity inserts its credentials into the message becomes important.    
>                Carmelo 

-- 
...........................................................
  Indigo                         Carmelo Zaccone             
    Software                       Head Software Engineer  
                                                           
  Indigo Software Group, Inc.                              
        505 Montgomery Street               50 rue Wiertz         
      San Francisco, CA 94111              Brussels, 1050        
                          USA                     Belgium               
                                                            
      Phone: 1 (415) 887-3511      Phone : +32 2 230 3594  
      Fax  : 1 (415) 887-3001      Direct: +32 2 235 0955  
                                   Fax   : +32 2 280 2676  
...........................................................

---

From: Carmelo Zaccone <[email-masked]>
Date: Mon, 09 Apr 2001 12:51:54 +0200

Hi Jonathan,

> [...]
> A much cleaner (though more bandwidth-intensive) way of solving this
> problem would be to define a 'message/sip' MIME type, which duplicates all
> the end-to-end headers and includes the body, and then run auth-int
> integrity checking over *that*.  Headers inside the message/sip body 'win'
> over the headers in the authenticated body.  This is much more robust in the
> presence of intermediate proxies which might mangle or re-order headers.
> 
> A 'message/sip' MIME type would also lets us use S/MIME and PGP/MIME
> authentication and encryption on message headers.
> 
> This discussion should maybe move to the main sip list?

	This idea seems indeed cleaner but as you mention, it 
	suffers from the bandwith point of view.
	This is even more consuming if you take into consideration the
	scenario where multiple challenges are proposed and therefore 
	multiple credentials have to be provided.

	e.g. 
	UA1 calls UA2 via Proxy P1 and Proxy P2
	UA1 -> P1 -> P2 -> UA2

	Let's imagine that P1, P2 and UA2 are requesting authentication to UA1

	This will lead to a message with the possible following skeletton

	INVITE ... SIP/2.0
	h1
	h2
	h3
	Px-Auth (for P1)
	Px-Auth (for P2)........./\
	Auth    (for UA2)..../\   |
	h4.............../\   |   |
	h5                |   |   |
	h6                |   |   |
	CRLF              |   |   |
	BODY.............\/..\/..\/
                         Chk Chk Chk
			 at  at  at
			 UA2 P1  P2

	Using the idea to play with the message/sip MIME type, we will also
	need to play with multiparts MIME.
	Indeed, every entity realising a check on the credentials has
	a different 'body' to sign (cf picture). This will imply that we 
	need to set the content-type of the SIP message not to message/sip
	but to multipart-mime such as to place the different signated bodies
	in different multipart-body. (each multipart-body having the content-type 
	set to message/sip)
	This obviously will increase significantly the message size and also
	implies providing a mechanism (e.g. sections order) for the 
	determination of which multipart-body is for which checking entity.

	Anyway, as it is mentioned in the SIP spec. at section 6,
	'If authentication is used, the rules in Section 13.2 apply. Proxies
	SHOULD NOT re-order header fields'
	(maybe we need to change this to MUST NOT ?)  
	
	We have now two choices of doing the same thing. Either we select one,
	or we decide to enable both...

	Cheers,

		Carmelo