Hi all,

        I hope that all of you who where in Cannes
        last week enjoyed, at least a little, ;-), the nice 
        location the ETSI provided for this last 
        bakeoff, and that you all had a nice trip back.

        So, let's talk about the real stuff!

        Last week, some of us tested the security schemes
        the SIP spec puts at our disposal.

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

S/MIME Cryptographic Signature

Reply via email to