Subject: [Sipping] SIP digest enhancements

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 23 Mar 2002 16:13:41 -0600

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

---

From: Michael Hammer <[email-masked]>
Date: Mon, 25 Mar 2002 10:40:43 -0500

Henning,

Would using this SIP message body set the precedent for how any header
that requires authentication (and in addition possibly confidentiality)
by the network be done?

Mike

At 04:13 PM 3/23/2002 -0600, Henning Schulzrinne wrote:

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

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

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

I'd like to revive a different proposal (which has been raised before
by

message/sip body, subject to normal Digest body protection
(auth-int).

Advantages:

checksums

canonicalization (the latter, among other things, sunk the previous
PGP

mechanism)

Disadvantages:

- ?

Same as enhanced digest:

- doesn't work with non-enhanced implementations (it probably could,
if

We may still want to use better bid-down protection, but again
seems

Henning

Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 25 Mar 2002 11:00:00 -0500

Michael Hammer wrote:
> that requires authentication (and in addition possibly
> confidentiality) by the network be done?
> 

I don't think I was trying to set precedent, but there do seem to be
certain properties of SIP (and similar protocols) that encourage
tunneling instead of per-header integrity protection, in particular the
ability of intermediate entities to change headers in various ways,
while being prohibited from mucking with bodies. I also tend to think
that having one type of approach across different application-layer
mechanisms might be helpful.