[drinks] Your DISCUSS on draft-ietf-drinks-spp-protocol-over-soap

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Mon, 23 March 2015 15:13 UTC

Return-Path: <alexander.mayrhofer@nic.at>
X-Original-To: drinks@ietfa.amsl.com
Delivered-To: drinks@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6CA11A8A09 for <drinks@ietfa.amsl.com>; Mon, 23 Mar 2015 08:13:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.741
X-Spam-Level:
X-Spam-Status: No, score=-5.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQUL8T-AjrkJ for <drinks@ietfa.amsl.com>; Mon, 23 Mar 2015 08:13:00 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D414E1A89AE for <drinks@ietf.org>; Mon, 23 Mar 2015 08:12:59 -0700 (PDT)
Received: from nics-exch2.sbg.nic.at ([10.17.175.6]) by mail.sbg.nic.at over TLS secured channel (TLSv1:AES128-SHA:128) with XWall v3.50 ; Mon, 23 Mar 2015 16:12:58 +0100
Received: from NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57]) by NICS-EXCH2.sbg.nic.at ([fe80::a5b2:6e42:e54d:9d57%12]) with mapi id 14.03.0224.002; Mon, 23 Mar 2015 16:12:54 +0100
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>
Thread-Topic: Your DISCUSS on draft-ietf-drinks-spp-protocol-over-soap
Thread-Index: AdBlearalYCS87AcQ0eGC/oL2ITwYg==
Date: Mon, 23 Mar 2015 15:12:53 +0000
Message-ID: <19F54F2956911544A32543B8A9BDE075467854F5@NICS-EXCH2.sbg.nic.at>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.3.2]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-XWALL-BCKS: auto
Archived-At: <http://mailarchive.ietf.org/arch/msg/drinks/Vs5xJeYJe7vd6ui1m40E-WK9Nio>
Cc: "drinks@ietf.org" <drinks@ietf.org>
Subject: [drinks] Your DISCUSS on draft-ietf-drinks-spp-protocol-over-soap
X-BeenThere: drinks@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DRINKS WG <drinks.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/drinks>, <mailto:drinks-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/drinks/>
List-Post: <mailto:drinks@ietf.org>
List-Help: <mailto:drinks-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/drinks>, <mailto:drinks-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2015 15:13:02 -0000

Hello Stephen,

You raised a DISCUSS around the use of Digest Authentication in the DRINKS SOAP transport
(https://datatracker.ietf.org/doc/draft-ietf-drinks-spp-protocol-over-soap/)

Specifically, you asked whether the WG considered client certificates as the authentication method. 
The WG had extensive "design team" discussions since 2009, and from what i remember (i couldn't find 
it in the minutes), the discussions about client certificates mostly based on experience with EPP (the 
Extensible Provisioning Protocol). EPP "sort of" requires client certificates (See Section 6 of RFC 5734), 
but in practical, almost none of the deployments of EPP in the field require a client to present a 
certificate. 

We wanted to avoid a similar situation with SPPP, and - with the practical experience from EPP - therefore
didn't want to require client certificate based authentication. Furthermore, we wanted to reduce the variety 
of authentication methods a client / server needs to implement to foster interopability (we were fearing a 
"mandatory to implement" style discussion, and hence agreed to used Digest only).

The text that is now in the document was based on feedback of the document's WGLC in 2012:
https://www.ietf.org/mail-archive/web/drinks/current/msg01233.html

If the explanation above  doesn't address your concerns, would adding text that allows "authentication methods with similar security properties" (I'm not sure whether that is too vague, and it also wouldn't address the concern of interopability) address that issue?

Also, i'm around in Dallas until Friday noon - so i'm more than happy to discuss this in person, if you have time? It would be great if we could resolve this over the next days, because we want to  finally get the documents "out of the door" so that Richard can shut down the WG :)

thanks,
Alex Mayrhofer