Re: [Sip] Using TLS in the first hop - Bug in RFC 5630

"Olle E. Johansson" <oej@edvina.net> Thu, 15 September 2011 13:44 UTC

Return-Path: <oej@edvina.net>
X-Original-To: sip@ietfa.amsl.com
Delivered-To: sip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6670221F8B11 for <sip@ietfa.amsl.com>; Thu, 15 Sep 2011 06:44:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.837
X-Spam-Level:
X-Spam-Status: No, score=-1.837 tagged_above=-999 required=5 tests=[AWL=-0.488, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_93=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W--WTWirDUOx for <sip@ietfa.amsl.com>; Thu, 15 Sep 2011 06:44:42 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) by ietfa.amsl.com (Postfix) with ESMTP id C964421F8B10 for <sip@ietf.org>; Thu, 15 Sep 2011 06:44:41 -0700 (PDT)
Received: from [192.168.20.63] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 3F473754BCE5; Thu, 15 Sep 2011 13:46:52 +0000 (UTC)
Mime-Version: 1.0 (Apple Message framework v1244.3)
Content-Type: text/plain; charset="iso-8859-1"
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <CALiegfnh2C3GNddnneepcVsGgtOd1pSDBVC3uH72S1KaVT_jHg@mail.gmail.com>
Date: Thu, 15 Sep 2011 15:46:52 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EBDBBCF-C3F3-4C64-B010-4F275B0A5A96@edvina.net>
References: <CALiegfkNfJ7McZAA=a5ajYVzYtmAjC_KQdK1P_ez2L1dia5v2g@mail.gmail.com> <CFFC2869-C704-423E-974D-3F4B93145BBB@edvina.net> <CALiegfnh2C3GNddnneepcVsGgtOd1pSDBVC3uH72S1KaVT_jHg@mail.gmail.com>
To: Iñaki Baz Castillo <ibc@aliax.net>
X-Mailer: Apple Mail (2.1244.3)
Cc: sip@ietf.org
Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Sep 2011 13:44:42 -0000

15 sep 2011 kl. 15:38 skrev Iñaki Baz Castillo:

> 2011/9/15 Olle E. Johansson <oej@edvina.net>:
>>> As a personal comment, I would like to say that nobody understands the
>>> usage of "sips" schema, just nobody. And the specs do not help.
>>> 
>> With the deprecation of "transport=tls" it becomes even more strange.
> 
> AFAIK "transport=tls" has never been deprecated. Instead, it has never
> been an standard. Note for example that RFC 3261 says:
> 
>      Note that in the SIPS URI scheme, transport is independent of TLS,
>      and thus "sips:alice@atlanta.com;transport=tcp" and
>      "sips:alice@atlanta.com;transport=sctp" are both valid (although
>      note that UDP is not a valid transport for SIPS).  The use of
>      "transport=tls" has consequently been deprecated, partly because
>      it was specific to a single hop of the request.  This is a change
>      since RFC 2543.
> 
> "A change since RFC 2543"?? transport=tls has never been defined in
> RFC 2543. Check yourself:
> 
>  http://tools.ietf.org/html/rfc2543
> 
> 
>> We should really spend some time on a "hitch hikers guide to SIP with TLS" and write an RFC to reinstate transtport=tls, which is what we all use.
> 
> Or spend some time in a new draft that *correctly* explains how to use
> TLS in the first hop (without requiring security in the whole path).
> This is *very* easy:
> 
> As I've explained in my first mail:
> 
>  INVITE sip:bob@biloxi.com SIP/2.0
>  Via: SIP/2.0/TLS 1.2.3.4
>  From: sip:alice@atlanta.com
>  Contact: sips:alice@1.2.3.4;transport=tcp
> 
> That's all. Just:
> - Set TLS in Via transport.
> - Use "sip" schema in every URI.
> - But use "sips" schema in Contact URI.
> 
> And it works.

This means thet the request URI of the ACK will be using SIPS, and then section 8.1.1.8 comes into play
and requires the other side to also use a SIPS uri in their contact.

In this case, both UAs need a TLS certificate.

Interesting.

/O