Re: [kitten] RFC2743 errata 4251
mrex@sap.com (Martin Rex) Tue, 16 December 2014 21:55 UTC
Return-Path: <mrex@sap.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC3F11A8736 for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 13:55:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.551
X-Spam-Level:
X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 AwV-HWtOvYAZ for <kitten@ietfa.amsl.com>; Tue, 16 Dec 2014 13:55:47 -0800 (PST)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A2E1A007A for <kitten@ietf.org>; Tue, 16 Dec 2014 13:55:47 -0800 (PST)
Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id DACE13A48F; Tue, 16 Dec 2014 22:55:44 +0100 (CET)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id A97834189E; Tue, 16 Dec 2014 22:55:44 +0100 (CET)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9E7EB1B087; Tue, 16 Dec 2014 22:55:44 +0100 (CET)
In-Reply-To: <20141215231340.GN3241@localhost>
To: Nico Williams <nico@cryptonector.com>
Date: Tue, 16 Dec 2014 22:55:44 +0100
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20141216215544.9E7EB1B087@ld9781.wdf.sap.corp>
From: mrex@sap.com
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Ru7mFbU0ToBwZ-HqftAB-AT3Dr8
Cc: kitten@ietf.org
Subject: Re: [kitten] RFC2743 errata 4251
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Tue, 16 Dec 2014 21:55:50 -0000
Nico Williams wrote: > On Mon, Dec 15, 2014 at 10:59:39PM +0100, Martin Rex wrote: > > The "early message protection" facilities will only ever succeed > > for early message protection (gss_wrap(), gss_getmic()), but will _never_ > > succeed for early message un-protection (gss_unwrap(), gss_verifymic()). > > RFC2743, page 26, contradicts you on this: No, this does not really contract me. :) > > For context establishment calls, this state Boolean is valid and > interpretable when the associated major_status is either > GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both > initiators and acceptors) can assume that per-message protection (via > -> GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is > available and ready for use if either: prot_ready_state == TRUE, or > major_status == GSS_S_COMPLETE, though mutual authentication (if > requested) cannot be guaranteed until GSS_S_COMPLETE is returned. The original purpose, semantics and security guarantees of GSS-API per-message protection services are *NOT* changed by PROT_READY. The original purpose and semantics (quoting rfc2743): Per-message GSS_Wrap() and GSS_Unwrap() calls provide the data origin authentication and data integrity services which GSS_GetMIC() and GSS_VerifyMIC() offer, and also support selection of confidentiality services as a caller option. or another quote from rfc2743: The GSS-API per-message integrity and data origin authentication services provide assurance to a receiving caller that protection was applied to a message by the caller's peer on the security context, corresponding to the entity named at context initiation. The GSS-API per-message confidentiality service provides assurance to a sending caller that the message's content is protected from access by entities other than the context's named peer. PROT_READY was never conceived to preempt any actually requested authentication or to neuter message protection services from data origin authentication--in case that this characteristic will be provided should security context establishment succeed with GSS_S_COMPLETE. rfc2743 acknowledges that prot_ready may cause message (un)protection to precede _confirmation_ of mutual authentication (back to the initiator), but not preempt mutual authentication (allowing the acceptor to get at the contents of confidentiality protected messages without actually succeeding authentication when mutual authentication is requested. What is a little less clear: what does this mean for the "simple" form of authentication, the unidirectional authentication from initiator to target, for gssapi mechanisms other than, say, Kerberos. > > And this makes plenty of sense too. I have my doubts. In the original design, TLS also does not allow application data to be sent prior to the verification of the server's Finished handshake message. There are hacks such as FALSE START, but AFAIK they at least still try to ensure not to leak application data to the server unless the server can successfully complete the TLS handshake (i.e. pass the authentication). Only confirmation of the Server passing the handshake gets delayed. > > Consider a mechanism that does a key exchange using ephemeral-ephemeral > DH in one round trip but nonetheless requires several more round trips > to complete authentication. The early prot_ready protection could be > available several context tokens prior to full establishment, > and this could be quite useful. And it will provide *MORE* than enough rope to apps to hang themselves... -Martin
- [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Stephen Farrell
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Martin Rex
- Re: [kitten] RFC2743 errata 4251 Stephen Farrell
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Jeffrey Hutzelman
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Benjamin Kaduk
- Re: [kitten] RFC2743 errata 4251 Nico Williams
- Re: [kitten] RFC2743 errata 4251 Greg Hudson
- Re: [kitten] RFC2743 errata 4251 Jeffrey Hutzelman