From nobody Sun May 5 23:34:23 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C812E12008D for ; Sun, 5 May 2019 23:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 M2tKMQ0dgMmo for ; Sun, 5 May 2019 23:34:20 -0700 (PDT) Received: from eastern.maple.relay.mailchannels.net (eastern.maple.relay.mailchannels.net [23.83.214.55]) (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 70F2F120033 for ; Sun, 5 May 2019 23:34:20 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 3C1EC6A2057; Mon, 6 May 2019 06:34:19 +0000 (UTC) Received: from pdx1-sub0-mail-a49.g.dreamhost.com (100-96-79-6.trex.outbound.svc.cluster.local [100.96.79.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AF9206A16B9; Mon, 6 May 2019 06:34:18 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a49.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 06:34:19 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Celery-Stretch: 34d8fa281dc59538_1557124459052_100526955 X-MC-Loop-Signature: 1557124459052:2302781048 X-MC-Ingress-Time: 1557124459051 Received: from pdx1-sub0-mail-a49.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a49.g.dreamhost.com (Postfix) with ESMTP id 9F7FE83426; Sun, 5 May 2019 23:34:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=re0QJTc/cm6rZTFs8rkp/NH2zzM=; b=nsp4RPb7ffS /hYP7nb5c/EL9lFtL6JaNGPv9bWREH6E4jOSmcJHepTO4a2i7+kVJ22bCQsv/Rwb 5g3Qh3MNqSOr5z6zQy8dy81Lf1TNjDYRveIsX7M53HMtSKf6fzNVlsjfr96w6KS+ MB/dpgz/zB0TDaXWz6uuYFMjkoRD2BL4= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a49.g.dreamhost.com (Postfix) with ESMTPSA id AA8CF83425; Sun, 5 May 2019 23:34:11 -0700 (PDT) Date: Mon, 6 May 2019 01:34:09 -0500 X-DH-BACKEND: pdx1-sub0-mail-a49 From: Nico Williams To: kitten@ietf.org Message-ID: <20190506063408.GF21049@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigdduuddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkgggtuggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 06:34:23 -0000 See subject. I assert that: - GSS_C_MUTUAL_FLAG is badly misnamed - GSS_C_MUTUAL_FLAGis not, never was, and never could have been about mutual authentication in the sense of authenticating two peers to each other, - and GSS_C_MUTUAL_FLAGis, always was, and only could have been about key confirmation. It is understandable that "mutual authentication" had a somewhat confusing definition back when RFCs 1508, 1509, and 1510 were written (huh, notice the sequential RFC numbers...). But it's time to nail it down. First off, a high-level observation: GSS (and Kerberos) always deals in *two* principal names, so GSS and Kerberos are *always* about mutual authentication. Even if the initiator's name is some sort of anonymous name authentication can still be said to be mutual. Consider that an anonymous name's credential might still convey some authorization information. E.g., some of a user's group memberships, just not the user's name. I.e., not all anonymous identities need be the same. Indeed, for PK-based mechanisms we could use an initiator's bare public key as its name even if they are "anonymous", which makes it more "pseudonymous" than "anonymous" authentication, and still mutual. (More on this below.) Even if both names are anonymous... the same argument about pseudonymity holds. The API by its very own nature implies mutual authentication even when one or the other (or both) name can be anonymous or pseudonymous. Second, we can look at all the mechanisms we know well enough, and all the mechanisms we can posit, and see that the above assertions hold: - Mechanisms that can have just one, or just two context tokens: - Kerberos Mutual really only means key confirmation. Mutual authentication is obtained naturally in that the acceptor cannot GSS_Unwrap() (or GSS_VerifyMIC()) without having the requested target acceptor's credentials. - Solaris' mech_dh (the GSS form of the old AUTH_DH) Same as Kerberos (even though it's based on DH). Any variant that works the same way (specifically: having a directory of all initiator and acceptor names and public keys) but uses other crypto could have the same semantics. E.g., a mechanism where the initiator uses RSA key transport using an acceptor's long-term public key, and signs the encrypted session key with the initiator's long-term private key. - a GSS version of SASL PLAIN There cannot be any real mutual authentication in either sense of the term. - Mechanisms that need more than 2 context tokens: For these mechanisms there's not much value in omitting key confirmation, and it isn't wise anyways, so I would argue that they must all always have key confirmation. - SCRAM Always mutual in that one password authenticates a pair of peers. Always mutual in that key confirmation cannot be elided (per the RFC). One could construct a SCRAM-like mechanism where the last message from the acceptor can be omitted if GSS_C_MUTUAL_FLAG is not requested, but one probably shouldn't. - Some GSS-PAKE Pretty much the same analysis as SCRAM. - NTLM Pretty much the same analysis as SCRAM. - Some PKIX-based mechanism (SPKM, GSS-TLS, PKU2U) w/o directories (i.e., not like mech_dh) Some such mechanisms truly could support non-mutual authentication in that one peer needs no credentials, not even anonymous credentials. E.g., an RSA key transport mechanism needs nothing like an initiator credential. Even if EDH is used, unless one thinks of the initiator's private EDH key as a credential, there's no need to authenticate an anonymous initiator name to the acceptor. Again, key confirmation is not wise to omit. Did I miss any mechanisms? Yes: OAuth/SAML mechanisms. Any OAuth/SAML mechanism constructions that end up needing no more than 2 context tokens will look a lot like Kerberos, and could have optional key confirmation. Any OAuth/SAML mechanism constructions that end up needing more than 2 context tokens because they do DH or similar key agreement should not omit key confirmation. Thirdly and lastly, I propose the following: - That we rename the GSS and Kerberos "mutual auth" flags to denote key confirmation rather than mutual authentication. We should explain the motivation for making key confirmation optional. This is ex-post, but still, the motivation is clearly protocol optimization. Note that GSS has a second mechanism for protocol optimization: PROT_READY. This one is akin to various TLS early application data schemes. - Recommend that any mechanism that needs more than one full round trip for security context establishment SHOULD NOT ever omit key confirmation. - That we clarify that authentication is always mutual except in the case that one or the other of the initiator or acceptor names is an anonymous name with no link to any authenticate user, and that no flag can alter this. We might also want to clarify / re-think PROT_READY. We should start a separate thread to cover a case that came up recently: the desire for a way to name a target principal but not authenticate it in the sense of not require having trust anchors for authenticating it. Applications that want to use an anonymous name, should use... a GSS_C_NT_ANONYMOUS name, or use GSS_C_ANON_FLAG to request that the initiator be anonymous (more about this flag in some other thread). If a mechanism always cannot authenticate the initiator, then it is a mechanism that doesn't provide mutual authentication (and notice that key confirmation has nothing to do with it, and that no flag could make the mechanism provide mutual authentication). A mechanisms that always cannot authenticate an acceptor is probably not a very useful mechanis, so I won't think of such a thing. Comments? Nico -- From nobody Sun May 5 23:54:49 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B5D12008D for ; Sun, 5 May 2019 23:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 UukEu7V0Sjn4 for ; Sun, 5 May 2019 23:54:45 -0700 (PDT) Received: from bird.maple.relay.mailchannels.net (bird.maple.relay.mailchannels.net [23.83.214.17]) (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 392C112003E for ; Sun, 5 May 2019 23:54:44 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1C6365C4DD1; Mon, 6 May 2019 06:54:44 +0000 (UTC) Received: from pdx1-sub0-mail-a49.g.dreamhost.com (unknown [100.96.28.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CAFDE5C5153; Mon, 6 May 2019 06:54:43 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a49.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 06:54:44 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Harbor-Abiding: 77f8afc72c422f1e_1557125683913_1552231218 X-MC-Loop-Signature: 1557125683913:453305882 X-MC-Ingress-Time: 1557125683912 Received: from pdx1-sub0-mail-a49.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a49.g.dreamhost.com (Postfix) with ESMTP id 88792825C0; Sun, 5 May 2019 23:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=ltj54eDoSAKELEQoYsrlIfboeLk =; b=qg2GFbKV4+uNXnIpsDqI5JLraOvy5mgWjqHeZU31i2U3xpTeop4UrnYayxZ 3ZqNG2aZyjZUpxf5K6LDQpUcHPxB/xJBbGf7MosavmNNYtNY7djtDIvqP4uBdVqM 0y7KKmrdrONIZ9ReDHOwc9AA3C62k+StPfPorTuvTiP1NaKU= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 050348342B; Sun, 5 May 2019 23:54:42 -0700 (PDT) Date: Mon, 6 May 2019 01:54:40 -0500 X-DH-BACKEND: pdx1-sub0-mail-a49 From: Nico Williams To: kitten@ietf.org Message-ID: <20190506065439.GG21049@localhost> References: <20190506063408.GF21049@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190506063408.GF21049@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigdduudeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd Archived-At: Subject: Re: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2019 06:54:47 -0000 On Mon, May 06, 2019 at 01:34:09AM -0500, Nico Williams wrote: > Did I miss any mechanisms? Yes: OAuth/SAML mechanisms. Any OAuth/SAML > [...] Also: IAKERB. Omitting key confirmation for IAKERB is a lot like omitting it for Kerberos, even though IAKERB necessarily needs more than one round trip. Also, any multi-round trip mechanism that can use something like TLS session resumption tickets to shorten subsequence security context establishments can be like Kerberos and support omission of key confirmation. I tend to think that PROT_READY is a much more fruitful way to optimize GSS mechanisms security context establishment. It also forces one to think long and hard about the security semantics and properties of "early data". The only protocols I can imagine where a single context establishment token is desirable and useful are stateless blind logging protocols. I know of no such protocols. But even if there were any, the overhead of sending {init_context_token, wrap_token} messages all the time would surely drive the protocol designer to opt for a more stateful design so that most messages can be just {context_ID, wrap_token}. Nico -- From nobody Tue May 7 19:53:57 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9ED120073 for ; Tue, 7 May 2019 19:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sPHQVGDY8nfx for ; Tue, 7 May 2019 19:53:53 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196F4120048 for ; Tue, 7 May 2019 19:53:53 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 44zLdq30vGzKm; Wed, 8 May 2019 04:53:51 +0200 (CEST) X-purgate-ID: 152705::1557284031-00000218-365DA75B/0/0 X-purgate-size: 6177 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 44zLdq1M12zGnwF; Wed, 8 May 2019 04:53:51 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1EF31404C; Wed, 8 May 2019 04:53:51 +0200 (CEST) In-Reply-To: <20190506063408.GF21049@localhost> References: <20190506063408.GF21049@localhost> To: Nico Williams Date: Wed, 8 May 2019 04:53:51 +0200 (CEST) CC: kitten@ietf.org Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190508025351.1EF31404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 02:53:56 -0000 Nico Williams wrote: > > See subject. > > I assert that: > > - GSS_C_MUTUAL_FLAG is badly misnamed Not really. Original GSS-API implied initator towards acceptor authentication, and GSS_C_MUTUAL_FLAG was used to request acceptor towards initiator authentication. The better terminology would have been to indicate the actually desired (additional) function, rather than describing the addition of what is requested, and what has been silently implied/assumed. The difference became obvious when the "Anoymous" authentication was added in GSS-APIv2, i.e. no authentication of initiator towards acceptor. Web Browsers using TLS usually do what at the GSS-API would be the combination of (GSS_C_ANON_FLAG|GSS_C_MUTUAL_FLAG), i.e. unidirectional authentication, acceptor towards initiator. > > - GSS_C_MUTUAL_FLAGis not, never was, and never could have been about > mutual authentication in the sense of authenticating two peers to > each other, Until GSS_C_ANON_FLAG was invented, MUTUAL was an implied requirement. > > - and GSS_C_MUTUAL_FLAGis, always was, and only could have been about > key confirmation. GSS-API is about authentication of name-based entities. There is no concept of keys in GSS-API. > > It is understandable that "mutual authentication" had a somewhat > confusing definition back when RFCs 1508, 1509, and 1510 were written > (huh, notice the sequential RFC numbers...). But it's time to nail it > down. > > First off, a high-level observation: GSS (and Kerberos) always deals in > *two* principal names, so GSS and Kerberos are *always* about mutual > authentication. Nope. Kerberos has always been about unidirectional authentication, and most of the time, MUTUAL is still unidirectional. Performing server name canonicalization through insecure DNS has been insecure and a well-known bad idea in 1996. You may want to check what Microsoft does 23 years later when encountering DNS CNAME records for rfc4559 SPNEGO authentication... (spoiler: insecure server name canonicalization through DNS) Essentially, Kerberos 5 never provided mutual authentication in the past, and you probably should not hold your breath until it happens. > > - SCRAM > > Always mutual in that one password authenticates a pair of peers. > > Always mutual in that key confirmation cannot be elided (per the > RFC). > > One could construct a SCRAM-like mechanism where the last message > from the acceptor can be omitted if GSS_C_MUTUAL_FLAG is not > requested, but one probably shouldn't. > > - Some GSS-PAKE > > Pretty much the same analysis as SCRAM. > > - NTLM > > Pretty much the same analysis as SCRAM. Definite *NO* for NTLM. NTLM is unidirectional initiator to target, and susceptible to man-in-the-middle. This was obvious in 1995, and causes some amount of headaches earlier this year. https://www.theregister.co.uk/2019/01/25/microsoft_exchange_domain_admin_eop/ > > - Some PKIX-based mechanism (SPKM, GSS-TLS, PKU2U) w/o directories > (i.e., not like mech_dh) I know PKIX-based mechanisms that perform mutual properly. But for convenience, some of them contain various tweaks/cheats to perform just uni-directional authentication. > > Some such mechanisms truly could support non-mutual authentication > in that one peer needs no credentials, not even anonymous > credentials. E.g., an RSA key transport mechanism needs nothing > like an initiator credential. Even if EDH is used, unless one > thinks of the initiator's private EDH key as a credential, there's > no need to authenticate an anonymous initiator name to the > acceptor. > > Again, key confirmation is not wise to omit. Security guarantees of GSS-API apply only to application data that has been protected by the GSS-API message protection primitives. If someome abuses the GSS-API context token exchange for an OTP-scheme, and then transfers application data without GSS-API message protection, that's spoiling between most and all of the security (again, rfc4559 HTTP Negotiate comes to mind). > > We should start a separate thread to cover a case that came up recently: > the desire for a way to name a target principal but not authenticate it > in the sense of not require having trust anchors for authenticating it. which is almost what Kerberos has been doing for the past 30 years thanks to canonicalizing service names through insecure DNS... > > Applications that want to use an anonymous name, should use... a > GSS_C_NT_ANONYMOUS name, or use GSS_C_ANON_FLAG to request that the > initiator be anonymous (more about this flag in some other thread). The "Applications that want to use an anonymous name," above sort of implies that the entire information conveyed must be public and free. Or were you also considering "pseudonymous", which GSS-API currently does not address, such as a "one from a certain group", such as an "unnamed paying customer". > > If a mechanism always cannot authenticate the initiator, then it is a > mechanism that doesn't provide mutual authentication (and notice that > key confirmation has nothing to do with it, and that no flag could make > the mechanism provide mutual authentication). > > A mechanisms that always cannot authenticate an acceptor is probably not > a very useful mechanis, so I won't think of such a thing. these things are called "Web Browsers". I'm not sure the folks from CABforum share your view. Have you noticed how poorly some browsers work with TLS client certificates? Almost indistinguishable from malice. Like "Enrollment"? Ever tried to make your Google Chrome automatically select a TLS client cert for accessing a Web Server that wants TLS client certs? Maybe not exactly "Beware of the leopard"-style, but sufficiently close. (stuff from Apple Inc. and TLS client certs? even worse). -Martin From nobody Wed May 8 13:19:10 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 632771200B5 for ; Wed, 8 May 2019 13:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 Cc_ekcFt9Q8H for ; Wed, 8 May 2019 13:19:06 -0700 (PDT) Received: from ostrich.birch.relay.mailchannels.net (ostrich.birch.relay.mailchannels.net [23.83.209.138]) (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 3898B120026 for ; Wed, 8 May 2019 13:19:06 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 637DA1406D3; Wed, 8 May 2019 20:19:05 +0000 (UTC) Received: from pdx1-sub0-mail-a9.g.dreamhost.com (100-96-78-10.trex.outbound.svc.cluster.local [100.96.78.10]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id D50E914067F; Wed, 8 May 2019 20:19:04 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a9.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Wed, 08 May 2019 20:19:05 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Scare-Blushing: 49dab264152422b2_1557346745226_1708140854 X-MC-Loop-Signature: 1557346745225:4235032393 X-MC-Ingress-Time: 1557346745225 Received: from pdx1-sub0-mail-a9.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTP id 315BC7FCB3; Wed, 8 May 2019 13:19:00 -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=dWJ9v36Ae48dnX NBrwGNLXUGZaI=; b=U8MmQwrEfnNWTQ4jLhmTvB55q+oyMA3CDTQ+Qt39SBZrA0 QfQfMGEoT9QALvT+80GlslEo0+UXLv0Mn/MPMZHBCRNlJHC4n2+71BgepUjSouQT +1QESYoRqnnlQliVBIruDrFrHcz+EJmVAxqWkUoMWheCeH0YUFno4CwdxG+zY= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a9.g.dreamhost.com (Postfix) with ESMTPSA id 2C2A37FCB0; Wed, 8 May 2019 13:18:58 -0700 (PDT) Date: Wed, 8 May 2019 15:18:56 -0500 X-DH-BACKEND: pdx1-sub0-mail-a9 From: Nico Williams To: Martin Rex Cc: kitten@ietf.org Message-ID: <20190508201855.GX21049@localhost> References: <20190506063408.GF21049@localhost> <20190508025351.1EF31404C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190508025351.1EF31404C@ld9781.wdf.sap.corp> User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: -100 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrkeefgddugeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepvdegrddvkedruddtkedrudekfeenucfrrghrrghmpehmohguvgepshhmthhppdhhvghloheplhhotggrlhhhohhsthdpihhnvghtpedvgedrvdekrddutdekrddukeefpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: Re: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2019 20:19:09 -0000 On Wed, May 08, 2019 at 04:53:51AM +0200, Martin Rex wrote: > Nico Williams wrote: > > I assert that: > > > > - GSS_C_MUTUAL_FLAG is badly misnamed > > Not really. > > Original GSS-API implied initator towards acceptor authentication, > and GSS_C_MUTUAL_FLAG was used to request acceptor towards initiator > authentication. I believe that conflates "mutual" with key confirmation. Assuming the cryptosystems are secure, an exchange of this form: I->A: init sec context token w/o "mutual" (AP-REQ) I->A: wrap token w/ confidentiality keeps the plaintext confidential even if the recipient is not the intended acceptor. Kerberos ensures that only the intended acceptor can unwrap that token. Moreover, in an exchange like this I->A: init sec context token w/o "mutual" (AP-REQ) A->I: sec context token (AP-REP) I->A: wrap token w/ confidentiality there is no assurance that there is not a party on-path that can observe the ciphertext of these tokens. Thus the only thing GSS_C_MUTUAL_FLAG can do in the case of Kerberos is provide key confirmation and, in RFC4121, a new sub-session key. In both cases there are *two* principal names, and they are cryptographically bound by the init sec context token alone. Moreover, the GSS-API always has two principal names involved in every security context. I suppose you could argue it's "up to two names", but I wouldn't agree. First, the initiator's credential (default or not) supplies one name (the initiator's) to GSS_Init_sec_context(). Second, GSS_Init_sec_context() requires a target_name (the acceptor's). Even if the initiator wishes to be anonymous, it still has a NAME as indicated by GSS_Inquire_context() -- that name will be of GSS_C_NT_ANONYMOUS type, indeed, but it will be a NAME. > The better terminology would have been to indicate the actually desired > (additional) function, rather than describing the addition of what is > requested, and what has been silently implied/assumed. If I understand this, you might actually be agreeing with me. But I probably didn't understand it. What alternative terminology would you propose? > The difference became obvious when the "Anoymous" authentication was > added in GSS-APIv2, i.e. no authentication of initiator towards acceptor. Has this been implemented by any mechanisms? (Kerberos is the only Internet mechanism that has this specified, but it's not yet been implemented, much less as specified.) A better design would have been to have the initiator application supply GSS_Inquire_context() with an input_cred_handle for a GSS_C_NT_ANONYMOUS desired_name. No flag should have been needed or specified. > Web Browsers using TLS usually do what at the GSS-API would be the > combination of (GSS_C_ANON_FLAG|GSS_C_MUTUAL_FLAG), i.e. > unidirectional authentication, acceptor towards initiator. This would seem like a contradiction in terms. Unless you take GSS_C_MUTUAL_FLAG to be about key confirmation, which is not optional in TLS, and so we're down to just GSS_C_ANON_FLAG (about which see above). > > - and GSS_C_MUTUAL_FLAGis, always was, and only could have been about > > key confirmation. > > GSS-API is about authentication of name-based entities. > There is no concept of keys in GSS-API. Key confirmation is a term of art referring to an aspect of the chosen mechanism's context token protocol. "Key confirmation" is certainly not about exposing keys to applications. But certainly, too, the existence of cryptographic keys is strongly implied by the GSS-API, at least assuming classical cryptography (and we can't assume quantum cryptography because while there are quantum key exchange systems, there are no quantum authentication systems). > > It is understandable that "mutual authentication" had a somewhat > > confusing definition back when RFCs 1508, 1509, and 1510 were written > > (huh, notice the sequential RFC numbers...). But it's time to nail it > > down. > > > > First off, a high-level observation: GSS (and Kerberos) always deals in > > *two* principal names, so GSS and Kerberos are *always* about mutual > > authentication. > > Nope. Kerberos has always been about unidirectional authentication, > and most of the time, MUTUAL is still unidirectional. I strongly disagree as explained above. > Performing server name canonicalization through insecure DNS > has been insecure and a well-known bad idea in 1996. I'd rather not distract this thread with that issue. Nico -- From nobody Wed May 8 20:40:50 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 559591201DA for ; Wed, 8 May 2019 20:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 AG8bLt53DYwI for ; Wed, 8 May 2019 20:40:45 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED92F120103 for ; Wed, 8 May 2019 20:40:44 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 44zzdQ6ctFz31; Thu, 9 May 2019 05:40:42 +0200 (CEST) X-purgate-ID: 152705::1557373242-0000020D-63E306F1/0/0 X-purgate-size: 6845 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail07.wdf.sap.corp (Postfix) with ESMTPS id 44zzdQ4vWTzGp2v; Thu, 9 May 2019 05:40:42 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 997D3404C; Thu, 9 May 2019 05:40:42 +0200 (CEST) In-Reply-To: <20190508201855.GX21049@localhost> References: <20190506063408.GF21049@localhost> <20190508025351.1EF31404C@ld9781.wdf.sap.corp> <20190508201855.GX21049@localhost> To: Nico Williams Date: Thu, 9 May 2019 05:40:42 +0200 (CEST) CC: Martin Rex , kitten@ietf.org Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20190509034042.997D3404C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2019 03:40:49 -0000 Nico Williams wrote: > On Wed, May 08, 2019 at 04:53:51AM +0200, Martin Rex wrote: >> Nico Williams wrote: >>> I assert that: >>> >>> - GSS_C_MUTUAL_FLAG is badly misnamed >> >> Not really. >> >> Original GSS-API implied initator towards acceptor authentication, >> and GSS_C_MUTUAL_FLAG was used to request acceptor towards initiator >> authentication. > > I believe that conflates "mutual" with key confirmation. Again, there is *NO* concept of keys in GSS-API, and adding this is a bad idea. You can do that within a particular gssapi mechanism, if you want to, but that is an implementation detail of a mechanism. > > Assuming the cryptosystems are secure, an exchange of this form: > > I->A: init sec context token w/o "mutual" (AP-REQ) > I->A: wrap token w/ confidentiality > > keeps the plaintext confidential even if the recipient is not the > intended acceptor. > > Kerberos ensures that only the intended acceptor can unwrap that token. plus the trusted third party (the Kerberos KDC) I'm just wondering about the MitM-unsafe GSS-API mechanism like Microsoft NTLM, because there is no "target name" parameter, and no binding to any target. Every MitM attacker with access to a domain member PC should be able to unwrap the tokens. So the "Seal" security level for RPC when negotiate drops to NTLM is potentially not quite what one expects. > > Moreover, in an exchange like this > > I->A: init sec context token w/o "mutual" (AP-REQ) > A->I: sec context token (AP-REP) > I->A: wrap token w/ confidentiality > > there is no assurance that there is not a party on-path that can observe > the ciphertext of these tokens. > > Thus the only thing GSS_C_MUTUAL_FLAG can do in the case of Kerberos is > provide key confirmation and, in RFC4121, a new sub-session key. Frankly, I don't know and I don't care what you mean by key confirmation. At the GSS-API level the term "key confirmation" has *NO* meaning. What is done within a gss-api mechanism, is irrelevant here. > > In both cases there are *two* principal names, and they are > cryptographically bound by the init sec context token alone. "by the init sec context token alone" -- sorry that is non-sensical. There can be any number of context-level tokens, and which context level token is bound to which particular name, is entirely mechanism specific. In particular, if the initiator happens to connect with a different entity that what it wanted to talk to, the token will be bound to some other name. Technically, GSS-API mechanisms may use a completely different approach, and start trying to perform mutual authentication of unspecified names, and when authentication succeeds, perform discovery of the names involved in the authentication, and match the result up with expectations. Even Kerberos knows such a scheme. It is called user2user authentication. It's not described in rfc1964/rfc4121, but Microsoft implemented it. > > Moreover, the GSS-API always has two principal names involved in every > security context. I suppose you could argue it's "up to two names", but > I wouldn't agree. First, the initiator's credential (default or not) > supplies one name (the initiator's) to GSS_Init_sec_context(). Second, > GSS_Init_sec_context() requires a target_name (the acceptor's). Even if > the initiator wishes to be anonymous, it still has a NAME as indicated > by GSS_Inquire_context() -- that name will be of GSS_C_NT_ANONYMOUS > type, indeed, but it will be a NAME. > > > The better terminology would have been to indicate the actually desired > > (additional) function, rather than describing the addition of what is > > requested, and what has been silently implied/assumed. > > If I understand this, you might actually be agreeing with me. But I > probably didn't understand it. What alternative terminology would you > propose? > > > The difference became obvious when the "Anoymous" authentication was > > added in GSS-APIv2, i.e. no authentication of initiator towards acceptor. > > Has this been implemented by any mechanisms? I'm pretty sure it has been implemented. I've seen a (proprietary) GSS-API mechanism wrapping TLS records in to GSS-API tokens about 18 years ago. We also have one (but its cheating on the flags at the API because that was easier for drop-in into installed base). The application on top recognizes when this happens, and drops back to traditional user&password authentication for initiator towards acceptor authentication. > > A better design would have been to have the initiator application supply > GSS_Inquire_context() with an input_cred_handle for a GSS_C_NT_ANONYMOUS > desired_name. No flag should have been needed or specified. This statement has at least two typos/confusions. > > > Web Browsers using TLS usually do what at the GSS-API would be the > > combination of (GSS_C_ANON_FLAG|GSS_C_MUTUAL_FLAG), i.e. > > unidirectional authentication, acceptor towards initiator. > > This would seem like a contradiction in terms. Unless you take > GSS_C_MUTUAL_FLAG to be about key confirmation, which is not optional in > TLS, and so we're down to just GSS_C_ANON_FLAG (about which see above). Nope. It says "mutual authentication minus initiator towards acceptor authentication". That like asking for a "virgin Cuba libre" (a Coke). > > > > - and GSS_C_MUTUAL_FLAGis, always was, and only could have been about > > > key confirmation. > > > > GSS-API is about authentication of name-based entities. > > There is no concept of keys in GSS-API. > > Key confirmation is a term of art referring to an aspect of the chosen > mechanism's context token protocol. "Key confirmation" is certainly not > about exposing keys to applications. > > But certainly, too, the existence of cryptographic keys is strongly > implied by the GSS-API, at least assuming classical cryptography (and we > can't assume quantum cryptography because while there are quantum key > exchange systems, there are no quantum authentication systems). No, GSS-API does *NOT* have this implication _at_all_. Making this implication at the GSS-API level, rather than at the level of a specific mechanism, is a terribly bad idea. You're using a whole dimension of what GSS-API can be. conceptually, there do not need to be any crypto inside the context level tokens at all (could all be out-of-band, potentially limiting the environment where such a gssapi mechanism can be used). However, I currently don't see how to provide the message protection services (integrity protection and confidentiality protection) without crypto in the per-message tokens. -Martin From nobody Wed May 15 11:57:14 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09DEA120780 for ; Wed, 15 May 2019 11:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wUcGrkWaCtIZ for ; Wed, 15 May 2019 11:57:11 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF51612078E for ; Wed, 15 May 2019 11:57:04 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D8274C04BD48; Wed, 15 May 2019 18:57:03 +0000 (UTC) Received: from localhost (dhcp-10-20-1-19.bss.redhat.com [10.20.1.19]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8EEBC1001DEF; Wed, 15 May 2019 18:57:03 +0000 (UTC) From: Robbie Harwood To: Nico Williams , kitten@ietf.org In-Reply-To: <20190506063408.GF21049@localhost> References: <20190506063408.GF21049@localhost> Date: Wed, 15 May 2019 14:57:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 15 May 2019 18:57:04 +0000 (UTC) Archived-At: Subject: Re: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2019 18:57:13 -0000 --=-=-= Content-Type: text/plain Nico Williams writes: > See subject. > > I assert that: > > - GSS_C_MUTUAL_FLAG is badly misnamed > > - GSS_C_MUTUAL_FLAGis not, never was, and never could have been about > mutual authentication in the sense of authenticating two peers to > each other, > > - and GSS_C_MUTUAL_FLAGis, always was, and only could have been about > key confirmation. > > It is understandable that "mutual authentication" had a somewhat > confusing definition back when RFCs 1508, 1509, and 1510 were written > (huh, notice the sequential RFC numbers...). But it's time to nail it > down. > > First off, a high-level observation: GSS (and Kerberos) always deals > in *two* principal names, so GSS and Kerberos are *always* about > mutual authentication. > > The API by its very own nature implies mutual authentication even when > one or the other (or both) name can be anonymous or pseudonymous. > > Second, we can look at all the mechanisms we know well enough, and all > the mechanisms we can posit, and see that the above assertions hold: > > - Mechanisms that can have just one, or just two context tokens: > > - Kerberos > > Mutual really only means key confirmation. > > Mutual authentication is obtained naturally in that the acceptor > cannot GSS_Unwrap() (or GSS_VerifyMIC()) without having the > requested target acceptor's credentials. This is true assuming it *does* call those functions. Authentication-only use is not only possible but (unfortunately, in my view) quite common: HTTP Negotiate, or GSSAPI auth in ssh, etc.. In those cases, without mutual authentication, any authentication of (for example) the HTTP server to the client must happen at another point (from the TLS channel in HTTPS). Of course, operating with mutual authentication along an untrusted channel won't buy you much since it's not tamper-proof. However, it does help against passive observers when opportuniustic (untrusted) encryption is used (as well as TOFU schemes). I realize this is a bit in the weeds and possibly not practically relevant, but this is a conversation about definitions, so... Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlzcYQcACgkQJTL5F2qV pEKG5Q/9HeourhM9GgncYIguFetrTHKK4p8vOjD7uObH7lfuzRE1MX0aEHuwERWw OGp6tqtPQH/vXINehiiLiQJ2Of/RJHI6F6Qx2na3353rN3hlYSG4ZWpqgnr/2mEN MKfrqAeTZ25qq/iKiv7tk6LX88fwzTcnIb0imtR2p+iImg8n9c/S8P6h5cdIJs/H 5eezA6BsP5+hITVG8cmp2Dw8hZWb6MUvS96oTWkQug4KE3cs7RJufybQ9D+wFfwr yL1MAm8YMsmkIk5dLpdFec1+xPM+F1IWs+sukyT1xyLohYhjsY9S0iY9r3a+TOfX 21PNPhIkXaBw5tHjYQroN7Mc9Zt6XYMJcrmQb7y2o5zb+FnpRLn+U3faTC0JTl14 zSWpT66fc/POXPkD2bmyKmUV/kldPmOF4YzrjDkxAPc5P9yoRPZHAqz3qtEcJY7s qkdHphis/3rWiLykSLwpiOpjf8M1z7oXl9L2iiipp0+bYINfLcCaQMHI9AtgF7ay UadpfQQ/p+33EX1GspHcrze9/1mZiNHHAq+TSwWwW0NQKquWsAh08mAh7twRkaXv PX1kxQI+EDXSFS8ttCsuVPhY/tHo7d9gv2z+5I9OJp5OdQqbOOHAi/xVGrF3IE1e aIO6MX8pafJTrLO7HRR+m+ETMA7FB/EGYE2cdiGn7oTCvqnhJ8I= =RDYQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu May 23 11:44:03 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5AA12008B for ; Thu, 23 May 2019 11:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com 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 9f88zkIoJ1pY for ; Thu, 23 May 2019 11:44:00 -0700 (PDT) Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.93]) (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 D5068120043 for ; Thu, 23 May 2019 11:43:59 -0700 (PDT) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C8DC6502763; Thu, 23 May 2019 18:43:58 +0000 (UTC) Received: from pdx1-sub0-mail-a87.g.dreamhost.com (100-96-38-7.trex.outbound.svc.cluster.local [100.96.38.7]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 799EA502589; Thu, 23 May 2019 18:43:58 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a87.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Thu, 23 May 2019 18:43:58 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Snatch-Glossy: 18c0ce7b3fbb4d8c_1558637038645_850517841 X-MC-Loop-Signature: 1558637038645:2974765295 X-MC-Ingress-Time: 1558637038644 Received: from pdx1-sub0-mail-a87.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a87.g.dreamhost.com (Postfix) with ESMTP id C591E7F8A2; Thu, 23 May 2019 11:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:mime-version:content-type; s= cryptonector.com; bh=QxNydUvWu2xJ96QjgAZFl4Gg2Ws=; b=EKWwQkfxbec 0kHNogpk3mqDSJ8eE+PqTlPQqYk25OdA0Xth8wr5WFiFrqqK6erQ9RPoG19rACPr n5r1K3Bgw1TtDN33jpVl3dTwNhXv10OdMUysg4yUtrSuLs1JWWecGbbDxuealQct suiW3QRZzZkgKcXZn3UTa5JvRL+bU0gg= Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a87.g.dreamhost.com (Postfix) with ESMTPSA id 42F667F8A1; Thu, 23 May 2019 11:43:56 -0700 (PDT) Date: Thu, 23 May 2019 13:38:31 -0500 X-DH-BACKEND: pdx1-sub0-mail-a87 From: Nico Williams To: kitten@ietf.org Message-ID: <20190523183830.GA12921@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) X-VR-OUT-STATUS: OK X-VR-OUT-SCORE: 0 X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddruddugedgudefudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucggtfgfnhhsuhgsshgtrhhisggvpdfftffgtefojffquffvnecuuegrihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfggtggufgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucfkphepkedrvddruddthedrudejnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepkedrvddruddthedrudejpdhrvghtuhhrnhdqphgrthhhpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqpdhmrghilhhfrhhomhepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhdpnhhrtghpthhtohepnhhitghosegtrhihphhtohhnvggtthhorhdrtghomhenucevlhhushhtvghrufhiiigvpedt Archived-At: Subject: [kitten] RFC5896 incorrectly listed as updating only RFC4120 -- also updates RFCs 2743, 2744, and 4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2019 18:44:02 -0000 How to fix this? Nico -- From nobody Fri May 24 13:17:59 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF51120355 for ; Fri, 24 May 2019 13:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 XZQgxsnNZgti for ; Fri, 24 May 2019 13:17:55 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BD212004C for ; Fri, 24 May 2019 13:17:55 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 929533082E0F; Fri, 24 May 2019 20:17:54 +0000 (UTC) Received: from localhost (dhcp-10-20-1-15.bss.redhat.com [10.20.1.15]) by smtp.corp.redhat.com (Postfix) with ESMTP id 575CB68B07; Fri, 24 May 2019 20:17:54 +0000 (UTC) From: Robbie Harwood To: Nico Williams , kitten@ietf.org In-Reply-To: <20190523183830.GA12921@localhost> References: <20190523183830.GA12921@localhost> Date: Fri, 24 May 2019 16:18:07 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.46]); Fri, 24 May 2019 20:17:54 +0000 (UTC) Archived-At: Subject: Re: [kitten] RFC5896 incorrectly listed as updating only RFC4120 -- also updates RFCs 2743, 2744, and 4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2019 20:17:57 -0000 --=-=-= Content-Type: text/plain Nico Williams writes: > How to fix this? Would this be covered under errata? https://www.rfc-editor.org/errata.php#reportnew Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAlzoUX8ACgkQJTL5F2qV pEK4QRAAxwcYdaMRt1TNra8473XugLVZpS1WuWvHAYoAa1qUVBZiez9IU7M/4xif ST58+wS9Rr3X5Bu8BFWvuj5beiZIYPODJ7Oi+ypjTsqTXRTeISQDEyhhv2mxRzZc L2/g/stXW51CAzEgvHSNB+rITrF0B0NrozZLoa5F5PXusxhoZQFYyd1kNlq7jVaj ZRhANuKKdZjyPBbNk62LuiKDw5Bp0lAnBLRYGHSMIdMacS5SortrBCaG30g1Fd1A VyoL0WWtcwHU82Fl4mNmY+gCN7NRvU3J9n+w00aakGGDqoch9PErBAg86b5QwhVZ IfMWHJwnC0ElwpKhZPkygpMvHoKGGljaPleg9wZsW0mSuzYxMiSBccJGLFC5Lw3M 4xRd9IrAvkmJ4PA8NwHFTinXj8BIip92sSAL0sPQW9d8ibvYFj/QFZJwtrWu4zGi jFonwiV009TueT89nGinOsR7MupQbevK02nndG8JDJJI3KK89tdEX/9dleQoXKcL NJXcFH0ENmUOyZLRb2UPtNkr2HkrOQtbGt8HHJZozU4OwEx6b/a+y1NSAjLQ6CnV g/I+s5LJ5gkqK7rcJqMNrk7gu48qoWDSSAgRQrWpjI+7CubWPxNr2MsrL8xZDOUL v3tt+K27NjI8HeWLcQoFVD6NLRaPAnkVzCRU+L8y7gPL05/Sfag= =Xy8X -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri May 24 20:36:07 2019 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F06AA120103 for ; Fri, 24 May 2019 20:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 scOX1hth47xB for ; Fri, 24 May 2019 20:36:02 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E3AA12018B for ; Fri, 24 May 2019 20:36:00 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id w1so10315450ljw.0 for ; Fri, 24 May 2019 20:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=isRMRMjDaVlsj1tnn8qspIAkOfZhQMWHrGneudi2gGA=; b=AQKLyY2UgS1r8kmGp5SVR0KIM0ovck5ap6z7Zv3Odt2+CDnHD+EMKFOgCc8ayYJwou niPZgXTRKYmnPE2C4QQjFmvpW5RCrFp1HYmQlGOcPf3axFziVK+SaPjBY78Mnb98B1zs iXf9/nZo6XrWfwLAe00XbrMurfOg+/jnamgixCC3/D5vSEb9ELCt1aVnkDPLNsdo62nH nEzAwE6eqvbBsuYKjktWzKrCOPBRneTHPh14FzfqBOfKEciN5afxjZvIQWPKro/Y03rp LJ3Fe9p0sFOYquF2dcNzrrR/5y9QRVJW7WKkr5QVYrFZY5p3bQJMjzVT0TJArg/ggsDu phBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=isRMRMjDaVlsj1tnn8qspIAkOfZhQMWHrGneudi2gGA=; b=MKzQ0ZGIo7SNKiyFAlBi8aeTk2zXVw+b3yR6VWTnNN0JktoNmTlHJLoiqCDSSYhOat knDAkVobGI4ta3isHXsoZH73QvK4MVZHAathvBffr8SGbcEIMr5FSt7KVE5yS2JHTilP nAEXOEN7mPPXg79ieXQEL1Gho15xW+BF5wSWQvzd5oNR10Cs21m3MHCD1pXGsDKlxPCb M3mC6UeMlKNmKFBCW1iumzcVUlAwC3G7vdkerde+2r4Spy7ff4ikLgTPRt/EmoHjw+Hu 4ILPOA4gh3S0D+eKnJItk7sLsPphXUBhVwGs5AK0LjlyRgbNyi+O1jMgdo8fpJ8mHKyY WWBQ== X-Gm-Message-State: APjAAAUyu/6UaNPQUrxieT/PTQsQp6JaEUCxlZhF1FghKGkgbSbwP4TH 7uzF7EUX6TGMlyEE9i7+DXv8vpMm0z8apr8ED+0= X-Google-Smtp-Source: APXvYqzWEeXXXqe/23r4FZxl4YmqKSXyyXLz7rzWmBB03kK4EMiX8GyYqLJ/Z9i9AMTCZYE4OMkRJIFNg1syw3uwAqM= X-Received: by 2002:a2e:8954:: with SMTP id b20mr8819741ljk.10.1558755358627; Fri, 24 May 2019 20:35:58 -0700 (PDT) MIME-Version: 1.0 References: <20190523183830.GA12921@localhost> In-Reply-To: From: Shawn Emery Date: Fri, 24 May 2019 21:35:47 -0600 Message-ID: To: Robbie Harwood Cc: Nico Williams , kitten@ietf.org Content-Type: multipart/alternative; boundary="000000000000715b130589ae03fd" Archived-At: Subject: Re: [kitten] RFC5896 incorrectly listed as updating only RFC4120 -- also updates RFCs 2743, 2744, and 4121 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2019 03:36:05 -0000 --000000000000715b130589ae03fd Content-Type: text/plain; charset="UTF-8" That would be my inclination, given that it does not affect implementation or deployment. Erratum could be made and then placed in a Hold for Document Update state. Shawn. -- On Fri, May 24, 2019 at 2:18 PM Robbie Harwood wrote: > Nico Williams writes: > > > How to fix this? > > Would this be covered under errata? > https://www.rfc-editor.org/errata.php#reportnew > > Thanks, > --Robbie > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > --000000000000715b130589ae03fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

That would be my inclination, given that it= does not affect implementation or deployment.=C2=A0 Erratum could be made = and then placed in a Hold for Document Update state.=C2=A0

Shawn.
--

On Fri, May 24, 2019 at 2:18 PM Robb= ie Harwood <rha= rwood@redhat.com> wrote:
Nico Williams <nico@cryptonector.com> writes:

> How to fix this?

Would this be covered under errata?
https://www.rfc-editor.org/errata.php#reportnew
Thanks,
--Robbie
_______________________________________________
Kitten mailing list
Kitten@ietf.org https://www.ietf.org/mailman/listinfo/kitten
--000000000000715b130589ae03fd-- From nobody Mon May 27 07:24:39 2019 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC17120004; Mon, 27 May 2019 07:24:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , kitten-chairs@ietf.org, Robbie Harwood , rharwood@redhat.com, kitten@ietf.org, kaduk@mit.edu, draft-ietf-kitten-pkinit-alg-agility@ietf.org, rfc-editor@rfc-editor.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155896707056.809.3019849952675149172.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2019 07:24:30 -0700 Archived-At: Subject: [kitten] Protocol Action: 'PKINIT Algorithm Agility' to Proposed Standard (draft-ietf-kitten-pkinit-alg-agility-08.txt) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2019 14:24:31 -0000 The IESG has approved the following document: - 'PKINIT Algorithm Agility' (draft-ietf-kitten-pkinit-alg-agility-08.txt) as Proposed Standard This document is the product of the Common Authentication Technology Next Generation Working Group. The IESG contact persons are Benjamin Kaduk and Roman Danyliw. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/ Technical Summary This document specifies an updated Public Key Cryptography for Initial Authentication in Kerberos (PKINIT, rfc4556) which is not dependent on SHA-1. In particular, it describes negotiation for Key Derivation Functions, and includes test vectors for these schemes. This is a Standards Track document since its core goal is to update PKINIT, which is a standard part of Kerberos implementations. Accordingly, it updates rfc4556 (PKINIT), which is Standards Track. Working Group Summary This document has been around for quite a long time, originally part of krb-wg before being taken up by kitten in the re-charter. Implementations have existed in both MIT krb5 and Heimdal since 2011 and 2008, respectively. Most shaping review happened under krb-wg, but those contributors are also participants in kitten. This document received review and/or implementation from a significant number of working group contributors. In an ideal world it would have been published much sooner, but has been repeatedly deprioritized in favor of other work. Document Quality There are two independent implementations that interoperate and validate the test vectors. Personnel Robbie Harwood is the document shepherd. Benjamin Kaduk is the responsible Area Director.