Subject: RE: [Sip] TLS, IPSec and consensus (bug #232)

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 30 Jan 2002 13:05:26 -0600

Brian is right about the fact that both IPSec and TLS work only for the
respective architectures to which they are applicable. I agree that there is
a critical need for an IPSec profile - I think the only real question is
whether or not it needs to be in bis in order for the security story in bis
to be complete. I don't know of any litmus test for this. I do know that I
got the impression that punting on confidentiality and keying wouldn't be
acceptable. I think we have the luxury to take our time and do IPSec right -
not to cram something into bis hastily - because our existing security
story, while it has limitations, covers many of the important threats.

One specific further note below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Rosen, Brian [mailto:[email-masked]]
> Sent: Wednesday, January 30, 2002 5:30 AM
> To: 'Peterson, Jon'; [email-masked]
> Subject: RE: [Sip] TLS, IPSec and consensus (bug #232)
> 
[snip]
> 
> I'd like to see a distinction between what a UA
> should/must do and what a PS should/must do.
> I'd like the UA to not have to should/must
> either TLS or IPsec, but rather be content
> with Digest.  I'd like to see some words that
> basically say that PS intended to work
> within a domain must implement IPSec, and
> PSs intended to work cross domain must implement
> TLS and both should implement both.

Harkening back to Rohan's mail, I think there are in fact multiple IPSec
'worlds' that people are interested in here. The ESP transport mode 'world'
could look pretty similar to TLS (provided it had some sort of
confidentiality and key exchange, and the application-binding stuff were
understood). The ESP tunnel mode 'world', based on security gateways, has
very different properties, I think. The requirements for support in various
SIP network elements of these two 'worlds' would be different.

> 
> Brian
> 
> > -----Original Message-----
> > From: Peterson, Jon [mailto:[email-masked]]
> > Sent: Wednesday, January 30, 2002 2:25 AM
> > To: [email-masked]
> > Subject: [Sip] TLS, IPSec and consensus (bug #232)
> > 
> > 
> > 
> > I would like to suggest, based on the list discussion that 
> > has transpired to
> > date, that the chairs consider whether or not we have rough 
> > consensus in
> > favor of the current normative text on TLS and IPSec in 
> bis06 22.3.1.
> > 
> > The summary I sent out earlier today (along with Brian and 
> > Mike's summaries)
> > provides an account of the current state of the discussion. I 
> > believe that
> > the bis authors have been able to present a reasonable 
> > response to Mike's
> > strenuous objections. In any event, the issues are on the 
> > table, and those
> > who have debated these issues for months have essentially 
> > said their peace.
> > If there are any further arguments, or reflections on TLS vs. IPSec
> > transport vs. IPSec tunnel, from other members of the SIP 
> > community, let's
> > hear them now, by all means. Most respondents have indicated 
> > that they can
> > live with the text in bis06 today.
> > 
> > I would also note that to date the reception of the proposed 
> > minimal IPSec
> > profile (ESP transport mode HMAC-MD5-NULL) has been lukewarm, 
> > I think. Some
> > respondents have expressed a preference for tunnel mode 
> > IPSec. The IESG also
> > seems to feel that some encryption algorithm, as well as a 
> story about
> > keying, should be a part of an IPSec profile for SIP. While 
> > some encryption
> > algorithms has been mentioned on the list (like DES, as 
> > required by RFC
> > 2406), I haven't heard one that people sound entirely 
> > comfortable with.
> > 
> > Ultimately, we all agree that we need to arrive at an IPSec 
> > profile for SIP
> > - I just don't believe that we need to solve this problem in bis.
> > 
> > Jon Peterson
> > NeuStar, Inc. 
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments on the application of sip
> > 
> 
> 
> This e-mail and any attachments are confidential. If you are not the
> intended recipient, please notify us immediately by reply 
> e-mail and then
> delete this message from your system. Do not copy this e-mail or any
> attachment, use the contents for any purposes, or disclose 
> the contents to
> any other person: to do so could be a breach of confidence.
> 

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

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 31 Jan 2002 15:40:16 -0800

A few points in the TLS/IPSEC debate: TLS, today, is much easier to
deploy than IPSEC because of two factors, NAT traversal and
one-way-authentication. We already heard of NAT traversal; TLS has a
reasonable story; there is an IPSEC over UDP solution that is being
developed, but it is sizably more complex than TLS. TLS enables
one-way-authentication, i.e. a situation in which only the "server" is
authenticated; IPSEC, in its current form, require that both server and
clients have a certificate. Providing every client with a certificate
turns out to be harder than expected.

Note that in the case of either TLS and IPSEC, we have a dependency on
the DNS. The "locating SIP servers" draft specifies the use of 1 or
possibly two indirections: a NAPTR query to find the supported
transports, then an SRV query to find the servers and port for the
selected transport, and finally an A or AAAA query to find the address.
DNS attacks such as cache pollution may be mounted at each of these
steps. One way to protect against such attacks is to check that the
names or credentials in the certificates used for TLS or IPSEC somehow
match the domain part of the SIP URI. We should specify it.

-- Christian Huitema