Subject: RE: [Sipping] SIP digest enhancements

From: "Vesa Torvinen (LMF)" <[email-masked]>
Date: Mon, 25 Mar 2002 17:21:38 +0100

Henning, 

Your suggestion potentially solves all problems related to our 
SIP layer integrity protection solution 
in 3GPP IP multimedia system. Now that we all learned in 
Minneapolis that 3GPP P-CSCF is in fact 'a transparent B2BUA', 
the new headers suggested in our Enhanced HTTP Digest draft 
are not necessarily needed anymore: UA and P-CSCF have an 
end-to-end relationship and they can use the existing headers. 
Furthermore, the 'auth-int' protects the body in 
which the 'one-hop' SIP message can be transported in the tunnel 
mode as you propose. So, there seems to exist a SIP layer solution 
for the first/last hop protection after all, and even without 
any further standardization? 

In general, how seriously will SIP be developed towards this 
'tunneling mode's? Is this a general trend in IETF application 
layer protocols? Is this approach a long term solution? 

I would also be interested to know what headers must be included 
to the external SIP message in minimum if tunneling was used for 
one-hop protection between UA and a 'transparent B2BUA'? Is it enough 
just to have the SIP method line and the Authorization header in the 
external message, and the rest in the tunneled message? 

Vesa 

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: 24. maaliskuuta 2002 0:14
> To: [email-masked]
> Subject: [Sipping] SIP digest enhancements
> 
> 
> I still believe that some form of digest enhancement that protects
> header fields is necessary. I don't believe that either IPsec 
> or TLS are
> sufficient for this purpose. The reason is simple: the prime motivator
> for Digest is SIP registration. (Digest for call authorization is
> difficult to scale, due to the need for a shared secret.) SIP
> registration can easily traverse multiple proxies. Even with IPsec or
> TLS, I have to trust the proxy not to modify the content. 
> When roaming,
> my trust in the outbound proxy may be rather limited. Thus, end-to-end
> integrity is needed here.
> 
> As I mentioned during the session, I think the previous-hop
> authentication is nice, but of somewhat lower priority. In many cases,
> this can be solved by the existing last-hop TLS path to the 
> UAS that may
> well be needed in any event.
> 
> I'd like to revive a different proposal (which has been 
> raised before by
> a number of people, I believe) that may get us unstuck and make the
> transition to S/MIME conceptually easier:
> 
> Proposal: let's put the protected data (primarily Contact) in a
> message/sip body, subject to normal Digest body protection (auth-int).
> 
> This requires no changes to RFC 2617 and is easily implemented.
> 
> Advantages:
> 
> - Tunneling and encapsulation is conceptually cleaner than header
> checksums
> - Will be able to re-use code from the S/MIME behavior
> - No need to worry about proxies modifying header fields and
> canonicalization (the latter, among other things, sunk the 
> previous PGP
> mechanism)
> 
> Disadvantages:
> 
> - somewhat less efficient due to header duplication, but any S/MIME
> scheme would pay the same penalty
> - ?
> 
> Same as enhanced digest:
> 
> - doesn't work with non-enhanced implementations (it probably 
> could, if
> such implementations ignore the REGISTER message body)
> 
> We may still want to use better bid-down protection, but again seems
> like a separable concern.
> 
> Henning
> 
> _______________________________________________
> 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