Re: KITTEN: IETF 75 - 76
Martin Rex <Martin.Rex@sap.com> Wed, 19 August 2009 22:11 UTC
Return-Path: <Martin.Rex@sap.com>
X-Original-To: kitten@core3.amsl.com
Delivered-To: kitten@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25DC23A6D48 for <kitten@core3.amsl.com>; Wed, 19 Aug 2009 15:11:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.781
X-Spam-Level:
X-Spam-Status: No, score=-5.781 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 xLqJZL08+Hh8 for <kitten@core3.amsl.com>; Wed, 19 Aug 2009 15:11:03 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 275573A6810 for <kitten@ietf.org>; Wed, 19 Aug 2009 15:11:02 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n7JMB6sC010688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Aug 2009 00:11:07 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200908192211.n7JMB5d3007759@fs4113.wdf.sap.corp>
Subject: Re: KITTEN: IETF 75 - 76
To: Nicolas.Williams@sun.com
Date: Thu, 20 Aug 2009 00:11:05 +0200
In-Reply-To: <20090819203055.GJ1043@Sun.COM> from "Nicolas Williams" at Aug 19, 9 03:30:56 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: kitten@ietf.org, Shawn.Emery@sun.com, Martin.Rex@sap.com
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Aug 2009 22:11:05 -0000
Nicolas Williams wrote: > > > And a communication might > > go entirely unidirectional after security context establishment > > for the rest of its lifetime (e.g. the data channel of an FTP > > with GSS-API extensions). > > That's an app protocol problem (see previous caveats that re-keying > _obviously_ would require app protocol changes). When I built our application framing protocol for exchanging GSS-API protected data in 1996, I added a capability for security context refresh into that framing protocol in order to support security context refresh for the Kerberos 5 gssapi mechanism, because rfc1964 compliant Kerberos 5 mechanisms expire their security contexts. (Microsoft tried it during W2K beta3 to enforce security context expiration in their Kerberos 5 SSP, but it created operational problems which none of their apps was able to cope with, that they reverted that change in W2K rc1). When the security context lifetime drops below a certain threshold, my app will poll the validity of the credentials to check whether they are valid longer than the remaining security context lifetime, it will then periodically attempt to refresh the security context prior to sending protected messages on a security context that is close to expiration. When the establishment of a new security context succeeds (same target and src_name), then the old security context is deleted and the new one is used for the protection of future messages. Technically, this has always been possible with all existing gssapi mechanisms at the application level. Just that hardly anyone seems to be doing it. The issues one has to deal with are: Unavailability of credentials, credentials expiration, failure to establish a new security context (the previous one is still around), not getting into a deadly embrace when the server wants the client to do a refresh, but the client is unable (or unwilling) to comply. Stuffing parts of that below gssapi will significantly increase the complexity of a gssapi mechanis, the gss-api semantics, need additional API-calls -- while still requiring significant changes/support from the application side. IMHO -- if the functionality is needed, it can be, and should be built at the application level entirely -- and it will work just fine with all existing gssapi mechanisms. -Martin
- KITTEN: IETF 75 - 76 Shawn M Emery
- Re: KITTEN: IETF 75 - 76 Alexey Melnikov
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Leif Johansson
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Martin Rex
- Re: KITTEN: IETF 75 - 76 Martin Rex
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Martin Rex
- Re: KITTEN: IETF 75 - 76 Martin Rex
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Martin Rex
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Martin Rex
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Martin Rex
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Michael B Allen
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Shawn M Emery
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Michael B Allen
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Michael B Allen
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Stefan (metze) Metzmacher
- Re: KITTEN: IETF 75 - 76 Michael B Allen
- Re: KITTEN: IETF 75 - 76 Love Hörnquist Åstrand
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Michael B Allen
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Michael B Allen
- Re: KITTEN: IETF 75 - 76 Jeffrey Hutzelman
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Jeffrey Hutzelman
- Re: KITTEN: IETF 75 - 76 Michael B Allen
- Re: KITTEN: IETF 75 - 76 Nicolas Williams
- Re: KITTEN: IETF 75 - 76 Jeffrey Hutzelman
- Re: KITTEN: IETF 75 - 76 Volker Lendecke
- Re: KITTEN: IETF 75 - 76 Volker Lendecke