Re: [Sipping] I-D Action:draft-kaplan-sipping-pai-responses-00.txt

"Elwell, John" <john.elwell@siemens.com> Mon, 01 December 2008 12:00 UTC

Return-Path: <sipping-bounces@ietf.org>
X-Original-To: sipping-archive@optimus.ietf.org
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B57083A68EB; Mon, 1 Dec 2008 04:00:09 -0800 (PST)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 232E43A68EB for <sipping@core3.amsl.com>; Mon, 1 Dec 2008 04:00:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.534
X-Spam-Level:
X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig7fCjnPmdaD for <sipping@core3.amsl.com>; Mon, 1 Dec 2008 04:00:07 -0800 (PST)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 306823A63EC for <sipping@ietf.org>; Mon, 1 Dec 2008 04:00:06 -0800 (PST)
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KB60051SWZ40E@siemenscomms.co.uk> for sipping@ietf.org; Mon, 01 Dec 2008 08:59:28 +0000 (GMT)
Date: Mon, 01 Dec 2008 08:59:27 +0000
From: "Elwell, John" <john.elwell@siemens.com>
In-reply-to: <E6C2E8958BA59A4FB960963D475F7AC31374B1F20F@mail>
To: Hadriel Kaplan <HKaplan@acmepacket.com>, sipping <sipping@ietf.org>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0014F2EBD@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: I-D Action:draft-kaplan-sipping-pai-responses-00.txt
Thread-Index: AclSSwAUefB1f4gPQCGcYR1WCXbbpQBRrEKQ
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <E6C2E8958BA59A4FB960963D475F7AC31374B1F20F@mail>
Cc: Cullen Jennings <fluffy@cisco.com>
Subject: Re: [Sipping] I-D Action:draft-kaplan-sipping-pai-responses-00.txt
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Hadriel,

Thanks for writing this. However, in my opinion it still suffers from
the same problem that we had with update-pai-06 (where we just said that
the proxy must have authenticated the source of the response by some
means) and update-pai-05 (where we cited one possible circumstance where
authentication could be assumed, i.e., when an earlier request over the
same TLS connection had been digest-authenticated). We received
objections to 06 because it did not cite at least one example of how to
achieve authentication and we received objections to 05 because the
mechanism is broken (there could be an intermediary that terminates the
TLS connection, so there is no guarantee that the UA that was previously
authenticated is the same as the UA that sends the response).

I think there are only two ways forward on this:
1. Somebody comes up with some text that describes a plausible way of
achieving authentication using present mechanisms. For example, if my
understanding is correct, I think the 3GPP mechanism relies on using the
same credentials for authenticating the UA and the underlying transport,
and hence the broken behaviour I described above does not apply. I
really wanted somebody else to provide some text, and I had hoped Keith
would do this.
2. We define a new mechanism. It has been stated that something based on
sip-outbound might be possible, but I don't really know what people have
in mind. As Cullen observes, this approach would most likely need to be
pursued in SIP rather than SIPPING.

John
 

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] 
> Sent: 29 November 2008 17:51
> To: sipping
> Cc: Elwell, John; Cullen Jennings
> Subject: I-D Action:draft-kaplan-sipping-pai-responses-00.txt
> 
> Howdy,
> At the most recent IETF meeting in Minneapolis, we were 
> informed that a WG decision regarding support for PAI in 
> responses in draft-ietf-sipping-update-pai had been reached 
> on the mailing list, and the decision was not to support 
> them.  I was instructed to submit a new draft if I wished to 
> propose any such support.  I have now done so.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-kaplan-sipping-pai-r
> esponses-00.txt
> 
> Of course any comments are welcomed and appreciated.
> 
> -hadriel
> p.s. and thanks to John Elwell for (unknowingly) providing 
> most of the text for this draft, since it is based on 
> draft-ietf-sipping-update-pai.
> 
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP