From nobody Fri Aug 1 00:54:36 2014 Return-Path: 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 4D24A1A0467 for ; Fri, 1 Aug 2014 00:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, 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 dkBGy6v2Dywh for ; Fri, 1 Aug 2014 00:54:28 -0700 (PDT) Received: from officesmtp2.one.com (officesmtp2.one.com [195.47.247.17]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 501C81A0463 for ; Fri, 1 Aug 2014 00:54:28 -0700 (PDT) Received: from [172.16.16.74] (unknown [46.30.211.29]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by officesmtp2.one.com (Postfix) with ESMTPSA id E93D1801173B3 for ; Fri, 1 Aug 2014 07:54:25 +0000 (UTC) Message-ID: <53DB47B1.6080204@one.com> Date: Fri, 01 Aug 2014 09:54:25 +0200 From: Peter Mogensen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: kitten@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LUEDDMDNVvBSkyCv7zV5otHSPHY Subject: Re: [kitten] CAMMAC review comments X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 07:54:33 -0000 On 2014-07-31 21:00, Simo Sorce wrote: > I think the kdc-verifier could be made optional, though I am not sure > why anyone would go through the trouble of disabling it using complex > heuristics to save a few bytes unless the CAMMAC payload is very small. Referencing our earlier discussion about how to make everything simpler and smaller (and why that was not easy withing the framework of RFC4120). Small CAMMAC payloads will not be rare. If you have a plain ticket without authdata and only need to add RFC6806 NT-ENTERPRISE capabilities, then protecting AD-LOGIN-ALIAS which can easily be around just 10 bytes, will have a checksum around 100 bytes. (*) Putting a few of those tickets in - say - an HTTP cookie will add considerably to the HTTP header size. (HTTP/2.0 would help a lot then) I don't think one should underestimate the value of small tickets. /Peter *: I know RFC6806 explicitly calls for AD-KDC-ISSUED, but one could easily imagine wanting to protect AD-LOGIN-ALIAS through S4U2proxy delegation too. From nobody Fri Aug 1 09:54:51 2014 Return-Path: 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 530EC1B282A for ; Fri, 1 Aug 2014 09:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 iCEqf805XGqN for ; Fri, 1 Aug 2014 09:54:43 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DF271B2839 for ; Fri, 1 Aug 2014 09:54:42 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-bb-53dbc6512ff1 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id E9.A7.24022.156CBD35; Fri, 1 Aug 2014 12:54:41 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s71Gseeb014575; Fri, 1 Aug 2014 12:54:41 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s71Gsdqr028258; Fri, 1 Aug 2014 12:54:40 -0400 From: Tom Yu To: Greg Hudson References: <53D7DBE2.3010105@mit.edu> Date: Fri, 01 Aug 2014 12:54:38 -0400 In-Reply-To: <53D7DBE2.3010105@mit.edu> (Greg Hudson's message of "Tue, 29 Jul 2014 13:37:38 -0400") Message-ID: Lines: 17 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixG6noht47HawQfdqZYuvbQ/YLI5uXsXi wOSxZMlPJo+VU0+zBzBFcdmkpOZklqUW6dslcGUsf/2PqeAkW8Wv50tZGhhXs3YxcnJICJhI 3H2+ixHCFpO4cG89WxcjF4eQwGwmicWrbrFAOBsYJRrnrYXKvGaUaJvRCdTCwcEmIC1xdHEZ SLeIgKLEs1VzWUBsZgEriV9dB8GmCgvYSLzZPZ8VpFxIwEGidbExSJhFQFXi3Y33zCA2p0Ca xPHudWAH8QroSnxtuMQOYvMIcEqcnLmVDSIuCGQ/gRqvJXHj30umCYwCs5CkZiFJLWBkWsUo m5JbpZubmJlTnJqsW5ycmJeXWqRrqJebWaKXmlK6iREUjpySPDsY3xxUOsQowMGoxMN7Y/ft YCHWxLLiytxDjJIcTEqivD1HgEJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeLdtA8rxpiRWVqUW 5cOkpDlYlMR531pbBQsJpCeWpGanphakFsFkZTg4lCR4VY8CNQoWpaanVqRl5pQgpJk4OEGG 8wAN1wep4S0uSMwtzkyHyJ9i1OVYtP9lN5MQS15+XqqUOG8ryHUCIEUZpXlwc2Bp5BWjONBb whDreIApCG7SK6AlTEBLagzBlpQkIqSkGhizr76YfmTZcd3lZzKXnFGLEIvt3PT5Z36o1Zk9 7gn8setW3H7/y+1g673/yYqLT+b1Zkjef/FF9fx231d9lyP3Ff3gim/QcPvbst6zVLea82Xa s/NuXYr5LhOetJeKfVcNy9fv4vwZ4b95D6f7qrN6X179zg5yDFnyZEuC98Ln6g1n+69YPnqp xFKckWioxVxUnAgAEQuXm/4CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TuqRJefzUM5j26x11sbAqzAcNJY Cc: kitten@ietf.org, Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 16:54:49 -0000 Greg Hudson writes: > My preference is to: > > * Advise that CAMMACs be put inside AD-IF-RELEVANT. > > * Specify that authdata contained within a CAMMAC should be considered > non-critical. (That is, you don't have to wrap everything inside a > CAMMAC in AD-IF-RELEVANT.) RFC 4120 already does this for AD-KDC-ISSUED > (section 5.2.6.2, last paragraph), presumably under the assumption that > it is used for positive rather than negative authdata. I agree that AD-CAMMAC should have the same effect on the criticality of its contents as AD-KDC-ISSUED. We can recommend that a CAMMAC be put in AD-IF-RELEVANT if it is likely that the consuming service won't understand it. The KDC might have enough knowledge of the capabilities of the service that the extra layer of wrapping might not be necessary. From nobody Fri Aug 1 10:13:06 2014 Return-Path: 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 DAD7E1B2840 for ; Fri, 1 Aug 2014 10:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 DCF4xgycaDxf for ; Fri, 1 Aug 2014 10:12:58 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA7A1B284F for ; Fri, 1 Aug 2014 10:12:40 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 9082526405D for ; Fri, 1 Aug 2014 10:12:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pIr1N5o7qzCpaWhSEUxk fR+IaO8=; b=fbgmAJSxBcXwdDqIzzV0olO/QNosnQsyFuqffmmfiNEs+7+59l4Z +jD/PCJiBcD/EJJDji4d8g7Cpg2lTc/+CvWyuGRwsevQhDP0MpyNn2P+97dhXi/P sPgH2zHiR7M7nmR+OWC2VC4/Iq4Bn2rhHgKzd0SRpGjyM534n/YPa/Q= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPSA id 43E42264059 for ; Fri, 1 Aug 2014 10:12:39 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so4558418wgh.5 for ; Fri, 01 Aug 2014 10:12:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.241 with SMTP id b17mr8769111wik.70.1406913157647; Fri, 01 Aug 2014 10:12:37 -0700 (PDT) Received: by 10.217.98.6 with HTTP; Fri, 1 Aug 2014 10:12:37 -0700 (PDT) In-Reply-To: References: <53D7DBE2.3010105@mit.edu> Date: Fri, 1 Aug 2014 12:12:37 -0500 Message-ID: From: Nico Williams To: Tom Yu Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Jk13AHk358mtFx5q1anVFI1M4Yc Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 17:13:06 -0000 On Fri, Aug 1, 2014 at 11:54 AM, Tom Yu wrote: > I agree that AD-CAMMAC should have the same effect on the criticality of > its contents as AD-KDC-ISSUED. We can recommend that a CAMMAC be put in > AD-IF-RELEVANT if it is likely that the consuming service won't > understand it. The KDC might have enough knowledge of the capabilities > of the service that the extra layer of wrapping might not be necessary. I agree with this. Nico -- From nobody Fri Aug 1 11:45:52 2014 Return-Path: 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 639761A0303 for ; Fri, 1 Aug 2014 11:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 oNq0Rvr5Ejuq for ; Fri, 1 Aug 2014 11:45:44 -0700 (PDT) Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60F921B289F for ; Fri, 1 Aug 2014 11:45:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id D5DBC20179; Fri, 1 Aug 2014 14:45:33 -0400 (EDT) Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niU90LAMWBat; Fri, 1 Aug 2014 14:45:32 -0400 (EDT) Received: from carter-zimmerman.suchdamage.org (unknown [10.1.10.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 1 Aug 2014 14:45:32 -0400 (EDT) Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id D941381B18; Fri, 1 Aug 2014 14:45:32 -0400 (EDT) From: Sam Hartman To: Nico Williams References: <53D7DBE2.3010105@mit.edu> Date: Fri, 01 Aug 2014 14:45:32 -0400 In-Reply-To: (Nico Williams's message of "Fri, 1 Aug 2014 12:12:37 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ox8DUlPjm5MN62AfI2IZRb3TdRw Cc: "kitten@ietf.org" , Sam Hartman Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:45:51 -0000 >>>>> "Nico" == Nico Williams writes: Nico> On Fri, Aug 1, 2014 at 11:54 AM, Tom Yu wrote: >> I agree that AD-CAMMAC should have the same effect on the >> criticality of its contents as AD-KDC-ISSUED. We can recommend >> that a CAMMAC be put in AD-IF-RELEVANT if it is likely that the >> consuming service won't understand it. The KDC might have enough >> knowledge of the capabilities of the service that the extra layer >> of wrapping might not be necessary. Nico> I agree with this. I'm fine with this too. From nobody Fri Aug 1 12:13:34 2014 Return-Path: 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 D52331A0314 for ; Fri, 1 Aug 2014 12:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 l4zLmxGxUGYW for ; Fri, 1 Aug 2014 12:13:31 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 421FB1A01C3 for ; Fri, 1 Aug 2014 12:13:31 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-4f-53dbe6da249a Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id E1.A0.28072.AD6EBD35; Fri, 1 Aug 2014 15:13:30 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s71JDTaT006500; Fri, 1 Aug 2014 15:13:29 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s71JDRZ0009925; Fri, 1 Aug 2014 15:13:28 -0400 From: Tom Yu To: "Zheng\, Kai" References: <53799133.70201@oracle.com> <53BB8362.3010605@oracle.com> <8D5F7E3237B3ED47B84CF187BB17B666118FB2BB@SHSMSX103.ccr.corp.intel.com> Date: Fri, 01 Aug 2014 15:13:27 -0400 In-Reply-To: <8D5F7E3237B3ED47B84CF187BB17B666118FB2BB@SHSMSX103.ccr.corp.intel.com> (Kai Zheng's message of "Tue, 8 Jul 2014 07:58:58 +0000") Message-ID: Lines: 31 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNIsWRmVeSWpSXmKPExsUixCmqrHvr2e1gg2mN/BbrW0+zWBzdvIrF ou/1IXYHZo8lS34yeSze85LJ4+PTWywBzFFcNimpOZllqUX6dglcGRNedbIU3OWqeL3hI3MD 4x6OLkZODgkBE4kfp5rZIGwxiQv31gPZXBxCArOZJLr/P2GFcDYwSpz5sQgq85pRYtG7Zyxd jBwcbALSEkcXl4F0iwioS9xa0sUKYjMLREqcPLaFCcQWFrCUuPDqDyNEbz+jRO/DzcwgCRYB VYlpH58wgticAhMYJebfDwexeQV0JfZd7AMbxCPAKXGoZyUjRFxQ4uTMJywQC7Qkbvx7yTSB UWAWktQsJKkFjEyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdC30cjNL9FJTSjcxgsKU3UV1B+OE Q0qHGAU4GJV4eG/svh0sxJpYVlyZe4hRkoNJSZTX7CFQiC8pP6UyI7E4I76oNCe1+BCjBAez kgjvtm1AOd6UxMqq1KJ8mJQ0B4uSOO9ba6tgIYH0xJLU7NTUgtQimKwMB4eSBC8HMB6FBItS 01Mr0jJzShDSTBycIMN5gIbzgNTwFhck5hZnpkPkTzEqSonz3nkClBAASWSU5sH1wtLIK0Zx oFeEeflA2nmAKQiu+xXQYCagwTWGYINLEhFSUg2MNjPX9czSmrug8NLFTS/a/AsruIQFrO/P DQ/sZqswXseUuclE7GTv3Kxtt8Tz9xu56rHvsXl7fP6Rxq4L6yut+jPr1E4WfasTeJMxwb9x mQzHjzOHtWR2h7XWL3y9/ubO7ReNVllcn7XQ7sJqmzDtr8nci06c+/JrUvCy1h03flqq7G9a tTlyjxJLcUaioRZzUXEiAC3HJ5j+AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ipFnv26bjW7gV2zNHhX6AhElmfA Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 19:13:33 -0000 "Zheng, Kai" writes: > Regarding the following: > === > However, protocol extensions such as Constrained Delegation (S4U2Proxy > [MS-SFU]) require that a service present to the KDC a service ticket > that the service received from a client, as evidence that the client > authenticated to the service. In the S4U2Proxy extension, the KDC > uses the evidence ticket as the basis for issuing a derivative ticket > that the service can then use to impersonate the client. > === [...] > This forwardable service ticket might have been obtained by a > KRB_AP_REQ and come from the user client (the case mentioned here), or > by an S4U2self request (ignored here). Hi Kai, Thanks for your comment. I can see how apparently ignoring tickets obtained from S4U2Self could be distracting or confusing to a reader. Would the following text be better? However, protocol extensions such as Constrained Delegation (S4U2Proxy [MS-SFU]) require that a service present to the KDC a service ticket that the KDC previously issued, as evidence that the service is authorized to impersonate the client principal named in that ticket. In the S4U2Proxy extension, the KDC uses the evidence ticket as the basis for issuing a derivative ticket that the service can then use to impersonate the client. From nobody Fri Aug 1 14:35:30 2014 Return-Path: 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 3C4041A8BB7; Fri, 1 Aug 2014 11:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 nUA0_R_y-Len; Fri, 1 Aug 2014 11:43:55 -0700 (PDT) Received: from mx11.netapp.com (mx11.netapp.com [216.240.18.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C7961A0AEC; Fri, 1 Aug 2014 11:43:55 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,781,1400050800"; d="scan'208";a="137802567" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx11-out.netapp.com with ESMTP; 01 Aug 2014 11:43:56 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 1 Aug 2014 11:43:55 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 1 Aug 2014 11:43:48 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Fri, 1 Aug 2014 11:43:48 -0700 From: "Adamson, Andy" To: Benjamin Kaduk Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPrAU48wbIQBIMg0W+Un2kpIHDeZu5RFkAgAICJQCAAUfegA== Date: Fri, 1 Aug 2014 18:43:48 +0000 Message-ID: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> References: <20140730163006.GG26316@fieldses.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <1047DC416D537F44A478A831616DA887@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/dWJmW94JosKe5TqvoQjJdyea7EM X-Mailman-Approved-At: Fri, 01 Aug 2014 14:35:20 -0700 Cc: "J. Bruce Fields" , "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:44:01 -0000 On Jul 31, 2014, at 7:10 PM, Benjamin Kaduk wrote: > On Wed, 30 Jul 2014, J. Bruce Fields wrote: >=20 >> On Wed, Jul 30, 2014 at 02:47:44PM +0000, Adamson, Andy wrote: >>> Hello >>>=20 >>> I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, an= d he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten W= G as well as to the NFSv4 WG to solicit reviews. Please review the draft w= hich adds two new RPCSEC GSS operations and is a normative reference to dra= ft-ietf-nfsv4-minorversion2. >>>=20 >>> As we are working to finish draft-ietf-nfsv4-minorversion2 , please sub= mit your reviews by Aug 31, 2014. >>>=20 >>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3 >>=20 >> I'm confused by multi-principal authentication: >=20 > Ah, good, it's not just me. > Sorry I didn't catch this before sending my giant pile of comments. >=20 >> The RPCSEC_GSS_CREATE request should demonstrate that the caller knows >> both parent and child's credentials. That's easy for the parent since >> an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS request >> sent as the parent. >>=20 >> For the child the caller has to calculate the mic of a nonce using the >> child context, but as far as I can tell the choice of nonce is entirely >> up to the caller. >>=20 >> Couldn't it then just choose as the nonce some data that it had >> previously seen a mic for? If so, would it work to remove the nonce and >> instead calculate, say, a mic of the rpc header (as we do when >> calculating the verifier?). >=20 > Certainly it would help to include (something with) the sequence number, = as a proof of "liveness". We may have to brainstorm a bit. I have always thought of Multi-principal authentication in terms of it=92s = use in NFSv4.2 Inter server to server copy, where all of the RPCSEC_GSS_CRE= ATE messages MUST use rpc_gss_svc_privacy=92=85. Good catch Bruce. So for this attack to occur the rgmp_nonce must be re-used by the same rgmp= _handle (same user-principal).=20 Insisting on using a random number generator to create nounce could be by-p= assed by a bad implementation... Bruces suggestion of using the new reply verifier data (rpc-header) should = do the trick. Any objections to this approach? >=20 >> I'm not sure about the reply either: >>=20 >> On a successful reply, the rgss3_gss_mp_auth field in the >> rgss3_create_res reply uses the parent RPCSEC_GSSv3 context as >> the rgmp_handle, the same rgmp_nounce as was sent in the call >> data with the rgmp_nounce_mic created using the GSS-API security >> context associate with the parent handle. Verification of the >> rbg_nounce_mic by the initiator demonstrates that the target >> agrees to the multi-principal authentication. >>=20 >> "The target" here is ambiguous. =20 Well, this is RPCSECGSS speak. There is only one target, and one initiator.= For NFS, the initiator is the client and the target is the server. >> The reply is already authenticated as >> the parent, the problem again is authenticating as the child You must mean the Multi-principal =93inner=94 handle. There is no =93child=92 as the child handle is the result of the successful= RPCSEC_GSS_CREATE call, and we are defining how success is determined. >> , so I think >> it should be calculating a mic using the child context (maybe over the >> header data again, as in section 2.3?). The child handle is varified on the target (server) by a successful GSS_Ver= ifyMIC using the user-principal GSS context and the nounce. This exchange i= s the target=20 >=20 > In some sense at least, the server "owns" all the resources on it. It co= uld choose to hand out a user's data to the whole world if it felt like it,= but we have to trust that it will not. =20 Yes, true with any server at any level of security. > In particular, the server could decline to validate the nonce-MIC at all,= and grant access to anyone who claimed to be the user; we must trust that = it does the verification properly. (A proper verification confirms that th= e server does have a valid context handle for the inner context.) =20 Correct, and that verification is noted in the sentence prior to the quote = above - this obviously could be clearer. I could separate the two verificat= ions into two paragraphs. The target verifies the multi-principal authentication by verifying the rgmp_nouce_mic. =20 I can see that the following can be re-worded, and updated with a better no= unce (just as Bruce suggested). On a successful reply, the rgss3_gss_mp_auth field in the rgss3_create_res reply uses the parent RPCSEC_GSSv3 context as the rgmp_handle, the same rgmp_nounce as was sent in the call data with the rgmp_nounce_mic created using the GSS-API security context associate with the parent handle. Verification of the rbg_nounce_mic by the initiator demonstrates that the target agrees to the multi-principal authentication. > In that sense, this reply is just serving as a confirmation that the serv= er accepts the multi-authentication claim, and a simple boolean would have = the same effect, so long as it is authenticated. Yes >=20 > Labels and MAC make this more interesting than the oversimplified picture= I just painted, of course, and I agree that this exchange has room for imp= rovement. >=20 >> (Also, note the draft uses at least "nonce", "nounc", and "nounce", a >> spellcheck would help here.) Yikes - a simple spell check is certainly not asking too much - I wlll fix = this :) =97>Andy >=20 > Thank you for saying it :) >=20 > -Ben From nobody Fri Aug 1 14:35:31 2014 Return-Path: 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 C7F161A0303; Fri, 1 Aug 2014 11:46:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 psMmBMfk-bT6; Fri, 1 Aug 2014 11:46:31 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 385381A0378; Fri, 1 Aug 2014 11:46:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,781,1400050800"; d="scan'208";a="179518725" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 01 Aug 2014 11:46:15 -0700 Received: from HIOEXCMBX05-PRD.hq.netapp.com (10.122.105.38) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 1 Aug 2014 11:46:14 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 1 Aug 2014 11:46:14 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Fri, 1 Aug 2014 11:46:14 -0700 From: "Adamson, Andy" To: "J. Bruce Fields" Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPrAU48wbIQBIMg0W+Un2kpIHDeZu5RFkAgAICJQCAAAXcAIABQrCA Date: Fri, 1 Aug 2014 18:46:13 +0000 Message-ID: References: <20140730163006.GG26316@fieldses.org> <20140731233116.GA24040@fieldses.org> In-Reply-To: <20140731233116.GA24040@fieldses.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tvJDe0WtFNZFAGksq8PNCW-qask X-Mailman-Approved-At: Fri, 01 Aug 2014 14:35:23 -0700 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 18:46:37 -0000 On Jul 31, 2014, at 7:31 PM, J. Bruce Fields wrote: > On Thu, Jul 31, 2014 at 07:10:18PM -0400, Benjamin Kaduk wrote: >> On Wed, 30 Jul 2014, J. Bruce Fields wrote: >>=20 >>> On Wed, Jul 30, 2014 at 02:47:44PM +0000, Adamson, Andy wrote: >>>> Hello >>>>=20 >>>> I spoke with Shawn Emery (the Kitten WG Chair) last week at IETF 90, a= nd he agreed that I should cross-post the RPCSEC_GSSv3 draft to the Kitten = WG as well as to the NFSv4 WG to solicit reviews. Please review the draft = which adds two new RPCSEC GSS operations and is a normative reference to dr= aft-ietf-nfsv4-minorversion2. >>>>=20 >>>> As we are working to finish draft-ietf-nfsv4-minorversion2 , please su= bmit your reviews by Aug 31, 2014. >>>>=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcsec-gssv3 >>>=20 >>> I'm confused by multi-principal authentication: >>=20 >> Ah, good, it's not just me. >> Sorry I didn't catch this before sending my giant pile of comments. >>=20 >>> The RPCSEC_GSS_CREATE request should demonstrate that the caller knows >>> both parent and child's credentials. That's easy for the parent since >>> an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS reques= t >>> sent as the parent. >>>=20 >>> For the child the caller has to calculate the mic of a nonce using the >>> child context, but as far as I can tell the choice of nonce is entirely >>> up to the caller. >>>=20 >>> Couldn't it then just choose as the nonce some data that it had >>> previously seen a mic for? If so, would it work to remove the nonce an= d >>> instead calculate, say, a mic of the rpc header (as we do when >>> calculating the verifier?). >>=20 >> Certainly it would help to include (something with) the sequence >> number, as a proof of "liveness". We may have to brainstorm a bit. >=20 > Maybe I'm forgetting some part of the motivation here: >=20 > http://tools.ietf.org/html/draft-ietf-nfsv4-minorversion2-26#section-4.1= 0.1.1 >=20 > There might be something in the complete COPY protocol that makes this > work. Though I don't see it yet. Yes, the use of privacy on the RPCSEC_GSS_CREATE calls due to the shared se= crete being passed in the Structured Privilege assertions.=20 >=20 > At a minimum we could use some more explanation in this draft. I agree we need to make Multi-principal authentication assertions secure al= l by itself - and not require privacy. =97>Andy >=20 > --b. From nobody Fri Aug 1 14:35:33 2014 Return-Path: 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 3E3A71B28CE; Fri, 1 Aug 2014 13:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 h_oX9LL8jDHD; Fri, 1 Aug 2014 13:28:28 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A155B1B28CF; Fri, 1 Aug 2014 13:28:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,782,1400050800"; d="scan'208";a="98348510" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx2-out.netapp.com with ESMTP; 01 Aug 2014 13:28:28 -0700 Received: from HIOEXCMBX01-PRD.hq.netapp.com (10.122.105.34) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 1 Aug 2014 13:28:28 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.913.22; Fri, 1 Aug 2014 13:28:26 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Fri, 1 Aug 2014 13:28:26 -0700 From: "Adamson, Andy" To: Nico Williams Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPrAU48wbIQBIMg0W+Un2kpIHDeZu7PYKAgAB5yoCAAPRMgA== Date: Fri, 1 Aug 2014 20:28:25 +0000 Message-ID: <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> References: <20140801055401.GA7409@localhost> In-Reply-To: <20140801055401.GA7409@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/OsupmLyi_3XZSpXM9DerXMd4Mqk X-Mailman-Approved-At: Fri, 01 Aug 2014 14:35:25 -0700 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 20:28:32 -0000 On Aug 1, 2014, at 1:54 AM, Nico Williams wrote: > On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: >> Hmm, this seems to have gotten rather long. =20 Well, it=92s two pages shorter than draft-williams-rpcsecgssv3-02.txt (!) >> The most important part >> is near the top, just after the refresher on the RPCSEC_GSS >> protocol. >=20 > I may reply in bite sizes :) >=20 >> [...] >> Three levels of protection are provided for the RPC bodies, none, >> integrity, and privacy. The choice of level for this attempt at >> this RPC, as well as a sequence number unique to this transmission, >> are encoded into the "credential", a part of the RPC request header; >> there is a GSS MIC over the header, so the header (and protection >> level and sequence number) are always protected. The request >> payload's encoding depends on the level; for none, it is unchanged. >> [...] >=20 > Though "none" always MICs the header. >=20 >> Multi-principal authentication >>=20 >> This draft proposes a multi-principal authentication scheme, >> restricted to just the case of a privileged client process on a >=20 > No, not only the case of a privileged client process. Sure, but for the Multi-principal piece we do say the following which says = that the use-case is privileged client process=85. RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of the client host principal and a user principal. This feature is needed, for example, when a client wishes to use authority assertions that the server may only grant if a user and a client are authenticated together to the server. Thus a server may refuse to grant requested authority to a user acting alone (e.g., via an unprivileged user-space program),=20 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6 or to a client acting alone (e.g. when a client is acting on behalf of a user) but may grant requested authority to a client acting on behalf of a user if the server identifies the user and trusts the client. It is assumed that an unprivileged user-space program would not have Adamson & Williams Expires December 29, 2014 [Page 10] ^L Internet-Draft NFSv4 June 2014 access to client host credentials needed to establish a GSS-API security context authenticating the client to the server, therefore an unprivileged user-space program could not create an RPCSEC_GSSv3 RPCSEC_GSS_CREATE message that successfully binds a client and a user security context. >=20 > RPCSEC_GSSv3 wants to solve TWO problems: >=20 > - cache poisoning attacks on the client by the user > - secure conveyance of privilege information for processes running with > more or even LESS privilege than the user normally would be accorded >=20 > Therefore we envision that RPCSEC_GSSv3 will *always* be used to > establish security contexts on any ONC RPC client where the client can > avail itself of a credential distinct from the user's. >=20 >> machine combining the (privileged) host's credentials with the >> (unprivileged) user's credentials so as to take action on behalf of >> the user. This is a similar combination to that we are using for >> RXGK_AFSCombineTokens (see draft-wilkinson-afs3-rxgk-afs), >=20 > Yes, it is similar to rxgk. >=20 >> restricted to just a combination of host and user credentials, >> specifying which one is which. I think this is the only >> well-understood scenario for compount authentication at the moment, >> and makes sense. >=20 > What is the antecedent of "this" here? Did you mean that conveying > local privilege information is not understood? >=20 >> The key material from the host's GSS context are used unchanged for >> securing RPCs issued with the combined identity, but the opaque >> RPCSEC_GSS context handle is changed to indicate that it represents >> a "child" context which has the combined identity (and possibly >=20 > A new context results. >=20 >> other attributes as well, not relevant for multi-principal >> authentication). The creation of the child context involves sending >=20 > Yes. >=20 >> an authenticated RPC using the parent/host-credential context, >> containing body data including a random nonce and the MIC of that >> nonce using the "inner" context (i.e., the user's credentials). The >> reply contains the same nonce, but the MIC in the reply is performed >> using the parent/host-credentials context. The RPC to create the >> child context is not permitted over a plaintext channel, and >> requires either integrity protection, confidentiality+integrity >> protection, or channel binding to a secure channel. >=20 > Eh? No, confidentiality is neither needed nor called for for context > establishment. >=20 >> However, I don't think this is strong enough; I think this scheme >> requires the "privacy" level of protection. Otherwise, an attacker >> could replay the nonce+MIC and obtain an RPCSEC_GSS context that >> will authenticate as the user from the "inner" context, without >> actually proving that it possesses the user's credentials. In >=20 > The client's credentials are required to make progress. So you do need to be a =91privileged client process=92 - in order to use th= e client=92s machine credentials. > That stops > replay attacks. We need only bind things sufficiently to the new > RPCSEC_GSS security context handle and the client credentials. An evil user that can get root on a client machine wouldn=92t need to bothe= r with intercepting a nounce - it could simply create it=92s own multi-prin= cipal RPCSEC_GSS_CREATE call because besides having access to the client ho= st principal creds and gss_context, it also has access to all active user-p= rincipal contexts in the GSS context cache. So adding protection for the no= unce is not required for the (currently only supported) case of client host= principal and user-principal multi-principal authentication. >=20 > Sure, if you're not using integrity protection for the payloads then an > attacker can hijack RPCs, but that was always true of RPCSEC_GSSv1. >=20 >> RXGK_AFSCombineTokens, we are not using (opaque) GSS credentials and >> can explicitly combine the key material for a strong proof of >> possession. GSS credentials are opaque, and the GSS-API does not >> really provide any primitives that seem applicable here. So, I would >> recommend requiring privacy protection for this call. >=20 > I'll have to take a look (Andy produced the latest update and it's been > a while since I've looked at RPCSEC_GSSv3), but IIRC it suffices to > provide integrity protection. This is the current wording: The client MUST use one of the following security services to protect the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message: o rpc_gss_svc_channel_prot (see RPCSEC_GSSv2 [4]) o rpc_gss_svc_integrity o rpc_gss_svc_privacy >=20 > More tomorrow. Thanks=20 =97>Andy >=20 > Nico > --=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 From nobody Fri Aug 1 15:15:40 2014 Return-Path: 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 797B01B28B6; Fri, 1 Aug 2014 15:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 EjRK8qKUALbF; Fri, 1 Aug 2014 15:15:38 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8C61A013B; Fri, 1 Aug 2014 15:15:38 -0700 (PDT) Received: from homiemail-a87.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTP id B85C226C063; Fri, 1 Aug 2014 15:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=0qeus2tHwHW/QddVl2BgsoPYUKM=; b=PaUqt1F0BPB fmpA4JztrpCkRB0GDIADdtD7kN71ZQ7HgX1xyTmnWKfEhkIXHO1zKLN/9O8d9jv1 N+TIfHPoVIy2u0KW0UMn9MpKvTXs1qRHAEiuLy/ek5ugY+vr2Z3zU6XesxboReZW 8+bEJyqtv2bYHFjNsjcR52cxyX6AgUcs= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a87.g.dreamhost.com (Postfix) with ESMTPA id 3E40626C05E; Fri, 1 Aug 2014 15:15:37 -0700 (PDT) Date: Fri, 1 Aug 2014 17:15:36 -0500 From: Nico Williams To: "Adamson, Andy" Message-ID: <20140801221535.GA3579@localhost> References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/stXpRQscg3jUfYA7s_OI8OYNT3A Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 22:15:39 -0000 On Fri, Aug 01, 2014 at 08:28:25PM +0000, Adamson, Andy wrote: > On Aug 1, 2014, at 1:54 AM, Nico Williams wrote= : > > On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: > >> Hmm, this seems to have gotten rather long. =20 >=20 > Well, it=E2=80=99s two pages shorter than draft-williams-rpcsecgssv3-02= .txt (!) :) > >> Multi-principal authentication > >>=20 > >> This draft proposes a multi-principal authentication scheme, > >> restricted to just the case of a privileged client process on a > >=20 > > No, not only the case of a privileged client process. >=20 > Sure, but for the Multi-principal piece we do say the following which s= ays that the use-case is privileged client process=E2=80=A6. It was always my intention that traditional (read: multi-user shared-cache) NFS client implementations would just always use "multi-principal" contexts when doing any RPCs on a user's behalf. That is, addressing the "user can impersonate the server to the client" problem was always my first and foremost goal with this protocol, though I didn't always say so explicitly (since at the time the attack was not well-known, I didn't want to publicize it). The conveyance of privilege (or under-privilege) is secondary, but extremely useful. (Was "multi-principal" my name for this? No, I called them compound authentication. I prefer "compound".) Local privilege or lack thereof is irrelevant to when compound authentication is to be used. The only relevant detail for that is: is the client trusting the server's response in any way that could compromise it or other users on the same client if the user on behalf of which the RPC is being done could impersonate the server. That's a mouthful, sorry (shorter version: shared-cache). > RPCSEC_GSSv3 clients MAY assert a multi-principal authentication of > the client host principal and a user principal. This feature is > needed, for example, when a client wishes to use authority assertion= s > that the server may only grant if a user and a client are > authenticated together to the server. Thus a server may refuse to > grant requested authority to a user acting alone (e.g., via an > unprivileged user-space program),=20 > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^6 That does not imply that compound contexts are only for privileged processes. Not at all. > >> However, I don't think this is strong enough; I think this scheme > >> requires the "privacy" level of protection. Otherwise, an attacker > >> could replay the nonce+MIC and obtain an RPCSEC_GSS context that > >> will authenticate as the user from the "inner" context, without > >> actually proving that it possesses the user's credentials. In > >=20 > > The client's credentials are required to make progress. >=20 > So you do need to be a =E2=80=98privileged client process=E2=80=99 - in= order to use > the client=E2=80=99s machine credentials. No. The client (the kernel, whatever) does it on behalf of the user. > > That stops > > replay attacks. We need only bind things sufficiently to the new > > RPCSEC_GSS security context handle and the client credentials. >=20 > An evil user that can get root on a client machine wouldn=E2=80=99t nee= d to > [...] Stop right there! We *always* assume local security when dealing with security protocols :) There's no need to state this assumption. It's bedrock. Kerberos, PKI, EAP, SSH, ... -- all assume local security, and can't do anything but assume local security. Obviously the cache poisoning problem is/can be a local security problem, but one we can address via a protocol like this. But we still assume local security in that protocol. Nico --=20 From nobody Fri Aug 1 15:45:15 2014 Return-Path: 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 288091B28D4; Fri, 1 Aug 2014 15:45:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 vgO-czivpOJj; Fri, 1 Aug 2014 15:45:09 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7BA031A0205; Fri, 1 Aug 2014 15:45:09 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 4E4AB20047B6A; Fri, 1 Aug 2014 15:45:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=hYIdaNfIkBh4Y7 VGppozcTm2ZXQ=; b=jzvSbfuEM5ScxF4Dw10R18fIBrSFFWmkGDr+A1hYE+n+Ow VaIO9Inj42AKpdOUM4jwmgc+cSGfd7GrjXxlXlr8mAMwiGe3jjNzvzIQK59LmqyC mzycPOJZBZ3fAk+LbABiE9GajBiYoSRJP/hJ8P8j7zRVCByQV418ilBGZbWZo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id CF56820047B5D; Fri, 1 Aug 2014 15:45:08 -0700 (PDT) Date: Fri, 1 Aug 2014 17:45:06 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140801224505.GB3579@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Prx-Fakmgm25nile3Dg1bQYLodE Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 22:45:11 -0000 On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: > The union construct in 2.6.1 with the default case being an opaque > is quite similar to the extensible union construct defined in > draft-keiser-afs3-xdr-union; the only difference is that the > encoding of the currently listed 'LABEL' and 'PRIVS' cases do not > include a length field. It might be nice to have afs3 and nfsv4 They don't need to. They are struct types, and may (do) have lengths embedded. > agree on a consistent type for the extensible union primitive, > though I understand that this is unlikely to happen on the timescale > you desire for the rpcsec-gssv3 draft. We should agree as to data model for this, but not necessarily as to encoding. NFS uses XDR. > --- > It feels a little strange to be talking about adding a way to > specify privileges/restrictions via "assertions" onto a GSS-based But that's what they are: the client asserting that some process local to it is running with some privilege. There's no way to authenticate this as we don't and could not possibly have a credential for every set of {user, }. > security scheme, since GSS is philosophically more of a "request and > check" scheme for features. This is not a realy problem, of course, This isn't GSS though. It's RPSEC_GSS. We could use GSS with naming attributes to convey everything. And a stackable GSS mechanism to do compound authentication. However, stackable GSS mechs went nowhere. > it just takes some getting used to. Actually, I guess it is still > kind of "request and check", since the server only replies with the > assertions it has accepted. Maybe this is indicative that the name > could be more descriptive. They aren't assertions in the send of a programming language "assert". They are the client's assertions about local conditions, which the client and only the client can know about. The server's job is to decide whether to accept those assertions considering all the context at hand, including the compound authenticated principals. > --- > This draft makes no mention of the use of the 'critical' bit for > structured privilege assertions, but does imply that the critical > bit will apply to any future branches that are added to the > rgss3_assertion_u. This strikes me as odd; at the very least it > could say that the critical bit is ignored. (That's my reading of > what the behavior is supposed to be, from section 2.6.1.3.) Criticality can always be decided by the client based on what the server accepts, I suppose, so we could probably remove either the critical bit or the echoing of accepted assertions in the reply. I would rather remove the critical bit than the latter. > --- > It seems like it would not adversely affect the document to move the > definition of rgss3_chan_binding up to between rgss3_gss_mp_auth and > the branches of rgss3_assertion, to match the layout of the > rgss3_create_args structure. Kind of minor, but helps the reader > find things. Channel binding is a lesser thing now that we never got RFC5660 widely implemented (or at all). > --- > I think it's valid to assume that a successful call to GSS_GetMIC > will never return a zero-length output, so the encoding of The GSS-API never produces zero-length tokens (RFC2743 says this). > rgss3_create_{args,res} could be reduced in size by just using an > opaque for their respective _chan_bind_mic fields, instead of > including the extra pointer in the type. I don't know if there's > enough need for space to make this worth doing, though. There is > some potential value in being able to easily differentiate "not > present" from zero-length. Good (if minor) point! > --- > Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample > code on page 7? It is not otherwise mentioned in the draft, and the Dunno. It was never marked so in my draft. Andy? > --- > And now, the minutiae: > > The phrasing in section 2.3 that "RPCSEC_GSS version 3 MUST change > the verifier" seems odd. This is the specification of RPCSEC_GSSv3, > [...] Also not in my draft. > In 2.6.1.1, the following text is a little confusing: > Thus a server may refuse to > grant requested authority to a user acting alone (e.g., via an > unprivileged user-space program), or to a client acting alone (e.g. > when a client is acting on behalf of a user) but may grant requested > authority to a client acting on behalf of a user if the server > identifies the user and trusts the client. > > It makes more sense when one reads "client" to mean "in-kernel NFS > client", but would probably be more clear if the "client is acting This is tricky. What's a "client"? The TCP client? The physical hardware running it and the NFS client stack? The process running the NFS client? Does it matter if it's in-kernel or a FUSE process, or some micro-kernel thing? For me the only thing that matters is if it has access to GSS credentials that the server will understand as being a "client's" as opposed to a "user's". Wording this is hard, yes. > on behalf of a user" is reworded, possibly to "on behalf of a single > user, using only that user's credentials). It looks like the That's more verbose! Yes, we need to distinguish "user with credentials" from "user without credentials" (since identity assertions are partly about the latter), but I think that should be clear anyways. > "client" vs. "kernel service" distinction is fuzzy throughout the > rest of the section, too. I would prefer if the word "client" We should absolutely not refer to "kernel" -- that's just an implementation detail. Instead we should refer to a "multi-user client" or something of the sort. > throughout the document referred only to "the RPC client", without > any implications about whether the RPC client is a trusted Yes, we could probably qualify "client" at every step, but it's not clear what other qualifiers to use when referring to "the OS", the "client service" (ah, maybe that's a good one), and so on. > (in-kernel) service or a program run by the user or anything else. > This document defines RPCSEC_GSSv3, not NFS; "client" should mean > "RPC client", not "NFS client". True, NFS is not the only application that could use RPCSEC_GSSv3, but it's very likely the only one for a long time that will. > Still on multi-principal authentication, the text says "Other > multi-principal parent and inner context handle uses might > eventually make sense." It seems like any such uses would require > standards action to specify them; you might as well also say that > they would be introduced in a new revision of the RPCSEC_GSS > protocol (e.g., v4). Sure, but that's implied. It's a forward-looking statement. (GSS did the same w.r.t. channel binding.) More later. Nico -- From nobody Fri Aug 1 19:53:17 2014 Return-Path: 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 A8B4A1A0373 for ; Fri, 1 Aug 2014 19:53:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 ahr3HBF4h7jv for ; Fri, 1 Aug 2014 19:53:13 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A01661A020A for ; Fri, 1 Aug 2014 19:53:13 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-57-53dc5297614b Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id 63.A2.32177.7925CD35; Fri, 1 Aug 2014 22:53:11 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s722rBOi009913 for ; Fri, 1 Aug 2014 22:53:11 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s722r9pZ003329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 1 Aug 2014 22:53:11 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s722r857004610; Fri, 1 Aug 2014 22:53:08 -0400 (EDT) Date: Fri, 1 Aug 2014 22:53:08 -0400 (EDT) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: Message-ID: References: <53D7DBE2.3010105@mit.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCIsWRmVeSWpSXmKPExsUixCmqrDs96E6wwZYv+hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsOJKewF99kruu7sY2pg/MPaxcjJISFgIrH+5kE2CFtM4sK9 9UA2F4eQwGwmiabFF9khnGOMEvumnGCGcK4zScxvmQPWIiRQL/Ho2RMWEJtFQEvidOdEsLFs AioSM99sBKsREVCX2HtoKliNsICNxJvd88FqOAXUJP7OPs0EYvMKOEqcnLYDattBRokvFzrZ QRKiAjoSq/dPYYEoEpQ4ORNiGbOApcS5P9fZJjAKzEKSmoUktYCRaRWjbEpulW5uYmZOcWqy bnFyYl5eapGusV5uZoleakrpJkZwAEry7WD8elDpEKMAB6MSD6/BvtvBQqyJZcWVuYcYJTmY lER5+czuBAvxJeWnVGYkFmfEF5XmpBYfYpTgYFYS4S1zA8rxpiRWVqUW5cOkpDlYlMR531pb BQsJpCeWpGanphakFsFkZTg4lCR4fwUANQoWpaanVqRl5pQgpJk4OEGG8wANfwNSw1tckJhb nJkOkT/FqMuxaP/LbiYhlrz8vFQpcd45IEUCIEUZpXlwc2CJ4xWjONBbwrxMgUBVPMCkAzfp FdASJqAlNYa3QZaUJCKkpBoYs5idZtlLrKxd52Sz59X3/ftlU0r3LTnw4uwf9w4byYM+qwoc 9xZ9WrfJX3K76qv97X4myz3fSZ5/JKGg6Hqn+fJrps/rN6ibV79NfHu+b+GObfzNIeK7HE3Z vi/9VL3BzNqzqL/nC9Oy2L2Tqi3Kflqaiviu5V9yWLM0dJ5Izff7eoyFwW11SizFGYmGWsxF xYkA3QsTSPcCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/H0VdEtUmxRzaXqFKAfXPiF-TzWA Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 02:53:15 -0000 On Fri, 1 Aug 2014, Sam Hartman wrote: >>>>>> "Nico" == Nico Williams writes: > > Nico> On Fri, Aug 1, 2014 at 11:54 AM, Tom Yu wrote: > >> I agree that AD-CAMMAC should have the same effect on the > >> criticality of its contents as AD-KDC-ISSUED. We can recommend > >> that a CAMMAC be put in AD-IF-RELEVANT if it is likely that the > >> consuming service won't understand it. The KDC might have enough > >> knowledge of the capabilities of the service that the extra layer > >> of wrapping might not be necessary. > > Nico> I agree with this. > > I'm fine with this too. I'm glad to see lots of people chiming in with agreement, but are we all clear on what we're agreeing to? Are we accepting Greg's reading of 4120 section 5.2.6.2, "This element and the elements it encapsulates MAY safely be ignored by applications, application servers, and KDCs that do not implement this element." -Ben From nobody Fri Aug 1 20:29:55 2014 Return-Path: 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 1428A1A0387 for ; Fri, 1 Aug 2014 20:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 BpzOeWFiPdyW for ; Fri, 1 Aug 2014 20:29:52 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C291E1A0381 for ; Fri, 1 Aug 2014 20:29:52 -0700 (PDT) Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 910DC2007F10B; Fri, 1 Aug 2014 20:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=qh5FmV66xBdk/o 1nJDs6pBrc49A=; b=gUd3TsVz3ZaaSv9PHwI5TL3Ja35HO+94rBQ9zQxi3NBm9w N6Fl/xNJem2IkjyRyO1B8S5o+MtBUjG8NDr//vQjg/9IfuFRdsTXlkkgdL59giaC s5uwelyCeUMrKXITwXekms4NhC2BCEctXpboSvkD+uLitQIaOuDKOSnlbFJCQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 419E62007F109; Fri, 1 Aug 2014 20:29:52 -0700 (PDT) Date: Fri, 1 Aug 2014 22:29:51 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140802032949.GD3579@localhost> References: <53D7DBE2.3010105@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zilcQk282JW9WMOFq5Gf_axqefI Cc: "kitten@ietf.org" Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 03:29:54 -0000 On Fri, Aug 01, 2014 at 10:53:08PM -0400, Benjamin Kaduk wrote: > I'm glad to see lots of people chiming in with agreement, but are we > all clear on what we're agreeing to? > > Are we accepting Greg's reading of 4120 section 5.2.6.2, "This > element and the elements it encapsulates MAY safely be ignored by > applications, application servers, and KDCs that do not implement > this element." Oh, hmmm. Will anyone ever want to include critical elements in a CAMMAC? If so then CAMMAC would need a way to signal that, or it'd have to be permitted to be critical itself. Maybe it really is time to revisit criticality... Maybe we just can't get it. From nobody Sat Aug 2 08:09:54 2014 Return-Path: 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 8E6011A0B0F for ; Sat, 2 Aug 2014 08:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 Q0ImrJL5En75 for ; Sat, 2 Aug 2014 08:09:48 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C91031A0B0B for ; Sat, 2 Aug 2014 08:09:47 -0700 (PDT) X-AuditID: 12074424-f79146d00000067c-11-53dcff3a6061 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 75.72.01660.A3FFCD35; Sat, 2 Aug 2014 11:09:46 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s72F9kqG022529 for ; Sat, 2 Aug 2014 11:09:46 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s72F9j2O023043 for ; Sat, 2 Aug 2014 11:09:46 -0400 From: Greg Hudson To: kitten@ietf.org Date: Sat, 02 Aug 2014 11:05:39 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGIsWRmVeSWpSXmKPExsUixCmqrGv1/06wwfPt2hZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxq7T15kKtipWdHV0MzcwbpXuYuTkkBAwkbg4+yorhC0mceHe erYuRi4OIYHZTBLP7p1mgnCOMUrcm7oAKtPOBOQcYwNpYRNQljh49hsLiC0iICyxe+s7ZhBb WMBAYsrPLewgNouAqkTPzL1AcQ4OXgFDiaULvEDCvAKCEidnPgFrZRbQkrjx7yXTBEaeWUhS s5CkFjAyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdI118vNLNFLTSndxAgKDnYXlR2MzYeUDjEK cDAq8fDe2H07WIg1say4MvcQoyQHk5Iob8PvO8FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHgf rwfK8aYkVlalFuXDpKQ5WJTEed9aWwULCaQnlqRmp6YWpBbBZGU4OJQkeAv+ATUKFqWmp1ak ZeaUIKSZODhBhvMADa/9CzK8uCAxtzgzHSJ/ilFRSpx3FUhCACSRUZoH1wuL3leM4kCvCPOm gKzgAUY+XPcroMFMQINrDG+DDC5JREhJNTD6/VG4dVo17+GHqsNGvko5m58JFs1vyOO7nPtV +8z0wiV2N60F3Z/uEfg7lf/bRSZmw4BkS+8j0i/218m/yVv2Y6mOQpGX3JquWLPyahe5VT9t Vrka+V7IMUgMv5lyq8xfhUFpl79t3MbU+WVBAhlaARMvGz9k5XZNdPy+7ayoZ42VR/Sje0os xRmJhlrMRcWJAPwq4IG5AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mTj0n8vBXSJ18hJ2TDT1YluIO-U Subject: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 15:09:52 -0000 This is intended as an easy-to-find mail thread in the archives which describes the status quo and possible future directions for the criticality of authorization data in Kerberos. This thread is not specific to any particular work item and does not make any specific short-term proposals. RFC 4120 envisions a model for authorization data which is primarily restrictive, such as a time-of-day restriction on tickets. KDCs are required to blindly propagate unknown authdata values in client requests. Application servers are expected to treat unknown authdata types as critical and reject the ticket. There is an AD-MANDATORY-FOR-KDC subcontainer for authdata which should be critical for the KDC. RFC 4120 contains two provisions for positive authdata. The AD-IF-RELEVANT subcontainer gives permission to application servers to ignore unknown authdata elements. The AD-KDCIssued subcontainer gives the same permission, and also has a checksum which proves to the application server that the contained authdata originated from the KDC and not from a client request. The AD-KDCIssued checksum is easily forged by the application server in a printed ticket; this is not a problem in the context of RFC 4120 because a service can, at most, fool itself via a ticket modification request. S4U2Proxy raises the stakes; a KDC cannot safely re-sign AD-KDCIssued authdata from an S4U2Proxy evidence ticket because it might have originated from the intermediate service. The PAC's KDC signature and the CAMMAC's KDC verifier are intended to address this shortcoming of AD-KDCIssued. I believe that all major implementations of Kerberos (and perhaps all implementations period) violate RFC 4120 by treating authorization data as non-critical in application servers. Moreover, I believe that implementations don't want to change for fear of breaking existing deployments. We generally specify authdata types under the assumption that some implementations obey this part of RFC 4120 and some don't. We cannot really specify an authdata type which needs to be critical for application servers at this time. There have been several positive authorization data types implemented or proposed to date: the PAC[1], the PAD[2], AD-INITIAL-VERIFIED-CAS[3], AD-LOGIN-ALIAS[4], AD-authentication-strength[5], the authentication indicator[6], and perhaps others. I am aware of only two negative authorization data types implemented or proposed to date: AD-fx-fast-armor[7] and an informal proposal by David Benjamin[8]. Both of those types are enforced by the KDC and not application servers. I can speculate on several future directions for critical authorization data: 1. The status quo. Almost all authorization data gets wrapped in AD-IF-RELEVANT at a penalty of 13 or more bytes. Critical authdata for application servers is impossible. 2. We somehow determine that all existing Kerberos implementations violate this aspect of RFC 4120. We could then specify that AD-IF-RELEVANT is no longer necessary. Critical authdata for application servers remains impossible. 3. We convince all of the major implementations to conform to RFC 4120, perhaps after determining that it wouldn't break any existing implementations as long as you ignore unwrapped PACs. We wait for all old deployments to fall out of service (i.e. decades pass). Criticial authdata becomes possible. 4. We specify a new AD-MANDATORY subcontainer and convince all of the major implementations to implement it. We wait for all old deployments to fall out of service. Critical authdata becomes possible using the wrapper. Can be combined with (2). Of these, (1) is by far the most likely. (2) is attractive given the practical constraints of ticket sizes in some environments, but seems difficult to accomplish. [1] http://msdn.microsoft.com/en-us/library/cc237917(PROT.13).aspx [2] draft-ietf-krb-wg-pad [3] RFC 4556 section 3.2.3 [4] RFC 6806 section 6 [5] RFC 6113 section 5.5 [6] draft-jain-kitten-krb-auth-indicator [7] RFC 6113 section 5.4.1.1 [8] David proposed an authdata type which causes the KDC to deny renewals of a service ticket if the client's kvno has changed. From nobody Sat Aug 2 13:00:19 2014 Return-Path: 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 894121B2985 for ; Sat, 2 Aug 2014 13:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, 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 ACS2yR_sCFuO for ; Sat, 2 Aug 2014 12:59:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2lp0237.outbound.protection.outlook.com [207.46.163.237]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F521B2982 for ; Sat, 2 Aug 2014 12:59:53 -0700 (PDT) Received: from BY2PR06CA027.namprd06.prod.outlook.com (10.141.250.145) by BLUPR06MB659.namprd06.prod.outlook.com (10.141.208.155) with Microsoft SMTP Server (TLS) id 15.0.995.14; Sat, 2 Aug 2014 19:59:51 +0000 Received: from BN1AFFO11FD027.protection.gbl (2a01:111:f400:7c10::189) by BY2PR06CA027.outlook.office365.com (2a01:111:e400:2c60::17) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Sat, 2 Aug 2014 19:59:50 +0000 Received: from mail.usda.gov (199.135.140.15) by BN1AFFO11FD027.mail.protection.outlook.com (10.58.52.87) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Sat, 2 Aug 2014 19:59:50 +0000 Received: from 001FSN2MMR1-015.001f.mgd2.msft.net (199.135.140.70) by 001FSN2MMR1-005.001f.mgd2.msft.net (199.135.140.15) with Microsoft SMTP Server (TLS) id 14.3.195.2; Sat, 2 Aug 2014 19:59:49 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.230]) by 001FSN2MMR1-015.001f.mgd2.msft.net ([199.135.140.70]) with mapi id 14.03.0195.002; Sat, 2 Aug 2014 19:59:48 +0000 From: "Nordgren, Bryce L -FS" To: 'Greg Hudson' , "'kitten@ietf.org'" Thread-Topic: [kitten] Critical authorization data in Kerberos Thread-Index: AQHPrmPTDCbEakO2PE24sq+RFXmwd5u9rVkg Date: Sat, 2 Aug 2014 19:59:48 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E70E278@001FSN2MPN1-045.001f.mgd2.msft.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:199.135.140.15; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(43784003)(51914003)(199002)(189002)(6806004)(69596002)(86146001)(87936001)(92726001)(23726002)(106116001)(106466001)(81156004)(77096002)(83322001)(44976005)(2171001)(95666004)(2656002)(76482001)(68736004)(85852003)(83072002)(47776003)(81542001)(84676001)(79102001)(81342001)(76176999)(107886001)(20776003)(107046002)(55846006)(31966008)(97736001)(74502001)(46406003)(86362001)(66066001)(77982001)(21056001)(92566001)(74482001)(4396001)(16796002)(46102001)(50466002)(85306004)(54356999)(50986999)(99396002)(74662001)(97756001)(33656002)(22756005)(64706001)(80022001)(80862004)(491001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB659; H:mail.usda.gov; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 029174C036 Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.15 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.15; helo=mail.usda.gov; Authentication-Results: spf=pass (sender IP is 199.135.140.15) smtp.mailfrom=bnordgren@fs.fed.us; X-OriginatorOrg: fs.fed.us Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3B6Sof22eD9KugULnRdTGk7mCfs Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 20:00:03 -0000 Thanks for the easy to digest summary!! I have some residual ignorance, tho: 1] Mandatory auth data sounds to me like something that absolutely everythi= ng in the domain (including the KDC) needs to understand consistently, due = to the fact that it is essentially broadcast to all domain services. It res= ults in permitting or denying access by the holder of a service ticket (to = all services? To some but not others?). Since permitting or denying access = based on information possessed by the KDC could be implemented simply by no= t issuing a ticket, why communicate this to services at all? Are there some= cases where the KDC is unaware of a critical piece of information to make = the decision? 2] Would the notion of "splitting the difference" be helpful? Keep the auth= data processing out on the services, but have the KDC only encode mandator= y auth data it expects a particular service to abide by. This approach has = the domain-wide effect of "Mandatory if applicable", but the semantics of "= Mandatory for you, Service X". It also puts the KDC in control of what is c= onsidered applicable to what services. I think this approach may allow serv= ice implementations to start obeying "mandatory" ad without fear of breakin= g all services in the entire domain. 3] What pieces of auth data have presented themselves as uniformly mandator= y for all of a domain's web services, file servers, workstations, directory= services, etc. to respect? Thanks again, Bryce This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Sat Aug 2 14:20:13 2014 Return-Path: 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 1E0FD1B29C8 for ; Sat, 2 Aug 2014 14:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 WK10Y_cDXmwD for ; Sat, 2 Aug 2014 14:20:10 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276C31B29C7 for ; Sat, 2 Aug 2014 14:20:09 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-a8-53dd56083c13 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D0.5D.12039.8065DD35; Sat, 2 Aug 2014 17:20:08 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s72LK76d014217; Sat, 2 Aug 2014 17:20:08 -0400 Received: from [18.101.8.244] (vpn-18-101-8-244.mit.edu [18.101.8.244]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s72LK50v011940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 2 Aug 2014 17:20:07 -0400 Message-ID: <53DD5605.3050901@mit.edu> Date: Sat, 02 Aug 2014 17:20:05 -0400 From: Greg Hudson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Nordgren, Bryce L -FS" , "'kitten@ietf.org'" References: <82E7C9A01FD0764CACDD35D10F5DFB6E70E278@001FSN2MPN1-045.001f.mgd2.msft.net> In-Reply-To: <82E7C9A01FD0764CACDD35D10F5DFB6E70E278@001FSN2MPN1-045.001f.mgd2.msft.net> X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixCmqrMsRdjfY4NE5c4urb36yWhzdvIrF gcnj9puzLB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4ubSdreC9cMX9U8eYGhhnCXQxcnJICJhI 9H9tZ4GwxSQu3FvP1sXIxSEkMJtJYmX/SUYIZwOjxI0HjVCZw0wSx28fZwdp4RVQk7i68yUb iM0ioCrx4t8UsFFsAsoSB89+A7NFBcIkHs85xwhRLyhxcuYTsLiIQKLE3e/PmEBsYQFbib5b 58BmCgnUSsy5cB0ozsHBKRAhMfehOMR1khLbFh0DK2EW0JF41/eAGcKWl9j+dg7zBEbBWUg2 zEJSNgtJ2QJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6Rnq5mSV6qSmlmxjBASzJu4Px3UGl Q4wCHIxKPLwG+24HC7EmlhVX5h5ilORgUhLlXWZ1N1iILyk/pTIjsTgjvqg0J7X4EKMEB7OS CO95PaAcb0piZVVqUT5MSpqDRUmc9621VbCQQHpiSWp2ampBahFMVoaDQ0mCd0sIUKNgUWp6 akVaZk4JQpqJgxNkOA/Q8FMgNbzFBYm5xZnpEPlTjIpS4rzdwUAJAZBERmkeXC8swbxiFAd6 RZj3Pkg7DzA5wXW/AhrMBDS4xvA2yOCSRISUVANjotPh+3muDKv1IhxeLHkt/LslTcDNUu30 ba0Ph8/ddJMyD5Vme++w7nb3Ls7/r9QDCk4ZXw8NvBuaK3R9f8ShcLetT/I4Sg9dfNmdtezH sqXHJup/uCRWo7vwiaPS/l1F767PvGYQcOde9FaeDRIHOnu7d0W9uXna2uv44xcGGzpacyfs EQ17pMRSnJFoqMVcVJwIAHdJssMLAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5V1rllSvGu7PO3PEjNHo-r5B3Ss Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Aug 2014 21:20:12 -0000 On 08/02/2014 03:59 PM, Nordgren, Bryce L -FS wrote: > 1] Mandatory auth data sounds to me like something that absolutely everything in the domain (including the KDC) needs to understand consistently, due to the fact that it is essentially broadcast to all domain services. It results in permitting or denying access by the holder of a service ticket (to all services? To some but not others?). Since permitting or denying access based on information possessed by the KDC could be implemented simply by not issuing a ticket, why communicate this to services at all? Are there some cases where the KDC is unaware of a critical piece of information to make the decision? RFC 4120 envisions authdata which is understood by the client and server, but not the KDC. Much as you can request a ticket for a shorter lifetime than the maximum lifetime, you could conceivably request a ticket that can only be used for specific purposes. Authorization can be finer-grained than completely denying access to a service, so it cannot always be implemented as a TGS policy. You could have access to an HTTP server but not access to all of its resources, for instance. Authorization data does not have to be broadcast to every service in a domain. It could be requested by the client in a TGS request or even in an AP request, or originated by the KDC for some service tickets and not others. > 2] Would the notion of "splitting the difference" be helpful? Keep the auth data processing out on the services, but have the KDC only encode mandatory auth data it expects a particular service to abide by. This approach has the domain-wide effect of "Mandatory if applicable", but the semantics of "Mandatory for you, Service X". It also puts the KDC in control of what is considered applicable to what services. I think this approach may allow service implementations to start obeying "mandatory" ad without fear of breaking all services in the entire domain. Making the KDC aware of software capabilities on each server is not always easy to administer, especially as there is no standard way for servers to communicate information like that to a KDC. > 3] What pieces of auth data have presented themselves as uniformly mandatory for all of a domain's web services, file servers, workstations, directory services, etc. to respect? I think I covered this in my post: nothing so far. The only standardized mandatory authdata element I'm aware of is AD-fx-fast-armor, and that is only intended to be mandatory for the KDC. From nobody Sat Aug 2 17:47:38 2014 Return-Path: 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 D87021A0062 for ; Sat, 2 Aug 2014 17:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, 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 PE3_ajxr9GKK for ; Sat, 2 Aug 2014 17:47:32 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3011A0060 for ; Sat, 2 Aug 2014 17:47:31 -0700 (PDT) Received: from BY2PR06CA022.namprd06.prod.outlook.com (10.141.250.140) by BLUPR06MB657.namprd06.prod.outlook.com (10.141.208.216) with Microsoft SMTP Server (TLS) id 15.0.995.14; Sun, 3 Aug 2014 00:47:29 +0000 Received: from BY2FFO11FD022.protection.gbl (2a01:111:f400:7c0c::189) by BY2PR06CA022.outlook.office365.com (2a01:111:e400:2c60::12) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Sun, 3 Aug 2014 00:47:28 +0000 Received: from mail.usda.gov (199.135.140.14) by BY2FFO11FD022.mail.protection.outlook.com (10.1.15.211) with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Sun, 3 Aug 2014 00:47:27 +0000 Received: from 001FSN2MPN1-045.001f.mgd2.msft.net ([169.254.5.230]) by 001FSN2MMR1-004.001f.mgd2.msft.net ([199.135.140.14]) with mapi id 14.03.0195.002; Sun, 3 Aug 2014 00:47:26 +0000 From: "Nordgren, Bryce L -FS" To: 'Greg Hudson' , "'kitten@ietf.org'" Thread-Topic: [kitten] Critical authorization data in Kerberos Thread-Index: AQHPrmPTDCbEakO2PE24sq+RFXmwd5u9rVkggAAk7YCAAAXUoA== Date: Sun, 3 Aug 2014 00:47:25 +0000 Message-ID: <82E7C9A01FD0764CACDD35D10F5DFB6E70F451@001FSN2MPN1-045.001f.mgd2.msft.net> References: <82E7C9A01FD0764CACDD35D10F5DFB6E70E278@001FSN2MPN1-045.001f.mgd2.msft.net> <53DD5605.3050901@mit.edu> In-Reply-To: <53DD5605.3050901@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.7.26.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:199.135.140.14; CTRY:US; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(199002)(189002)(69596002)(79102001)(2656002)(54356999)(46102001)(33656002)(55846006)(77096002)(92726001)(76482001)(22756005)(106116001)(77982001)(85306004)(74482001)(22746005)(86362001)(104016003)(86146001)(87936001)(46406003)(68736004)(76176999)(50466002)(50986999)(6806004)(74662001)(4396001)(81156004)(31966008)(74502001)(107886001)(99396002)(83072002)(80022001)(83322001)(107046002)(44976005)(84676001)(97756001)(20776003)(81342001)(47776003)(23726002)(66066001)(2171001)(97736001)(64706001)(92566001)(85852003)(106466001)(21056001)(81542001)(95666004)(80862004)(491001)(79686002); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR06MB657; H:mail.usda.gov; FPR:; MLV:sfv; PTR:InfoDomainNonexistent; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 02929ECF07 Received-SPF: Pass (protection.outlook.com: domain of fs.fed.us designates 199.135.140.14 as permitted sender) receiver=protection.outlook.com; client-ip=199.135.140.14; helo=mail.usda.gov; Authentication-Results: spf=pass (sender IP is 199.135.140.14) smtp.mailfrom=bnordgren@fs.fed.us; X-OriginatorOrg: fs.fed.us Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VXcMRrPL69ixv1gcG9I27NxRWBw Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 00:47:37 -0000 > RFC 4120 envisions authdata which is understood by the client and server, > but not the KDC. Much as you can request a ticket for a shorter lifetime= than > the maximum lifetime, you could conceivably request a ticket that can onl= y > be used for specific purposes. This seems to me like a protocol issue between the client and the server. I= f the access control is vital to the correct functioning of the application= , or even constitutes a major feature, it seems unlikely that the protocol = would be written to depend on a KDC to convey it. The protocol (NFS, LDAP, = WebDAV etc.) is likely designed to work with non-Kerberos authentication me= thods as well, which may or may not have a parallel conveyance mechanism. > Authorization can be finer-grained than completely denying access to a > service, so it cannot always be implemented as a TGS policy. You could h= ave > access to an HTTP server but not access to all of its resources, for inst= ance. Methinks there are two orthogonal granularities embedded in that statement:= a spectrum of permissions between permit and deny, which are potentially a= ggregated into "roles"; and the inventory of resources offered by the servi= ce. Not sure anything other than the server has any business making fine-graine= d decisions about access to individual resources offered by the service. As= you say, this is a hard thing for the KDC to do because it would have to u= nderstand the server's inventory of things, as well as its array of availab= le permissions and roles. Potentially, there could be some constrained dele= gation scenario where I as a client request a limited ticket authorizing so= me process to access a specific directory as me. I think grid-computing env= ironments support such a notion via PKI. I don't think I've seen anything l= ike this in the desktop world (or the cluster-of-workstations supercomputer= world for that matter). Was there any discussion of trying to use Kerberos= auth data for constrained delegation (or anything?) when writing NFS 4.x? = What were the pros and cons? The most compelling case I can make for controlling sub-service access by s= omething other than the service would be centralized management of many ins= tances of similar services. Does FreeIPA (domain controller) and sssd (serv= ice) use Kerberos auth data to manage fine-grained access (e.g., sudo, abil= ity to login etc.; the spectrum between permit and deny) or does it use som= e other mechanism? Orthogonally, for access to individual resources, I beli= eve it communicates group membership via LDAP. To what extent does Microsof= t leverage Kerberos auth data to manage clients? If these use cases can't l= everage mandatory auth data, or can leverage it only partially, it's not ve= ry likely that others can. Even if these applications succeed, the centrali= zed manager pretty much has to operate its own KDC, which severely limits t= he potential application. This does shine a light on a third potential usage scenario: centralized ma= nagement of many instances of similar services, by something that is neithe= r a KDC nor a client. Posit a cluster of machines running database engines= , and a centralized management app to keep track of which databases are dep= loyed where, and which keeps track of who may access what. To allow this ma= nagement app to exercise control over the Kerberos auth data, Kerberos woul= d need a standard means of storing black box auth data, and a standard rule= language for determining when a particular black box should be inserted in= to service tickets. Lacking such a mechanism in the KDC, by far the easiest= thing to do is have the management app directly manage permissions on each= database engine via SQL. Is there a security benefit to putting auth data = in a Kerberos ticket, compared to using the native method? Anything which w= ould motivate developers to demand that Kerberos supply the necessary infra= structure? The theme with these examples is that it's probably worth finding out if th= ere are reasons not to use mandatory Kerberos auth data in the client->serv= ice and KDC->service contexts. Is Kerberos trying to replace a native acces= s control method? What value does Kerberos add over the native access contr= ol methods? Identifying cases where it could have been used, but wasn't, is= probably important. This differentiates an indifferent response by impleme= nters from a real problem with the concept. I gather that the elephant in t= he room is the suspicion that there is a real problem with the concept. Determining why everyone is breaking the rules may give some insight as to = whether the rules are ever likely to be followed, and may provide a justifi= cation for moving forward with your option #2. > Authorization data does not have to be broadcast to every service in a > domain. It could be requested by the client in a TGS request or even in = an AP > request, or originated by the KDC for some service tickets and not others= . Ah, this obviates my #2. Thanks. Bryce This electronic message contains information generated by the USDA solely f= or the intended recipients. Any unauthorized interception of this message o= r the use or disclosure of the information it contains may violate the law = and subject the violator to civil or criminal penalties. If you believe you= have received this message in error, please notify the sender and delete t= he email immediately. From nobody Sat Aug 2 22:47:20 2014 Return-Path: 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 EBFA61A0175; Sat, 2 Aug 2014 22:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 GI6lHab_FSKp; Sat, 2 Aug 2014 22:47:17 -0700 (PDT) Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81F761A0171; Sat, 2 Aug 2014 22:47:16 -0700 (PDT) X-AuditID: 12074425-f79766d000006da8-1e-53ddcce2794a Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id A2.97.28072.2ECCDD35; Sun, 3 Aug 2014 01:47:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s735lDlR001710; Sun, 3 Aug 2014 01:47:14 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s735l8It024943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Aug 2014 01:47:10 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s735l7vl026125; Sun, 3 Aug 2014 01:47:07 -0400 (EDT) Date: Sun, 3 Aug 2014 01:47:06 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140801224505.GB3579@localhost> Message-ID: References: <20140801224505.GB3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6novvozN1gg64L1hZHN69isZj9/hGr xalrR9gspi+ycmDxeHnqHKPHkiU/mTxmfPrCFsAcxWWTkpqTWZZapG+XwJWx+mdZQadOxe2P pQ2Mr5S6GDk5JARMJGb0vGWEsMUkLtxbz9bFyMUhJDCbSWLSs9mMEM4GRom3e9ZBZQ4ySVz/ cgesRUigXuLwxQ5WEJtFQEvi4Kq3bCA2m4CKxMw3G8FsEQFNievzloLZzAJlEt3T2sHqhQXc JJpf/WIGsTkF9CQaNp8FmsnBwSvgKDHjJzvE+KmMEvu35oPYogI6Eqv3T2EBsXkFBCVOznzC AjHSUuLcn+tsExgFZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXQi83s0QvNaV0 EyM4gF1UdzBOOKR0iFGAg1GJh1dh791gIdbEsuLK3EOMkhxMSqK8P3cBhfiS8lMqMxKLM+KL SnNSiw8xSnAwK4nwfskGyvGmJFZWpRblw6SkOViUxHnfWlsFCwmkJ5akZqemFqQWwWRlODiU JHjNgJEqJFiUmp5akZaZU4KQZuLgBBnOAzScGaSGt7ggMbc4Mx0if4pRUUqc98ppoIQASCKj NA+uF5ZgXjGKA70izHsNpIoHmJzgul8BDWYCGlxjeBtkcEkiQkqqgXHP0YPJC3z1Z/JnPqm5 c7v+rm+C7Lu8f3sD/uUL7DAvk31uv//Cc/aUE5fLj3d/2tR116Pw1tSTBksYG3OZZvHwTVCN vVAmeDc5QWfm//53fYW+hxi+PInnq/M/Np29fY+O1i3H30uS8mUeMJaVHs1/wP5v8s31UUWJ 518ETlONfWE2bZv8votKLMUZiYZazEXFiQB3wlveCwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VIH4GQayYX2ExbkuVEAqpzzLlTY Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 05:47:19 -0000 I guess I'll split my replies amongst the existing thread instead of trying to reconsolidate everything. Going in reverse order so as to try to avoid duplicating previous discussion... On Fri, 1 Aug 2014, Nico Williams wrote: > On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: >> The union construct in 2.6.1 with the default case being an opaque >> is quite similar to the extensible union construct defined in >> draft-keiser-afs3-xdr-union; the only difference is that the >> encoding of the currently listed 'LABEL' and 'PRIVS' cases do not >> include a length field. It might be nice to have afs3 and nfsv4 > > They don't need to. They are struct types, and may (do) have lengths > embedded. > >> agree on a consistent type for the extensible union primitive, >> though I understand that this is unlikely to happen on the timescale >> you desire for the rpcsec-gssv3 draft. > > We should agree as to data model for this, but not necessarily as to > encoding. NFS uses XDR. I think we're talking past each other. AFS and NFS both use XDR; AFS is proposing to add a new fundamental data structure, in addition to the existing 'struct' and 'union' types. This is a union type to which additional discriminant values (and corresponding data branches) may be added without causing existing implementations to fail to decode the binary data. To do this requires that the encoded form for each branch of the union include a length field, for the length of the encoded form of the data branch. I mention it because it is equivalent to having each data branch be an opaque, whose contents are the encoded form of the "actual" data, and here the default branch is just such an opaque. >> --- > > They aren't assertions in the send of a programming language "assert". > They are the client's assertions about local conditions, which the > client and only the client can know about. The server's job is to > decide whether to accept those assertions considering all the context at > hand, including the compound authenticated principals. I understand what they are. All I am saying is that, while talking about "assertions" in this sense is normal for, e.g., SAML, it is not common in the GSS-API world. This is an observation, not an actionable statement. >> --- >> This draft makes no mention of the use of the 'critical' bit for >> structured privilege assertions, but does imply that the critical >> bit will apply to any future branches that are added to the >> rgss3_assertion_u. This strikes me as odd; at the very least it >> could say that the critical bit is ignored. (That's my reading of >> what the behavior is supposed to be, from section 2.6.1.3.) > > Criticality can always be decided by the client based on what the server > accepts, I suppose, so we could probably remove either the critical bit > or the echoing of accepted assertions in the reply. I would rather > remove the critical bit than the latter. I don't think it's quite that cut-and-dried, as I can see cases where the client should be able to make non-critical requests, but also cases where the client should ask the server to fail the RPC if the request is not fulfillable. >> --- >> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample >> code on page 7? It is not otherwise mentioned in the draft, and the > > Dunno. It was never marked so in my draft. Andy? (This is the comment in the saple code, in the definition of enum rpc_gss_proc_t.) >> In 2.6.1.1, the following text is a little confusing: >> Thus a server may refuse to >> grant requested authority to a user acting alone (e.g., via an >> unprivileged user-space program), or to a client acting alone (e.g. >> when a client is acting on behalf of a user) but may grant requested >> authority to a client acting on behalf of a user if the server >> identifies the user and trusts the client. >> >> It makes more sense when one reads "client" to mean "in-kernel NFS >> client", but would probably be more clear if the "client is acting > > This is tricky. What's a "client"? The TCP client? The physical > hardware running it and the NFS client stack? The process running the > NFS client? Does it matter if it's in-kernel or a FUSE process, or some > micro-kernel thing? For me the only thing that matters is if it has > access to GSS credentials that the server will understand as being a > "client's" as opposed to a "user's". > > Wording this is hard, yes. > >> on behalf of a user" is reworded, possibly to "on behalf of a single >> user, using only that user's credentials). It looks like the > > That's more verbose! Yes, we need to distinguish "user with > credentials" from "user without credentials" (since identity assertions > are partly about the latter), but I think that should be clear anyways. Hmm, I was talking about the distinction between "host with credentials" and "host without credentials". Clearly there is still room for improvement :) >> "client" vs. "kernel service" distinction is fuzzy throughout the >> rest of the section, too. I would prefer if the word "client" > > We should absolutely not refer to "kernel" -- that's just an > implementation detail. Instead we should refer to a "multi-user client" > or something of the sort. I agree that we should not refer to "kernel"; this was intended as a comment about the use of the word "client" in this document and that it may not be appropriate in all the cases where it is currently used. -Ben From nobody Sat Aug 2 22:50:57 2014 Return-Path: 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 C76D41A0171; Sat, 2 Aug 2014 22:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 ArNdUxtMLgEd; Sat, 2 Aug 2014 22:50:50 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AB7A1A0172; Sat, 2 Aug 2014 22:50:50 -0700 (PDT) X-AuditID: 1209190f-f79f86d0000061c8-72-53ddcdb9c211 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 09.CA.25032.9BDCDD35; Sun, 3 Aug 2014 01:50:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s735oluQ006974; Sun, 3 Aug 2014 01:50:48 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s735ojhT025594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Aug 2014 01:50:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s735oj8W026587; Sun, 3 Aug 2014 01:50:45 -0400 (EDT) Date: Sun, 3 Aug 2014 01:50:44 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140801221535.GA3579@localhost> Message-ID: References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-2132172227-1407045045=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIKsWRmVeSWpSXmKPExsUixCmqrbvz7N1gg12vJC2Obl7FYjH7/SNW i1PXjrBZTF9k5cDi8fLUOUaPJUt+MnnM+PSFLYA5issmJTUnsyy1SN8ugSvj67VupoKDshXP 9hk3MP4Q72Lk5JAQMJH4+bSLFcIWk7hwbz1bFyMXh5DAbCaJ0zvvMEI4GxgluvbMZIVwDjJJ LP/aA+RwADn1Eje/1IN0swhoSdx+dJoZxGYTUJGY+WYjG4gtIqApcX3eUjCbWaBMontaO9g2 YQE3ieZXv8DqOQX0JDpffAGL8wo4Srz695IJYtdLRonbF/aAFYkK6Eis3j+FBaJIUOLkzCcs EEMDJVruPWafwCg4C0lqFpLULKBTmQXMJBa22UGEtSXu32xjW8DIsopRNiW3Sjc3MTOnODVZ tzg5MS8vtUjXRC83s0QvNaV0EyM45CX5dzB+O6h0iFGAg1GJh1dh791gIdbEsuLK3EOMkhxM SqK8P3cBhfiS8lMqMxKLM+KLSnNSiw8xSnAwK4nwfskGyvGmJFZWpRblw6SkOViUxHnfWlsF CwmkJ5akZqemFqQWwWRlODiUJHjZgLEtJFiUmp5akZaZU4KQZuLgBBnOAzR81xmQ4cUFibnF mekQ+VOMilLivFdOAyUEQBIZpXlwvbCU9IpRHOgVYV5GkBU8wHQG1/0KaDAT0OAaw9sgg0sS EVJSDYwdtTYxbWXrdvllTDPgvhC/Z27x2036S7WfZacF8XYq5SYIq+04FmXoe11o0mSlD2KR hretlx/cZMa3Q/Fx9amfSd5LGvadyzorYBy8exHP94YK45vSO89UxuWejP+5/facBum1ZxUn vnWQEXXilQt/yWBi3cN92a34y4a5DWWmjRwbeXvz25RYijMSDbWYi4oTARHG7uwkAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qMpKHEa1ixLKUoOMxiEhCTn3hpM Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 05:50:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-2132172227-1407045045=:21571 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 1 Aug 2014, Nico Williams wrote: > On Fri, Aug 01, 2014 at 08:28:25PM +0000, Adamson, Andy wrote: >> On Aug 1, 2014, at 1:54 AM, Nico Williams wrote: >>> On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: >>>> Hmm, this seems to have gotten rather long. >> >> Well, it=E2=80=99s two pages shorter than draft-williams-rpcsecgssv3-02.= txt (!) > > :) I meant "my email is getting long", not "the draft is getting long", just= =20 so we're clear. >>>> Multi-principal authentication >>>> >>>> This draft proposes a multi-principal authentication scheme, >>>> restricted to just the case of a privileged client process on a >>> >>> No, not only the case of a privileged client process. >> >> Sure, but for the Multi-principal piece we do say the following which=20 >> says that the use-case is privileged client process=E2=80=A6. > > It was always my intention that traditional (read: multi-user > shared-cache) NFS client implementations would just always use > "multi-principal" contexts when doing any RPCs on a user's behalf. > > That is, addressing the "user can impersonate the server to the client" > problem was always my first and foremost goal with this protocol, though > I didn't always say so explicitly (since at the time the attack was not > well-known, I didn't want to publicize it). > > The conveyance of privilege (or under-privilege) is secondary, but > extremely useful. > > (Was "multi-principal" my name for this? No, I called them compound > authentication. I prefer "compound".) > > Local privilege or lack thereof is irrelevant to when compound > authentication is to be used. The only relevant detail for that is: is > the client trusting the server's response in any way that could > compromise it or other users on the same client if the user on behalf of > which the RPC is being done could impersonate the server. That's a > mouthful, sorry (shorter version: shared-cache). When I said "privileged", I mean "the thing maintaining the cache, which=20 has its own credentials that are distinct from any other processes=20 benefitting from the cache. >>>> However, I don't think this is strong enough; I think this scheme >>>> requires the "privacy" level of protection. Otherwise, an attacker >>>> could replay the nonce+MIC and obtain an RPCSEC_GSS context that >>>> will authenticate as the user from the "inner" context, without >>>> actually proving that it possesses the user's credentials. In >>> >>> The client's credentials are required to make progress. >> >> So you do need to be a =E2=80=98privileged client process=E2=80=99 - in = order to use >> the client=E2=80=99s machine credentials. > > No. The client (the kernel, whatever) does it on behalf of the user. I think we're actually in agreement on what's going on here, just using=20 different words to describe it. >>> That stops >>> replay attacks. We need only bind things sufficiently to the new >>> RPCSEC_GSS security context handle and the client credentials. >> >> An evil user that can get root on a client machine wouldn=E2=80=99t need= to >> [...] > > Stop right there! We *always* assume local security when dealing with > security protocols :) There's no need to state this assumption. It's Indeed, this is not the point I was trying to make. More under separate=20 cover. -Ben ---559023410-2132172227-1407045045=:21571-- From nobody Sat Aug 2 23:04:46 2014 Return-Path: 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 C35A21A0179; Sat, 2 Aug 2014 23:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 DCRyPxiVEs5n; Sat, 2 Aug 2014 23:04:38 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6EF1A0176; Sat, 2 Aug 2014 23:04:38 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-1f-53ddd0f5055e Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 2D.59.24022.5F0DDD35; Sun, 3 Aug 2014 02:04:37 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7364Z5e007971; Sun, 3 Aug 2014 02:04:36 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7364WYF028311 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Aug 2014 02:04:34 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7364WGl028341; Sun, 3 Aug 2014 02:04:32 -0400 (EDT) Date: Sun, 3 Aug 2014 02:04:31 -0400 (EDT) From: Benjamin Kaduk To: "Adamson, Andy" In-Reply-To: <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> Message-ID: References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-691950968-1407045871=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1v164W6wwd59AhYvpkRZHN28isVi 9vtHrBbTF1k5sHhsmNrE5rFkyU8mjxmfvrAFMEdx2aSk5mSWpRbp2yVwZXzv28JU8EO14nXn RZYGxktyXYycHBICJhL3V7xng7DFJC7cWw9kc3EICcxmkth26DErhLOBUeL8qgcsEM5BJomV Bw4xdTFyADn1ErvneoN0swhoSZw9/ZwZxGYTUJGY+WYjG0iJiICBxMalqiBhZoEiicVbf7GC 2MICbhLNr36BlXMK2Ek8m93CBGLzCjhK3DqzBmrvaUaJpiPn2UESogI6Eqv3T2GBKBKUODnz CQvIfGaBAIlTq00nMArOQpKZhZCZBbbZVmLV2t2MELa2xP2bbWwLGFlWMcqm5Fbp5iZm5hSn JusWJyfm5aUW6Rrq5WaW6KWmlG5iBIe7JM8OxjcHlQ4xCnAwKvHwKuy9GyzEmlhWXJl7iFGS g0lJlPfnLqAQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd4v2UA53pTEyqrUonyYlDQHi5I471tr q2AhgfTEktTs1NSC1CKYrAwHh5IEb+B5oEbBotT01Iq0zJwShDQTByfIcB6g4X4gNbzFBYm5 xZnpEPlTjIpS4rxLzwElBEASGaV5cL2wdPSKURzoFWHeaJB2HmAqg+t+BTSYCWhwjeFtkMEl iQgpqQZG03cfJnu0vmXZUMk1L/Tb5LXH7xU+3pT/3jup84if26o961LMGmUOSx8ISF7/QOhS w6K+sGczg5/u6jjUxHxrcYK5SbRrXK3x9f19HaYZqlz9vH0dt+LvLfSodVuxZoOv8qv81PSJ BQ1RD46lzPh+7dT5pcreCZqNU06+Er6bUznh2o7fEs5TlFiKMxINtZiLihMBVfR/7iIDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/52ekwOefQlryBkYNexRyDwljSCA Cc: "J. Bruce Fields" , "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 06:04:41 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-691950968-1407045871=:21571 Content-Type: TEXT/PLAIN; charset=Windows-1252; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 1 Aug 2014, Adamson, Andy wrote: > > On Jul 31, 2014, at 7:10 PM, Benjamin Kaduk wrote: > >> On Wed, 30 Jul 2014, J. Bruce Fields wrote: >> >> >>> The RPCSEC_GSS_CREATE request should demonstrate that the caller knows >>> both parent and child's credentials. That's easy for the parent since >>> an RPCSEC_GSS_CREATE request is also just an ordinary RPCSEC_GSS reques= t >>> sent as the parent. >>> >>> For the child the caller has to calculate the mic of a nonce using the >>> child context, but as far as I can tell the choice of nonce is entirely >>> up to the caller. >>> >>> Couldn't it then just choose as the nonce some data that it had >>> previously seen a mic for? If so, would it work to remove the nonce an= d >>> instead calculate, say, a mic of the rpc header (as we do when >>> calculating the verifier?). >> >> Certainly it would help to include (something with) the sequence=20 >> number, as a proof of "liveness". We may have to brainstorm a bit. > > I have always thought of Multi-principal authentication in terms of it=92= s=20 > use in NFSv4.2 Inter server to server copy, where all of the=20 > RPCSEC_GSS_CREATE messages MUST use rpc_gss_svc_privacy=92=85. Good catch= =20 > Bruce. > > So for this attack to occur the rgmp_nonce must be re-used by the same=20 > rgmp_handle (same user-principal). Insisting on using a random number=20 > generator to create nounce could be by-passed by a bad implementation... > > Bruces suggestion of using the new reply verifier data (rpc-header)=20 > should do the trick. Any objections to this approach? > >> >>> The reply is already authenticated as >>> the parent, the problem again is authenticating as the child > > You must mean the Multi-principal =93inner=94 handle. > > There is no =93child=92 as the child handle is the result of the successf= ul=20 > RPCSEC_GSS_CREATE call, and we are defining how success is determined. > > >>> , so I think >>> it should be calculating a mic using the child context (maybe over the >>> header data again, as in section 2.3?). > > The child handle is varified on the target (server) by a successful=20 > GSS_VerifyMIC using the user-principal GSS context and the nounce. This= =20 > exchange is the target >> > >> In particular, the server could decline to validate the nonce-MIC at=20 >> all, and grant access to anyone who claimed to be the user; we must=20 >> trust that it does the verification properly. (A proper verification=20 >> confirms that the server does have a valid context handle for the inner= =20 >> context.) > > Correct, and that verification is noted in the sentence prior to the=20 > quote above - this obviously could be clearer. I could separate the two= =20 > verifications into two paragraphs. > > The target verifies the multi-principal authentication by verifying > the rgmp_nouce_mic. I'm not sure we're all on the same page about the concerns about the=20 "inner" RPCSEC context handle of the multi-principal authentication. If I understand correctly, the child RPCSEC contex handle will use the=20 same GSS context as the parent RPCSEC context handle (i.e., using the=20 host's credentials, not the user's credentials). This means that when=20 creating the child RPCSEC context, there must be some proof that the RPC=20 client controls the GSS context corresponding to the inner RPCSEC context= =20 handle, since the child RPCSEC context will perform operations acting as=20 the user specified by the GSS context of the inner RPCSEC context. My reading of the current draft is that the only attempt to do this is by= =20 presenting a random nonce and a GSS_GetMIC of that nonce, created using=20 the GSS context of the inner RPCSEC context. The server must verify that= =20 the MIC is a valid mic, but I do not see any other binding to this GSS=20 context. In particular, the nonce+MIC could be eavesdropped on the wire,= =20 and inserted into an attacker's RPCSEC_GSS_CREATE call, where the attacker= =20 provides its own parent RPCSEC context but does not actually have an inner= =20 context at all. The attacker can reuse the valid nonce+MIC that it has=20 intercepted, which will validate correctly on the server, and the server=20 will issue a child RPCSEC context that acts as the user indicated by the=20 GSS context of the inner RPCSEC context but uses the key material from the= =20 attacker's GSS context. -Ben ---559023410-691950968-1407045871=:21571-- From nobody Sat Aug 2 23:09:00 2014 Return-Path: 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 1D0B41A0179; Sat, 2 Aug 2014 23:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 mcPLFOQcKbTp; Sat, 2 Aug 2014 23:08:54 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67CA61A0176; Sat, 2 Aug 2014 23:08:54 -0700 (PDT) X-AuditID: 12074424-f79146d00000067c-f0-53ddd1f5b379 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 30.DF.01660.5F1DDD35; Sun, 3 Aug 2014 02:08:53 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s7368p0t009701; Sun, 3 Aug 2014 02:08:52 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7368n9e029159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 3 Aug 2014 02:08:50 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7368n5H028888; Sun, 3 Aug 2014 02:08:49 -0400 (EDT) Date: Sun, 3 Aug 2014 02:08:48 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140801055401.GA7409@localhost> Message-ID: References: <20140801055401.GA7409@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRmVeSWpSXmKPExsUixG6nrvv14t1gg6+HxSyObl7FYjH7/SNW i1PXjrBZTF9k5cDi8fLUOUaPJUt+MnnM+PSFLYA5issmJTUnsyy1SN8ugSvj5Ox57AUPOSum nI1pYHzJ3sXIwSEhYCLxcT13FyMnkCkmceHeerYuRi4OIYHZTBJTn/YzgySEBDYwSkzdWQyR OMgksWjSIVaIRL3ExKs9rCCDWAS0JF7dzAAJswmoSMx8s5ENxBYR0JS4Pm8pmM0sUCbRPa0d rFVYwE2i+dUvsPmcAnoSD77OYQexeQUcJTYs/c8IsWsqo8Tzi7PBmkUFdCRW75/CAlEkKHFy 5hMWiKGWEuf+XGebwCg4C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbrmermZJXqp KaWbGMEB7KKyg7H5kNIhRgEORiUe3or9d4OFWBPLiitzDzFKcjApifL+3AUU4kvKT6nMSCzO iC8qzUktPsQowcGsJML7JRsox5uSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoEk5Xh 4FCS4G27ANQoWJSanlqRlplTgpBm4uAEGc4DNLwCpIa3uCAxtzgzHSJ/ilFRSpyXCyQhAJLI KM2D64UlmFeM4kCvCPN2gFTxAJMTXPcroMFMQINrDG+DDC5JREhJNTAySrhKTP1u/5VzyqRT t159eNUu+PB+m4O5ldxuZwaz/+x/zB8c+23yRsCyUadj9q0WRrcfvmdX34j7YnkyL8465G+O y8Qv3jkTd+dytX09/C07alZwzouX+3ZEnaq2LMlN2hjRkiigfUo7RcjrJ+fTb5J6DAbz14lO X8/0T8tVzKEt7mv/u3QlluKMREMt5qLiRAD/ieQMCwMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/C-0XEe3NQMh4CqrU8tAvkLzPV5I Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Aug 2014 06:08:56 -0000 On Fri, 1 Aug 2014, Nico Williams wrote: >> Three levels of protection are provided for the RPC bodies, none, >> integrity, and privacy. The choice of level for this attempt at >> this RPC, as well as a sequence number unique to this transmission, >> are encoded into the "credential", a part of the RPC request header; >> there is a GSS MIC over the header, so the header (and protection >> level and sequence number) are always protected. The request >> payload's encoding depends on the level; for none, it is unchanged. >> [...] > > Though "none" always MICs the header. Yes. >> restricted to just a combination of host and user credentials, >> specifying which one is which. I think this is the only >> well-understood scenario for compount authentication at the moment, >> and makes sense. > > What is the antecedent of "this" here? Did you mean that conveying > local privilege information is not understood? "this" is the scenario wherein host credentials and user credentials are combined for the compound authentication. I make no statement on local privilege information, rather I claim that scenarios such as combining user A's credentials with uesr B's credentials is not well understood. -Ben From nobody Mon Aug 4 06:57:31 2014 Return-Path: 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 8852B1B2B05 for ; Mon, 4 Aug 2014 06:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, 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 cxx_E607kWqU for ; Mon, 4 Aug 2014 06:57:30 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 361411B2B01 for ; Mon, 4 Aug 2014 06:57:30 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga101.ch.intel.com with ESMTP; 04 Aug 2014 06:57:29 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,798,1400050800"; d="scan'208";a="464728467" Received: from fmsmsx106.amr.corp.intel.com ([10.19.9.37]) by azsmga001.ch.intel.com with ESMTP; 04 Aug 2014 06:57:28 -0700 Received: from fmsmsx154.amr.corp.intel.com (10.18.116.70) by FMSMSX106.amr.corp.intel.com (10.19.9.37) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 06:57:28 -0700 Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by FMSMSX154.amr.corp.intel.com (10.18.116.70) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 06:57:28 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.75]) by SHSMSX104.ccr.corp.intel.com ([169.254.5.97]) with mapi id 14.03.0195.001; Mon, 4 Aug 2014 21:57:20 +0800 From: "Zheng, Kai" To: Tom Yu Thread-Topic: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 Thread-Index: AQHPrbyzdGP0t8sy2UWah8ekcxJ/1ZvAfBww Date: Mon, 4 Aug 2014 13:57:20 +0000 Message-ID: <8D5F7E3237B3ED47B84CF187BB17B6661193B4ED@SHSMSX103.ccr.corp.intel.com> References: <53799133.70201@oracle.com> <53BB8362.3010605@oracle.com> <8D5F7E3237B3ED47B84CF187BB17B666118FB2BB@SHSMSX103.ccr.corp.intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/tLDcXUnHr6BVswz9rvslPchlrbk Cc: "kitten@ietf.org" Subject: Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 13:57:31 -0000 Hi Tom, Yes it looks better. Thanks for your response! Regards, Kai -----Original Message----- From: Tom Yu [mailto:tlyu@MIT.EDU]=20 Sent: Saturday, August 02, 2014 3:13 AM To: Zheng, Kai Cc: Shawn M Emery; kitten@ietf.org Subject: Re: [kitten] WGLC on draft-ietf-krb-wg-cammac-08 "Zheng, Kai" writes: > Regarding the following: > =3D=3D=3D > However, protocol extensions such as Constrained Delegation (S4U2Proxy > [MS-SFU]) require that a service present to the KDC a service ticket > that the service received from a client, as evidence that the client > authenticated to the service. In the S4U2Proxy extension, the KDC > uses the evidence ticket as the basis for issuing a derivative ticket > that the service can then use to impersonate the client. > =3D=3D=3D [...] > This forwardable service ticket might have been obtained by a=20 > KRB_AP_REQ and come from the user client (the case mentioned here), or=20 > by an S4U2self request (ignored here). Hi Kai, Thanks for your comment. I can see how apparently ignoring tickets obtaine= d from S4U2Self could be distracting or confusing to a reader. Would the following text be better? However, protocol extensions such as Constrained Delegation (S4U2Proxy [MS-SFU]) require that a service present to the KDC a service ticket that the KDC previously issued, as evidence that the service is authorized to impersonate the client principal named in that ticket. In the S4U2Proxy extension, the KDC uses the evidence ticket as the basis for issuing a derivative ticket that the service can then use to impersonate the client. From nobody Mon Aug 4 08:48:01 2014 Return-Path: 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 718231A0356; Mon, 4 Aug 2014 08:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 TOvfYGGDhEw6; Mon, 4 Aug 2014 08:47:51 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id DA9041A014D; Mon, 4 Aug 2014 08:47:51 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 88C9D594069; Mon, 4 Aug 2014 08:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=1L6btOT4W4QYyS kHOn+4WquZyM4=; b=la4ZVSMRM2Pnqv288elHS8GDYt5NfV578uYi2TqY5WIxyc t2OmEyvUIlJLXTqBRApQOnOa44YULJKZnqL5J7IpJivvDDF/Kupa3qdE+aEf2CmG bIruop2r5LY4dX9TSHhu0TJSDvvk4f1iymlQS9Yybew61/NqWhciVj3PdARoo= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPA id 1B0ED594061; Mon, 4 Aug 2014 08:47:51 -0700 (PDT) Date: Mon, 4 Aug 2014 10:47:47 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140804154746.GE3579@localhost> References: <20140801224505.GB3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/3fk-25Fwu6-Q6FMNrE67IN7W6kY Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:47:57 -0000 On Sun, Aug 03, 2014 at 01:47:06AM -0400, Benjamin Kaduk wrote: > On Fri, 1 Aug 2014, Nico Williams wrote: > >We should agree as to data model for this, but not necessarily as to > >encoding. NFS uses XDR. > > I think we're talking past each other. AFS and NFS both use XDR; > AFS is proposing to add a new fundamental data structure, in > addition to the existing 'struct' and 'union' types. This is a > union type to which additional discriminant values (and > corresponding data branches) may be added without causing existing > implementations to fail to decode the binary data. To do this > requires that the encoded form for each branch of the union include > a length field, for the length of the encoded form of the data > branch. Fair enough. > >>--- > > > >They aren't assertions in the send of a programming language "assert". > >They are the client's assertions about local conditions, which the > >client and only the client can know about. The server's job is to > >decide whether to accept those assertions considering all the context at > >hand, including the compound authenticated principals. > > I understand what they are. All I am saying is that, while talking > about "assertions" in this sense is normal for, e.g., SAML, it is > not common in the GSS-API world. This is an observation, not an > actionable statement. But this isn't GSS. It's RPC, using GSS. The term assertion here has nothing to do with GSS. What's being asserted has nothing to do with GSS. And incidentally, assertion in the SAML sense does fit what's happening here. Here the client makes assertions about the identity and/or authorization attributes of a subject, "signs" them, and the server decides what to do with them. Other words can fit the bill, no doubt, but "assertion" seems best, because it resembles the SAML usage, and because the English language meaning of "assertion" fitst best. > >>--- > >[...] > > I don't think it's quite that cut-and-dried, as I can see cases > where the client should be able to make non-critical requests, but > also cases where the client should ask the server to fail the RPC if > the request is not fulfillable. Then you're proposing that criticality be described for the other cases where it's provided, correct? I agree. > >>In 2.6.1.1, the following text is a little confusing: > >> Thus a server may refuse to > >> grant requested authority to a user acting alone (e.g., via an > >> unprivileged user-space program), or to a client acting alone (e.g. > >> when a client is acting on behalf of a user) but may grant requested > >> authority to a client acting on behalf of a user if the server > >> identifies the user and trusts the client. > >> > >>It makes more sense when one reads "client" to mean "in-kernel NFS > >>client", but would probably be more clear if the "client is acting > > > >This is tricky. What's a "client"? The TCP client? The physical > >hardware running it and the NFS client stack? The process running the > >NFS client? Does it matter if it's in-kernel or a FUSE process, or some > >micro-kernel thing? For me the only thing that matters is if it has > >access to GSS credentials that the server will understand as being a > >"client's" as opposed to a "user's". > > > >Wording this is hard, yes. > > > >>on behalf of a user" is reworded, possibly to "on behalf of a single > >>user, using only that user's credentials). It looks like the > > > >That's more verbose! Yes, we need to distinguish "user with > >credentials" from "user without credentials" (since identity assertions > >are partly about the latter), but I think that should be clear anyways. > > Hmm, I was talking about the distinction between "host with > credentials" and "host without credentials". Clearly there is still > room for improvement :) I'm not sure that we can have a "host without credentials" any more since anonymous PKINIT (and equivalents for other mechanisms[*]) suffices for the purpose of protecting the client from the user. And, obviously, in the case of a user-level, per-user inplementation of NFSv4, there's no need for host credentials at all. The server doesn't need to the client to use compound authentication -- that's for the client's protection. But it may demand it in order to grant more-than-normal privilege to the user. Clearly anonymous client credentials won't do in that case. It's fair to expect that the clients that should be authorized to have assertions honored must have credentials! [*] The key is that the user must not be able to determine the client's security contexts' session keys, even if the user is in full control of the wire. > >>"client" vs. "kernel service" distinction is fuzzy throughout the > >>rest of the section, too. I would prefer if the word "client" > > > >We should absolutely not refer to "kernel" -- that's just an > >implementation detail. Instead we should refer to a "multi-user client" > >or something of the sort. > > I agree that we should not refer to "kernel"; this was intended as a > comment about the use of the word "client" in this document and that > it may not be appropriate in all the cases where it is currently > used. Sure, that may be. I'll take a look. Nico -- From nobody Mon Aug 4 08:51:09 2014 Return-Path: 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 E56EB1B2B87; Mon, 4 Aug 2014 08:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 lYPuFcs-I-qf; Mon, 4 Aug 2014 08:51:03 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7731A014D; Mon, 4 Aug 2014 08:50:46 -0700 (PDT) Received: from homiemail-a36.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTP id 50C3577806E; Mon, 4 Aug 2014 08:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=CtbYg8rtjNGFiUs1gKGh9gyBtT0=; b=lBmZ36FOMNd ulJVPwROAnply6bNfZuvucvSo2VNNBHSsn8g0W7igAT1tRbydUc3Q5OWUrNxvdyJ LQjbz/LIeZPhPOvcDT7VXsoqZ9xHy1tWqZHTGL9rnZQxxSUwdTO84kWoC5wS5umS YGVxKgeFKU5VYGDsxbVmdOhVNJvyOrcE= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a36.g.dreamhost.com (Postfix) with ESMTPA id F00B977805B; Mon, 4 Aug 2014 08:50:45 -0700 (PDT) Date: Mon, 4 Aug 2014 10:50:45 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140804155035.GF3579@localhost> References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mAXOpW4nSt9JL-3H3AjcG3GE8DM Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:51:07 -0000 On Sun, Aug 03, 2014 at 01:50:44AM -0400, Benjamin Kaduk wrote: > On Fri, 1 Aug 2014, Nico Williams wrote: >=20 > I think we're actually in agreement on what's going on here, just > using different words to describe it. OK. > >>> That stops > >>>replay attacks. We need only bind things sufficiently to the new > >>>RPCSEC_GSS security context handle and the client credentials. > >> > >>An evil user that can get root on a client machine wouldn=E2=80=99t n= eed to > >>[...] > > > >Stop right there! We *always* assume local security when dealing with > >security protocols :) There's no need to state this assumption. It's >=20 > Indeed, this is not the point I was trying to make. More under > separate cover. I was responding to Andy :) From nobody Mon Aug 4 08:53:49 2014 Return-Path: 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 9E0A11A036D; Mon, 4 Aug 2014 08:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 0w5105y63FOw; Mon, 4 Aug 2014 08:53:45 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB681A0356; Mon, 4 Aug 2014 08:53:45 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 6E1C73B807C; Mon, 4 Aug 2014 08:53:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=m8HiCJwn9c6mRC kviYCPtwYMqRk=; b=O/YOTIAUEMoACSdNBuIw20GDvrApx4z3NB1n8/y95s3kiZ qEOsFKa2MeZI5ltyW/nmdPTlg2CmTjHiTila1F1/JS7coEjvAnUluKsc8QncTP41 k+Ud4R7O7b17SvCxT/4z+gp8KYKncUnH+1eFKOzgxh+85sYsS87hYcb+Zoors= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 0752C3B8078; Mon, 4 Aug 2014 08:53:44 -0700 (PDT) Date: Mon, 4 Aug 2014 10:53:44 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140804155343.GG3579@localhost> References: <20140801055401.GA7409@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ILMUgswCz6PWXuheicePjjSGMBY Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 15:53:46 -0000 On Sun, Aug 03, 2014 at 02:08:48AM -0400, Benjamin Kaduk wrote: > On Fri, 1 Aug 2014, Nico Williams wrote: > > >>Three levels of protection are provided for the RPC bodies, none, > >>integrity, and privacy. The choice of level for this attempt at > >>this RPC, as well as a sequence number unique to this transmission, > >>are encoded into the "credential", a part of the RPC request header; > >>there is a GSS MIC over the header, so the header (and protection > >>level and sequence number) are always protected. The request > >>payload's encoding depends on the level; for none, it is unchanged. > >>[...] > > > >Though "none" always MICs the header. > > Yes. This is important, BTW, because the RPCSEC_GSS context handle is part of the header that gets MICed, and this is/was part of the compoung binding as I recall envisioning it. > >>restricted to just a combination of host and user credentials, > >>specifying which one is which. I think this is the only > >>well-understood scenario for compount authentication at the moment, > >>and makes sense. > > > >What is the antecedent of "this" here? Did you mean that conveying > >local privilege information is not understood? > > "this" is the scenario wherein host credentials and user credentials > are combined for the compound authentication. I make no statement > on local privilege information, rather I claim that scenarios such > as combining user A's credentials with uesr B's credentials is not > well understood. Well, a user with some set of privileges might nonetheless want to assert a subset of them without client/host credentials. There's nothing wrong with that. It's the case of asserting more privilege than normal that [generally] requires a trusted agent to vouch for the assertion. Nico -- From nobody Mon Aug 4 09:00:23 2014 Return-Path: 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 E0E9C1A03A1; Mon, 4 Aug 2014 09:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 MV6G7i8KeGRR; Mon, 4 Aug 2014 09:00:19 -0700 (PDT) Received: from fieldses.org (fieldses.org [174.143.236.118]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99ADC1A039F; Mon, 4 Aug 2014 09:00:19 -0700 (PDT) Received: from bfields by fieldses.org with local (Exim 4.76) (envelope-from ) id 1XEKgK-0001jk-KM; Mon, 04 Aug 2014 12:00:16 -0400 Date: Mon, 4 Aug 2014 12:00:16 -0400 To: Nico Williams Message-ID: <20140804160016.GC23341@fieldses.org> References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140801221535.GA3579@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) From: "J. Bruce Fields" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Cw2MpuQqd1apHIjy4TuBLqyOH-E Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:00:22 -0000 On Fri, Aug 01, 2014 at 05:15:36PM -0500, Nico Williams wrote: > On Fri, Aug 01, 2014 at 08:28:25PM +0000, Adamson, Andy wrote: > > On Aug 1, 2014, at 1:54 AM, Nico Williams wrote: > > > On Thu, Jul 31, 2014 at 06:38:09PM -0400, Benjamin Kaduk wrote: > > >> Hmm, this seems to have gotten rather long. > > > > Well, it’s two pages shorter than draft-williams-rpcsecgssv3-02.txt (!) > > :) > > > >> Multi-principal authentication > > >> > > >> This draft proposes a multi-principal authentication scheme, > > >> restricted to just the case of a privileged client process on a > > > > > > No, not only the case of a privileged client process. > > > > Sure, but for the Multi-principal piece we do say the following which says that the use-case is privileged client process…. > > It was always my intention that traditional (read: multi-user > shared-cache) NFS client implementations would just always use > "multi-principal" contexts when doing any RPCs on a user's behalf. > > That is, addressing the "user can impersonate the server to the client" > problem was always my first and foremost goal with this protocol, though > I didn't always say so explicitly (since at the time the attack was not > well-known, I didn't want to publicize it). Oh, that's really helpful to know. It'd be great if we could get a paragraph into the draft explaining this. (And also the server-to-server copy stuff, and any other example uses.) It's easier to understand with the motivations. --b. From nobody Mon Aug 4 09:15:00 2014 Return-Path: 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 EF7021A03D8 for ; Mon, 4 Aug 2014 09:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.034 X-Spam-Level: * X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 NrNgdhZR64GH for ; Mon, 4 Aug 2014 09:14:57 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 638271A03C3 for ; Mon, 4 Aug 2014 09:14:57 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id 451872007F133; Mon, 4 Aug 2014 09:14:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=snJg/x9cxJ+9jk xgV1sEBygDMGE=; b=rDTCTxqVQCUESuMoumEElY+fGpngAUE4naIgD56UD5hY0V XpL8KPHpjMdTAUK2hJ5Ubs57vOwO4P6KcHSTXbwFCCHccCx5vuggTc+3B2mZF4KQ W99Z02TMR0kVMomXjKPP7KSLwVV/ogLD0ZiKM6N5f9GixrfNTipeBZNnbjgeQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id E7C8E2007F12C; Mon, 4 Aug 2014 09:14:56 -0700 (PDT) Date: Mon, 4 Aug 2014 11:14:56 -0500 From: Nico Williams To: Greg Hudson Message-ID: <20140804161454.GH3579@localhost> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/20YIKIpBc6q80A3sQgw-WTHWUB4 Cc: kitten@ietf.org Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:14:59 -0000 On Sat, Aug 02, 2014 at 11:05:39AM -0400, Greg Hudson wrote: > I believe that all major implementations of Kerberos (and perhaps all > implementations period) violate RFC 4120 by treating authorization data > as non-critical in application servers. Moreover, I believe that > implementations don't want to change for fear of breaking existing > deployments. We generally specify authdata types under the assumption > that some implementations obey this part of RFC 4120 and some don't. We > cannot really specify an authdata type which needs to be critical for > application servers at this time. The biggest problem is that criticality must be decided by the application, not by the Kerberos implementation, but we lack the APIs by which to give applications access to raw (or processed[*]) critical AD. In order to fail safe, the Kerberos implementation must know if the application will understand critical AD; it's not enough to have APIs by which to convey critical AD to the application. [*] Processing AD in the Kerberos implementation requires knowing the AD type a priori. > There have been several positive authorization data types implemented or > proposed to date: the PAC[1], the PAD[2], AD-INITIAL-VERIFIED-CAS[3], Arguably AD-INITIAL-VERIFIED-CAS should have been critical. It's like transit path, which is critical. This one is mostly for the Kerberos implementation to judge, since it's the Kerberos implementation that applies transit path policy. Though with my proposed generic naming attributes for the RFC6680 model the application could check the transit path itself and apply further policy. Altogether, it isn't all that important that AD-INITIAL-VERIFIED-CAS be critical. It is important that it be signed by the KDC though. > AD-LOGIN-ALIAS[4], AD-authentication-strength[5], the authentication > indicator[6], and perhaps others. I am aware of only two negative > authorization data types implemented or proposed to date: > AD-fx-fast-armor[7] and an informal proposal by David Benjamin[8]. Both > of those types are enforced by the KDC and not application servers. Right: we can always introduce AD that are critical for KDC services. That's fine. > I can speculate on several future directions for critical authorization > data: > > 1. The status quo. Almost all authorization data gets wrapped in > AD-IF-RELEVANT at a penalty of 13 or more bytes. Critical authdata I am fine with this. > for application servers is impossible. Not necessarily. RFC6680 gives us the APIs we need by which applications can judge critical AD, but it doesn't give the mechanism any way to know if the application will understand and evaluate critical AD. We might be able to get critical AD support in APIs but no fail-safe mechanism in the mechanism. > 2. We somehow determine that all existing Kerberos implementations > violate this aspect of RFC 4120. We could then specify that > AD-IF-RELEVANT is no longer necessary. Critical authdata for > application servers remains impossible. I think it will be difficult to make that determination. > 3. We convince all of the major implementations to conform to RFC 4120, > perhaps after determining that it wouldn't break any existing > implementations as long as you ignore unwrapped PACs. We wait for > all old deployments to fall out of service (i.e. decades pass). > Criticial authdata becomes possible. See comments above. > 4. We specify a new AD-MANDATORY subcontainer and convince all of the > major implementations to implement it. We wait for all old > deployments to fall out of service. Critical authdata becomes > possible using the wrapper. Can be combined with (2). No need to wait in order to start using it. Right? > Of these, (1) is by far the most likely. (2) is attractive given the > practical constraints of ticket sizes in some environments, but seems > difficult to accomplish. Why couldn't we go with (4). Nico -- From nobody Mon Aug 4 09:39:50 2014 Return-Path: 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 6312B1B2BAD; Mon, 4 Aug 2014 09:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 ZrbXsA9RWJSO; Mon, 4 Aug 2014 09:38:22 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DE8D1A0451; Mon, 4 Aug 2014 09:38:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,799,1400050800"; d="scan'208";a="179931786" Received: from vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) by mx12-out.netapp.com with ESMTP; 04 Aug 2014 09:38:21 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by vmwexceht02-prd.hq.netapp.com (10.106.76.240) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 09:38:18 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 4 Aug 2014 09:38:17 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Mon, 4 Aug 2014 09:38:17 -0700 From: "Adamson, Andy" To: Nico Williams Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPrAU48wbIQBIMg0W+Un2kpIHDeZu7PYKAgAGURgCABFCEgA== Date: Mon, 4 Aug 2014 16:38:16 +0000 Message-ID: References: <20140801224505.GB3579@localhost> In-Reply-To: <20140801224505.GB3579@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4B4AC2733C182648BE32E257CE8FD7CF@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/CApsiCxTmxCHhNnqJ4aTNpJoT28 X-Mailman-Approved-At: Mon, 04 Aug 2014 09:39:49 -0700 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:38:23 -0000 On Aug 1, 2014, at 6:45 PM, Nico Williams wrote: >>=20 >> --- >> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample >> code on page 7? It is not otherwise mentioned in the draft, and the >=20 > Dunno. It was never marked so in my draft. Andy? It is marked as =93not used=94 in GSSv3 because GSSv3 provides it=92s own c= hannel binding method. =97>Andy From nobody Mon Aug 4 09:43:11 2014 Return-Path: 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 2CCD71A0601; Mon, 4 Aug 2014 09:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 gQNTaI8VLYKx; Mon, 4 Aug 2014 09:43:05 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 31A001A05F5; Mon, 4 Aug 2014 09:43:05 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id EE6AA20047B8D; Mon, 4 Aug 2014 09:43:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=qvUWt/s7uFy8pX mmokKhFYo4RFw=; b=THgqrR+w2JexnmQSqtjbKbxYF4gyahAFJD6JHZv907MADx /SxLSzGXazxt1SrSTwILbkmStXFGwJ/87HJvXqhMoVsZlegzH4yluTpZqWGCPwFi 3qZ6mGdM5qSwkAssgi9HBXM00/qMNVoHuPvyVovFErH5Z8MOvUmvhSZNuSf10= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPA id 8AE1220047B8C; Mon, 4 Aug 2014 09:43:04 -0700 (PDT) Date: Mon, 4 Aug 2014 11:43:04 -0500 From: Nico Williams To: "J. Bruce Fields" Message-ID: <20140804164302.GJ3579@localhost> References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> <20140804160016.GC23341@fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140804160016.GC23341@fieldses.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LyGlA9Q-TPpkOtmXtk234u-VhjM Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:43:06 -0000 On Mon, Aug 04, 2014 at 12:00:16PM -0400, J. Bruce Fields wrote: > On Fri, Aug 01, 2014 at 05:15:36PM -0500, Nico Williams wrote: > > It was always my intention that traditional (read: multi-user > > shared-cache) NFS client implementations would just always use > > "multi-principal" contexts when doing any RPCs on a user's behalf. > > > > That is, addressing the "user can impersonate the server to the client" > > problem was always my first and foremost goal with this protocol, though > > I didn't always say so explicitly (since at the time the attack was not > > well-known, I didn't want to publicize it). > > Oh, that's really helpful to know. Yeah :( I mentioned it several times at meetings. The cat has been out of the bag for a long time as to the vulnerability for shared-cache clients, so we might as well state this motivation clearly. Note that such clients really need server support for this. The only other alternative for clients is to not share the NFSv4 cache _at all_, but this is very difficult for some client architectures. It's trivial for clients that can do Plan9-style namespace management, though even then it's critical that when the system does an exec() it doesn't trust any set-uid/gid bits from an executable's vnode. I.e., it's critical that the cache not be shared even with the privilege management parts of the system. Even where cache non-sharing is trivial, cache sharing has significant resource usage benefits in multi-user systems, therefore it is or can be highly desirable. It's worth noting that multi-user systems are becoming less common, but multiple levels of privilege for a single user's processes is still likely to be a common situation. > It'd be great if we could get a paragraph into the draft explaining > this. (And also the server-to-server copy stuff, and any other example > uses.) It's easier to understand with the motivations. Yes. Nico -- From nobody Mon Aug 4 09:44:12 2014 Return-Path: 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 B8D711A04B1; Mon, 4 Aug 2014 09:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 wL70mEdczX5j; Mon, 4 Aug 2014 09:44:10 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 278421A0421; Mon, 4 Aug 2014 09:44:09 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id 05EF83B8062; Mon, 4 Aug 2014 09:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=td1OSiz9MpFcQhbmHetNZas/W5U=; b=A+joMFJzs4L vGiPnBQUatZsEJTvMsYoV4ocUCiWJ1NfK6EHRBzDr1b+Xoryhs8xWR8HEmKzMpZK N82zz6y2ZbcpjztPs3vn6DbZco6xU42H+G5tqdURZL3iha+OMM05w9YxvgN9cNg+ nd7LQOZsvdHD34EA6aSQAxKnz62uVOn4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPA id 888443B805C; Mon, 4 Aug 2014 09:44:08 -0700 (PDT) Date: Mon, 4 Aug 2014 11:44:08 -0500 From: Nico Williams To: "Adamson, Andy" Message-ID: <20140804164406.GK3579@localhost> References: <20140801224505.GB3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DH-MHwdnypM5p2mghwmXmAOJrMU Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:44:10 -0000 On Mon, Aug 04, 2014 at 04:38:16PM +0000, Adamson, Andy wrote: > On Aug 1, 2014, at 6:45 PM, Nico Williams wrote= : > >> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample > >> code on page 7? It is not otherwise mentioned in the draft, and the > >=20 > > Dunno. It was never marked so in my draft. Andy? >=20 > It is marked as =E2=80=9Cnot used=E2=80=9D in GSSv3 because GSSv3 provi= des it=E2=80=99s own channel binding method. Ah, right, that's a v2 thing. Thanks for reminding me! From nobody Mon Aug 4 09:56:12 2014 Return-Path: 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 4C0D51A0059; Mon, 4 Aug 2014 09:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 CvMarnyta95T; Mon, 4 Aug 2014 09:56:02 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98F3B1A0019; Mon, 4 Aug 2014 09:56:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,799,1400050800"; d="scan'208";a="337397197" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx1-out.netapp.com with ESMTP; 04 Aug 2014 09:56:03 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 09:55:59 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 4 Aug 2014 09:55:58 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Mon, 4 Aug 2014 09:55:58 -0700 From: "Adamson, Andy" To: Nico Williams Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPrAU48wbIQBIMg0W+Un2kpIHDeZu7PYKAgAB5yoCAAPRMgIAAHfIAgARdswA= Date: Mon, 4 Aug 2014 16:55:57 +0000 Message-ID: References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> In-Reply-To: <20140801221535.GA3579@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5096B889A7C7B444BB2BD24131998673@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/zXH3as2DEEho8lMAJ9nd5aAwglc Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 16:56:09 -0000 On Aug 1, 2014, at 6:15 PM, Nico Williams wrote: > (Was "multi-principal" my name for this? No, I called them compound > authentication. I prefer "compound=94.) Hi NIco I changed the name from =91compound=92 to multi-principal=92 in response th= e review comments at IETF 89 where many NFSv4 WG members expressed that =91= compound=92 had too many meanings (especially in NFSv4.x) and led to confus= ion. =97>Andy From nobody Mon Aug 4 10:22:36 2014 Return-Path: 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 771411A0026; Mon, 4 Aug 2014 10:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 N-i8i8-2BhNL; Mon, 4 Aug 2014 10:22:29 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9871A0019; Mon, 4 Aug 2014 10:22:28 -0700 (PDT) X-AuditID: 12074423-f79bf6d000007580-ac-53dfc153b874 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 2B.6C.30080.351CFD35; Mon, 4 Aug 2014 13:22:27 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s74HMQ4r020488; Mon, 4 Aug 2014 13:22:26 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s74HMMQn008194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2014 13:22:25 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s74HMMtY023324; Mon, 4 Aug 2014 13:22:22 -0400 (EDT) Date: Mon, 4 Aug 2014 13:22:22 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140804154746.GE3579@localhost> Message-ID: References: <20140801224505.GB3579@localhost> <20140804154746.GE3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDIsWRmVeSWpSXmKPExsUixG6noht88H6wwc4/+hZHN69isZj9/hGr xalrR9gspi+ycmDxeHnqHKPHkiU/mTxmfPrCFsAcxWWTkpqTWZZapG+XwJVxoOc2U8EdqYqD 7UuZGhj7RbsYOTkkBEwkHj76ywJhi0lcuLeerYuRi0NIYDaTRM+zT+wQzgZGiRl7v0I5B5kk jmx5wQrSIiRQL9G+8BAbiM0ioCWxtn0DWJxNQEVi5puNYHERAU2J6/OWgtnMAmUS3dPawWqE Bdwkml/9YgaxOQX0JGbNawSzeQUcJQ6dXccKsewto8Skzx/AmkUFdCRW75/CAlEkKHFy5hMW iKGWEuf+XGebwCg4C0lqFpLUAkamVYyyKblVurmJmTnFqcm6xcmJeXmpRbpmermZJXqpKaWb GMGB7KK8g/HPQaVDjAIcjEo8vAJq94OFWBPLiitzDzFKcjApifJq7AUK8SXlp1RmJBZnxBeV 5qQWH2KU4GBWEuGtOwCU401JrKxKLcqHSUlzsCiJ8761tgoWEkhPLEnNTk0tSC2CycpwcChJ 8AaBNAoWpaanVqRl5pQgpJk4OEGG8wANVwIbXlyQmFucmQ6RP8WoKCXOOwEkIQCSyCjNg+uF JZpXjOJArwjzWoJU8QCTFFz3K6DBTECDzXTABpckIqSkGhj7jvQrdzxMMdkzNVis83pVl/ay OpYVxxPm79y0dPXFiBfzubuWfZy92bvwjJeXq6j7CpZDzvW7T+1TLk997v7rXpCr4xlrladV +5au0mA1X3LLvuGM/Y1z2Qyv7jD3aLQ2W+568cXrrXHQCrHla5r+ftbSObdFVvXjX+dgnsYd h2VcIgrdpP8psRRnJBpqMRcVJwIApI1PLw8DAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Oi6kUJzTJ7E81WaXLUhojs7jlYk Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:22:33 -0000 On Mon, 4 Aug 2014, Nico Williams wrote: > On Sun, Aug 03, 2014 at 01:47:06AM -0400, Benjamin Kaduk wrote: >> On Fri, 1 Aug 2014, Nico Williams wrote: >>>> --- >>> [...] >> >> I don't think it's quite that cut-and-dried, as I can see cases >> where the client should be able to make non-critical requests, but >> also cases where the client should ask the server to fail the RPC if >> the request is not fulfillable. > > Then you're proposing that criticality be described for the other cases > where it's provided, correct? I agree. I think so? I'm not sure I understand exactly what you're saying. The main thing I'm saying is that we define a critical bit for all types of rgss3_assertion, but do not specify what to set it to for one branch of the rgss3_assertion_u union. That looks like what you're saying, too. >>>> In 2.6.1.1, the following text is a little confusing: >>>> Thus a server may refuse to >>>> grant requested authority to a user acting alone (e.g., via an >>>> unprivileged user-space program), or to a client acting alone (e.g. >>>> when a client is acting on behalf of a user) but may grant requested >>>> authority to a client acting on behalf of a user if the server >>>> identifies the user and trusts the client. >>>> >>>> It makes more sense when one reads "client" to mean "in-kernel NFS >>>> client", but would probably be more clear if the "client is acting >>> >>> This is tricky. What's a "client"? The TCP client? The physical >>> hardware running it and the NFS client stack? The process running the >>> NFS client? Does it matter if it's in-kernel or a FUSE process, or some >>> micro-kernel thing? For me the only thing that matters is if it has >>> access to GSS credentials that the server will understand as being a >>> "client's" as opposed to a "user's". >>> >>> Wording this is hard, yes. >>> >>>> on behalf of a user" is reworded, possibly to "on behalf of a single >>>> user, using only that user's credentials). It looks like the >>> >>> That's more verbose! Yes, we need to distinguish "user with >>> credentials" from "user without credentials" (since identity assertions >>> are partly about the latter), but I think that should be clear anyways. >> >> Hmm, I was talking about the distinction between "host with >> credentials" and "host without credentials". Clearly there is still >> room for improvement :) > > I'm not sure that we can have a "host without credentials" any more > since anonymous PKINIT (and equivalents for other mechanisms[*]) > suffices for the purpose of protecting the client from the user. Many krb5 realms do not have PKINIT enabled on the KDC. > And, obviously, in the case of a user-level, per-user inplementation of > NFSv4, there's no need for host credentials at all. Yes. > The server doesn't need to the client to use compound authentication -- > that's for the client's protection. But it may demand it in order to > grant more-than-normal privilege to the user. Clearly anonymous client > credentials won't do in that case. It's fair to expect that the clients > that should be authorized to have assertions honored must have > credentials! > > [*] The key is that the user must not be able to determine the client's > security contexts' session keys, even if the user is in full control > of the wire. Yes. -Ben From nobody Mon Aug 4 11:07:20 2014 Return-Path: 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 709501A00D7; Mon, 4 Aug 2014 11:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 0Ywo_xafcRAD; Mon, 4 Aug 2014 11:07:06 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D23C01A00DA; Mon, 4 Aug 2014 11:07:04 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 8C0C36B007E; Mon, 4 Aug 2014 11:07:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=0dXDsy0Ue272hz 9eg5SL7RwyjdI=; b=ZHXbKQCF6o2UgN2kg3gJLx1IOvt7DXgwnmo0K77SLTSqkT cY/+L9oM/qcUar5VFRXfhrdnDwiHiQJPzqWNoFlpKajJsPaBBEgeCEwXfX3H7gEC yV99YbQBo+xzKDTB6PAAtSLDUdQ00kkFKYZR+B00BcXw0H3hprHy3X/Rg/ENQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPA id 13ED76B0078; Mon, 4 Aug 2014 11:07:03 -0700 (PDT) Date: Mon, 4 Aug 2014 13:07:03 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140804180702.GQ3579@localhost> References: <20140801224505.GB3579@localhost> <20140804154746.GE3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/GNHj4bwQrjxrGgFX7lPhyfl9wFw Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:07:07 -0000 On Mon, Aug 04, 2014 at 01:22:22PM -0400, Benjamin Kaduk wrote: > On Mon, 4 Aug 2014, Nico Williams wrote: > >Then you're proposing that criticality be described for the other cases > >where it's provided, correct? I agree. > > I think so? I'm not sure I understand exactly what you're saying. > The main thing I'm saying is that we define a critical bit for all > types of rgss3_assertion, but do not specify what to set it to for > one branch of the rgss3_assertion_u union. That looks like what > you're saying, too. The critical bit is already factored out. We should do the same for the text. > >>[...] > > > >I'm not sure that we can have a "host without credentials" any more > >since anonymous PKINIT (and equivalents for other mechanisms[*]) > >suffices for the purpose of protecting the client from the user. > > Many krb5 realms do not have PKINIT enabled on the KDC. "Meh". If they don't want PKINIT then they must key their clients. If they don't want to key their clients then they must enable anon PKINIT. (Another possibility is to deploy a different mechanism for the client<->server contexts.) For single user systems where the user owns the system there is no need for client credentials, and anyways, device enrolment can take care of that. The point is that clients can be expected to have credentials suitable for this purpose. I think this is quite clearly true. Nico -- From nobody Mon Aug 4 11:09:57 2014 Return-Path: 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 1B4551A00DC; Mon, 4 Aug 2014 11:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 XgkVE6qB-5D3; Mon, 4 Aug 2014 11:09:53 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id BFCF01A00AE; Mon, 4 Aug 2014 11:09:48 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id 917C0438080; Mon, 4 Aug 2014 11:09:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=k8RGyJU1MTrH5kx1JMJexeVI18c=; b=k8mrlrxlrab 1pT52I2yKFGPNV7P5uk6HHxxZyDzAUaaacdY4n/lGGCy6nsPV88qW5VZDI5ibePE CZEnUWgVCPZ9xL3FaZe5XrtbwX6ufYmwLyrX+Jp6KBLLw10s866BRUxb+RIgP2r9 I6U+qSRRCPzTfmCdrYnR9KOHQwCARyQw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id 2F5AE43807F; Mon, 4 Aug 2014 11:09:48 -0700 (PDT) Date: Mon, 4 Aug 2014 13:09:47 -0500 From: Nico Williams To: "Adamson, Andy" Message-ID: <20140804180946.GR3579@localhost> References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/qkg3xk1BemusiKdDwy_UQijWTvw Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:09:54 -0000 On Mon, Aug 04, 2014 at 04:55:57PM +0000, Adamson, Andy wrote: > On Aug 1, 2014, at 6:15 PM, Nico Williams wrote= : > > (Was "multi-principal" my name for this? No, I called them compound > > authentication. I prefer "compound=E2=80=9D.) >=20 > Hi NIco >=20 > I changed the name from =E2=80=98compound=E2=80=99 to multi-principal=E2= =80=99 in response > the review comments at IETF 89 where many NFSv4 WG members expressed > that =E2=80=98compound=E2=80=99 had too many meanings (especially in NF= Sv4.x) and > led to confusion. "Compound" is used as an adjective in all cases. I don't see how "compound authentication" (or "compound context handle", ...) is confusable with "compound RPC". But this isn't important enough to me; aligning the terminology with AFS' rxgk is. Ben, what does rxgk call this? From nobody Mon Aug 4 11:13:34 2014 Return-Path: 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 414301A00AE; Mon, 4 Aug 2014 11:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 CLBsxdzu0G9H; Mon, 4 Aug 2014 11:13:26 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 994981A00BA; Mon, 4 Aug 2014 11:13:26 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-66-53dfcd45e732 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 5B.41.12039.54DCFD35; Mon, 4 Aug 2014 14:13:25 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s74IDOsD004443; Mon, 4 Aug 2014 14:13:24 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s74IDLqb026838 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2014 14:13:23 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s74IDK55029698; Mon, 4 Aug 2014 14:13:20 -0400 (EDT) Date: Mon, 4 Aug 2014 14:13:20 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140804164406.GK3579@localhost> Message-ID: References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-559023410-1761750950-1407176000=:21571" X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEKsWRmVeSWpSXmKPExsUixG6nrut69n6wwbomVYujm1exWMx+/4jV 4tS1I2wW0xdZObB4vDx1jtFjyZKfTB4zPn1hC2CO4rJJSc3JLEst0rdL4Mq4u/IPW8FhzorD p04wNTC+ZO9i5OSQEDCRmND0igXCFpO4cG89WxcjF4eQwGwmieN3Z7JCOBsYJbaue8AC4Rxk klh8+gFYu5BAvcTUnw1gNouAlsSaNT+ZQGw2ARWJmW82soHYIgKaEtfnLQWzmQXKJLqntbOC 2MICbhLNr34xg9icAnoSkyZOADuDV8BR4vzpk2wQ818ySlzfHQJiiwroSKzePwWqRlDi5Mwn LBAzAyUWT37LPoFRcBaS1CwkqVmMHEC2mcTCNjuIsLbE/ZttbAsYWVYxyqbkVunmJmbmFKcm 6xYnJ+blpRbpGunlZpbopaaUbmIEBT2nJO8OxncHlQ4xCnAwKvHwCqjdDxZiTSwrrsw9xCjJ waQkyrvzOFCILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG/cKaAcb0piZVVqUT5MSpqDRUmc9621 VbCQQHpiSWp2ampBahFMVoaDQ0mCt/sMUKNgUWp6akVaZk4JQpqJgxNkOA/Q8GiQGt7igsTc 4sx0iPwpRkUpcd5dp4ESAiCJjNI8uF5YUnrFKA70ijBvAUg7DzChwXW/AhrMBDTYTAdscEki QkqqgXHxfUm/WazqQbc/yP49mmR5K+rum60X7r0WqjbW6v7GrfPw5RcvcUWbpzvTfq05s2Zu k+U8yzlneDcvy7/ZmcL14fvhvH17u+3yGaavfeHl09PW9YSFRTL4wsMPPg/3273v5r5+YtcE i0+5q3MvLZE52KfhWvjNyVtdWkjpckJSeemsZ5teTUpXYinOSDTUYi4qTgQAP2izcyUDAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RF8mOsKKVmcC7x2t3e7u3zLvB5o Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:13:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1761750950-1407176000=:21571 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 4 Aug 2014, Nico Williams wrote: > On Mon, Aug 04, 2014 at 04:38:16PM +0000, Adamson, Andy wrote: >> On Aug 1, 2014, at 6:45 PM, Nico Williams wrote: >>>> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample >>>> code on page 7? It is not otherwise mentioned in the draft, and the >>> >>> Dunno. It was never marked so in my draft. Andy? >> >> It is marked as =E2=80=9Cnot used=E2=80=9D in GSSv3 because GSSv3 provid= es it=E2=80=99s own channel binding method. > > Ah, right, that's a v2 thing. Thanks for reminding me! Sorry if this is belaboring the point, but my reading of the text in -08=20 is that v3 permits the use of RPCSEC_GSS_BIND_CHANNEL to establish a=20 channel over which RPCSEC_GSS_CREATE can be called, and implicitly=20 disrecommends the use of this operation for any other use. -Ben ---559023410-1761750950-1407176000=:21571-- From nobody Mon Aug 4 11:45:13 2014 Return-Path: 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 548871A0109; Mon, 4 Aug 2014 11:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 NZ2kZFLKsTXv; Mon, 4 Aug 2014 11:45:06 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24E1A00DF; Mon, 4 Aug 2014 11:45:06 -0700 (PDT) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id F352C10060; Mon, 4 Aug 2014 11:45:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=HFZL0xxqABfG7Krqrv7L+hN7NJ0=; b=lTY9aDTNTev FDbFsZsGK/HpvhCtiaOanx9Kc4ipbnYPG+zhgFqtKTTJ1jQgqLrFGWgYV8YtHToQ hv3MEDCZlc92dH32nm6PtLJkzCgSOjGWOI1AB8vjlRw2ahUheO6HGtdoCb/jXxsW mBUM/HInJ1yG0TnhnbPGw0AxJF6SeV7s= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPA id 8C8E910059; Mon, 4 Aug 2014 11:45:05 -0700 (PDT) Date: Mon, 4 Aug 2014 13:45:05 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140804184503.GS3579@localhost> References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Cc7IVZpyUDXs-bdJNxaYnaoLVmc Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:45:10 -0000 On Mon, Aug 04, 2014 at 02:13:20PM -0400, Benjamin Kaduk wrote: > On Mon, 4 Aug 2014, Nico Williams wrote: >=20 > >On Mon, Aug 04, 2014 at 04:38:16PM +0000, Adamson, Andy wrote: > >>On Aug 1, 2014, at 6:45 PM, Nico Williams wro= te: > >>>>Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample > >>>>code on page 7? It is not otherwise mentioned in the draft, and th= e > >>> > >>>Dunno. It was never marked so in my draft. Andy? > >> > >>It is marked as =E2=80=9Cnot used=E2=80=9D in GSSv3 because GSSv3 pro= vides it=E2=80=99s own channel binding method. > > > >Ah, right, that's a v2 thing. Thanks for reminding me! >=20 > Sorry if this is belaboring the point, but my reading of the text in > -08 is that v3 permits the use of RPCSEC_GSS_BIND_CHANNEL to > establish a channel over which RPCSEC_GSS_CREATE can be called, and > implicitly disrecommends the use of this operation for any other > use. - v3 (all versions so far) permits the use of any RPCSEC_GSS context handle, whether a v1, v2, or v3 handle. - v2 handles may have been channel bound with RPCSEC_GSS_BIND_CHANNEL; this is implied and need not be stated, IMO. RPCSEC_GSS_BIND_CHANNEL should be explicitly forbidden on v3 handles, as v3 has a different mechanism for channel binding. It is listed only for completeness given that v3 is an extension of the earlier versions. Do you agree? Or did I miss the point? Nico --=20 From nobody Mon Aug 4 11:59:37 2014 Return-Path: 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 F04FA1A0173; Mon, 4 Aug 2014 11:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 UWQuRFE8XPq4; Mon, 4 Aug 2014 11:59:32 -0700 (PDT) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D29A11A0198; Mon, 4 Aug 2014 11:59:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,799,1400050800"; d="scan'208";a="98673424" Received: from vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) by mx2-out.netapp.com with ESMTP; 04 Aug 2014 11:59:31 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht05-prd.hq.netapp.com (10.106.77.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 11:59:29 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 4 Aug 2014 11:59:27 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Mon, 4 Aug 2014 11:59:27 -0700 From: "Adamson, Andy" To: Nico Williams Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPsA/O768gZXx3NUq3zN1fzegP6pvBPaKAgAAEBoA= Date: Mon, 4 Aug 2014 18:59:27 +0000 Message-ID: <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> <20140804184503.GS3579@localhost> In-Reply-To: <20140804184503.GS3579@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <72054805DFDC3E43B9AED6FC3272E258@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/vQJkGQIBm9sX2qvOGDhCcs-EtJA Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 18:59:34 -0000 On Aug 4, 2014, at 2:45 PM, Nico Williams wrote: > On Mon, Aug 04, 2014 at 02:13:20PM -0400, Benjamin Kaduk wrote: >> On Mon, 4 Aug 2014, Nico Williams wrote: >>=20 >>> On Mon, Aug 04, 2014 at 04:38:16PM +0000, Adamson, Andy wrote: >>>> On Aug 1, 2014, at 6:45 PM, Nico Williams wrot= e: >>>>>> Why is RPCSEC_GSS_BIND_CHANNEL marked as "not used" in the sample >>>>>> code on page 7? It is not otherwise mentioned in the draft, and the >>>>>=20 >>>>> Dunno. It was never marked so in my draft. Andy? >>>>=20 >>>> It is marked as =93not used=94 in GSSv3 because GSSv3 provides it=92s = own channel binding method. >>>=20 >>> Ah, right, that's a v2 thing. Thanks for reminding me! >>=20 >> Sorry if this is belaboring the point, but my reading of the text in >> -08 is that v3 permits the use of RPCSEC_GSS_BIND_CHANNEL to >> establish a channel over which RPCSEC_GSS_CREATE can be called, and >> implicitly disrecommends the use of this operation for any other >> use. >=20 > - v3 (all versions so far) permits the use of any RPCSEC_GSS context > handle, whether a v1, v2, or v3 handle. No, multiple handle versions were left behind once we made v3 a proper supe= rset of v2 (and v1). Only v3 handles allowed in v3. >=20 > - v2 handles may have been channel bound with RPCSEC_GSS_BIND_CHANNEL; > this is implied and need not be stated, IMO. No v2 handles >=20 > RPCSEC_GSS_BIND_CHANNEL should be explicitly forbidden on v3 handles, > as v3 has a different mechanism for channel binding. It is listed only > for completeness given that v3 is an extension of the earlier versions. Correct. This should be made more clear. When using v3 RPCSEC_GSS_BIND_CHAN= NEL is depricated in favor of the v3 channel binding mechanism. =97>Andy >=20 > Do you agree? Or did I miss the point? >=20 > Nico > -- From nobody Mon Aug 4 12:07:23 2014 Return-Path: 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 BFE481A0173; Mon, 4 Aug 2014 12:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 0FSFq2kblWYQ; Mon, 4 Aug 2014 12:07:18 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id D35AE1A0145; Mon, 4 Aug 2014 12:07:18 -0700 (PDT) Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id 5D998264060; Mon, 4 Aug 2014 12:07:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=8e+tOcY1DxclWB SSH3HWthPL1l0=; b=ITywCAQ9LxJ/T6zWS3TrwVE30RBIFRuLcWayzNrfhCUzKG 1hqMtJhgBu8iaslnZ6uTNkw1tTxHOWLFNM2r6e73cxnKuSP43B06DPReUelr4I55 B/KrG1qgAR+c1zOuykFUR3qrOXDX0Ge7JOepCfZnG2LPtvkxa7VAyBDEiXM9Y= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id E39BE264058; Mon, 4 Aug 2014 12:07:17 -0700 (PDT) Date: Mon, 4 Aug 2014 14:07:17 -0500 From: Nico Williams To: "Adamson, Andy" Message-ID: <20140804190715.GW3579@localhost> References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> <20140804184503.GS3579@localhost> <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/rO5_avc9u-m3I5DC4HZNbxpD6uo Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 19:07:19 -0000 On Mon, Aug 04, 2014 at 06:59:27PM +0000, Adamson, Andy wrote: > On Aug 4, 2014, at 2:45 PM, Nico Williams wrote: > > - v3 (all versions so far) permits the use of any RPCSEC_GSS context > > handle, whether a v1, v2, or v3 handle. > > No, multiple handle versions were left behind once we made v3 a proper > superset of v2 (and v1). Only v3 handles allowed in v3. My idea was that existing code to setup v1 contexts could be left as-is and augmented with code that uses v1 contexts to setup v3 contexts when compound authentication and/or assertions are required. This would help interop: the client sets up v1 contexts, and if it can't setup v3 contexts, then it either gives up (e.g., if it needs protection for the shared-cache case, or if it has critical assertions to make) or continues and hopes for the best (if it has non-critical assertions to make). Nico -- From nobody Mon Aug 4 12:17:06 2014 Return-Path: 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 383411A023F; Mon, 4 Aug 2014 12:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 peC4LKNisPeL; Mon, 4 Aug 2014 12:17:02 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5E7761A0202; Mon, 4 Aug 2014 12:17:02 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 41C3F20047B74; Mon, 4 Aug 2014 12:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=2z8idu2E3FGehT B7v4Xx1sZOfNk=; b=oFwsGeLwnEpyIrgvTZ+12F7CN1CNe35QsEjH2FGNKYCX24 njqfXHj+GLHz4iOoNvkg66A+1PUpDU6LYlAnwuFNSAoHBZkEv9qXymMH18aBE+2C eWezVLkonnaDuRjECE7B/bxQfvtGuOC4kTgblbGXPy9bfQOsgfQkhCqoU/ys4= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPA id CBEA120047B5D; Mon, 4 Aug 2014 12:17:01 -0700 (PDT) Date: Mon, 4 Aug 2014 14:17:01 -0500 From: Nico Williams To: "Adamson, Andy" Message-ID: <20140804191659.GX3579@localhost> References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> <20140804184503.GS3579@localhost> <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1lJk4fVwx4MknC57BcThsPSNf-Q Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 19:17:03 -0000 I should add that one personal motivation for v3 was "disk-less" clients: they should be able to have access to shares they "own" as if they had been local filesystems, but without the ability to make arbitrary assertions about process credentials -user, group IDs, privileges, labels- they couldn't quite get local filesystem access control semantics. I ran into this problem when Least Privilege integrated into Solaris, something like 10 years ago or so. Roughly around the same time that (maybe a year after) I noticed the cache poisoning problem. Without RPCSEC_GSSv3, the best a disk-less client can do w.r.t. shares it "owns" is: - use AUTH_SYS, with all its limitations (no cryptographic security), for conveying subject process identity (user ID/group ID) or - use host credentials ("root") and chown/chgrp new objects, and evaluate ACLs locally Both of those options were just... awful. The ability to securely make arbitrary assertions, using name@domain form for identity assertions, was my solution. This explains the criticality design: the client can just always make these assertions and let the server grant these for the shares owned by the client and not for others. Nico -- From nobody Mon Aug 4 12:46:20 2014 Return-Path: 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 A24321A02F0; Mon, 4 Aug 2014 12:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 CrS2aiPqR7dF; Mon, 4 Aug 2014 12:46:16 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F06EE1A02A2; Mon, 4 Aug 2014 12:46:15 -0700 (PDT) X-AuditID: 1209190e-f79946d000007db1-73-53dfe306896b Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id E5.61.32177.603EFD35; Mon, 4 Aug 2014 15:46:14 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s74JkDrt016496; Mon, 4 Aug 2014 15:46:14 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s74JkAAM028688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2014 15:46:12 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s74JkAL1011528; Mon, 4 Aug 2014 15:46:10 -0400 (EDT) Date: Mon, 4 Aug 2014 15:46:09 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140804180702.GQ3579@localhost> Message-ID: References: <20140801224505.GB3579@localhost> <20140804154746.GE3579@localhost> <20140804180702.GQ3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplleLIzCtJLcpLzFFi42IRYrdT12V7fD/YYNokU4ujm1exWMx+/4jV 4tS1I2wW0xdZObB4vDx1jtFjyZKfTB4zPn1hC2CO4rJJSc3JLEst0rdL4MpY96qTvWAWW8Xd N7fZGhhfsHQxcnJICJhI/N3zjRHCFpO4cG89WxcjF4eQwGwmic9njzFBOBsYJXa+62CBcA4y SbS07GDtYuQAcuol5p+MBelmEdCSaD90iB3EZhNQkZj5ZiMbiC0ioClxfd5SMJtZoEyie1o7 K4gtLOAm0fzqFzOIzSmgJ3Gg7QtYL6+Ao8TGF89ZIXYdZ5L48v8HWLOogI7E6v1TWCCKBCVO znzCAjHUUuLcn+tsExgFZyFJzUKSWsDItIpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXWC83s0Qv NaV0EyMojDkl+XYwfj2odIhRgINRiYdXQO1+sBBrYllxZe4hRkkOJiVRXt0HQCG+pPyUyozE 4oz4otKc1OJDjBIczEoivHGngHK8KYmVValF+TApaQ4WJXHet9ZWwUIC6YklqdmpqQWpRTBZ GQ4OJQle7UdAjYJFqempFWmZOSUIaSYOTpDhPEDDTUBqeIsLEnOLM9Mh8qcYjTmm/D7dxsSx aP/LbiYhlrz8vFQpcV6eh0ClAiClGaV5cNNgqegVozjQc8K8bCADeYBpDG7eK6BVTECrzHTA VpUkIqSkGhjDj4QtE4pwicnW+LfB492Oc0vWTm9PS+kKrOr8nrKHo8zv06ZIucwFLmXbNHad zLq9c9nWwvPdPyY6Oy7iFlLcrBfwoeg6u828wh499/Mb/qSsK93+c+5JVmYfW0WLQ0mfgmM+ b9zPeCBB/EO8wYxO5oI3vJsutqdzXZthMveLq4bhxnVvvc8qsRRnJBpqMRcVJwIAugVBFiAD AAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/GWhfNMIRRmGJizPiaiVk4b6coFw Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 19:46:17 -0000 On Mon, 4 Aug 2014, Nico Williams wrote: > The critical bit is already factored out. We should do the same for the > text. Okay. "Are you volunteering?" > The point is that clients can be expected to have credentials suitable > for this purpose. I think this is quite clearly true. I would like to live in a world where that is true. I don't think we're quite in the state where we can say that this is "quite clearly" true yet, though. (Consider people doing cloud deployments; provisioning a new image with its own credentials is a hassle unless you add your own tooling on top of stock kadmin.) Anyway, I don't think this is a worthwhile topic for us to discuss here, and it doesn't seem very relevant to the actual text of the document in question. -Ben From nobody Mon Aug 4 13:01:25 2014 Return-Path: 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 1FAE01A028A; Mon, 4 Aug 2014 13:01:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 Ss0I-JyUWTaj; Mon, 4 Aug 2014 13:01:22 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20C801A020A; Mon, 4 Aug 2014 13:01:22 -0700 (PDT) X-AuditID: 12074424-f79146d00000067c-27-53dfe690adcc Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.F8.01660.096EFD35; Mon, 4 Aug 2014 16:01:20 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s74K1IFb008173; Mon, 4 Aug 2014 16:01:19 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s74K1GwJ001912 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2014 16:01:18 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s74K1Fdk013901; Mon, 4 Aug 2014 16:01:15 -0400 (EDT) Date: Mon, 4 Aug 2014 16:01:15 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140804180946.GR3579@localhost> Message-ID: References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> <20140804180946.GR3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1280839398-1407182342=:21571" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsUixG6nojvh2f1ggzWHLC2Obl7FYjH7/SNW i1PXjrBZTF9k5cDi8fLUOUaPJUt+MnnM+PSFLYA5issmJTUnsyy1SN8ugSvjwu6VjAVThSqu 7pnK1MDYwN/FyMkhIWAi8eZgCwuELSZx4d56ti5GLg4hgdlMEptOHmSHcDYwSszoWswK4Rxk klhzYC4jSIuQQL3Ej6NLgKo4OFgEtCS6d/qChNkEVCRmvtnIBmKLCGhKXJ+3FMxmFiiT6J7W zgpiCwu4STS/+sUMYnMK6EnsmHyeCcTmFXCUmNjQyAKxaz+TxMpzc8ASogI6Eqv3T2GBKBKU ODnzCQvE0ECJiz+fsUPYjhK3eo6zTWAUmoWkbBaSsllIymYBnc0sYCaxYW82RFhb4v7NNjaY kkfL37EvYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuul5tZopeaUrqJERw9Lio7GJsPKR1i FOBgVOLhFVC7HyzEmlhWXJl7iFGSg0lJlPfeE6AQX1J+SmVGYnFGfFFpTmrxIUYJDmYlEd64 U0A53pTEyqrUonyYlDQHi5I471trq2AhgfTEktTs1NSC1CKYrAwHh5IEr+NToEbBotT01Iq0 zJwShDQTByfIcB6g4dUgNbzFBYm5xZnpEPlTjIpS4rw+IAkBkERGaR5cLyy5vWIUB3pFmLcb pIoHmBjhul8BDWYCGmymAza4JBEhJdXA2LIuI7nw8JdlvxarVP97+uNkZfrH3Zc4TmySuRfK bMl+XthklYZ96/r1x39m61yzenRhcZjUhPo3x47ZtAi6b6haaMHNvyQ90Cunc7sFd+KL5fHn Th+OyjDbKf/1l+GS6287FFbcZeZ/Ld/2x3LdnS85Hc3fVK+EJT9d5P/7kvP32AuGoqUP5iux FGckGmoxFxUnAgAcUGWASQMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-hu8UJVKnYKV4NsviNtw2gUqNNE Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:01:24 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1280839398-1407182342=:21571 Content-Type: TEXT/PLAIN; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: On Mon, 4 Aug 2014, Nico Williams wrote: > On Mon, Aug 04, 2014 at 04:55:57PM +0000, Adamson, Andy wrote: >> On Aug 1, 2014, at 6:15 PM, Nico Williams wrote: >>> (Was "multi-principal" my name for this? No, I called them compound >>> authentication. I prefer "compound=E2=80=9D.) >> >> Hi NIco >> >> I changed the name from =E2=80=98compound=E2=80=99 to multi-principal=E2= =80=99 in response >> the review comments at IETF 89 where many NFSv4 WG members expressed >> that =E2=80=98compound=E2=80=99 had too many meanings (especially in NFS= v4.x) and >> led to confusion. > > "Compound" is used as an adjective in all cases. I don't see how > "compound authentication" (or "compound context handle", ...) is > confusable with "compound RPC". But this isn't important enough to me; > aligning the terminology with AFS' rxgk is. Ben, what does rxgk call > this? If I remember correclty from the talk from Toronto, Andy was not quite so= =20 keen to align with rxgk, but that may have been based on incomplete data. Anyway, for rxgk, we don't talk very much about the actual ~compound=20 token; the operation itself is CombineTokens or AFSCombineTokens, with the= =20 latter being the operation which is analogous to the rpcsec case. The=20 AFSCombineTokens case is a little convoluted, since rxgk-afs=20 differentiates between "vlserver tokens" (roughly analogous to the MDS)=20 and "fileserver tokens" (analogous to the DS). AFSCombineTokens takes=20 vlserver tokens as input and produces fileserver tokens as output, so a=20 lot of the time they are just referred to as "fileserver tokens". There are a couple places where we refer to the CombineTokens output as a= =20 "combined token", which is I think what you're looking for as an answer.=20 That doesn't look like it translates very nicely to the rpcsec case,=20 though. :( -Ben ---559023410-1280839398-1407182342=:21571-- From nobody Mon Aug 4 13:37:09 2014 Return-Path: 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 876761A0301; Mon, 4 Aug 2014 13:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 KeQJkv--dvOB; Mon, 4 Aug 2014 13:37:05 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A289D1A0290; Mon, 4 Aug 2014 13:37:05 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,800,1400050800"; d="scan'208";a="179976740" Received: from vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) by mx12-out.netapp.com with ESMTP; 04 Aug 2014 13:37:06 -0700 Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by vmwexceht03-prd.hq.netapp.com (10.106.76.241) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 13:37:01 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 4 Aug 2014 13:37:01 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Mon, 4 Aug 2014 13:37:01 -0700 From: "Adamson, Andy" To: Nico Williams Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPsA/O768gZXx3NUq3zN1fzegP6pvBPaKAgAAEBoCAAAIugIAAGRWA Date: Mon, 4 Aug 2014 20:37:00 +0000 Message-ID: <2CE95260-F4BE-45EA-A9C1-B0CB603FFC0C@netapp.com> References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> <20140804184503.GS3579@localhost> <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> <20140804190715.GW3579@localhost> In-Reply-To: <20140804190715.GW3579@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <3286BA72DAB9BC488520893D3A3E2423@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/KgynUZjX4CSqoBeA6kxfSR6ywIQ Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:37:07 -0000 On Aug 4, 2014, at 3:07 PM, Nico Williams wrote: > On Mon, Aug 04, 2014 at 06:59:27PM +0000, Adamson, Andy wrote: >> On Aug 4, 2014, at 2:45 PM, Nico Williams wrote: >>> - v3 (all versions so far) permits the use of any RPCSEC_GSS context >>> handle, whether a v1, v2, or v3 handle. >>=20 >> No, multiple handle versions were left behind once we made v3 a proper >> superset of v2 (and v1). Only v3 handles allowed in v3. >=20 > My idea was that existing code to setup v1 contexts could be left as-is > and augmented with code that uses v1 contexts to setup v3 contexts when > compound authentication and/or assertions are required. >=20 > This would help interop: the client sets up v1 contexts, and if it can't > setup v3 contexts, then it either gives up (e.g., if it needs protection > for the shared-cache case, or if it has critical assertions to make) or > continues and hopes for the best (if it has non-critical assertions to > make). It=92s not a big deal to negotiate GSS version at context initiation, my Li= nux prototype tries v3 and falls back to v1 if it fails. Not worrying about which context version is a win, and simplifies v3. The new reply verifier is also a plus. =97>Andy >=20 > Nico > --=20 >=20 > _______________________________________________ > nfsv4 mailing list > nfsv4@ietf.org > https://www.ietf.org/mailman/listinfo/nfsv4 From nobody Mon Aug 4 13:37:59 2014 Return-Path: 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 D88DD1A02F4; Mon, 4 Aug 2014 13:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 Rn53T0CirqWq; Mon, 4 Aug 2014 13:37:51 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3401A0290; Mon, 4 Aug 2014 13:37:50 -0700 (PDT) X-AuditID: 1209190f-f79f86d0000061c8-8a-53dfef1d4e3d Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 26.A2.25032.D1FEFD35; Mon, 4 Aug 2014 16:37:49 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s74KblTq021102; Mon, 4 Aug 2014 16:37:48 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s74Kbjnh015393 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 4 Aug 2014 16:37:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s74KbieF020667; Mon, 4 Aug 2014 16:37:44 -0400 (EDT) Date: Mon, 4 Aug 2014 16:37:44 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140804190715.GW3579@localhost> Message-ID: References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> <20140804184503.GS3579@localhost> <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> <20140804190715.GW3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUixCmqrSv7/n6wwcU9ahZHN69isZj9/hGr xalrR9gspi+ycmDxeHnqHKPHkiU/mTxmfPrCFsAcxWWTkpqTWZZapG+XwJWxe81kpoJPghXv v91kb2Ds4Oti5OSQEDCReH38MCOELSZx4d56ti5GLg4hgdlMEsead7NDOBsYJfbtv8gK4Rxk kpj7bjETSIuQQL3En21bwdpZBLQk1t5rYAex2QRUJGa+2cgGYosIaEpcn7cUzGYWKJPontbO CmILC7hJNL/6xQxicwroSRy4PwOol4ODV8BR4v57C4hd05klDly9yQJSIyqgI7F6/xQwm1dA UOLkzCcsEDMtJf6t/cU6gVFwFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1i5MT8/JSi3RN9HIz S/RSU0o3MYLDWJJ/B+O3g0qHGAU4GJV4eAXU7gcLsSaWFVfmHmKU5GBSEuVNfgEU4kvKT6nM SCzOiC8qzUktPsQowcGsJMIbdwoox5uSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoE k5Xh4FCS4GV6B9QoWJSanlqRlplTgpBm4uAEGc4DNPzTW5DhxQWJucWZ6RD5U4yKUuK8LSAJ AZBERmkeXC8szbxiFAd6RZjXBmQFDzBFwXW/AhrMBDTYTAdscEkiQkqqgZGRTW7dnVXOJ+aU ZW3f4Vnkom2e5d5ZsIppftmZVU48jCuOlEv72m3tFf604KOkxLHjIW2fbjdNetblfTJdwzX5 UeTxbYsXh6XuEnh+/ti7rmz9z5nNGWGfMuw2n4rxKotNc2vUttzgwpl16eaSTo6bK/bLd4R3 6vhsmdSk3CrTsibs85xdHUosxRmJhlrMRcWJADL+XYgOAwAA Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/QK_dFmJVg4LOxpu75v0hdjv5xOI Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:37:57 -0000 On Mon, 4 Aug 2014, Nico Williams wrote: > On Mon, Aug 04, 2014 at 06:59:27PM +0000, Adamson, Andy wrote: >> On Aug 4, 2014, at 2:45 PM, Nico Williams wrote: >>> - v3 (all versions so far) permits the use of any RPCSEC_GSS context >>> handle, whether a v1, v2, or v3 handle. >> >> No, multiple handle versions were left behind once we made v3 a proper >> superset of v2 (and v1). Only v3 handles allowed in v3. > > My idea was that existing code to setup v1 contexts could be left as-is > and augmented with code that uses v1 contexts to setup v3 contexts when > compound authentication and/or assertions are required. > > This would help interop: the client sets up v1 contexts, and if it can't > setup v3 contexts, then it either gives up (e.g., if it needs protection > for the shared-cache case, or if it has critical assertions to make) or > continues and hopes for the best (if it has non-critical assertions to > make). Section 2.2 currently has: The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 3 of a target with version 1 or version 2 of the same target. The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned by version 1 or version 2 of a target with version 3 of the same target. which does not seem to permit this mixed-version worldview. > RPCSEC_GSS_BIND_CHANNEL should be explicitly forbidden on v3 handles, > as v3 has a different mechanism for channel binding. It is listed only > for completeness given that v3 is an extension of the earlier versions. Section 2.6 currently has: The client MUST use one of the following security services to protect the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message: o rpc_gss_svc_channel_prot (see RPCSEC_GSSv2 [4]) o rpc_gss_svc_integrity o rpc_gss_svc_privacy which does not match with the quoted statement above (I think is from Nico; copied from a different mail). Note that though Section 2.6.1.4 permits rpc_gss_svc_channel_prot to be used by a child RPCSEC_GSSv3 handle that was created with channel bindings, but child handles are forbidden from being used for RPCSEC_GSS_CREATE calls by the last item in section 2 (aka section 2.0) -Ben From nobody Mon Aug 4 13:38:17 2014 Return-Path: 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 232BA1A0316; Mon, 4 Aug 2014 13:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 ZCqHSErdUik2; Mon, 4 Aug 2014 13:38:09 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2EBD71A0290; Mon, 4 Aug 2014 13:38:09 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 0E3F62007D812; Mon, 4 Aug 2014 13:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=5MRoCm0jvngjVB pMEuWZiV7we5M=; b=JdOQwPEo+Y4f+6t5byyUgNdzatTSuiftV2IQPsXWfEXR8K d3eVj4FhgkfqGxniSDymmARIYeP+aVcn79bRxQBH+1iGATEp7o4FqDHCyHItHOix DhHy0Q7tP4+jCRSiCEBmkvkmcbyf2MzAvgfPD4DYFDKfavL4ibAMzdBJ8Gvpc= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPA id 9A1902007D802; Mon, 4 Aug 2014 13:38:08 -0700 (PDT) Date: Mon, 4 Aug 2014 15:37:53 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140804203751.GD3579@localhost> References: <20140801224505.GB3579@localhost> <20140804154746.GE3579@localhost> <20140804180702.GQ3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/u1LYaMdsdhOiyNb-I6oNApWFfIc Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:38:10 -0000 On Mon, Aug 04, 2014 at 03:46:09PM -0400, Benjamin Kaduk wrote: > On Mon, 4 Aug 2014, Nico Williams wrote: > >The critical bit is already factored out. We should do the same for > >the text. > > Okay. "Are you volunteering?" I'd like to leave it to Andy for now. > >The point is that clients can be expected to have credentials > >suitable for this purpose. I think this is quite clearly true. > > I would like to live in a world where that is true. I don't think > we're quite in the state where we can say that this is "quite clearly" > true yet, though. (Consider people doing cloud deployments; > provisioning a new image with its own credentials is a hassle unless > you add your own tooling on top of stock kadmin.) Anyway, I don't > think this is a worthwhile topic for us to discuss here, and it > doesn't seem very relevant to the actual text of the document in > question. It really is true. Provisioning is no more or less painful now than it ever was, but since: a) truly multi-user systems generally need server-like provisioning anyways (otherwise they couldn't authenticate users with Kerberos!), b) anon PKINIT is available at rather low cost, my statement is effectively true: it can be made true at low cost anywhere that it already isn't. Nico -- From nobody Mon Aug 4 13:38:46 2014 Return-Path: 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 3AAC71A0290; Mon, 4 Aug 2014 13:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 yzHRkk0GkWrl; Mon, 4 Aug 2014 13:38:43 -0700 (PDT) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D49221A0308; Mon, 4 Aug 2014 13:38:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,800,1400050800"; d="scan'208";a="179977077" Received: from vmwexceht06-prd.hq.netapp.com ([10.106.77.104]) by mx12-out.netapp.com with ESMTP; 04 Aug 2014 13:38:41 -0700 Received: from HIOEXCMBX08-PRD.hq.netapp.com (10.122.105.41) by vmwexceht06-prd.hq.netapp.com (10.106.77.104) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 13:38:37 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 4 Aug 2014 13:38:36 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Mon, 4 Aug 2014 13:38:36 -0700 From: "Adamson, Andy" To: Benjamin Kaduk Thread-Topic: [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPrAU48wbIQBIMg0W+Un2kpIHDeZu7PYKAgAB5yoCAAPRMgIAAHfIAgARdswCAABSegIAAHySAgAAKcgA= Date: Mon, 4 Aug 2014 20:38:36 +0000 Message-ID: <79B24BBE-50EA-4006-8D8D-14B95E0CCB97@netapp.com> References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> <20140804180946.GR3579@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/p_khdwcmBIxBm5p027MxciZjUKc Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:38:44 -0000 On Aug 4, 2014, at 4:01 PM, Benjamin Kaduk wrote: > On Mon, 4 Aug 2014, Nico Williams wrote: >=20 >> On Mon, Aug 04, 2014 at 04:55:57PM +0000, Adamson, Andy wrote: >>> On Aug 1, 2014, at 6:15 PM, Nico Williams wrote= : >>>> (Was "multi-principal" my name for this? No, I called them compound >>>> authentication. I prefer "compound=94.) >>>=20 >>> Hi NIco >>>=20 >>> I changed the name from =91compound=92 to multi-principal=92 in respons= e >>> the review comments at IETF 89 where many NFSv4 WG members expressed >>> that =91compound=92 had too many meanings (especially in NFSv4.x) and >>> led to confusion. >>=20 >> "Compound" is used as an adjective in all cases. I don't see how >> "compound authentication" (or "compound context handle", ...) is >> confusable with "compound RPC". But this isn't important enough to me; >> aligning the terminology with AFS' rxgk is. Ben, what does rxgk call >> this? >=20 > If I remember correclty from the talk from Toronto, Andy was not quite so= keen to align with rxgk, but that may have been based on incomplete data. Well, I looked at the AFS =91combined=92 tokes, and thought they were close= , but not close enough to re-use the name. =97>Andy >=20 > Anyway, for rxgk, we don't talk very much about the actual ~compound toke= n; the operation itself is CombineTokens or AFSCombineTokens, with the latt= er being the operation which is analogous to the rpcsec case. The AFSCombi= neTokens case is a little convoluted, since rxgk-afs differentiates between= "vlserver tokens" (roughly analogous to the MDS) and "fileserver tokens" (= analogous to the DS). AFSCombineTokens takes vlserver tokens as input and = produces fileserver tokens as output, so a lot of the time they are just re= ferred to as "fileserver tokens". >=20 > There are a couple places where we refer to the CombineTokens output as a= "combined token", which is I think what you're looking for as an answer. T= hat doesn't look like it translates very nicely to the rpcsec case, though.= :( >=20 > -Ben From nobody Mon Aug 4 13:40:19 2014 Return-Path: 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 D9FE51A0308; Mon, 4 Aug 2014 13:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 4D3AuoqAAP-9; Mon, 4 Aug 2014 13:40:18 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 09E2B1A02F4; Mon, 4 Aug 2014 13:40:18 -0700 (PDT) Received: from homiemail-a26.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTP id DF6A1B805B; Mon, 4 Aug 2014 13:40:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=b5sST64KSHXWOC KWc04K5MjFnYA=; b=e/gRjiZRnJ5zlob7ekxcn6wXUEaDZwcWbdjV0WK+vI0+f7 lyPNQjsKJsDlP2DKOIKUkc8xJF029p/mdqXWV27NUXOHWoh2a9K46+MInHd5HFYM V3KOrxTRF2mku7piBO0mR6pv/eqhxEW2Kobr1Z08iabedz5wNs8tlVS1IXMqU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a26.g.dreamhost.com (Postfix) with ESMTPA id 763E9B805C; Mon, 4 Aug 2014 13:40:17 -0700 (PDT) Date: Mon, 4 Aug 2014 15:40:17 -0500 From: Nico Williams To: Benjamin Kaduk Message-ID: <20140804204007.GE3579@localhost> References: <20140801055401.GA7409@localhost> <8FD0C272-6FD3-44FE-BD3D-BAB220E0FF13@netapp.com> <20140801221535.GA3579@localhost> <20140804180946.GR3579@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/RYPDwIU-2-jMWWq1uobtwPYd300 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:40:19 -0000 On Mon, Aug 04, 2014 at 04:01:15PM -0400, Benjamin Kaduk wrote: > On Mon, 4 Aug 2014, Nico Williams wrote: > >"Compound" is used as an adjective in all cases. I don't see how > >"compound authentication" (or "compound context handle", ...) is > >confusable with "compound RPC". But this isn't important enough to me; > >aligning the terminology with AFS' rxgk is. Ben, what does rxgk call > >this? > > If I remember correclty from the talk from Toronto, Andy was not > quite so keen to align with rxgk, but that may have been based on > incomplete data. Well, it'd be nice to have that, but it isn't required. rxgk's use of "combine" is very specific to what it does, which is very different from what RPCSEC_GSSv3 does in specifics though effectively the same, so perhaps alignment with rxgk as to terminology would not be usefule anyways. From nobody Mon Aug 4 13:41:56 2014 Return-Path: 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 3C1E91A0313; Mon, 4 Aug 2014 13:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 uhga9xj9msCM; Mon, 4 Aug 2014 13:41:51 -0700 (PDT) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDF81A02F4; Mon, 4 Aug 2014 13:41:51 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.01,800,1400050800"; d="scan'208";a="337422793" Received: from vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) by mx1-out.netapp.com with ESMTP; 04 Aug 2014 13:41:52 -0700 Received: from HIOEXCMBX02-PRD.hq.netapp.com (10.122.105.35) by vmwexceht01-prd.hq.netapp.com (10.106.76.239) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 4 Aug 2014 13:41:48 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com (10.122.105.36) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.913.22; Mon, 4 Aug 2014 13:41:47 -0700 Received: from HIOEXCMBX03-PRD.hq.netapp.com ([::1]) by hioexcmbx03-prd.hq.netapp.com ([fe80::6112:44a3:1946:292f%21]) with mapi id 15.00.0913.011; Mon, 4 Aug 2014 13:41:47 -0700 From: "Adamson, Andy" To: Benjamin Kaduk Thread-Topic: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review Thread-Index: AQHPsCP82UXQ/XAWfUqGp9getM05yZvBXhWA Date: Mon, 4 Aug 2014 20:41:46 +0000 Message-ID: References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> <20140804184503.GS3579@localhost> <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> <20140804190715.GW3579@localhost> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1874) x-originating-ip: [10.122.56.79] Content-Type: text/plain; charset="Windows-1252" Content-ID: <35638B53FB7D7246BAB0CAE7CA078011@hq.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/PHekydm9W-UsaZtQ61XbUKeg1w4 Cc: "kitten@ietf.org" , "Adamson, Andy" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:41:53 -0000 On Aug 4, 2014, at 4:37 PM, Benjamin Kaduk wrote: > On Mon, 4 Aug 2014, Nico Williams wrote: >=20 >> On Mon, Aug 04, 2014 at 06:59:27PM +0000, Adamson, Andy wrote: >>> On Aug 4, 2014, at 2:45 PM, Nico Williams wrote= : >>>> - v3 (all versions so far) permits the use of any RPCSEC_GSS context >>>> handle, whether a v1, v2, or v3 handle. >>>=20 >>> No, multiple handle versions were left behind once we made v3 a proper >>> superset of v2 (and v1). Only v3 handles allowed in v3. >>=20 >> My idea was that existing code to setup v1 contexts could be left as-is >> and augmented with code that uses v1 contexts to setup v3 contexts when >> compound authentication and/or assertions are required. >>=20 >> This would help interop: the client sets up v1 contexts, and if it can't >> setup v3 contexts, then it either gives up (e.g., if it needs protection >> for the shared-cache case, or if it has critical assertions to make) or >> continues and hopes for the best (if it has non-critical assertions to >> make). >=20 > Section 2.2 currently has: > The initiator MUST NOT attempt to use an RPCSEC_GSS handle returned > by version 3 of a target with version 1 or version 2 of the same > target. The initiator MUST NOT attempt to use an RPCSEC_GSS handle > returned by version 1 or version 2 of a target with version 3 of the > same target. >=20 > which does not seem to permit this mixed-version worldview. >=20 >=20 >> RPCSEC_GSS_BIND_CHANNEL should be explicitly forbidden on v3 handles, >> as v3 has a different mechanism for channel binding. It is listed only >> for completeness given that v3 is an extension of the earlier versions. >=20 > Section 2.6 currently has: > The client MUST use one of the following security services to protect > the RPCSEC_GSS_CREATE or RPCSEC_GSS_LIST control message: >=20 > o rpc_gss_svc_channel_prot (see RPCSEC_GSSv2 [4]) Yeah - thanks for the review - f rpc_gss_svc_channel_prot should also not b= e used. I can clean this up. =97>Andy >=20 > o rpc_gss_svc_integrity >=20 > o rpc_gss_svc_privacy >=20 > which does not match with the quoted statement above (I think is from Nic= o; copied from a different mail). >=20 > Note that though Section 2.6.1.4 permits rpc_gss_svc_channel_prot to be u= sed by a child RPCSEC_GSSv3 handle that was created with channel bindings, = but child handles are forbidden from being used for RPCSEC_GSS_CREATE calls= by the last item in section 2 (aka section 2.0) >=20 > -Ben >=20 > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Mon Aug 4 13:42:01 2014 Return-Path: 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 2767C1A0324; Mon, 4 Aug 2014 13:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.233 X-Spam-Level: X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 wn96ri6ejjyt; Mon, 4 Aug 2014 13:41:57 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDD91A0317; Mon, 4 Aug 2014 13:41:57 -0700 (PDT) Received: from homiemail-a28.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTP id 2A3911B4058; Mon, 4 Aug 2014 13:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=RoMfN+GTuNrsQwx0hpqmKMYV9Lo=; b=XlcHy7ELDdA V37t0uvuxcUieflr7Yv3roJmmCPCIbotP1sxDbORMb8uSRivoZieCyU8UkvlncOV Fz7duJ2spQJ0pdrTDe0WAPKXQ2cyYgEaJQdGN9aCeagzv9Y4rBy/hb/RXr6ZzBep tEhHe2nV0J4jCIxISAYlWCJnyW9mlkWU= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a28.g.dreamhost.com (Postfix) with ESMTPA id A957B1B4057; Mon, 4 Aug 2014 13:41:56 -0700 (PDT) Date: Mon, 4 Aug 2014 15:41:56 -0500 From: Nico Williams To: "Adamson, Andy" Message-ID: <20140804204154.GF3579@localhost> References: <20140801224505.GB3579@localhost> <20140804164406.GK3579@localhost> <20140804184503.GS3579@localhost> <1C1E7672-8E50-482D-A5B3-8C4E56458BA9@netapp.com> <20140804190715.GW3579@localhost> <2CE95260-F4BE-45EA-A9C1-B0CB603FFC0C@netapp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2CE95260-F4BE-45EA-A9C1-B0CB603FFC0C@netapp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/VjlaqFkrNGI-D1iMACdYdyH-HQY Cc: "kitten@ietf.org" , NFSv4 Subject: Re: [kitten] [nfsv4] draft-ietf-nfsv4-rpcsec-gssv3: request for review X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 20:41:58 -0000 On Mon, Aug 04, 2014 at 08:37:00PM +0000, Adamson, Andy wrote: > It=E2=80=99s not a big deal to negotiate GSS version at context initiat= ion, > my Linux prototype tries v3 and falls back to v1 if it fails. Not > worrying about which context version is a win, and simplifies v3. The > new reply verifier is also a plus. OK, fair enough. From nobody Thu Aug 7 13:25:57 2014 Return-Path: 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 A85E41B28D0 for ; Thu, 7 Aug 2014 13:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.2 X-Spam-Level: * X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 Dg1LcpDqxx17 for ; Thu, 7 Aug 2014 13:25:53 -0700 (PDT) Received: from nm10-vm0.bullet.mail.bf1.yahoo.com (nm10-vm0.bullet.mail.bf1.yahoo.com [98.139.213.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFF21B28B3 for ; Thu, 7 Aug 2014 13:25:53 -0700 (PDT) Received: from [98.139.215.142] by nm10.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2014 20:25:52 -0000 Received: from [98.139.212.204] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 07 Aug 2014 20:25:52 -0000 Received: from [127.0.0.1] by omp1013.mail.bf1.yahoo.com with NNFMP; 07 Aug 2014 20:25:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 265282.22381.bm@omp1013.mail.bf1.yahoo.com Received: (qmail 56329 invoked by uid 60001); 7 Aug 2014 20:25:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1407443152; bh=3KHvMEnDbI2zfCL1g0GVU/nxsFQXmVC5rQGwXQIeJ88=; h=Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=MeT/Bx5mZWUsYaGnb1GX6YxrY0HxexIq7y9salZ0Ik1GfStBWuxlXeAgbCB6VZSS0Z+zEkjLcAxxOhS2Gvsy6VvxoKp+AxvuZ2AKpttdMuI2o/eNCYQeNno02XWlpHXa/NMVrEijSn2yNo+BxLRB6v4FnvJflAq28O9e3mUQ5t4= X-YMail-OSG: JdMiKUQVM1lBpCzgNSoGODxHZwkxMM8J_g3N_A58mEl.3an Ws_Cgl6UIJDjN0j1diKxZqmGy_aTgkaC9LYZy.FHdWU1NRjlCHd7x6Y5hS9K 8OWT1qM3TKxQDBid3dvFD5vXBsNeBMgjBOQ9S.ASC8HM_Sxgz7rIVGJuNDaw NVSDLFrXUvcICJ2tMY89GX0Fhglw4WtaHNNc2Xn9iXtykzpdFzhd94xC_QHh FsDHtOovX9fkF0oZRpeL8XcX75.f.AzWaJ1q8UYub3ipRh3WQiQL1wx1925k 4Bu8ElqDK7S4pDR.taYdjv.cM7d6GMdYxzKxQPZnwaP5bGuO0M.pAyBGCVGd rF5CNFAH.WzvL2X05ENE9sNVH62uBrijrOp.5wQhYyCnYMAm6VabsCYn6NwO LraO67jaOLR8vA74WQY.2QVn3azd9lQnWzPM.M1.n1kjI4BrsQItKcz0_e15 5XSpKj1u1OE5LkAWB9llfNqt6vYAPg9Yt2JelNtgHW79lHUVqNFU3UrGmu0u ffSLEEVf2Rf2GShseK2lXVt5XUB8HJjM6t.VPME67QeGQ7u3TlLsx2NQ- Received: from [167.220.24.195] by web142802.mail.bf1.yahoo.com via HTTP; Thu, 07 Aug 2014 13:25:52 PDT X-Rocket-MIMEInfo: 002.001, VGhlIE9BdXRoIFNBU0wgZHJhZnQgd2FzIGluIFdHTEMsIGJ1dCB3ZSBtYWRlIHNpZ25pZmljYW50IGNoYW5nZXMuIMKgV2UndmUgaGFkIG9uZSBicmllZiByZXZpZXcgb2YgaXQgc2luY2UgLTE1LCB0aGF0IGRvZXNuJ3Qgc2VlbSBsaWtlIGVub3VnaCB0byBzYXkgaXQgbWlnaHQgYmUgY2xvc2UgdG8gV0dMQyBlbGlnaWJsZSBhZ2Fpbi4gwqBJJ2QgZXNwZWNpYWxseSBsaWtlIGl0IGlmIG9uZSBvciBtb3JlIG9mIHRoZSBmb2xrcyBhdCBHb29nbGUgY291bGQgdGFrZSBhIGxvb2sgYXMgdGhleSdyZSB0aGUgbWEBMAEBAQE- X-Mailer: YahooMailWebService/0.8.200.695 Message-ID: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> Date: Thu, 7 Aug 2014 13:25:52 -0700 From: Bill Mills To: "kitten@ietf.org" , Ryan Troll MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1397251415-1089322076-1407443152=:85652" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/pne9d8Usa9tVN-8YQAFdpnoxrN0 Subject: [kitten] next steps on oauth sasl draft? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 20:25:54 -0000 --1397251415-1089322076-1407443152=:85652 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable The OAuth SASL draft was in WGLC, but we made significant changes. =A0We've= had one brief review of it since -15, that doesn't seem like enough to say= it might be close to WGLC eligible again. =A0I'd especially like it if one= or more of the folks at Google could take a look as they're the major impl= ementor so far.=0A=0AHoping to wrap this up.=0A=0AThanks,=0A=0A-bill --1397251415-1089322076-1407443152=:85652 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
The OAuth SASL draft was in WGLC, but we made significan= t changes.  We've had one brief review of it since -15, that doesn't s= eem like enough to say it might be close to WGLC eligible again.  I'd = especially like it if one or more of the folks at Google could take a look = as they're the major implementor so far.

Hoping to wrap this up.

Thanks,

-bill
--1397251415-1089322076-1407443152=:85652-- From nobody Fri Aug 8 00:02:17 2014 Return-Path: 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 B22421A03AC for ; Fri, 8 Aug 2014 00:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 SOI-TDUA5aNA for ; Fri, 8 Aug 2014 00:02:13 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4157C1A036B for ; Fri, 8 Aug 2014 00:02:13 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7872BRZ005599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 8 Aug 2014 07:02:12 GMT Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7872BGg017328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 8 Aug 2014 07:02:11 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7872BFk017319 for ; Fri, 8 Aug 2014 07:02:11 GMT Received: from [10.154.154.235] (/10.154.154.235) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Aug 2014 00:02:10 -0700 Message-ID: <53E47603.3080302@oracle.com> Date: Fri, 08 Aug 2014 01:02:27 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20140508 Thunderbird/17.0.11 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> <53D18F6F.1060204@att.com> In-Reply-To: <53D18F6F.1060204@att.com> Content-Type: multipart/alternative; boundary="------------030406010409060805010009" X-Source-IP: acsinet22.oracle.com [141.146.126.238] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/a76KZYwgTX7exx9EId0dfKumrH8 Subject: Re: [kitten] Fwd: I-D Action: draft-hansen-scram-sha256-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 07:02:16 -0000 This is a multi-part message in MIME format. --------------030406010409060805010009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/24/14 4:57 PM, Tony Hansen wrote: > I just posted this update to the document I circulated back in April, > registering SCRAM-SHA-256 as a SASL mechanism. > > I added Minimum iteration-count and OID to the registration form for > SCRAM-* registrations. > > I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. This > should probably be discussed further. I know RFC 3962 calls for 4096 rounds for SHA-1. I haven't heard of anything that would make us want to change this. Are there specific use-cases for this mechanism that would be negatively affected when choosing a higher iteration or is there guidance on policies when using this number of iterations or lower? > One question I have for this: would it be worth change SCRAM > registrations to Expert Review in place of IETF review? Do you envision a number of future mechanisms under the SCRAM* family? If not then I would prefer leaving it as IETF review. > There was discussion in the HTTPAUTH working group this morning, > asking about the use of SHA2 as an HTTP mechanism instead of the SHA1 > being discussed in Alexey's draft. > > An open question is whether this could/should become a working group > draft. I am happy with it being handled either that way or keeping it > an individual AD-sponsored draft. (I've already spoken with Steven and > Kathleen about that possibility.) Speaking as co-chair; it has been a strain on the WG's resources with getting through the previous and current set of SASL work items. So my initial position on this would be to have this draft AD-sponsored. Shawn. -- > -------- Original Message -------- > Subject: I-D Action: draft-hansen-scram-sha256-01.txt > Date: Thu, 24 Jul 2014 15:49:56 -0700 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms > Author : Tony Hansen > Filename : draft-hansen-scram-sha256-01.txt > Pages : 5 > Date : 2014-07-24 > > Abstract: > This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- > SHA-256-PLUS. It also updates RFC 5802 in minor ways. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-hansen-scram-sha256-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------030406010409060805010009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 7/24/14 4:57 PM, Tony Hansen wrote:
I just posted this update to the document I circulated back in April, registering SCRAM-SHA-256 as a SASL mechanism.

I added Minimum iteration-count and OID to the registration form for SCRAM-* registrations.

I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. This should probably be discussed further.

I know RFC 3962 calls for 4096 rounds for SHA-1.  I haven't heard of anything that would make us want to change this.  Are there specific use-cases for this mechanism that would be negatively affected when choosing a higher iteration or is there guidance on policies when using this number of iterations or lower?

One question I have for this: would it be worth change SCRAM registrations to Expert Review in place of IETF review?

Do you envision a number of future mechanisms under the SCRAM* family?  If not then I would prefer leaving it as IETF review.

There was discussion in the HTTPAUTH working group this morning, asking about the use of SHA2 as an HTTP mechanism instead of the SHA1 being discussed in Alexey's draft.

An open question is whether this could/should become a working group draft. I am happy with it being handled either that way or keeping it an individual AD-sponsored draft. (I've already spoken with Steven and Kathleen about that possibility.)

Speaking as co-chair; it has been a strain on the WG's resources with getting through the previous and current set of SASL work items.  So my initial position on this would be to have this draft AD-sponsored.

Shawn.
--
-------- Original Message --------
Subject: I-D Action: draft-hansen-scram-sha256-01.txt
Date: Thu, 24 Jul 2014 15:49:56 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms
        Author          : Tony Hansen
	Filename        : draft-hansen-scram-sha256-01.txt
	Pages           : 5
	Date            : 2014-07-24

Abstract:
   This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
   SHA-256-PLUS.  It also updates RFC 5802 in minor ways.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hansen-scram-sha256-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/




_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

--------------030406010409060805010009-- From nobody Fri Aug 8 13:22:00 2014 Return-Path: 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 631B91A02A2 for ; Fri, 8 Aug 2014 13:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 RjRLtKKGr6fx for ; Fri, 8 Aug 2014 13:21:56 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA7C1A0109 for ; Fri, 8 Aug 2014 13:21:56 -0700 (PDT) X-AuditID: 12074422-f79be6d000007518-85-53e531633761 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id A7.B0.29976.36135E35; Fri, 8 Aug 2014 16:21:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s78KLtFx009894 for ; Fri, 8 Aug 2014 16:21:55 -0400 Received: from localhost (equal-rites.mit.edu [18.18.1.59]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s78KLsHS018392 for ; Fri, 8 Aug 2014 16:21:54 -0400 From: Greg Hudson To: kitten@ietf.org Date: Fri, 08 Aug 2014 16:17:48 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUixCmqrZts+DTY4G+vgcXRzatYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8W3LI7aChUIV8/b0MzUw3uTrYuTkkBAwkZh34BU7hC0mceHe erYuRi4OIYHZTBLP1zQwQjjHGCVOr1vOCuG0M0nsP7UErIVNQFni4NlvLCC2iICwxO6t75hB bGEBY4mL988xgtgsAqoSh+7/ZQKxeQUMJT5teMoOYQtKnJz5BKyXWUBL4sa/l0wTGHlmIUnN QpJawMi0ilE2JbdKNzcxM6c4NVm3ODkxLy+1SNdULzezRC81pXQTIyg82F2UdjD+PKh0iFGA g1GJh1eg+3GwEGtiWXFl7iFGSQ4mJVFeb72nwUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeJ88 ehIsxJuSWFmVWpQPk5LmYFES531rbRUsJJCeWJKanZpakFoEk5Xh4FCS4PU3ABoqWJSanlqR lplTgpBm4uAEGc4DNNwKpIa3uCAxtzgzHSJ/ilFRSpxXVh8oIQCSyCjNg+uFxe8rRnGgV4R5 Y0HaeYCxD9f9CmgwE9BgWdXHIINLEhFSUg2MSeuVXgpYHFQOSbrGzH9j6vK54oaunxfH/HT4 8vPCpu7jT2Yax4q1KDb/edu0NnO+H+PjLfd/HojXP7Jg4Y423qV8ixk6/rW/+zj1csrG+RNP zJ52d1Yhx7QJWQbb/GPt06+HK/n9uc3yUaU5LCm/68eHGZ/y6w8e2Vl4N2HZCtbpj27IpJUm 31BiKc5INNRiLipOBACP14nuugIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/323vy7IKba-oNn71rdd-a-6DAvQ Subject: [kitten] CAMMAC and ticket server principal binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 20:21:58 -0000 In the current CAMMAC draft, the KDC verifier binds the CAMMAC contents to all the EncTicketPart fields, which includes the ticket client principal, all of the timestamps, and the ticket session key, but not the ticket server principal. Sam pointed this out in http://www.ietf.org/mail-archive/web/kitten/current/msg04774.html but I wanted a thread to discuss the issue specifically. With the current binding, a KDC cannot assume that the contents of a CAMMAC originated from a KDC in a ticket issued for the claimed service. The scope for potential tampering is narrow but extant. Imagine that I know the keys for two different services svc1 and svc2. I receive a ticket for svc1. I can extract the CAMMAC from that ticket, then print up a ticket for svc2 containing a CAMMAC with the same contents. If the new ticket uses the same session key, timestamps, and client principal, then the kdc-verifier in the CAMMAC will appear valid to the KDC, even though it originated in a ticket issued to svc1. (The svc-verifier would appear invalid if I simply copied it, but I can construct a valid svc-verifier using my knowledge of svc2's key.) As Sam noted, we have two options: we can add a ticket server binding, or we can document that there isn't one. Most of the people I have talked to are in favor of documenting, for these reasons: * All of the ways we could bind the ticket server add some additional complexity to the specification and to implementations. * The types we have so far proposed to put inside CAMMAC only make statements about the client or the means of client authorization, not the relationship between the client and a specific service. * The purpose of the kdc-verifier is to allow CAMMAC contents to be propagated to a ticket for a different service. If the CAMMAC contains a hypothetical authdata type which talks about the relationship between the client and the old service, it would need to discarded or recomputed for the new service. * A hypothetical authdata type which talks about the client-server relationship should probably bind to the service principal (perhaps just by naming it) independently of CAMMAC, in case a KDC ignorantly propagates it to a ticket for a different service. Do other people have conflicting opinions? From nobody Fri Aug 8 14:15:14 2014 Return-Path: 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 D099A1ABD18 for ; Fri, 8 Aug 2014 14:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.079 X-Spam-Level: X-Spam-Status: No, score=-1.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 X0_CbHYjdcqG for ; Fri, 8 Aug 2014 14:15:09 -0700 (PDT) Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410201A0450 for ; Fri, 8 Aug 2014 14:15:09 -0700 (PDT) Received: by mail-ig0-f173.google.com with SMTP id h18so1684508igc.0 for ; Fri, 08 Aug 2014 14:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=VGRaeSl+q6Mc/BiEbFQs/0wjH9cpe0eX92ztpJchfRQ=; b=SQZ9JlqTdbDI8kq288f0jIE8OVY7FSPTkjZZ3TshZPTju8+U5Q4qaBEU63tK8TlqUY r8ZocEUa70oLBWUh72gcXW8uGJEdhQREGs+641gSnz94IjcGVfSLFQvtGA/FTEATjQc7 VW85BklEg6CrsljuVn4LDpXu7Rzgo7qmDL0KYEQzO0SfYdYKRUxEOC0bW1L78/TR8G2G GAhQzJ2CrruzH+XrD/hcO4zq+D9ibkMGjJFW4yXbwILg1HaO77RiNoJf4qQOg/hcycu5 O26G91V07poTkaYIdGhXTgrdgdvpRdD+Qquyk0eNhT2fCrGf5o/y+LP1UA3dSLBuEwQh rSIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VGRaeSl+q6Mc/BiEbFQs/0wjH9cpe0eX92ztpJchfRQ=; b=NWpvLRqNRh+/JF4ViYFDbZ46kjAEIHgZhUfEpwg8eRz9lvCm8p+30fHo7bHneNaqXX LERZghS5GmPw4o0zq2HrNSzHO59i8jEZS2tTKwWtg+idG6qzpL4NOuwJutHw79i5oFax nlPCHsa1L/Q2RhBO0G3LVM8LgAd8VUNTLRmO8qYW112ibl5Vm7I3/MSwOdfZ2SvAQOUV yDHssJRaJFAg+HGv2qu2/aXI9HG5NBbotFMpP5ZE58BIzkIa96TaNcJI0QZqQyjOTYNJ bRR8tUHM0vldi6WQ5PytHDPnOSPx16tHBG0m+gtK46ae7FWtCowKPSqDE4aouCgUDNhF rl3A== X-Gm-Message-State: ALoCoQl5ZkhgplUOOVqdA7WRqnBPMAeawI0EZ5LfW0BCPmNQhqRQcIHUFqJze7mVPEeUbZxQ6Gfz X-Received: by 10.51.17.2 with SMTP id ga2mr8958139igd.12.1407532508476; Fri, 08 Aug 2014 14:15:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.62.78 with HTTP; Fri, 8 Aug 2014 14:14:38 -0700 (PDT) In-Reply-To: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> References: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> From: =?UTF-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= Date: Fri, 8 Aug 2014 14:14:38 -0700 Message-ID: To: Bill Mills Content-Type: multipart/alternative; boundary=001a113491e42d9a8d050024b386 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/aKkItPSD5f_ljQ8u8c_RDwK_zes Cc: "kitten@ietf.org" Subject: Re: [kitten] next steps on oauth sasl draft? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:15:12 -0000 --001a113491e42d9a8d050024b386 Content-Type: text/plain; charset=UTF-8 We've reviewed it at Google and we think we can implement it. We'll require the authzid to be specified in the gs2 header. On Thu, Aug 7, 2014 at 1:25 PM, Bill Mills wrote: > The OAuth SASL draft was in WGLC, but we made significant changes. We've > had one brief review of it since -15, that doesn't seem like enough to say > it might be close to WGLC eligible again. I'd especially like it if one or > more of the folks at Google could take a look as they're the major > implementor so far. > > Hoping to wrap this up. > > Thanks, > > -bill > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > --001a113491e42d9a8d050024b386 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We've reviewed it at Google and we think we can implem= ent it. We'll require the authzid to be specified in the gs2 header.


On Thu, Au= g 7, 2014 at 1:25 PM, Bill Mills <wmills_92105@yahoo.com> wrote:
The OAuth SASL draft was in WGLC, but we made significant changes. =C2= =A0We've had one brief review of it since -15, that doesn't seem li= ke enough to say it might be close to WGLC eligible again. =C2=A0I'd es= pecially like it if one or more of the folks at Google could take a look as= they're the major implementor so far.


Thanks,

-bill

_______________________________________________<= br> Kitten mailing list
Kitten@ietf.org
= https://www.ietf.org/mailman/listinfo/kitten


--001a113491e42d9a8d050024b386-- From nobody Fri Aug 8 19:54:26 2014 Return-Path: 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 E41E41A03BE for ; Fri, 8 Aug 2014 19:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 YbA5N6cLBVoQ for ; Fri, 8 Aug 2014 19:54:23 -0700 (PDT) Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 615E31A03A4 for ; Fri, 8 Aug 2014 19:54:23 -0700 (PDT) Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5 TLS/8.14.5) with ESMTP id s792sLuM016916 for ; Fri, 8 Aug 2014 19:54:22 -0700 Received: from vpn-135-70-102-22.vpn.swst.att.com ([135.70.102.22]) by maillennium.att.com (mailgw1) with ESMTP id <20140809025418gw100j0cqje>; Sat, 9 Aug 2014 02:54:19 +0000 X-Originating-IP: [135.70.102.22] Message-ID: <53E58D77.1020100@att.com> Date: Fri, 08 Aug 2014 22:54:47 -0400 From: Tony Hansen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "kitten@ietf.org" References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> <53D18F6F.1060204@att.com> <53E47603.3080302@oracle.com> In-Reply-To: <53E47603.3080302@oracle.com> Content-Type: multipart/alternative; boundary="------------010603080406040407040907" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/lyGVjQwG_0VtmgiaYh8s4p7arik Subject: Re: [kitten] Fwd: I-D Action: draft-hansen-scram-sha256-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 02:54:26 -0000 This is a multi-part message in MIME format. --------------010603080406040407040907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thank you Shawn. On 8/8/14, 3:02 AM, Shawn M Emery wrote: > On 7/24/14 4:57 PM, Tony Hansen wrote: >> I just posted this update to the document I circulated back in April, >> registering SCRAM-SHA-256 as a SASL mechanism. >> >> I added Minimum iteration-count and OID to the registration form for >> SCRAM-* registrations. >> >> I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. >> This should probably be discussed further. > > I know RFC 3962 calls for 4096 rounds for SHA-1. I haven't heard of > anything that would make us want to change this. Are there specific > use-cases for this mechanism that would be negatively affected when > choosing a higher iteration or is there guidance on policies when > using this number of iterations or lower? I am not aware of any guidance on how to choose an appropriate number of iterations. I do know that we found 4096 iterations to be significant on a handheld device, and I would *prefer* not raising it any higher. (We would not be willing to change our existing implementation of scram-sha-256 to a higher number unless there was a >>really good reason<<.) >> One question I have for this: would it be worth change SCRAM >> registrations to Expert Review in place of IETF review? > > Do you envision a number of future mechanisms under the SCRAM* > family? If not then I would prefer leaving it as IETF review. I could envision a SHA3-based registration in the future, but I wouldn't guarantee it. I'm personally of the opinion that registrations WITHIN a family should be lighter weight than registrations of mechanism families. But I'm happy to go with WG consensus on the question. >> There was discussion in the HTTPAUTH working group this morning, >> asking about the use of SHA2 as an HTTP mechanism instead of the SHA1 >> being discussed in Alexey's draft. >> >> An open question is whether this could/should become a working group >> draft. I am happy with it being handled either that way or keeping it >> an individual AD-sponsored draft. (I've already spoken with Steven >> and Kathleen about that possibility.) > > Speaking as co-chair; it has been a strain on the WG's resources with > getting through the previous and current set of SASL work items. So > my initial position on this would be to have this draft AD-sponsored. As I said, I'm happy keeping it AD-sponsored. I would continue to keep the reviews within kitten. I'll pursue that further then. Tony > Shawn. > -- >> -------- Original Message -------- >> Subject: I-D Action: draft-hansen-scram-sha256-01.txt >> Date: Thu, 24 Jul 2014 15:49:56 -0700 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms >> Author : Tony Hansen >> Filename : draft-hansen-scram-sha256-01.txt >> Pages : 5 >> Date : 2014-07-24 >> >> Abstract: >> This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM- >> SHA-256-PLUS. It also updates RFC 5802 in minor ways. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-hansen-scram-sha256-01 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-01 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> >> _______________________________________________ >> Kitten mailing list >> Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten --------------010603080406040407040907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thank you Shawn.

On 8/8/14, 3:02 AM, Shawn M Emery wrote:
On 7/24/14 4:57 PM, Tony Hansen wrote:
I just posted this update to the document I circulated back in April, registering SCRAM-SHA-256 as a SASL mechanism.

I added Minimum iteration-count and OID to the registration form for SCRAM-* registrations.

I kept the minimum iteration count for SCRAM-SHA-256 set at 4096. This should probably be discussed further.

I know RFC 3962 calls for 4096 rounds for SHA-1.  I haven't heard of anything that would make us want to change this.  Are there specific use-cases for this mechanism that would be negatively affected when choosing a higher iteration or is there guidance on policies when using this number of iterations or lower?

I am not aware of any guidance on how to choose an appropriate number of iterations.

I do know that we found 4096 iterations to be significant on a handheld device, and I would *prefer* not raising it any higher. (We would not be willing to change our existing implementation of scram-sha-256 to a higher number unless there was a >>really good reason<<.)

One question I have for this: would it be worth change SCRAM registrations to Expert Review in place of IETF review?

Do you envision a number of future mechanisms under the SCRAM* family?  If not then I would prefer leaving it as IETF review.

I could envision a SHA3-based registration in the future, but I wouldn't guarantee it.

I'm personally of the opinion that registrations WITHIN a family should be lighter weight than registrations of mechanism families.

But I'm happy to go with WG consensus on the question.

There was discussion in the HTTPAUTH working group this morning, asking about the use of SHA2 as an HTTP mechanism instead of the SHA1 being discussed in Alexey's draft.

An open question is whether this could/should become a working group draft. I am happy with it being handled either that way or keeping it an individual AD-sponsored draft. (I've already spoken with Steven and Kathleen about that possibility.)

Speaking as co-chair; it has been a strain on the WG's resources with getting through the previous and current set of SASL work items.  So my initial position on this would be to have this draft AD-sponsored.

As I said, I'm happy keeping it AD-sponsored. I would continue to keep the reviews within kitten. I'll pursue that further then.

    Tony

Shawn.
--
-------- Original Message --------
Subject: I-D Action: draft-hansen-scram-sha256-01.txt
Date: Thu, 24 Jul 2014 15:49:56 -0700
From: internet-drafts@ietf.org
Reply-To: internet-drafts@ietf.org
To: i-d-announce@ietf.org 


A New Internet-Draft is available from the on-line Internet-Drafts directories.


        Title           : SCRAM-SHA-256 and SCRAM-SHA-256-PLUS SASL Mechanisms
        Author          : Tony Hansen
	Filename        : draft-hansen-scram-sha256-01.txt
	Pages           : 5
	Date            : 2014-07-24

Abstract:
   This document registers the SASL mechanisms SCRAM-SHA-256 and SCRAM-
   SHA-256-PLUS.  It also updates RFC 5802 in minor ways.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-hansen-scram-sha256/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-hansen-scram-sha256-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-hansen-scram-sha256-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/




_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten




_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten

--------------010603080406040407040907-- From nobody Fri Aug 8 21:16:20 2014 Return-Path: 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 190BA1A0646 for ; Fri, 8 Aug 2014 21:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 CfTvLTljC4Rn for ; Fri, 8 Aug 2014 21:16:17 -0700 (PDT) Received: from smtp.stanford.edu (smtp2.Stanford.EDU [171.67.219.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB1B1A0A8B for ; Fri, 8 Aug 2014 21:16:17 -0700 (PDT) Received: from codegreen1.stanford.edu (codegreen1.Stanford.EDU [171.67.224.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 31F32341B34 for ; Fri, 8 Aug 2014 21:16:14 -0700 (PDT) Received: from codegreen1.stanford.edu (localhost.localdomain [127.0.0.1]) by codegreen1.stanford.edu (Postfix) with ESMTP id 2404084 for ; Fri, 8 Aug 2014 21:16:14 -0700 (PDT) Received: from smtp.stanford.edu (smtp1.Stanford.EDU [171.67.219.81]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by codegreen1.stanford.edu (Postfix) with ESMTP id 17A3E84 for ; Fri, 8 Aug 2014 21:16:14 -0700 (PDT) Received: from smtp.stanford.edu (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 4C84021767 for ; Fri, 8 Aug 2014 21:16:09 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 497EF21768 for ; Fri, 8 Aug 2014 21:15:59 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id 506582F573; Fri, 8 Aug 2014 21:15:42 -0700 (PDT) From: Russ Allbery To: "kitten\@ietf.org" In-Reply-To: <53E58D77.1020100@att.com> (Tony Hansen's message of "Fri, 08 Aug 2014 22:54:47 -0400") Organization: The Eyrie References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> <53D18F6F.1060204@att.com> <53E47603.3080302@oracle.com> <53E58D77.1020100@att.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Date: Fri, 08 Aug 2014 21:15:42 -0700 Message-ID: <8738d670y9.fsf@windlord.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/-ZIGgJDTpW5FPW12i2b6f-0LAdE Subject: Re: [kitten] Fwd: I-D Action: draft-hansen-scram-sha256-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 04:16:19 -0000 Tony Hansen writes: > On 8/8/14, 3:02 AM, Shawn M Emery wrote: >> I know RFC 3962 calls for 4096 rounds for SHA-1. I haven't heard of >> anything that would make us want to change this. Are there specific >> use-cases for this mechanism that would be negatively affected when >> choosing a higher iteration or is there guidance on policies when using >> this number of iterations or lower? > I am not aware of any guidance on how to choose an appropriate number of > iterations. The rule of thumb that I was told by the CS crypto faculty at Stanford was to use a number of iterations such that string-to-key would take 0.1 seconds on a computer with typical current performance. That may or may not be practical, given... > I do know that we found 4096 iterations to be significant on a handheld > device, and I would *prefer* not raising it any higher. (We would not be > willing to change our existing implementation of scram-sha-256 to a higher > number unless there was a >>really good reason<<.) ...you're already seeing performance issues with 4,096, and my testing showed that meeting that rule of thumb would require at least 14,500 iterations of SHA-2 with PBKDF2. -- Russ Allbery (eagle@eyrie.org) From nobody Fri Aug 8 22:58:14 2014 Return-Path: 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 3EF3E1A0AB5 for ; Fri, 8 Aug 2014 22:58:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 LZvjOYfaQxlY for ; Fri, 8 Aug 2014 22:58:11 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1D41A0AAD for ; Fri, 8 Aug 2014 22:58:11 -0700 (PDT) Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s795w9Os022199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 9 Aug 2014 05:58:10 GMT Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet22.oracle.com (8.14.5+Sun/8.14.5) with ESMTP id s795w75k016955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 9 Aug 2014 05:58:09 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s795w5fY014104 for ; Sat, 9 Aug 2014 05:58:05 GMT Received: from shawn-emerys-computer.local (/75.166.175.246) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 08 Aug 2014 22:58:04 -0700 Message-ID: <53E5B870.7010307@oracle.com> Date: Fri, 08 Aug 2014 23:58:08 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: kitten@ietf.org References: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Source-IP: ucsinet22.oracle.com [156.151.31.94] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TffvJXHPqBQA8BIKlc2wiM0veX8 Subject: Re: [kitten] next steps on oauth sasl draft? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 05:58:13 -0000 On 8/8/14 3:14 PM, Jamie Nicolson (倪志明) wrote: > We've reviewed it at Google and we think we can implement it. We'll > require the authzid to be specified in the gs2 header. Thank you for the feedback. We'll start another WGLC on this draft in the next few days. Shawn. -- > On Thu, Aug 7, 2014 at 1:25 PM, Bill Mills > wrote: > > The OAuth SASL draft was in WGLC, but we made significant changes. > We've had one brief review of it since -15, that doesn't seem > like enough to say it might be close to WGLC eligible again. I'd > especially like it if one or more of the folks at Google could > take a look as they're the major implementor so far. > > Hoping to wrap this up. > > Thanks, > > -bill > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > > > > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Sat Aug 9 02:07:29 2014 Return-Path: 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 AE54F1A0B06 for ; Sat, 9 Aug 2014 02:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no 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 jtzJ4Zzwhi8J for ; Sat, 9 Aug 2014 02:07:26 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D55D41A0B12 for ; Sat, 9 Aug 2014 02:07:25 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:f2de:f1ff:fe16:509b]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s7997D1O006613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 9 Aug 2014 11:07:16 +0200 Date: Sat, 9 Aug 2014 11:07:13 +0200 From: Simon Josefsson To: Tony Hansen Message-ID: <20140809110713.0955eff3@latte.josefsson.org> In-Reply-To: <53E58D77.1020100@att.com> References: <20140724224956.3620.25084.idtracker@ietfa.amsl.com> <53D18F6F.1060204@att.com> <53E47603.3080302@oracle.com> <53E58D77.1020100@att.com> X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/4DSm4Qy0hOlbOgq4sAnpWnlnlfM Cc: "kitten@ietf.org" Subject: Re: [kitten] Fwd: I-D Action: draft-hansen-scram-sha256-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 09:07:27 -0000 > >> One question I have for this: would it be worth change SCRAM > >> registrations to Expert Review in place of IETF review? > > > > Do you envision a number of future mechanisms under the SCRAM* > > family? If not then I would prefer leaving it as IETF review. > > I could envision a SHA3-based registration in the future, but I > wouldn't guarantee it. > > I'm personally of the opinion that registrations WITHIN a family > should be lighter weight than registrations of mechanism families. I think the reasoning for this was that introducing a new SASL mechanism has no backwards compatibility issues so it causes no problems -- however introducing a new SCRAM mechanism poses some more complexity wrt negotiation and the GSS-API part that warrants more thinking, hence more review requirements. However in practice I think the SASL family concept introduces more complexity and problems than it helps with, so I would prefer if all SASL mechanisms were separate from each other or that the mechanisms instead dictated their relationship rather than the framework. /Simon From nobody Mon Aug 11 08:52:31 2014 Return-Path: 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 16D7D1A0652 for ; Mon, 11 Aug 2014 08:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.833 X-Spam-Level: X-Spam-Status: No, score=0.833 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO_END_DIGIT=0.25, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, 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 8k-SOGIZJO8H for ; Mon, 11 Aug 2014 08:52:27 -0700 (PDT) Received: from nm26-vm0.bullet.mail.bf1.yahoo.com (nm26-vm0.bullet.mail.bf1.yahoo.com [98.139.213.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83F0D1A0668 for ; Mon, 11 Aug 2014 08:52:27 -0700 (PDT) Received: from [98.139.212.151] by nm26.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2014 15:52:26 -0000 Received: from [98.139.212.228] by tm8.bullet.mail.bf1.yahoo.com with NNFMP; 11 Aug 2014 15:52:25 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 11 Aug 2014 15:52:25 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 715682.83927.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 41132 invoked by uid 60001); 11 Aug 2014 15:52:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1407772345; bh=WeZncB+BWMN0zFfB6Oo4y7UY76XsoDqVwOcwiMhpqWQ=; h=References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=aILk+g8TMQa7loG03KEdWY7TEw4MPgRmvViH152lAUol5YyV7mKvT+xhin6KZD2XRpeJ0Uj7mAIjg6oS0DU/TG5ZJt4G6SXtqsJn18jtxMU9lclyqVS6f0J43iH4mcw64NdAWRxxcEPGH82Nq1zwBCvwMtdItNueHV0urDbB73M= X-YMail-OSG: H7A9bDAVM1nBjrP1JpAuYicLuU47r913rYD06la4530qBSI Ztoo0OVLgXf6Ef6k14gTMlLxtICIFKf1ileGZRnxwgZ9JOCFnsbaF2_uy7YB pzWjNa7tugcLQkSxU2R09xVCi6AORyT9fEmh.zsjgQ_7BTpT.Xg3SpitRS_U TuPZZgNGLRuls7QGfFF6Z9h4VADnzoeDw_.xLa4I6Y9qcOb0dvfKRd5UWBmu hk2eDpsG9JNkRdM8u2QK7b2Vefl7iZ5TZFmExPoeoSpt2znRxEMILZPhkCy7 8sGZSOi.1KWoe_xwgfZE2UP3QmufzHWSHB4_oY1FHLmhh4Et3SVovrCPklaJ 3p0oJ00rsJIphB.gnNeNG2gXoadUR.1vrMEj0q1ex2vLKktTpbmFqzt3.et_ pYX653fbsfJgBt6OvNrWJW0Xla78Xh38_26OwDHPxUlxEdC1mNH2jr.D2cOf yOwPBOLx3XlmyckiQVNQ4HxtuAM7ziJ1ZWt8C.yV80thWm1OlsoEvFgJe47S kaO0TuzGL1UnxiDiUKujVwXmjGvsMMcThqmEd4g5WnpIiFPDfvfvle7PY Received: from [99.31.212.42] by web142803.mail.bf1.yahoo.com via HTTP; Mon, 11 Aug 2014 08:52:25 PDT X-Rocket-MIMEInfo: 002.001, SmFtaWUsCgpUaGFuayB5b3UgZm9yIHRoZSByZXZpZXcuIMKgVmVyeSBoZWxwZnVsLgoKLWJpbGwKCgpPbiBGcmlkYXksIEF1Z3VzdCA4LCAyMDE0IDI6MTQgUE0sIEphbWllIE5pY29sc29uICjlgKrlv5fmmI4pIDxuaWNvbHNvbkBnb29nbGUuY29tPiB3cm90ZToKIAoKCldlJ3ZlIHJldmlld2VkIGl0IGF0IEdvb2dsZSBhbmQgd2UgdGhpbmsgd2UgY2FuIGltcGxlbWVudCBpdC4gV2UnbGwgcmVxdWlyZSB0aGUgYXV0aHppZCB0byBiZSBzcGVjaWZpZWQgaW4gdGhlIGdzMiBoZWFkZXIuCgoKCk9uIFRodSwgQXUBMAEBAQE- X-Mailer: YahooMailWebService/0.8.201.700 References: <1407443152.85652.YahooMailNeo@web142802.mail.bf1.yahoo.com> Message-ID: <1407772345.71263.YahooMailNeo@web142803.mail.bf1.yahoo.com> Date: Mon, 11 Aug 2014 08:52:25 -0700 From: Bill Mills To: =?utf-8?B?SmFtaWUgTmljb2xzb24gKOWAquW/l+aYjik=?= In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="905790552-295836019-1407772345=:71263" Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/9fY-3kUZYvsLTaBBG0vhae160Bk Cc: "kitten@ietf.org" Subject: Re: [kitten] next steps on oauth sasl draft? X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Bill Mills List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Aug 2014 15:52:29 -0000 --905790552-295836019-1407772345=:71263 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jamie,=0A=0AThank you for the review. =C2=A0Very helpful.=0A=0A-bill=0A=0A= =0AOn Friday, August 8, 2014 2:14 PM, Jamie Nicolson (=E5=80=AA=E5=BF=97=E6= =98=8E) wrote:=0A =0A=0A=0AWe've reviewed it at Googl= e and we think we can implement it. We'll require the authzid to be specifi= ed in the gs2 header.=0A=0A=0A=0AOn Thu, Aug 7, 2014 at 1:25 PM, Bill Mills= wrote:=0A=0AThe OAuth SASL draft was in WGLC, but= we made significant changes. =C2=A0We've had one brief review of it since = -15, that doesn't seem like enough to say it might be close to WGLC eligibl= e again. =C2=A0I'd especially like it if one or more of the folks at Google= could take a look as they're the major implementor so far.=0A>=0A>=0A>Hopi= ng to wrap this up.=0A>=0A>=0A>Thanks,=0A>=0A>=0A>-bill=0A>________________= _______________________________=0A>Kitten mailing list=0A>Kitten@ietf.org= =0A>https://www.ietf.org/mailman/listinfo/kitten=0A>=0A> --905790552-295836019-1407772345=:71263 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Jamie,

Thank you for the review. =  Very helpful.

-bill


On Friday, August 8, 2014 2:14 PM, Jamie Nicolson (=E5=80=AA=E5=BF=97= =E6=98=8E) <nicolson@google.com> wrote:


=


--905790552-295836019-1407772345=:71263-- From nobody Thu Aug 14 12:23:39 2014 Return-Path: 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 C42C21A0466 for ; Thu, 14 Aug 2014 12:23:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 sGh6oLtvTkjG for ; Thu, 14 Aug 2014 12:23:36 -0700 (PDT) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FDF81A802D for ; Thu, 14 Aug 2014 12:23:34 -0700 (PDT) X-AuditID: 1209190d-f79c06d000002f07-30-53ed0cb5fd69 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 9A.1F.12039.5BC0DE35; Thu, 14 Aug 2014 15:23:33 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7EJNWwH005097 for ; Thu, 14 Aug 2014 15:23:33 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7EJNUKO020148 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 14 Aug 2014 15:23:32 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7EJNUGp010629; Thu, 14 Aug 2014 15:23:30 -0400 (EDT) Date: Thu, 14 Aug 2014 15:23:30 -0400 (EDT) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: Message-ID: References: <20140702154337.23812.83936.idtracker@ietfa.amsl.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixG6noruV522wwcu/chZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxt/ubpaCQwYVa6+/Z2xgvKTexcjJISFgIrH61S1mCFtM4sK9 9WxdjFwcQgKzmST69p+Bco4zSnT/+8UC4dxgknh0aR5UpoFR4ugWkB5ODhYBbYmuv93sIDab gIrEzDcbweIiAuoSew9NZQGxhQX8JNpWHQfbxymgK7Fj8iIwm1fAUeLxmYdQQ2cwSvw8dB6s WVRAR2L1/iksEEWCEidnPgGzmQW0JJZP38YygVFgFpLULCSpBYxMqxhlU3KrdHMTM3OKU5N1 i5MT8/JSi3SN9HIzS/RSU0o3MYJCkFOSdwfju4NKhxgFOBiVeHg1tr4JFmJNLCuuzD3EKMnB pCTK68D6NliILyk/pTIjsTgjvqg0J7X4EKMEB7OSCG85SI43JbGyKrUoHyYlzcGiJM771toq WEggPbEkNTs1tSC1CCYrw8GhJMH7khuoUbAoNT21Ii0zpwQhzcTBCTKcB2j4eZAa3uKCxNzi zHSI/ClGXY4zP1/2Mgmx5OXnpUqJ85aAFAmAFGWU5sHNgaWOV4ziQG8J834FqeIBph24Sa+A ljABLdns+gpkSUkiQkqqgbFyGYPFxJ2rFR9pTlh6yePoNYtNn69z6byKP3nLNO6ni9/tqn0m p5ebTnVbPu+GZP+p5cxxPELxTy7ydtpyyIj/vzgj6s7FfrGCuN/LP0XbPXdO/7ZJo/KT0jV2 w0Yuzsnl7eWvHi25ID+7cd3xlydWdH7Rmjshqu/JpkVWxutf952Z3unSlBKvxFKckWioxVxU nAgAU3OkNvgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/1838Wj02OXF4bD7pjANNcjp24J4 Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 19:23:37 -0000 On Mon, 7 Jul 2014, Peck, Michael A wrote: > Ben, > > Thanks for reviewing the changes. > > I put together test vectors this morning for deriving Kp from the base-key > and for the pseudo-random function invocations. > I can add the following text to Appendix A (Test Vectors) once > Internet-Draft submission reopens. > If you'd like to verify these I certainly wouldn't mind. The key derivation vectors are pretty easy to verify -- one can just use the openssl command-line tool with the appropriate knobs set. The string2key and encryption vectors look like they'll take some more effort to verify. Here's what I have so far: > Sample results for key derivation: > ---------------------------------- > > enctype aes128-cts-hmac-sha256-128: > 128-bit base-key: > 37 05 D9 60 80 C1 77 28 A0 E8 00 EA B6 E0 D2 3C > Kc value for key usage 2 (constant = 0x0000000299): > B3 1A 01 8A 48 F5 47 76 F4 03 E9 A3 96 32 5D C3 > Ke value for key usage 2 (constant = 0x00000002AA): > 9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E > Ki value for key usage 2 (constant = 0x0000000255): > 9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C > Kp value (constant = 0x707266): > 9C 66 77 98 08 4F 16 82 1E 77 15 DD 5A A6 EB 71 no-knife:~/krb/aes/kd> printf "\x00\x00\x00\x02\x99"|openssl dgst -mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 (stdin)= 682df7d0a529ed3c7eabeaf3bae7f1507365f7cd676feaaf4f07803f56331f49 no-knife:~/krb/aes/kd> printf "\x00\x00\x00\x01\x00\x00\x00\x02\x99\x00\x00\x00\x00\x80" | openssl dgst -mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 (stdin)= b31a018a48f54776f403e9a396325dc3a688db623e7e5718ca087f29a6e0d18b no-knife:~/krb/aes/kd> printf "\x00\x00\x00\x01\x00\x00\x00\x02\xaa\x00\x00\x00\x00\x80" | openssl dgst -mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 (stdin)= 9b197dd1e8c5609d6e67c3e37c62c72e86165fff45c059c5430c2cb28271c8e1 no-knife:~/krb/aes/kd> printf "\x00\x00\x00\x01\x00\x00\x00\x02\x55\x00\x00\x00\x00\x80" | openssl dgst -mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 (stdin)= 9fda0e56ab2d85e1569a688696c26a6c5a76939834fa73931ab260832012c15f no-knife:~/krb/aes/kd> printf "\x00\x00\x00\x01prf\x00\x00\x00\x00\x80" | openssl dgst -mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 (stdin)= 9c667798084f16821e7715dd5aa6eb71edcc9410a3c32474ba097333187f23bc I didn't find a way to get openssl to perform the k-truncation, but since one is doing a manual verification anyway at this point, that doesn't seem like a big deal. > enctype aes256-cts-hmac-sha384-192: > 256-bit base-key: > 6D 40 4D 37 FA F7 9F 9D F0 D3 35 68 D3 20 66 98 > 00 EB 48 36 47 2E A8 A0 26 D1 6B 71 82 46 0C 52 > Kc value for key usage 2 (constant = 0x0000000299): > EF 57 18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 C4 > BA 41 F2 8F AF 69 E7 3D > Ke value for key usage 2 (constant = 0x00000002AA): > 56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7 > A5 EB 1C 82 51 60 C3 83 12 98 0C 44 2E 5C 7E 49 > Ki value for key usage 2 (constant = 0x0000000255): > 69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 > 22 C4 D0 0F FC 23 ED 1F > Kp value (constant = 0x707266): > 5D 63 0D B7 EF DE 37 DE 9C 92 03 C5 2B D9 6C 77 > 31 BE 1C 5B DD 50 DC 75 44 D9 60 AF F3 CC 23 04 grumpy-fuzzball:~> printf "\x00\x00\x00\x01\x00\x00\x00\x02\x99\x00\x00\x00\x00\xc0" | openssl dgst -mac hmac -sha256 -macopt hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 (stdin)= 6b727ae22a201c0a9c1254814582cd7dbbc2bc52eb2e9911d956051f12d744a7 grumpy-fuzzball:~> printf "\x00\x00\x00\x01\x00\x00\x00\x02\x99\x00\x00\x00\x00\xc0" | openssl dgst -mac hmac -sha384 -macopt hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 (stdin)= ef5718be86cc84963d8bbb5031e9f5c4ba41f28faf69e73db59bbe8665a6c224a58ed65f1d7921a017b9f9c173fb79ed grumpy-fuzzball:~> printf "\x00\x00\x00\x01\x00\x00\x00\x02\xaa\x00\x00\x00\x01\x00" | openssl dgst -mac hmac -sha384 -macopt hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 (stdin)= 56ab22bee63d82d7bc5227f6773f8ea7a5eb1c825160c38312980c442e5c7e490e6e8072e7c673258eff172053f03f35 grumpy-fuzzball:~> printf "\x00\x00\x00\x01\x00\x00\x00\x02\x55\x00\x00\x00\x00\xc0" | openssl dgst -mac hmac -sha384 -macopt hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 (stdin)= 69b16514e3cd8e56b82010d5c73012b622c4d00ffc23ed1f19c6803ff0cf1ecf953b5ef3c3f1202fd849fbddfbf3a908 grumpy-fuzzball:~> printf "\x00\x00\x00\x01prf\x00\x00\x00\x01\x00" | openssl dgst -mac hmac -sha384 -macopt hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 (stdin)= 5d630db7efde37de9c9203c52bd96c7731be1c5bdd50dc7544d960aff3cc23042f35cd2dae8522ec44215ee31aab49d0 Note that the last bytes of the printf invocation must change whether we are producing Kc/Ki or Ke/Kp. > Sample pseudo-random function (PRF) invocations: > ----------------------------------------- > > PRF input octet-string: "test" (0x74657374) > > enctype aes128-cts-hmac-sha256-128: > Kp value: > 9C 66 77 98 08 4F 16 82 1E 77 15 DD 5A A6 EB 71 > PRF output: > 3A CA 18 6C C1 26 56 76 5C FE B1 D2 2D 1C B1 36 > > enctype aes256-cts-hmac-sha384-192: > Kp value: > 5D 63 0D B7 EF DE 37 DE 9C 92 03 C5 2B D9 6C 77 > 31 BE 1C 5B DD 50 DC 75 44 D9 60 AF F3 CC 23 04 > PRF output: > 01 72 03 F2 90 CD 16 6C D6 B2 BB 4F 18 7D 16 23 > 6B 9A 4E D7 66 19 D8 11 6C 64 06 A3 37 E7 F9 08 These also look good: grumpy-fuzzball:~> printf "test" | openssl dgst -mac hmac -sha256 -macopt hexkey:9C667798084F16821E7715DD5AA6EB71 (stdin)= 3aca186cc12656765cfeb1d22d1cb136761138f3463d5987be408ab09039523d grumpy-fuzzball:~> printf "test" | openssl dgst -mac hmac -sha384 -macopt hexkey:5D630DB7EFDE37DE9C9203C52BD96C7731BE1C5BDD50DC7544D960AFF3CC2304 (stdin)= 017203f290cd166cd6b2bb4f187d16236b9a4ed76619d8116c6406a337e7f9087882bd79edd42abc6d44319f94db2fa5 -Ben From nobody Fri Aug 15 09:57:06 2014 Return-Path: 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 1A2801A007B for ; Fri, 15 Aug 2014 09:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 WWvQBSeNCHMo for ; Fri, 15 Aug 2014 09:57:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (smtpksrv1.mitre.org [198.49.146.77]) by ietfa.amsl.com (Postfix) with ESMTP id 89FFD1A006C for ; Fri, 15 Aug 2014 09:57:02 -0700 (PDT) Received: from smtpksrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id E1A241F0AF3; Fri, 15 Aug 2014 12:57:01 -0400 (EDT) Received: from IMCCAS01.MITRE.ORG (imccas01.mitre.org [129.83.29.78]) by smtpksrv1.mitre.org (Postfix) with ESMTP id D36731F0AF1; Fri, 15 Aug 2014 12:57:01 -0400 (EDT) Received: from IMCMBX04.MITRE.ORG ([169.254.4.226]) by IMCCAS01.MITRE.ORG ([129.83.29.68]) with mapi id 14.03.0174.001; Fri, 15 Aug 2014 12:57:01 -0400 From: "Peck, Michael A" To: Benjamin Kaduk , "kitten@ietf.org" Thread-Topic: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-03.txt Thread-Index: AQHPlgxyGHeCy5BqJE6NR5iOV7LZfJuSjYgAgAIfAYCAPFTiAIABJloA Date: Fri, 15 Aug 2014 16:57:00 +0000 Message-ID: References: <20140702154337.23812.83936.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.1.140326 x-originating-ip: [172.31.48.181] Content-Type: text/plain; charset="us-ascii" Content-ID: <201891C0FC786D4B9E148F8082E91A97@imc.mitre.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/XKkNo5p8zffGjbhPjqAK1573Dfg Subject: Re: [kitten] I-D Action: draft-ietf-kitten-aes-cts-hmac-sha2-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 16:57:05 -0000 Ben, Thanks for checking these, I did not think of using openssl. We separately wrote code in both Java (with Bouncy Castle) and Python to generate the test vectors. Bouncy Castle supports PBKDF2, CTS mode, etc. We found Python code for everything except CTS, so we used CBC there and manually modified the result. Mike On 8/14/14, 3:23 PM, "Benjamin Kaduk" wrote: >On Mon, 7 Jul 2014, Peck, Michael A wrote: > >> Ben, >> >> Thanks for reviewing the changes. >> >> I put together test vectors this morning for deriving Kp from the >>base-key >> and for the pseudo-random function invocations. >> I can add the following text to Appendix A (Test Vectors) once >> Internet-Draft submission reopens. >> If you'd like to verify these I certainly wouldn't mind. > >The key derivation vectors are pretty easy to verify -- one can just use >the openssl command-line tool with the appropriate knobs set. The >string2key and encryption vectors look like they'll take some more effort >to verify. Here's what I have so far: > >> Sample results for key derivation: >> ---------------------------------- >> >> enctype aes128-cts-hmac-sha256-128: >> 128-bit base-key: >> 37 05 D9 60 80 C1 77 28 A0 E8 00 EA B6 E0 D2 3C >> Kc value for key usage 2 (constant =3D 0x0000000299): >> B3 1A 01 8A 48 F5 47 76 F4 03 E9 A3 96 32 5D C3 >> Ke value for key usage 2 (constant =3D 0x00000002AA): >> 9B 19 7D D1 E8 C5 60 9D 6E 67 C3 E3 7C 62 C7 2E >> Ki value for key usage 2 (constant =3D 0x0000000255): >> 9F DA 0E 56 AB 2D 85 E1 56 9A 68 86 96 C2 6A 6C >> Kp value (constant =3D 0x707266): >> 9C 66 77 98 08 4F 16 82 1E 77 15 DD 5A A6 EB 71 > > >no-knife:~/krb/aes/kd> printf "\x00\x00\x00\x02\x99"|openssl dgst -mac >hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 >(stdin)=3D 682df7d0a529ed3c7eabeaf3bae7f1507365f7cd676feaaf4f07803f56331f4= 9 >no-knife:~/krb/aes/kd> printf >"\x00\x00\x00\x01\x00\x00\x00\x02\x99\x00\x00\x00\x00\x80" | openssl dgst >-mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 >(stdin)=3D b31a018a48f54776f403e9a396325dc3a688db623e7e5718ca087f29a6e0d18= b >no-knife:~/krb/aes/kd> printf >"\x00\x00\x00\x01\x00\x00\x00\x02\xaa\x00\x00\x00\x00\x80" | openssl dgst >-mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 >(stdin)=3D 9b197dd1e8c5609d6e67c3e37c62c72e86165fff45c059c5430c2cb28271c8e= 1 >no-knife:~/krb/aes/kd> printf >"\x00\x00\x00\x01\x00\x00\x00\x02\x55\x00\x00\x00\x00\x80" | openssl dgst >-mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C -sha256 >(stdin)=3D 9fda0e56ab2d85e1569a688696c26a6c5a76939834fa73931ab260832012c15= f >no-knife:~/krb/aes/kd> printf "\x00\x00\x00\x01prf\x00\x00\x00\x00\x80" | >openssl dgst -mac hmac -macopt hexkey:3705D96080C17728A0E800EAB6E0D23C >-sha256 >(stdin)=3D 9c667798084f16821e7715dd5aa6eb71edcc9410a3c32474ba097333187f23b= c > >I didn't find a way to get openssl to perform the k-truncation, but since >one is doing a manual verification anyway at this point, that doesn't seem >like a big deal. > > > > >> enctype aes256-cts-hmac-sha384-192: >> 256-bit base-key: >> 6D 40 4D 37 FA F7 9F 9D F0 D3 35 68 D3 20 66 98 >> 00 EB 48 36 47 2E A8 A0 26 D1 6B 71 82 46 0C 52 >> Kc value for key usage 2 (constant =3D 0x0000000299): >> EF 57 18 BE 86 CC 84 96 3D 8B BB 50 31 E9 F5 C4 >> BA 41 F2 8F AF 69 E7 3D >> Ke value for key usage 2 (constant =3D 0x00000002AA): >> 56 AB 22 BE E6 3D 82 D7 BC 52 27 F6 77 3F 8E A7 >> A5 EB 1C 82 51 60 C3 83 12 98 0C 44 2E 5C 7E 49 >> Ki value for key usage 2 (constant =3D 0x0000000255): >> 69 B1 65 14 E3 CD 8E 56 B8 20 10 D5 C7 30 12 B6 >> 22 C4 D0 0F FC 23 ED 1F >> Kp value (constant =3D 0x707266): >> 5D 63 0D B7 EF DE 37 DE 9C 92 03 C5 2B D9 6C 77 >> 31 BE 1C 5B DD 50 DC 75 44 D9 60 AF F3 CC 23 04 > > > >grumpy-fuzzball:~> printf >"\x00\x00\x00\x01\x00\x00\x00\x02\x99\x00\x00\x00\x00\xc0" | openssl dgst >-mac hmac -sha256 -macopt >hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 >(stdin)=3D 6b727ae22a201c0a9c1254814582cd7dbbc2bc52eb2e9911d956051f12d744a= 7 >grumpy-fuzzball:~> printf >"\x00\x00\x00\x01\x00\x00\x00\x02\x99\x00\x00\x00\x00\xc0" | openssl dgst >-mac hmac -sha384 -macopt >hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 >(stdin)=3D >ef5718be86cc84963d8bbb5031e9f5c4ba41f28faf69e73db59bbe8665a6c224a58ed65f1d >7921a017b9f9c173fb79ed >grumpy-fuzzball:~> printf >"\x00\x00\x00\x01\x00\x00\x00\x02\xaa\x00\x00\x00\x01\x00" | openssl dgst >-mac hmac -sha384 -macopt >hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 >(stdin)=3D >56ab22bee63d82d7bc5227f6773f8ea7a5eb1c825160c38312980c442e5c7e490e6e8072e7 >c673258eff172053f03f35 >grumpy-fuzzball:~> printf >"\x00\x00\x00\x01\x00\x00\x00\x02\x55\x00\x00\x00\x00\xc0" | openssl dgst >-mac hmac -sha384 -macopt >hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 >(stdin)=3D >69b16514e3cd8e56b82010d5c73012b622c4d00ffc23ed1f19c6803ff0cf1ecf953b5ef3c3 >f1202fd849fbddfbf3a908 >grumpy-fuzzball:~> printf "\x00\x00\x00\x01prf\x00\x00\x00\x01\x00" | >openssl dgst -mac hmac -sha384 -macopt >hexkey:6D404D37FAF79F9DF0D33568D320669800EB4836472EA8A026D16B7182460C52 >(stdin)=3D >5d630db7efde37de9c9203c52bd96c7731be1c5bdd50dc7544d960aff3cc23042f35cd2dae >8522ec44215ee31aab49d0 > >Note that the last bytes of the printf invocation must change whether we >are producing Kc/Ki or Ke/Kp. > > > >> Sample pseudo-random function (PRF) invocations: >> ----------------------------------------- >> >> PRF input octet-string: "test" (0x74657374) >> >> enctype aes128-cts-hmac-sha256-128: >> Kp value: >> 9C 66 77 98 08 4F 16 82 1E 77 15 DD 5A A6 EB 71 >> PRF output: >> 3A CA 18 6C C1 26 56 76 5C FE B1 D2 2D 1C B1 36 >> >> enctype aes256-cts-hmac-sha384-192: >> Kp value: >> 5D 63 0D B7 EF DE 37 DE 9C 92 03 C5 2B D9 6C 77 >> 31 BE 1C 5B DD 50 DC 75 44 D9 60 AF F3 CC 23 04 >> PRF output: >> 01 72 03 F2 90 CD 16 6C D6 B2 BB 4F 18 7D 16 23 >> 6B 9A 4E D7 66 19 D8 11 6C 64 06 A3 37 E7 F9 08 > >These also look good: > >grumpy-fuzzball:~> printf "test" | openssl dgst -mac hmac -sha256 -macopt >hexkey:9C667798084F16821E7715DD5AA6EB71 >(stdin)=3D 3aca186cc12656765cfeb1d22d1cb136761138f3463d5987be408ab09039523= d >grumpy-fuzzball:~> printf "test" | openssl dgst -mac hmac -sha384 -macopt >hexkey:5D630DB7EFDE37DE9C9203C52BD96C7731BE1C5BDD50DC7544D960AFF3CC2304 >(stdin)=3D >017203f290cd166cd6b2bb4f187d16236b9a4ed76619d8116c6406a337e7f9087882bd79ed >d42abc6d44319f94db2fa5 > >-Ben > >_______________________________________________ >Kitten mailing list >Kitten@ietf.org >https://www.ietf.org/mailman/listinfo/kitten From nobody Fri Aug 15 11:06:16 2014 Return-Path: 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 303FE1A01F7 for ; Fri, 15 Aug 2014 11:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 31RW9lF-FQIC for ; Fri, 15 Aug 2014 11:06:12 -0700 (PDT) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED541A01F6 for ; Fri, 15 Aug 2014 11:06:10 -0700 (PDT) X-AuditID: 1209190c-f79ef6d000005dd6-62-53ee4c11fbef Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-1.mit.edu (Symantec Messaging Gateway) with SMTP id 24.1C.24022.11C4EE35; Fri, 15 Aug 2014 14:06:09 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id s7FI675V030522; Fri, 15 Aug 2014 14:06:08 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7FI65Nj018520 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 15 Aug 2014 14:06:07 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7FI65VW018749; Fri, 15 Aug 2014 14:06:05 -0400 (EDT) Date: Fri, 15 Aug 2014 14:06:05 -0400 (EDT) From: Benjamin Kaduk To: Nico Williams In-Reply-To: <20140804161454.GH3579@localhost> Message-ID: References: <20140804161454.GH3579@localhost> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nrivo8y7Y4Ng8OYujm1exWJy6doTN gcnj5alzjB5LlvxkCmCK4rJJSc3JLEst0rdL4Mro/nWNpWC1aMXi/tfMDYw3BLoYOTgkBEwk Pr217GLkBDLFJC7cW88GYgsJzGaSuPAvuYuRC8jeyChx/+djZgjnEJPExNaJrBBOA6PE28UL mEBaWAS0Jbpe3mcFsdkEVCRmvtkINkpEQFPi+rylbCDbmAWMJC78ygAJCwvYSvTdOscOEuYU 0JP41GsFEuYVcJT4cm4yK8QRwRKTFr5kBLFFBXQkVu+fwgJRIyhxcuYTMJtZQEti+fRtLBMY BWchSc1CklrAyLSKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI11AvN7NELzWldBMjKEg5JXl2ML45 qHSIUYCDUYmHV0D8XbAQa2JZcWXuIUZJDiYlUd6l+kAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxK Iryr3IByvCmJlVWpRfkwKWkOFiVx3rfWVsFCAumJJanZqakFqUUwWRkODiUJXlNvoEbBotT0 1Iq0zJwShDQTByfIcB6g4ZEgNbzFBYm5xZnpEPlTjIpS4rwNXkAJAZBERmkeXC8sibxiFAd6 RZj3D0gVDzABwXW/AhrMBDS4ZvNbkMEliQgpqQbGOdVrMhcxKaa/CH3p/C+RSej/Of7Xmhxp F8JvzuD8E3HwQE3kFfFftkzNwob8gQciS6W+/E135ct5biB22u9yW4Qqs8xM9b7UI55PHi43 +uxu+a/hqbRf3+1LdmwV39ecUNDUSHj502b/9w3dyieLD1WvMdy37i1vDOtK5tI5E1zf/bAP m8OtxFKckWioxVxUnAgA4oYBD/0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/Iq4WJiz6mL0JQ6T4_gO_oq7BlHc Cc: kitten@ietf.org Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 18:06:14 -0000 On Mon, 4 Aug 2014, Nico Williams wrote: > On Sat, Aug 02, 2014 at 11:05:39AM -0400, Greg Hudson wrote: > > > I can speculate on several future directions for critical authorization > > data: > > > > 1. The status quo. Almost all authorization data gets wrapped in > > AD-IF-RELEVANT at a penalty of 13 or more bytes. Critical authdata > > I am fine with this. > > > for application servers is impossible. > > Not necessarily. RFC6680 gives us the APIs we need by which > applications can judge critical AD, but it doesn't give the mechanism > any way to know if the application will understand and evaluate critical > AD. We might be able to get critical AD support in APIs but no > fail-safe mechanism in the mechanism. > > > 2. We somehow determine that all existing Kerberos implementations > > violate this aspect of RFC 4120. We could then specify that > > AD-IF-RELEVANT is no longer necessary. Critical authdata for > > application servers remains impossible. > > I think it will be difficult to make that determination. > > > 3. We convince all of the major implementations to conform to RFC 4120, > > perhaps after determining that it wouldn't break any existing > > implementations as long as you ignore unwrapped PACs. We wait for > > all old deployments to fall out of service (i.e. decades pass). > > Criticial authdata becomes possible. > > See comments above. > > > 4. We specify a new AD-MANDATORY subcontainer and convince all of the > > major implementations to implement it. We wait for all old > > deployments to fall out of service. Critical authdata becomes > > possible using the wrapper. Can be combined with (2). > > No need to wait in order to start using it. Right? > > > Of these, (1) is by far the most likely. (2) is attractive given the > > practical constraints of ticket sizes in some environments, but seems > > difficult to accomplish. > > Why couldn't we go with (4). I think I am also fine with (1), but (4) does present a reasonably viable way forward, should we decide that we're interested in having actually mandatory/critical authdata at some point in the future. The new container would contain things intended to be mandatory, with the understanding that much time would need to pass before consumers could rely on all peers actually respecting that intention. The main question in my mind, deciding between (1) and (4), is: do we believe that we will want to specify authdata that are treated as critical by application servers, ever? (What would such things look like?) From the commentary in Bryce's email, it is unclear that we shoul have such an expectation. -Ben From nobody Fri Aug 15 16:06:29 2014 Return-Path: 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 1915C1A07C7 for ; Fri, 15 Aug 2014 16:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 Ok9Ymw5iKJp7 for ; Fri, 15 Aug 2014 16:06:26 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A701A07C9 for ; Fri, 15 Aug 2014 16:06:19 -0700 (PDT) X-AuditID: 1209190f-f79f86d0000061c8-10-53ee926a3000 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 55.FA.25032.A629EE35; Fri, 15 Aug 2014 19:06:18 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7FN6HEg028499 for ; Fri, 15 Aug 2014 19:06:18 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7FN6FPs016953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 15 Aug 2014 19:06:17 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7FN6FpN026568; Fri, 15 Aug 2014 19:06:15 -0400 (EDT) Date: Fri, 15 Aug 2014 19:06:15 -0400 (EDT) From: Benjamin Kaduk To: kitten@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEIsWRmVeSWpSXmKPExsUixG6nops16V2wweLZnBZHN69icWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRueptYwFU5grrq04zN7AuJGpi5GDQ0LARGLNXI0uRk4gU0zi wr31bF2MXBxCArOZJL586GKCcI4zSlzfvpEVwrnBJDHlwAZGCKeBUeLq2a0sIKNYBLQlrnRo gYxiE1CRmPlmIxuILSIgLLF76ztmEFtYwEFiwcStjCA2p4CRxJ63x9hBbF4BR4m5W6+B1QgJ GEqcfH0JzBYV0JFYvX8KC0SNoMTJmU/AbGYBLYnl07exTGAUmIUkNQtJagEj0ypG2ZTcKt3c xMyc4tRk3eLkxLy81CJdE73czBK91JTSTYyg4OOU5N/B+O2g0iFGAQ5GJR7eDMl3wUKsiWXF lbmHGCU5mJREeYPbgUJ8SfkplRmJxRnxRaU5qcWHGCU4mJVEeFe5AeV4UxIrq1KL8mFS0hws SuK8b62tgoUE0hNLUrNTUwtSi2CyMhwcShK87ROBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGTwGp 4S0uSMwtzkyHyJ9i1OVoaXrbyyTEkpeflyoFtGYCUJEASFFGaR7cHFjSeMUoDvSWMK8TyCge YMKBm/QKaAkT0JKazW9BlpQkIqSkGhi9GQ7GuslFvXdWUv5U1hf5SszilIuB6/RzchZzdJ7e 3ST2qtjIkUfmsO/SJyvd9xx6dEV9VWbAe1sXb9l/3zwWl+wJ/5Z3KWtf5V6fGX8XevQ1pk18 Ldaelrcuue94tdTvfScl8tTOCby3UlWZ8Oeh0QUvM20hP/Gj2zZdtft8JbUm/oPa5blKLMUZ iYZazEXFiQC4MlGg9QIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/TN4tRlKZ92DXL6PpOLgD8l758W4 Subject: Re: [kitten] CAMMAC and ticket server principal binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2014 23:06:28 -0000 On Fri, 8 Aug 2014, Greg Hudson wrote: > > As Sam noted, we have two options: we can add a ticket server binding, > or we can document that there isn't one. Most of the people I have > talked to are in favor of documenting, for these reasons: > [...] > > Do other people have conflicting opinions? [Just to get it in the archives] No; I am one of those in favor of documenting. -Ben From nobody Wed Aug 20 08:32:03 2014 Return-Path: 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 E6D921A0680; Wed, 20 Aug 2014 08:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 D2M1ahTqjPge; Wed, 20 Aug 2014 08:31:56 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72E001A0662; Wed, 20 Aug 2014 08:31:56 -0700 (PDT) X-AuditID: 12074424-f79346d000004923-53-53f4bf6bb108 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id A4.57.18723.B6FB4F35; Wed, 20 Aug 2014 11:31:55 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7KFVrwT000776; Wed, 20 Aug 2014 11:31:54 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7KFVp6N023463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 20 Aug 2014 11:31:53 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7KFVpfH004880; Wed, 20 Aug 2014 11:31:51 -0400 (EDT) Date: Wed, 20 Aug 2014 11:31:50 -0400 (EDT) From: Benjamin Kaduk To: "Adamson, Andy" In-Reply-To: Message-ID: References: <20140730163006.GG26316@fieldses.org> <9BF7E3EA-59DB-4B91-A27A-659790AED727@netapp.com> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; boundary="-559023410-1699034942-1408548420=:21571" Content-ID: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrLKsWRmVeSWpSXmKPExsUixCmqrZu9/0uwwcLPQhZHN69isZj9/hGr xfRFVg7MHkuW/GTymPHpC1sAUxSXTUpqTmZZapG+XQJXxr3WdraCRdIV3/d8YWxg/CDaxcjJ ISFgInFs0V4mCFtM4sK99WwgtpDAbCaJNRO4uxi5gOyNjBINu3rZIJxDTBKXWm4zQjgNjBK7 bp1mBmlhEdCW2P9qMTuIzSagIjHzzUagDg4OEQEDiY1LVUHCzAL2Ej27XoFtEAbafOL2CrBW TgEniSlbroO18go4Stzs2cMOMb+ZSaJ/ez9Yg6iAjsTq/VNYIIoEJU7OfMICMTRQ4sDzT2wQ tqNE/9x7zBMYhWYhKZuFpGwWkjIIW13iwKeLjBC2tsT9m21wNT3rfjEuYGRbxSibklulm5uY mVOcmqxbnJyYl5dapGuul5tZopeaUrqJERQr7C4qOxibDykdYhTgYFTi4b2x6EuwEGtiWXFl 7iFGSQ4mJVHehbuAQnxJ+SmVGYnFGfFFpTmpxYcYJTiYlUR4T2wAyvGmJFZWpRblw6SkOViU xHnfWlsFCwmkJ5akZqemFqQWwWRlODiUJHir9wE1ChalpqdWpGXmlCCkmTg4QYbzAA1fDFLD W1yQmFucmQ6RP8WoKCXOqwWSEABJZJTmwfXCUtkrRnGgV4R5N4BU8QDTIFz3K6DBTECDty7+ CDK4JBEhJdXAWOD8dA/3zIDlk1vmhp9YY+/Vdbc4+M1PzbfrJ0SoZTO4XlNd0vd/Dp/5DN60 TfM3FvRvCdC8WqiwjOnu/QvrP3YYB8xJfrlm3kSdiJOXXMz40m592M6w+56b6vO5q56s3jdj vtN6t0+sW1vSNkp6zjgSuLL+otpziSkBsRcvlNYaWdhw3f50iEuJpTgj0VCLuag4EQBIVSXP QAMAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/C95yOyetqW5sYOunqyuHS8AcJm4 Cc: "kitten@ietf.org" , NFSv4 Subject: [kitten] rpcsec-gssv3 multi-principal authentication X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 15:31:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---559023410-1699034942-1408548420=:21571 Content-Type: TEXT/PLAIN; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Content-ID: I'm starting a new thread for this, since I think it is the most important item revealed by my review, but it seems to have been lost amidst the other discussions. On Sun, 3 Aug 2014, Benjamin Kaduk wrote: > On Fri, 1 Aug 2014, Adamson, Andy wrote: > > > > > I have always thought of Multi-principal authentication in terms of it= =E2=80=99s use > > in NFSv4.2 Inter server to server copy, where all of the RPCSEC_GSS_CRE= ATE > > messages MUST use rpc_gss_svc_privacy=E2=80=99=E2=80=A6. Good catch Bru= ce. > > > > So for this attack to occur the rgmp_nonce must be re-used by the same > > rgmp_handle (same user-principal). Insisting on using a random number > > generator to create nounce could be by-passed by a bad implementation..= =2E > > > > Bruces suggestion of using the new reply verifier data (rpc-header) sho= uld > > do the trick. Any objections to this approach? I don't think I correctly understand this proposal. Can someone try to explain it in more detail, please? > If I understand correctly, the child RPCSEC contex handle will use the sa= me > GSS context as the parent RPCSEC context handle (i.e., using the host's > credentials, not the user's credentials). This means that when creating = the > child RPCSEC context, there must be some proof that the RPC client contro= ls > the GSS context corresponding to the inner RPCSEC context handle, since t= he > child RPCSEC context will perform operations acting as the user specified= by > the GSS context of the inner RPCSEC context. > > My reading of the current draft is that the only attempt to do this is by > presenting a random nonce and a GSS_GetMIC of that nonce, created using t= he > GSS context of the inner RPCSEC context. The server must verify that the= MIC > is a valid mic, but I do not see any other binding to this GSS context. = In > particular, the nonce+MIC could be eavesdropped on the wire, and inserted= into > an attacker's RPCSEC_GSS_CREATE call, where the attacker provides its own > parent RPCSEC context but does not actually have an inner context at all.= The > attacker can reuse the valid nonce+MIC that it has intercepted, which wil= l > validate correctly on the server, and the server will issue a child RPCSE= C > context that acts as the user indicated by the GSS context of the inner R= PCSEC > context but uses the key material from the attacker's GSS context. Basically, my reading is that the triple of (opaque inner handle, nonce, mic) is a bearer token that is valid as long as the inner rpcsec context is valid, as specified in the -08. The inner handle is only used to lookup the GSS security context to use to verify the MIC of the nonce, so if all three are passed together, there is no binding to anything else that I can see. An attacker who gets a copy of this bearer token could then use it to create its own child context from a parent context that the attacker controls, and perform actions as the user corresponding to the GSS security context of the inner context handle. -Ben ---559023410-1699034942-1408548420=:21571-- From nobody Wed Aug 20 17:26:47 2014 Return-Path: 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 9E1E01A0649 for ; Wed, 20 Aug 2014 17:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 tlit3UwZ6DW5 for ; Wed, 20 Aug 2014 17:26:44 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 570781A003A for ; Wed, 20 Aug 2014 17:26:44 -0700 (PDT) Received: from acsinet21.oracle.com (acsinet21.oracle.com [141.146.126.237]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7L0Qg0K027353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 21 Aug 2014 00:26:43 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7L0Qf4F025771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Aug 2014 00:26:41 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s7L0Qe1t006281 for ; Thu, 21 Aug 2014 00:26:40 GMT Received: from shawn-emerys-computer.local (/10.159.185.216) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 20 Aug 2014 17:26:40 -0700 Message-ID: <53F53D1F.7010305@oracle.com> Date: Wed, 20 Aug 2014 18:28:15 -0600 From: Shawn M Emery User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: kitten@ietf.org References: <52AE9A65.1010700@oracle.com> In-Reply-To: <52AE9A65.1010700@oracle.com> X-Forwarded-Message-Id: <52AE9A65.1010700@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: acsinet21.oracle.com [141.146.126.237] Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/2JY5hxHBhhSQpLZxwS6hMi3yMJ8 Subject: [kitten] WGLC on draft-ietf-kitten-sasl-oauth-15 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 00:26:45 -0000 This message officially starts the 3rd kitten Working Group Last Call for the following document: A set of SASL Mechanisms for OAuth http://tools.ietf.org/html/draft-ietf-kitten-sasl-oauth-15 The Working Group Last Call for this document starts today on Wednesday, August 20th and will end on Wednesday, September 3rd. Please send any comments to the kitten mailing list or directly to the chairs. Even if you reviewed this document and found no issues then please provide this feed-back. Thank you, Shawn Emery kitten co-chair -- From nobody Thu Aug 21 17:43:57 2014 Return-Path: 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 40AFD1A06C1 for ; Thu, 21 Aug 2014 17:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 lDJB3xFapzsP for ; Thu, 21 Aug 2014 17:43:54 -0700 (PDT) Received: from smtp03.srv.cs.cmu.edu (smtp03.srv.cs.cmu.edu [128.2.217.202]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C07B41A0649 for ; Thu, 21 Aug 2014 17:43:54 -0700 (PDT) Received: from [192.168.1.235] (184-195-240-202.pools.spcsdns.net [184.195.240.202]) (authenticated bits=0) by smtp03.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s7M0hnIY006892 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 21 Aug 2014 20:43:50 -0400 (EDT) Message-ID: <1408668228.5360.46.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Benjamin Kaduk Date: Thu, 21 Aug 2014 20:43:48 -0400 In-Reply-To: References: <20140804161454.GH3579@localhost> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.202 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/mn_vfeInJCooRODyz9ZOcwZhQ6A Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 00:43:56 -0000 On Fri, 2014-08-15 at 14:06 -0400, Benjamin Kaduk wrote: > I think I am also fine with (1), but (4) does present a reasonably viable > way forward, should we decide that we're interested in having actually > mandatory/critical authdata at some point in the future. The new > container would contain things intended to be mandatory, with the > understanding that much time would need to pass before consumers could > rely on all peers actually respecting that intention. > > The main question in my mind, deciding between (1) and (4), is: do we > believe that we will want to specify authdata that are treated as critical > by application servers, ever? (What would such things look like?) From > the commentary in Bryce's email, it is unclear that we shoul have such an > expectation. The more I think about this, the more I think it's unrealistic to believe we will ever be able to rely on application servers to treat AD as critical. Fortunately, I don't think that will actually be a problem. Any sort of restrictive authorization data likely to be meaningful to an application will almost certainly have to be application-specific. The originator of such data, whether client or KDC (or KDC administrator) will need to have some knowledge of the service in order to construct it, and thus ought to know whether the server is likely to be able to accept it. That said, I can think of one class of uses for which critical AD would be useful. Specifically, suppose a user wishes to add AD to a ticket, informing the server that the ticket should be usable only for a limited subset of operations, and then forward that ticket to a third party. The difficulty arises when the ability to do this has been added to an application, and the user does not know whether the particular server is new enough to support the new feature. Resolving this basically requires some negotiation mechanism within the application protocol. But then, that's no different from what we have now. In short, things might be a whole lot easier if we just give up on critical AD and adopt (1), or a variation thereof. Particularly, we can update Kerberos to explicitly state that AD is non-critical, and give KDC's permission to omit or strip AD-IF-RELEVANT in cases where the server is known not to require it. For example, the KDC might have a per-service flag, or might infer this property for any service which is known to support enctypes adopted after a particular date. -- Jeff From nobody Thu Aug 21 17:46:13 2014 Return-Path: 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 3CAC71A06C1 for ; Thu, 21 Aug 2014 17:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 Jhno0y3erodA for ; Thu, 21 Aug 2014 17:46:11 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9434D1A0655 for ; Thu, 21 Aug 2014 17:46:11 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id 32FB7594059 for ; Thu, 21 Aug 2014 17:46:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ieyBO2nLqUK8WKir0FWy B25nKp0=; b=ByDWV0ihGgH3XCBjA07tPxV6kYMAXK96lUm4g7rIOXZ8wVD77xXC h6Mr6X3guS+UU/IK67WXkus4XuUc5uQ+Uk4igx4RNm75Si4HbL3/QoiB2FVmlmer BdLTavTOv6gpWSC8cyeK7pDKm850kdd10aAi2UumptgiEb7fMTX3e/k= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id CEEEE594054 for ; Thu, 21 Aug 2014 17:46:10 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so9484683wib.16 for ; Thu, 21 Aug 2014 17:46:09 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.241 with SMTP id b17mr25637139wik.70.1408668369682; Thu, 21 Aug 2014 17:46:09 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 21 Aug 2014 17:46:09 -0700 (PDT) In-Reply-To: <1408668228.5360.46.camel@destiny.pc.cs.cmu.edu> References: <20140804161454.GH3579@localhost> <1408668228.5360.46.camel@destiny.pc.cs.cmu.edu> Date: Thu, 21 Aug 2014 19:46:09 -0500 Message-ID: From: Nico Williams To: Jeffrey Hutzelman Content-Type: multipart/alternative; boundary=e89a8f647247c809dc05012d29f8 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ZwKrj6kyD8mCQ-ZdKajYvQRzyfo Cc: "kitten@ietf.org" Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 00:46:12 -0000 --e89a8f647247c809dc05012d29f8 Content-Type: text/plain; charset=UTF-8 Sold. Let's make AD non-critical by default. --e89a8f647247c809dc05012d29f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sold. =C2=A0Let's make AD non-critical by default. --e89a8f647247c809dc05012d29f8-- From nobody Thu Aug 21 17:53:25 2014 Return-Path: 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 40D271A0655 for ; Thu, 21 Aug 2014 17:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] 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 IYiojZWGw4_P for ; Thu, 21 Aug 2014 17:53:23 -0700 (PDT) Received: from smtp02.srv.cs.cmu.edu (smtp02.srv.cs.cmu.edu [128.2.217.201]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178A51A0649 for ; Thu, 21 Aug 2014 17:53:23 -0700 (PDT) Received: from [192.168.1.235] (184-195-240-202.pools.spcsdns.net [184.195.240.202]) (authenticated bits=0) by smtp02.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id s7M0rJ8A002264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 21 Aug 2014 20:53:20 -0400 (EDT) Message-ID: <1408668799.5360.52.camel@destiny.pc.cs.cmu.edu> From: Jeffrey Hutzelman To: Greg Hudson Date: Thu, 21 Aug 2014 20:53:19 -0400 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: mimedefang-cmuscs on 128.2.217.201 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/ptWeA70wSWELMcc9IRObMkv2ONA Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] CAMMAC and ticket server principal binding X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 00:53:24 -0000 On Fri, 2014-08-08 at 16:17 -0400, Greg Hudson wrote: > As Sam noted, we have two options: we can add a ticket server binding, > or we can document that there isn't one. Most of the people I have > talked to are in favor of documenting, for these reasons: = > * All of the ways we could bind the ticket server add some additional > complexity to the specification and to implementations. It seems like it would be easy to add a binding, in the form of AD (inside CAMMAC) containing the server name and realm. A KDC wishing to depend on AD making a statement about the server or client-server relationship would need to compare the server name in the new AD element with those in the outer part of the ticket. Everyone else could simply ignore the server-name AD. Of course, one of the features of this approach is that it can be adopted lazily, the first time a new AD type is introduced for which such a binding is important. > * The purpose of the kdc-verifier is to allow CAMMAC contents to be > propagated to a ticket for a different service. Well, and also to allow the KDC to trust the CAMMAC contents in an existing ticket for some other service (which may have been printed by the service). I have no objection to simply documenting the issue and moving on. -- Jeff From nobody Fri Aug 22 08:19:15 2014 Return-Path: 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 095251A0342 for ; Fri, 22 Aug 2014 08:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 6WnebltK3oYx for ; Fri, 22 Aug 2014 08:19:00 -0700 (PDT) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4B531A032C for ; Fri, 22 Aug 2014 08:18:59 -0700 (PDT) X-AuditID: 12074423-f799d6d00000337c-49-53f75f622a31 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 42.C7.13180.26F57F35; Fri, 22 Aug 2014 11:18:58 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id s7MFIvTK027490 for ; Fri, 22 Aug 2014 11:18:57 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7MFItO7020981 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 22 Aug 2014 11:18:57 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id s7MFItqr005895; Fri, 22 Aug 2014 11:18:55 -0400 (EDT) Date: Fri, 22 Aug 2014 11:18:55 -0400 (EDT) From: Benjamin Kaduk To: "kitten@ietf.org" In-Reply-To: Message-ID: References: <20140804161454.GH3579@localhost> <1408668228.5360.46.camel@destiny.pc.cs.cmu.edu> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixG6nopsU/z3YoKtX2OLo5lUsDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKOLRTvWAlY8X8L8tZGxgbGbsYOTkkBEwkXl6YzwJhi0lcuLee rYuRi0NIYDaTRO+7aywQznFGiTOtJ5khnBtMEue+nGCFcBoYJeaumwQ2i0VAW2LN5mY2EJtN QEVi5puNYLaIgLrE3kNTwXYIC9hK9N06xw5icwoESnQ33GACsXkFHCUmvbnICDH0P6NE7/1+ sCJRAR2J1funsEAUCUqcnPkEzGYW0JJYPn0bywRGgVlIUrOQpBYwMq1ilE3JrdLNTczMKU5N 1i1OTszLSy3SNdPLzSzRS00p3cQIDkAX5R2Mfw4qHWIU4GBU4uFVsPoeLMSaWFZcmXuIUZKD SUmUd0MMUIgvKT+lMiOxOCO+qDQntfgQowQHs5II71wboBxvSmJlVWpRPkxKmoNFSZz3rbVV sJBAemJJanZqakFqEUxWhoNDSYLXMg6oUbAoNT21Ii0zpwQhzcTBCTKcB2i4GkgNb3FBYm5x ZjpE/hSjMcee9pe9TBwtTW97mYRY8vLzUqXEeZfHApUKgJRmlObBTYMlkVeM4kDPCfOWgwzk ASYguHmvgFYxAa2aPuMryKqSRISUVAOj6Yz9Z2NZFvFXHubieHxyz+bX6cztWXlabivaN+/m POxt8aa16ds27TsXP82dddWAP1ia2+9MhzTT629x2f7xamtOregPe/ZBfL6jEEPx/5O3wsyu 32p2ctjSlD0xZ2aPcnN19dYf06eI+BxMzzs04Z2SW9J1vr1fqtyZGixsj2/q/vxzap6vEktx RqKhFnNRcSIA40Z1nP0CAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/5SW-UgaaS5nlujOSLZQQLgZh434 Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 15:19:05 -0000 On Thu, 21 Aug 2014, Nico Williams wrote: > Sold. Let's make AD non-critical by default. I guess we'll need a separate document to make it so, though... -Ben From nobody Sun Aug 24 06:26:23 2014 Return-Path: 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 744411A8982 for ; Sun, 24 Aug 2014 06:26:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.856 X-Spam-Level: X-Spam-Status: No, score=0.856 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no 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 xhNs26Tov-pm for ; Sun, 24 Aug 2014 06:26:21 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1500C1A8981 for ; Sun, 24 Aug 2014 06:26:20 -0700 (PDT) Received: from [77.188.37.252] by 3capp-gmx-bs19.server.lan (via HTTP); Sun, 24 Aug 2014 15:26:14 +0200 MIME-Version: 1.0 Message-ID: From: D.Rogers@gmx.net To: "Jeffrey Hutzelman" Content-Type: text/html; charset=UTF-8 Date: Sun, 24 Aug 2014 15:26:14 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <1408668228.5360.46.camel@destiny.pc.cs.cmu.edu> References: <20140804161454.GH3579@localhost> , <1408668228.5360.46.camel@destiny.pc.cs.cmu.edu> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:sCUd+eVrMfKoIdz8A36/3LotEjkls/9NgH4uHfCLJ5f 7Ub/eXLZ1nS5kvwjb3pYFMVuWaVnqMxun781Qx7e5fq3zTofqo 6l9folBRVSB/Ua1+YvIu+gltNfwAKduG6qv408f58uKJc24ePB fpedEF+7kLvrQMbjwUYOj0VWaD64mWA9pXzGw6RYkP1cBBZzK5 cfINvKshwQCUzG+wqX3e7s3U3OFziUf6p2L6FRCdgvkAPSaZfP nAz0o/2DwDUqyi8liPeUwj32+O3n+MVSAqPNNxVzHYR6ZAVBqB nE223E= X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/io1kH5DPrgQ_LD6RL3yffrta_yY Cc: kitten@ietf.org, jhutz@cmu.edu Subject: Re: [kitten] Critical authorization data in Kerberos X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Aug 2014 13:26:22 -0000
Hi All,
 
sorry about the late reply. It seems to me that the discusion has moved in the right direction.
My feeling is that authentication and authorization go hand in hand, and although it is worthwhile to
efffect a level of interaction between the two, this cannot be as effective as a fully integrated
authentication/authorization system - of which we are still quite a ways off. If pursuing interaction
would encourage enquiry into integrated systems this would be a way forward, otherwise concentrate
on improvement and new developments in the authentication system.
 
Dean
Gesendet: Freitag, 22. August 2014 um 02:43 Uhr
Von: "Jeffrey Hutzelman" <jhutz@cmu.edu>
An: "Benjamin Kaduk" <kaduk@mit.edu>
Cc: kitten@ietf.org, jhutz@cmu.edu
Betreff: Re: [kitten] Critical authorization data in Kerberos
On Fri, 2014-08-15 at 14:06 -0400, Benjamin Kaduk wrote:

> I think I am also fine with (1), but (4) does present a reasonably viable
> way forward, should we decide that we're interested in having actually
> mandatory/critical authdata at some point in the future. The new
> container would contain things intended to be mandatory, with the
> understanding that much time would need to pass before consumers could
> rely on all peers actually respecting that intention.
>
> The main question in my mind, deciding between (1) and (4), is: do we
> believe that we will want to specify authdata that are treated as critical
> by application servers, ever? (What would such things look like?) From
> the commentary in Bryce's email, it is unclear that we shoul have such an
> expectation.

The more I think about this, the more I think it's unrealistic to
believe we will ever be able to rely on application servers to treat AD
as critical. Fortunately, I don't think that will actually be a
problem. Any sort of restrictive authorization data likely to be
meaningful to an application will almost certainly have to be
application-specific. The originator of such data, whether client or
KDC (or KDC administrator) will need to have some knowledge of the
service in order to construct it, and thus ought to know whether the
server is likely to be able to accept it.

That said, I can think of one class of uses for which critical AD would
be useful. Specifically, suppose a user wishes to add AD to a ticket,
informing the server that the ticket should be usable only for a limited
subset of operations, and then forward that ticket to a third party.
The difficulty arises when the ability to do this has been added to an
application, and the user does not know whether the particular server is
new enough to support the new feature. Resolving this basically
requires some negotiation mechanism within the application protocol.
But then, that's no different from what we have now.


In short, things might be a whole lot easier if we just give up on
critical AD and adopt (1), or a variation thereof. Particularly, we can
update Kerberos to explicitly state that AD is non-critical, and give
KDC's permission to omit or strip AD-IF-RELEVANT in cases where the
server is known not to require it. For example, the KDC might have a
per-service flag, or might infer this property for any service which is
known to support enctypes adopted after a particular date.

-- Jeff

_______________________________________________
Kitten mailing list
Kitten@ietf.org
https://www.ietf.org/mailman/listinfo/kitten
From nobody Thu Aug 28 09:37:12 2014 Return-Path: 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 4F14B1A87A8 for ; Thu, 28 Aug 2014 09:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_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 PkLFpcJC7qMJ for ; Thu, 28 Aug 2014 09:37:08 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 105C21A8779 for ; Thu, 28 Aug 2014 09:37:05 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s7SGb52D015051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Thu, 28 Aug 2014 12:37:05 -0400 Received: from vpn-63-189.rdu2.redhat.com (vpn-63-189.rdu2.redhat.com [10.10.63.189]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s7SGawbn030357 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 28 Aug 2014 12:37:04 -0400 Message-ID: <1409243818.9966.3.camel@redhat.com> From: Nathaniel McCallum To: kitten@ietf.org Date: Thu, 28 Aug 2014 12:36:58 -0400 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/MkTGhEiEUnH02eoYAY7oCIl-bEQ Subject: [kitten] Authentication Indicator in Kerberos tickets X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 16:37:10 -0000 I have submitted a new draft for Kerberos Authentication Indicators and I'd like to start a discussion about moving the draft through the process. I'm a newbie here, so any help would be greatly appreciated. The purpose of Authentication Indicators is to be able to assert some positive attributes about the authentication event itself in the ticket. This should also be usable in the case of S4U2Proxy. The draft can be found here: http://www.ietf.org/id/draft-jain-kitten-krb-auth-indicator-01.txt For some background information, see the MIT krb5 project page: http://k5wiki.kerberos.org/wiki/Projects/Authentication_indicator Thanks! Nathaniel McCallum From nobody Thu Aug 28 11:36:41 2014 Return-Path: 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 ADFCE1A8954 for ; Thu, 28 Aug 2014 11:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 7ZAHY3Hai9fn for ; Thu, 28 Aug 2014 11:36:38 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59DC11A8952 for ; Thu, 28 Aug 2014 11:36:36 -0700 (PDT) X-AuditID: 1209190f-f79aa6d000005b45-d8-53ff76b3b1fb Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.88.23365.3B67FF35; Thu, 28 Aug 2014 14:36:35 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id s7SIaYjg017339; Thu, 28 Aug 2014 14:36:35 -0400 Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s7SIaXKZ019383; Thu, 28 Aug 2014 14:36:34 -0400 From: Tom Yu To: Sam Hartman References: Date: Thu, 28 Aug 2014 14:36:33 -0400 In-Reply-To: (Sam Hartman's message of "Mon, 28 Jul 2014 12:23:01 -0400") Message-ID: Lines: 9 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixCmqrbu57H+wwcZpMhZf2x6wWRzdvIrF gcljyZKfTB4rp55mD2CK4rJJSc3JLEst0rdL4Mr48WIJY8E+5orZd3cyNjB+Yupi5OSQEDCR +NL8lRHCFpO4cG89WxcjF4eQwGwmid3PnzFDOBsZJY58/cgC4bxhlLh9eCsbSAubgLTE8cu7 wEaJCKhLrL40iR3EZhYQlTi37ggriC0sYCPxZvd8MFtIQFVi36PnYL0sQPb5Kb/AejkFUiV2 3mliAbF5BXQl3nyeDDaHR4BDYu+dE6wQcUGJkzOfsEDM15K48e8l0wRGgVlIUrOQpBYwMq1i lE3JrdLNTczMKU5N1i1OTszLSy3SNdHLzSzRS00p3cQIDklJ/h2M3w4qHWIU4GBU4uGdkfAv WIg1say4MvcQoyQHk5Io7/a8/8FCfEn5KZUZicUZ8UWlOanFhxglOJiVRHj3lQLleFMSK6tS i/JhUtIcLErivG+trYKFBNITS1KzU1MLUotgsjIcHEoSvHdBGgWLUtNTK9Iyc0oQ0kwcnCDD eYCG7wEbXlyQmFucmQ6RP8Woy9HS9LaXSYglLz8vVUqc9ypIkQBIUUZpHtwcWCp5xSgO9JYw 7ymQKh5gGoKb9ApoCRPQkl8df0GWlCQipKQaGL3lUu3UTj8QkJXzrLmd4dHQ9iU+qoL9QM3+ kGyLZ7vZ8hR8Beyq5HfM/Fd0W7TFhU/IQnDmhl3zROuL16Wvy7ny11CXNbkwb0nXuvdBDTph sZebPX8W6uTleD5ZcPqK7lzPqdzbXhXns57NPRocuPPyda2ZAbozssOzLn/JY3/85lPaLFFl JZbijERDLeai4kQAznI0+AADAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/DnsKLHrz38ezZJ0RkPnigMCjCao Cc: kitten@ietf.org Subject: Re: [kitten] Comments on draft-ietf-krb-wg-camac-08 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 18:36:39 -0000 Sam Hartman writes: > My recommendation is that we move the authorization data registry from > Kerberos IANA to section 6 here and remove section 5. > I feel reasonably strongly that publishing this document without either > an IETF consumer or an IANA registry is bad. I believe the recently revived draft-jain-kitten-krb-auth-indicator-01 should satisfy your "IETF consumer" requirement, if the WG adopts it.