Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-09.txt]

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Wed, 19 June 2013 12:06 UTC

Return-Path: <keith.drage@alcatel-lucent.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C290B21F9B85 for <sipcore@ietfa.amsl.com>; Wed, 19 Jun 2013 05:06:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Level:
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 F8C5iOOGnULP for <sipcore@ietfa.amsl.com>; Wed, 19 Jun 2013 05:06:41 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id F293321F9B84 for <sipcore@ietf.org>; Wed, 19 Jun 2013 05:06:40 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r5JC6U1e024963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 19 Jun 2013 07:06:31 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id r5JC6SL2005206 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 19 Jun 2013 08:06:29 -0400
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 19 Jun 2013 08:06:28 -0400
Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.27]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 19 Jun 2013 14:06:10 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: Iñaki Baz Castillo <ibc@aliax.net>, Saúl Ibarra Corretgé <saul@ag-projects.com>
Thread-Topic: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-09.txt]
Thread-Index: AQHObODJXZqFHUE1DEqThtssXIioxZk87d6g
Date: Wed, 19 Jun 2013 12:06:09 +0000
Message-ID: <949EF20990823C4C85C18D59AA11AD8B055194@FR712WXCHMBA10.zeu.alcatel-lucent.com>
References: <20130613011708.18316.28106.idtracker@ietfa.amsl.com> <CALiegfkg-KU1bB01eLXuksZV1ehBY92uf+0+F3fQuha-WnOS1A@mail.gmail.com> <013c01ce6c4e$29e33c90$7da9b5b0$@co.in> <CALiegfnQ8=R1PRbHwPSDjJ=jH+bBeiNqjU12yr8KmJvHWQg1Mg@mail.gmail.com> <12FDD6C8-F172-4B3B-A83A-211CF553DA1A@ag-projects.com> <CALiegfneR2MwFEgGnZVtNJUXbDv0Mw0uWK2RYOGi-euWvYpR1g@mail.gmail.com>
In-Reply-To: <CALiegfneR2MwFEgGnZVtNJUXbDv0Mw0uWK2RYOGi-euWvYpR1g@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
Cc: "SIPCORE (Session Initiation Protocol Core) WG" <sipcore@ietf.org>, Parthasarathi R <partha@parthasarathi.co.in>
Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE: I-D Action: draft-ietf-sipcore-sip-websocket-09.txt]
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 12:06:47 -0000

I would not use RFC 3261 as justification for what should, or should not, be said about authentication. The current RFC 3261 would probably fail a security directorate review if it was attempted to be approved as an RFC now.

(I'd also point out that for any security consideration of RFC 3261, one should also read RFC 5630.)

So I would suggest you conduct an independent security evaluation of what is needed.

For the use case you give:

> A website (a shop) offers a widget in which the visitor can click and
> made a SIP call (+WebRTC) that will end in the callcenter of the
> company, answered by an agent that will inform the user about the
> product he is interested in. Why do we require WWW or SIP
> authentication in this scenario?

I'd suggest that the issue to be discussed is what happens when the action described results in a transaction of some form to a third party (in the SIP case a call). The visitor then includes information that will be relayed to the third party. Who does the third party rely on to ensure that information is authentically given by the visitor.

Regards

Keith



> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
> Of Iñaki Baz Castillo
> Sent: 19 June 2013 12:32
> To: Saúl Ibarra Corretgé
> Cc: SIPCORE (Session Initiation Protocol Core) WG; Parthasarathi R
> Subject: Re: [sipcore] No WebSocket level authentication scenario [was RE:
> I-D Action: draft-ietf-sipcore-sip-websocket-09.txt]
> 
> 2013/6/19 Saúl Ibarra Corretgé <saul@ag-projects.com>:
> > Why is authentication a MUST? Lets assume that I'm using UDP and my
> proxy establishes a WS connection with a foreign domain's proxy because of
> NAPTR and my proxy supports acting as a WS client. It obviously won't be
> able to authenticate. If this scenario supposed to be covered?
> 
> Honestly I agree. I cannot find in RFC 3261 (or other RFCs) a
> normative statement mandating authentication, regardless the request
> comes from a UA.
> 
> In another thread we are discussing about MTI authentication
> mechanisms that must be implemented by SIP WS Clients and Servers.
> IMHO that is correct, but mandating SIP authentication or WWW
> authentication for ALL the scenarios seem innapropriate for me. I come
> back to an use case:
> 
> A website (a shop) offers a widget in which the visitor can click and
> made a SIP call (+WebRTC) that will end in the callcenter of the
> company, answered by an agent that will inform the user about the
> product he is interested in. Why do we require WWW or SIP
> authentication in this scenario?
> 
> If WG agrees with this, I will remove the normative statements in
> "Authentication" section, and instead address the MTI authentication
> mechanisms.
> 
> 
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore