From nobody Sun Nov 5 07:32:32 2017 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 2CB5613FBA5 for ; Sun, 5 Nov 2017 07:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.219 X-Spam-Level: X-Spam-Status: No, score=-1.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 ZhxA-bKTUuOI for ; Sun, 5 Nov 2017 07:32:29 -0800 (PST) Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (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 2B3C313FB7F for ; Sun, 5 Nov 2017 07:32:29 -0800 (PST) Received: by mail-wm0-f51.google.com with SMTP id r68so6611230wmr.0 for ; Sun, 05 Nov 2017 07:32:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=kImTjdX+7Wr5OEmad9MwQSM3KbBomogWT9sx2nzDk68=; b=VVFCx1vFFXH2SzejbztD1xcvYU+QvOC3LY+0ndRpJsX0dAhev6yEgCLbgu+9dcx4hS NIQjXMD3R6PotPsUDFB0GT8KIwTh5C5SGSlKztXpCn5TnqpH3IGZ7XcGEyFdyY/uB9Rs vjZ4aFigM8TNAkqLbeyNAoVVt11FlowbtD2qbQXdmdpU7ti7ad2MKPUPXNbCn6HfM2Gx ZWV/EzVYtGGAWW4ihe825u5VHPDnQb6a9jhaXq9ISgSbIfQH/eJug4iQYRGEnUgDLFzH nVmaGIH/wzKmu1kzQkpxW/igT1ToARhfbC5hbAJjLIayfwAnld8C257ymYvPec+tC4Wa iw2Q== X-Gm-Message-State: AMCzsaVlBLcTtYayQi8CzgQF7WDcLGhsjiVVe3V2mgJn6/D27bVvPWth to528MaceSf2X7loEq+mx9k= X-Google-Smtp-Source: ABhQp+RNhWmBnhZDnp3zMAwpKASvq1iwd7PQXB3De4UaqgrYnfL85vKF2mzy/zc6ZfCp+jwp19qJeQ== X-Received: by 10.80.164.24 with SMTP id u24mr16232196edb.11.1509895947311; Sun, 05 Nov 2017 07:32:27 -0800 (PST) Received: from ?IPv6:2001:a62:11ea:101:adb1:1e2b:c5cc:a70c? ([2001:a62:11ea:101:adb1:1e2b:c5cc:a70c]) by smtp.googlemail.com with ESMTPSA id 41sm9384292edz.66.2017.11.05.07.32.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Nov 2017 07:32:26 -0800 (PST) To: kitten@ietf.org Cc: Simo Sorce References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> <1508245337.6230.31.camel@redhat.com> From: Florian Schmaus Message-ID: <1fc6c84a-94b7-15d2-5311-20a64e8b63a8@geekplace.eu> Date: Sun, 5 Nov 2017 16:32:24 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <1508245337.6230.31.camel@redhat.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9PHQkdotubTprQWNBT4hLBnA6D92R37p9" Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Nov 2017 15:32:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9PHQkdotubTprQWNBT4hLBnA6D92R37p9 Content-Type: multipart/mixed; boundary="iqcqx286efkS4qfTdpp6dTMcTX214rga7"; protected-headers="v1" From: Florian Schmaus To: kitten@ietf.org Cc: Simo Sorce Message-ID: <1fc6c84a-94b7-15d2-5311-20a64e8b63a8@geekplace.eu> Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> <20171016025117.GL96685@kduck.kaduk.org> <1508245337.6230.31.camel@redhat.com> In-Reply-To: <1508245337.6230.31.camel@redhat.com> --iqcqx286efkS4qfTdpp6dTMcTX214rga7 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17.10.2017 15:02, Simo Sorce wrote: > I think this draft has many goals in common with this one: > https://tools.ietf.org/html/draft-wibrown-ldapssotoken-02 >=20 > I wonder if we can end up having a solution that will work well to > cover it all ? >=20 > The main issue here would be the requirement to bind it to TLS as LDAP > (as well as other connection-oriented protocols) can use other means to= > encrypt the channel (namely GSSAPI, although GSSAPI doe not have a > session resumption mechanism ...). I had a look at ldapssotoken. Although I have worked with LDAP in the past, I wouldn't consider myself an expert. What follows is a short summary of how I understand ldapssotoken and the differences between sasl-ht. The ldapssotoken I-D allows the creation of tokens for different services which can be relayed by middleware. This enables a SSO experience without the need of Kerberos. It also specifies a SASL mechanism which transports the token to the LDAP server for verification/authentication. Tokens can also be revoked at the LDAP serve= r. The major difference between ldapssotoken and sasl-ht is that the latter uses short lived exclusively ephemeral tokens. That is, the token is immediately revoked after it has been used. IMHO this is a necessary requirement: For increased security the lifetime of the token should be as short as possible. Furthermore SASL HT-* enables mutual authentication of initiator and responder using channel binding, and therefore it is required that SASL HT-* is performed over TLS. Mutual authentication is a very desirable property of an SASL mechanism, especially for one using short lived tokens for authentication. Also sasl-ht specifies a SASL mechanism and nothing more. But it can only be used with an application protocol specific extension like [1]. I think it is advantageous that those two parts are kept separate. In summary, while both I-D use tokens, I think they do not try to achieve the exact same goals. Therefore I am not sure if it is sensible to merge those two I-Ds into on= e. Some unrelated remarks and possibly nits about draft-wibrown-ldapssotoken-02: - It talks about authid when it should possibly be authcid? - Security Strength Factor seems to be nowhere defined in a RFC? - Florian 1: http://geekplace.eu/xeps/xep-isr-sasl2/xep-isr-sasl2.html --iqcqx286efkS4qfTdpp6dTMcTX214rga7-- --9PHQkdotubTprQWNBT4hLBnA6D92R37p9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAln/LwhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFLZGAf8DhX4BDZ33BK0z94FIhljJ3f97CkdWds+ 2V69JKexu3jzvxiLaxCpwhGFgTPl14D1jnDqDPrFyNR+U6dX9QtlZWtElVroASg1 Mjuuu4V7RXB2bQBJuEzx84SFfH3lp0q1dBaV32WVCqzJV2kwlqdudMbSzjnHMMyw tRsEqONrk1CIuk0yvfmoguB3WHkBNCTQm6Bz87h/EBm26lyx7Ve7l/6vMQKtHLCi OlCALUAXJmVCPhL/GioOyJzPJG3vWaCpIjc7q9m/ilaVwp0Nz5qQCM8fo2mra+hd sUKDuopsmwYOfjcpuEKeEg+WRrIEGLe7o8Ti6yzvXs7sHIapL2xpDQ== =gqIt -----END PGP SIGNATURE----- --9PHQkdotubTprQWNBT4hLBnA6D92R37p9-- From nobody Fri Nov 10 10:54:47 2017 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 D96B1128BB7 for ; Fri, 10 Nov 2017 10:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WsJSKaxbTlpd for ; Fri, 10 Nov 2017 10:54:43 -0800 (PST) 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 35EDD1289B0 for ; Fri, 10 Nov 2017 10:54:43 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 8687B81E03; Fri, 10 Nov 2017 18:54:42 +0000 (UTC) Received: from localhost (ovpn-117-36.phx2.redhat.com [10.3.117.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5A2DC6FEF1; Fri, 10 Nov 2017 18:54:42 +0000 (UTC) From: Robbie Harwood To: Greg Hudson , kitten@ietf.org In-Reply-To: References: Date: Fri, 10 Nov 2017 13:54:41 -0500 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.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Fri, 10 Nov 2017 18:54:42 +0000 (UTC) Archived-At: Subject: Re: [kitten] SPAKE edwards25519 M/N values and test vectors X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 18:54:45 -0000 --=-=-= Content-Type: text/plain Greg Hudson writes: > I noticed two problems with the current edwards25519 group definition in > the SPAKE preauth draft which I would like to correct: > > 1. When I created the test vectors, I generated x/y values incorrectly. > The IRTF SPAKE draft says "A picks x randomly and uniformly from the > integers in [0,ph) divisible by h", but I instead just picked from > [0,p], so most of the x and y values aren't divisible by the cofactor. > Depending on how an implementation works, this could make testing > awkward. > > 2. The M and N constants aren't in the prime-order subgroup, as is > required by the IRTF SPAKE draft. This causes a few low-order bits of w > to be leaked, which could be used as a pre-filter before an online > password attack. This could be papered over by forcing w to be > divisible by the cofactor, but I think providing M/N values in > conformance with the IRTF draft is much more elegant. I generated new > values with point order checking: > > M: d048032c6ea0b6d697ddc2e86bda85a33adac920f1bf18e1b0c6d166a5cecdaf > N: d3bfb518f44f3430f29d0c92af503865a1ed3281dc69b35dd868ba85f886c4ab > > The appendix describing M/N generation needs to be adjusted to match, as > it currently says that the M/N values are just hashes of the seed > strings. I propose the wording: > > The M and N constants for the NIST groups are from > [I-D.irtf-cfrg-spake2] section 3. > > The M and N constants for the edwards25519 group were generated using > the algorithm from [I-D.irtf-cfrg-spake2] section 3 and the seed > strings "edwards25519 point generation seed (M)" and "edwards25519 > point generation seed (N)". > > (I plan to see about adding edwards25519 to the IRTF SPAKE draft, in > which case this appendix can be simplified or eliminated. But first I > want to fix the kitten draft.) > > The full document update is at https://github.com/greghudson/ietf/pull/3 > but is mostly changes to hex strings. Wording changes look good to me. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAloF9fEACgkQJTL5F2qV pEJT4xAAg5wieB0+z3UMs2zGFcfU8Q8T21A3XJDfP3XU3YOCGy58NZXEVAiphA53 1BZ+vgqej8WsWJT1SCZMb3svm/1jU236viuICfcTZczypbVe8QjlxScmTDbYLdb2 byZvTU5xuIgiUqw2D1URQfGaqY6d6UZQryi2KMky+NGkoTz2BQTBvnZF+Swp0vnz jfe3H9z2WHdTrx/MyPig+97dPTSd/fD8YMB3oo/Xs8zsVE/wvAYi373Rm0FuoKYx ozmXn7xqx+nPP/UmxtOmlC57BNMbltB48v6zQXCo0959v5b1XRBJTNPs9jcp1Zmk VZHnMgZ6d/WFnhOQ/dD5VoyOBVrtOi2FZx7Z0TqcZIOUc4f4hzAdS7uRbtbbN8zE HTRoMDPY7tgbtr6lvYQXdmdQLX2sdehZKYaguS5pyX9Mm07RWCSXesZB/lPqn209 6+KO1Yu4b+K1a4Gc8IBWnme7tbysPWVQcL/5bgGZl/e0IZ+A5FfhsG3epnCiafnh SHPLjR2DNV85L93yAPQdn0ee4SMghtVdFlU2k/p6mCxnseMHcthOLly5dm9wzxmy l06fhBfIp6KzgBNBLUQpLBrkA1n5//dauXqfRIj5sATic+tpVkc4CmgKOR/8BGod WapB7LKpUTtwnKvooCYzkclJyIh6hhrh2SMBFVZvKwkHWfdUE5o= =i1Nf -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Nov 11 23:03:47 2017 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 5872A126C0F; Sat, 11 Nov 2017 23:03:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151047022629.30885.8329319869026464244@ietfa.amsl.com> Date: Sat, 11 Nov 2017 23:03:46 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-rfc5653bis-06.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 07:03:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF. Title : Generic Security Service API Version 2: Java Bindings Update Authors : Mayank D. Upadhyay Seema Malkani Wang Weijun Filename : draft-ietf-kitten-rfc5653bis-06.txt Pages : 94 Date : 2017-11-11 Abstract: The Generic Security Services Application Program Interface (GSS-API) offers application programmers uniform access to security services atop a variety of underlying cryptographic mechanisms. This document updates the Java bindings for the GSS-API that are specified in "Generic Security Service API Version 2 : Java Bindings Update" (RFC 5653). This document obsoletes RFC 5653 by adding a new output token field to the GSSException class so that when the initSecContext or acceptSecContext methods of the GSSContext class fails it has a chance to emit an error token which can be sent to the peer for debugging or informational purpose. The stream-based GSSContext methods are also removed in this version. The GSS-API is described at a language-independent conceptual level in "Generic Security Service Application Program Interface Version 2, Update 1" (RFC 2743). The GSS-API allows a caller application to authenticate a principal identity, to delegate rights to a peer, and to apply security services such as confidentiality and integrity on a per-message basis. Examples of security mechanisms defined for GSS- API are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2" (RFC 4121). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-rfc5653bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-rfc5653bis-06 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-rfc5653bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-rfc5653bis-06 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/ From nobody Sun Nov 12 01:29:58 2017 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 1E6AD124BE8 for ; Sun, 12 Nov 2017 01:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no 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 zUMRIRIrjOvV for ; Sun, 12 Nov 2017 01:29:54 -0800 (PST) Received: from mail-wm0-f48.google.com (mail-wm0-f48.google.com [74.125.82.48]) (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 5AC86120726 for ; Sun, 12 Nov 2017 01:29:54 -0800 (PST) Received: by mail-wm0-f48.google.com with SMTP id r68so9782975wmr.3 for ; Sun, 12 Nov 2017 01:29:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to; bh=jhAY/6xzwWiR8UUtwfD0NtPo3kMA50nkWCvz1AL9bUg=; b=LLH2V2dDjPlNzyCR8lap1+ICmiilxParsa3eM2TeC41xDbWR3YeXw0G8lPKeGuB50R jSEewQVNDDcml9gtDqu9r/PhTsiarkAiL+2cF8jUKXoow7aIpUBwxd0lx9wSmmY803qo vRYbsijS13R+jD0jlWLMxm44yQEJqklgZ1qZL5tiFTfl4ugPfkIG7OPY0lo/WT3SGkkK wzdcWThmDlZ8Qn4fVHTPr/I/z3DBdh3t77HzF0wAHei73+vxfJmiHVZSwZH+gaqk8qkG i7ICb8uaABAB4yk8szAIgQt8w5ePNcX+BVn6mSJugwcUMw30Z1kVCRET91lDJBnBXPAD GXyg== X-Gm-Message-State: AJaThX5X9l1ZqdRL7vj9dnJtl9hLt9VXQFPKJje7TNBEoxRrBk2/fqk1 E2PbNGJjVoE5DgaJXT2/PsdSuBT3 X-Google-Smtp-Source: AGs4zMYIbaRE2nJ8zNJm+bJFtUktGAaJn0I1y5hsTIeRDzb9sbDLlc1VlcxYXM5TV/D1VsrG5arUCQ== X-Received: by 10.80.135.226 with SMTP id 31mr8220644edz.210.1510478992605; Sun, 12 Nov 2017 01:29:52 -0800 (PST) Received: from ?IPv6:2001:a62:110a:1e01:72c8:490c:b0a9:6be1? ([2001:a62:110a:1e01:72c8:490c:b0a9:6be1]) by smtp.googlemail.com with ESMTPSA id h2sm11575181edc.89.2017.11.12.01.29.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 12 Nov 2017 01:29:51 -0800 (PST) From: Florian Schmaus To: kitten@ietf.org References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> Message-ID: Date: Sun, 12 Nov 2017 10:29:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1hSm9cQ9HPCUBHSlqbrh7rpDMOCxFprFu" Archived-At: Subject: Re: [kitten] The Hashed-Token SASL Mechanism (SASL-HT) X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 09:29:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1hSm9cQ9HPCUBHSlqbrh7rpDMOCxFprFu Content-Type: multipart/mixed; boundary="Qjh9TOK9LoKJGxw4SoeKgKe6mu0NVb6KC"; protected-headers="v1" From: Florian Schmaus To: kitten@ietf.org Cc: Peter Saint-Andre Message-ID: Subject: Re: The Hashed-Token SASL Mechanism (SASL-HT) References: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> In-Reply-To: <9913d71b-ae22-cc48-34b8-fb29fdf9a00c@geekplace.eu> --Qjh9TOK9LoKJGxw4SoeKgKe6mu0NVb6KC Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable I have just published -03 of draft-schmaus-kitten-sasl-ht, which is now available online at https://tools.ietf.org/html/draft-schmaus-kitten-sasl-ht-03 Besides some minor changes the major ones are: The incorporation of the requirements of the application specific extension protocol, which where already stated in the ProtoXEP [1], but really belong (also) in he HT SASL mechanism. Describe how (I believe) the Hashed Token SASL mechanism could be used with TLS 1.3 early data safely. An attempt to clarify that the used tokens are one time tokens. The I-D is now in a state where its authors need a mentor or guide on how we continue from here on. That is obviously why I put PSA into the cc, but help from other people is, of course, also appreciated. :) - Florian 1: http://geekplace.eu/xeps/xep-isr-sasl2/xep-isr-sasl2.html --Qjh9TOK9LoKJGxw4SoeKgKe6mu0NVb6KC-- --1hSm9cQ9HPCUBHSlqbrh7rpDMOCxFprFu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQGlBAEBCgCPFiEEl3UFnzoh3OFr5PuuIjmn6PWFIFIFAloIFI1fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk3 NzUwNTlGM0EyMURDRTE2QkU0RkJBRTIyMzlBN0U4RjU4NTIwNTIRHGZsb0BnZWVr cGxhY2UuZXUACgkQIjmn6PWFIFIsngf/XvEVlx4kgmddlbkd2DMhFkTw4F3rPkS9 gL+wWDcvBJJF93AC/PlIJtukYgZaU4rRs1Auo2EMv6oxEraytcxeK4/LqyEUtaG8 JRIjP1QudrxTtduTXWtTRNiIeqAUxAD2SDzzBBMMUtrRBtuPG6yFQ5QVALk47MQ+ 2kSIhveq1qB7++ok6e/TL/mzsqhRMjPjQ43bdDOjyv9ZxM+BDHdcW67LROMySgK5 34iGHxbBweZFFO7yXeV2MLfl8fLW3ntTJbGVHC+2Uw/gsIcOpSdR4pSK15fK//2K XlagmLqk/siHKv1MicgsIb5dol2+yYLF8NL50N887KRj9hJ7M3c82A== =nr2I -----END PGP SIGNATURE----- --1hSm9cQ9HPCUBHSlqbrh7rpDMOCxFprFu-- From nobody Thu Nov 30 10:01:00 2017 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 13E80127977; Thu, 30 Nov 2017 10:00:59 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.66.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151206485902.25914.16222407249374346828@ietfa.amsl.com> Date: Thu, 30 Nov 2017 10:00:59 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-krb-spake-preauth-03.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.22 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Nov 2017 18:00:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF. Title : SPAKE Pre-Authentication Authors : Nathaniel McCallum Simo Sorce Robbie Harwood Greg Hudson Filename : draft-ietf-kitten-krb-spake-preauth-03.txt Pages : 31 Date : 2017-11-30 Abstract: This document defines a new pre-authentication mechanism for the Kerberos protocol that uses a password authenticated key exchange. This document has three goals. First, increase the security of Kerberos pre-authentication exchanges by making offline brute-force attacks infeasible. Second, enable the use of second factor authentication without relying on FAST. This is achieved using the existing trust relationship established by the shared first factor. Third, make Kerberos pre-authentication more resilient against time synchronization errors by removing the need to transfer an encrypted timestamp from the client. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-krb-spake-preauth/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-kitten-krb-spake-preauth-03 https://datatracker.ietf.org/doc/html/draft-ietf-kitten-krb-spake-preauth-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-krb-spake-preauth-03 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/