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