Re: [TLS] the use cases for GSS-based TLS and the plea for

Martin Rex <Martin.Rex@sap.com> Fri, 20 July 2007 18:28 UTC

Return-path: <tls-bounces@lists.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxDh-0005cP-EQ; Fri, 20 Jul 2007 14:28:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBxDg-0005cJ-FH for tls@ietf.org; Fri, 20 Jul 2007 14:28:52 -0400
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBxDf-0004qo-2x for tls@ietf.org; Fri, 20 Jul 2007 14:28:52 -0400
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA03496; Fri, 20 Jul 2007 20:28:25 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200707201828.l6KISQgI011525@fs4113.wdf.sap.corp>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
To: jaltman@secure-endpoints.com
Date: Fri, 20 Jul 2007 20:28:26 +0200
In-Reply-To: <46A0F72F.40800@secure-endpoints.com> from "Jeffrey Altman" at Jul 20, 7 01:55:59 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
X-SAP: out
X-SAP: out
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: Nicolas.Williams@sun.com, tls@ietf.org
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

Jeffrey Altman wrote:
> 
> Martin Rex wrote:
> > What I meant (and forgot to add) was "certificate-based credential
> > (self-signed when no PKI is used) as a mandatory to implement
> > feature for interoperability".
> >
> > If support of cert-based credentials is a mere MAY, then I am sure
> > there will be servers/services where installing or using a PKI
> > credential is impossible/defective/unusable, and you cannot complain
> > to the vendor because not-supporting it is fully compliant with the spec.
> >
> > Everyone will be happy when Kerberos can be used cross-organization
> > one day.  But until that day, I want to make sure that the customer
> > has the working alternative to use PKI when there is a need for it.

> Let me rephrase what you want:
> 
> * You do not want to require that a server certificate be used when a
> TLS_GSS cipher is selected

Nope.  I completely dislike the lack of orthogonality to TLS on
this issue.  I do NOT want the gssapi-over-tls require any particular
ciphersuite (instead work with those that are there and future ones),
and in particular I do this spec NOT want to define a new cipher
suite.


> 
> * You do want to require that all TLS implementations support for the
> certificate based ciphers

I want a mandatory to implement subset of ciphersuites.  SSLv3 had
this and from what Nico says, TLSv1.1 might still have it.
(I'm behind on TLS evlutionary changes).

> 
> Note that while we can standardize implementation requirements, we
> cannot standardize the deployment requirements. 

We can not require which buttons the customer presses on installation,
but we can require which buttons must be available to the customer for
installation/configuration. 


> 
> No one that is promoting TLS GSS wants to eliminate the use of
> certificate based TLS ciphers.  The purpose of adding the TLS GSS
> ciphers is to provide a solution for environments that certificate
> management costs exceed the costs of the pre-existing infrastructure.

I have _never_ disputed this motivation.  And I certainly do not
want to take this freedom away from the customer.  However, I clearly
want to deny the vendor a compliance tag for not providing a fully
functional option to the customer.


-Martin

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls