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

Martin Rex <Martin.Rex@sap.com> Fri, 20 July 2007 18:19 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 1IBx4f-0006EH-B7; Fri, 20 Jul 2007 14:19:33 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBx4d-00063I-Vl for tls@ietf.org; Fri, 20 Jul 2007 14:19:32 -0400
Received: from smtpde01.sap-ag.de ([155.56.68.171]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBx4d-0000Np-BA for tls@ietf.org; Fri, 20 Jul 2007 14:19:31 -0400
Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA21064; Fri, 20 Jul 2007 20:19:24 +0200 (MESZ)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200707201819.l6KIJOFW010809@fs4113.wdf.sap.corp>
Subject: Re: [TLS] the use cases for GSS-based TLS and the plea for
To: Nicolas.Williams@sun.com
Date: Fri, 20 Jul 2007 20:19:24 +0200
In-Reply-To: <20070720175053.GL26603@Sun.COM> from "Nicolas Williams" at Jul 20, 7 12:50:53 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: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Cc: Martin.Rex@sap.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

Nicolas Williams wrote:
> 
> On Fri, Jul 20, 2007 at 07:40:34PM +0200, 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.
> 
> I don't think this spec aims to change TLS 1.1 to make any current
> cipher suites that are REQUIRED to implement no longer REQUIRED to
> implement.  Nor would I support that, for interop reasons, of course.

This isn't about what the TLS implementation supports, but what
subset of the TLS implementations features a server/service
is able to use.

The hard part of the work isn't the code, it is the configuration
and administrative UI stuff.

As I wrote in previous Emails, I think the gssapi-over-tls authentication
should be put into a module "TLSplus" above a mostly vanilla TLS and next
to completely vanilla GSS-API and look like a normal TLS for the
application caller.  Implementors will probably use different approaches,
some will not provide seperate module and not be able to plug'n'play
gssapi mechanisms.  Others may want to offer exactly this modularization,
and especially the gss-api plug'n'play.

For the architecture I've been trying to describe, ABI issues and
binary plug'n'play is fairly easy compared to the interoperability
issues among independent implementations (at least if you do a certain
level of QA on the API -- tough luck, Solaris Kerberos included
SunOS 5.9 still contains numerous API-level bugs in the GSS-API
they should consider adopting several 10-year old fixes from MIT
Kerberos GSS-API).

-Martin

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