From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Tue Jan 3 10:48:12 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F98129AD1 for ; Tue, 3 Jan 2017 10:48:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 44iDRcD2weQa for ; Tue, 3 Jan 2017 10:48:09 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 D7985129AD6 for ; Tue, 3 Jan 2017 10:48:04 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 94CCB85600; Tue, 3 Jan 2017 18:48:03 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 522A7855EF; Tue, 3 Jan 2017 18:48:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 5F6DC84CFB for ; Tue, 3 Jan 2017 12:17:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id KnM4mMb13-tv for ; Tue, 3 Jan 2017 12:17:12 +0000 (UTC) Received: from serpens.de (serpens.de [195.22.142.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 6CC7A84CEF for ; Tue, 3 Jan 2017 12:17:11 +0000 (UTC) Received: from serpens.de (spz@localhost [127.0.0.1]) by serpens.de (8.15.2/8.13.3) with ESMTPS id v03CGrSC013419 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Tue, 3 Jan 2017 13:17:05 +0100 (MET) Received: (from spz@localhost) by serpens.de (8.15.2/8.12.11) id v03CGoKq001056 for ietf-ssh@NetBSD.org; Tue, 3 Jan 2017 13:16:52 +0100 (MET) Date: Tue, 3 Jan 2017 13:16:49 +0100 From: "S.P.Zeidler" To: ietf-ssh@NetBSD.org Subject: Universal 2nd Factor (U2F) Authentication for Secure Shell? Message-ID: <20170103121647.GF4689@serpens.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Happy New Year, I've encountered https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt and wondered if this august forum had an opinion both on making u2f available in SSH and the draft given. regards, spz -- spz@serpens.de (S.P.Zeidler) From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jan 4 21:53:00 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1EB129533 for ; Wed, 4 Jan 2017 21:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net 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 wbnZP53qU-DS for ; Wed, 4 Jan 2017 21:52:57 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 B21FA12952E for ; Wed, 4 Jan 2017 21:52:57 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 14BA6855D2; Thu, 5 Jan 2017 05:52:57 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id B0A34855CB; Thu, 5 Jan 2017 05:52:56 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id 0D56C855A9 for ; Wed, 4 Jan 2017 04:46:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Authentication-Results: mail.netbsd.org (amavisd-new); dkim=pass (1024-bit key) header.d=timeheart.net Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 9qAyvGjbrBJ4 for ; Wed, 4 Jan 2017 04:46:19 +0000 (UTC) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 2DA8C8557C for ; Wed, 4 Jan 2017 04:46:18 +0000 (UTC) Received: by mail-pf0-x22b.google.com with SMTP id 189so80269811pfz.3 for ; Tue, 03 Jan 2017 20:46:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timeheart.net; s=mail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=EZIMoizQ1mzGHdtdeAPxYaxhGDDU0A/YCSKgvL11SY4=; b=TWN4Pb4BBWV9w3NBEqaULfRuc47L+446GqrNlnQRRbNc/FCktyFrWvgQetk9+SOHqN VlU4SumhpoVEQXsfQQFchXVJOD1Llskw3bDCNMbMNkJbtYJ+KJJD+WVkriZ5NzLWy0MF 5d5ossSTGVWrACZxgEbzWu7CLq8Kk63Pf6eMg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=EZIMoizQ1mzGHdtdeAPxYaxhGDDU0A/YCSKgvL11SY4=; b=adDtNbdi2kj4C1IhhCGyN9zJalst5Lmz0135QFcx4pZzCjE+xGUEBwtXI33/Yg6Psv CPSewL48HBHIGiv+D9DrG8ws9Ozinb9+4wWyH7dxxbycLM8w5eEq09ZVKWAswmzkTuOB 1iFxdLs5S8O2CQj8TRGSJiNH9O02Bv7ldVYW7x19OQvyygXUbgyEFgHtFHxNxIlgYhz4 9EQ5cE6RIcD3Q+WlFmx0IXzD1P4LDiGz+2RrlK6oXSu1OZO5f89n3ctOiJHjNAVIX+6M wMIOxzgcG7lPu9Tu2E4KDcjQ5OHf2ukFkB3uHgCdlhM0AjUIch6/dw7/ONCwXKx6eoOi pdRw== X-Gm-Message-State: AIkVDXJoU/2vQSnxbNQ8jwInYjrKgaIXHxtM/KSlKSY5ZCiIONaOGINe+a/+Pk57OBhM0w== X-Received: by 10.84.214.1 with SMTP id h1mr144184947pli.47.1483505177653; Tue, 03 Jan 2017 20:46:17 -0800 (PST) Received: from ?IPv6:2601:647:4282:2200:cfa:5497:d692:7eeb? ([2601:647:4282:2200:cfa:5497:d692:7eeb]) by smtp.gmail.com with ESMTPSA id p64sm143327563pfi.88.2017.01.03.20.46.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jan 2017 20:46:16 -0800 (PST) From: Ron Frederick Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_BDA02452-3532-4013-843A-5660A4C98A0B" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Universal 2nd Factor (U2F) Authentication for Secure Shell? Date: Tue, 3 Jan 2017 20:46:15 -0800 In-Reply-To: <20170103121647.GF4689@serpens.de> Cc: ietf-ssh@NetBSD.org To: "S.P.Zeidler" References: <20170103121647.GF4689@serpens.de> X-Mailer: Apple Mail (2.3259) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Apple-Mail=_BDA02452-3532-4013-843A-5660A4C98A0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Jan 3, 2017, at 4:16 AM, S.P.Zeidler wrote: > I've encountered > https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt > and wondered if this august forum had an opinion both on making u2f > available in SSH and the draft given. There are multiple things that don=E2=80=99t make sense to me or that = I=E2=80=99d want to change in this draft. First and foremost, I don=E2=80=99t think it makes sense for the = RegisterRequest to be done inside an SSH_MSG_USERAUTH_REQUEST. This is = not part of authenticating a client. It=E2=80=99s a step which would = have to be done on the server machine by the owner of the account which = is being logged into where they decide what U2F tokens they want to = accept and they create appropriate entries in authorized_keys. I could = imagine a took like ssh-keygen being augmented to speak the necessary = protocol to generate the U2F registration request and retrieve the = response and convert it into an appropriate form for insertion into = authorized_keys, but I don=E2=80=99t see it as making sense during SSH = client authentication. That step should only need to do the = SignRequest/SignResponse handshake, assuming there was an appropriate = U2F key entry which was trusted. That leads to the next issue, which is that there=E2=80=99s no = description of what this authorized_key entry should look like. Also, = since the authorized_key file is used today for public keys and = certificates, is this really the right file? Perhaps registered U2F keys = should be kept in a separate file designed specifically for this = purpose. I don=E2=80=99t really see the advanced in combining the two, = unless there is an intention of wanting to take advantage of the options = available in authorized_keys. Some of those (like cert-authority and = principals) don=E2=80=99t really make sense, though, and since U2F is = designed to be used as a secondary authentication to strengthen other = auth mechanisms, it=E2=80=99s not clear it makes sense for these keys to = end up deciding things like what SSH features should be allowed to be = used. If a combination of public key and U2F authentication is used, = which set of options should apply to the resulting connection? In terms of the specifics of the proposed messages, it appears that the = values SSH2_MSG_USERAUTH_INFO_REQUEST and = SSH2_MSG_USERAUTH_INFO_RESPONSE defined for use in keyboard-interactive = authentication are being repurposed here. I think it would be better to = define new SSH2_MSG_USERAUTH values specific to U2F here, even if the = assigned numbers are reused. For instance, the message names could be = SSH2_MSG_USERAUTH_SIGN_REQUEST and SSH2_MSG_USERAUTH_SIGN_RESPONSE. If = the registration is done out of band, there=E2=80=99s also no need for = the =E2=80=9CU2F mode=E2=80=9D integer in the original USERAUTH request. Finally, setting both =E2=80=9Corigin=E2=80=9D and =E2=80=9CappId=E2=80=9D= to =E2=80=9Cssh://localhost =E2=80=9D when creating = the U2F tokens also doesn=E2=80=99t seem quite right. It seems to me = like there might be some value in allowing tokens associated with = specific user or host principals, similar to what is done for SSH = certificates. However, I=E2=80=99m not all that familiar with U2F, so I = don=E2=80=99t know how those fields are typically used. Was a prototype of this ever implemented? --=20 Ron Frederick ronf@timeheart.net --Apple-Mail=_BDA02452-3532-4013-843A-5660A4C98A0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On Jan 3, 2017, at 4:16 AM, S.P.Zeidler <spz@serpens.de> = wrote:
I've encountered
https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.tx= t
and wondered if this august forum had an opinion = both on making u2f
available in SSH and the draft = given.

There are multiple things that don=E2=80=99t make sense = to me or that I=E2=80=99d want to change in this draft.
First and foremost, I don=E2=80=99t = think it makes sense for the RegisterRequest to be done inside an = SSH_MSG_USERAUTH_REQUEST. This is not part of authenticating a client. = It=E2=80=99s a step which would have to be done on the server machine by = the owner of the account which is being logged into where they decide = what U2F tokens they want to accept and they create appropriate entries = in authorized_keys. I could imagine a took like ssh-keygen being = augmented to speak the necessary protocol to generate the U2F = registration request and retrieve the response and convert it into an = appropriate form for insertion into authorized_keys, but I don=E2=80=99t = see it as making sense during SSH client authentication. That step = should only need to do the SignRequest/SignResponse handshake, assuming = there was an appropriate U2F key entry which was trusted.

That leads to the next = issue, which is that there=E2=80=99s no description of what this = authorized_key entry should look like. Also, since the authorized_key = file is used today for public keys and certificates, is this really the = right file? Perhaps registered U2F keys should be kept in a separate = file designed specifically for this purpose. I don=E2=80=99t really see = the advanced in combining the two, unless there is an intention of = wanting to take advantage of the options available in authorized_keys. = Some of those (like cert-authority and principals) don=E2=80=99t really = make sense, though, and since U2F is designed to be used as a secondary = authentication to strengthen other auth mechanisms, it=E2=80=99s not = clear it makes sense for these keys to end up deciding things like what = SSH features should be allowed to be used. If a combination of public = key and U2F authentication is used, which set of options should apply to = the resulting connection?

In terms of the specifics of the proposed messages, it = appears that the values SSH2_MSG_USERAUTH_INFO_REQUEST and = SSH2_MSG_USERAUTH_INFO_RESPONSE defined for use in keyboard-interactive = authentication are being repurposed here. I think it would be better to = define new SSH2_MSG_USERAUTH values specific to U2F here, even if the = assigned numbers are reused. For instance, the message names could be = SSH2_MSG_USERAUTH_SIGN_REQUEST and SSH2_MSG_USERAUTH_SIGN_RESPONSE. If = the registration is done out of band, there=E2=80=99s also no need for = the =E2=80=9CU2F mode=E2=80=9D integer in the original USERAUTH = request.

Finally, setting both =E2=80=9Corigin=E2=80=9D and = =E2=80=9CappId=E2=80=9D to =E2=80=9Cssh://localhost=E2=80=9D when creating the U2F tokens = also doesn=E2=80=99t seem quite right. It seems to me like there might = be some value in allowing tokens associated with specific user or host = principals, similar to what is done for SSH certificates. However, I=E2=80= =99m not all that familiar with U2F, so I don=E2=80=99t know how those = fields are typically used.

Was a prototype of this ever implemented?
-- 
Ron = Frederick
ronf@timeheart.net



= --Apple-Mail=_BDA02452-3532-4013-843A-5660A4C98A0B-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Wed Jan 4 21:59:28 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2CA129ABC for ; Wed, 4 Jan 2017 21:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 lnVBnr6gfb5v for ; Wed, 4 Jan 2017 21:59:26 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 61893129533 for ; Wed, 4 Jan 2017 21:59:26 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 91547855B4; Thu, 5 Jan 2017 05:52:28 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 4865C855A9; Thu, 5 Jan 2017 05:52:28 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A9B0A855B8 for ; Wed, 4 Jan 2017 13:28:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id 32j3CM-uil42 for ; Wed, 4 Jan 2017 13:28:02 +0000 (UTC) Received: from serpens.de (serpens.de [195.22.142.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.netbsd.org (Postfix) with ESMTPS id 71ABE84CBD for ; Wed, 4 Jan 2017 13:28:01 +0000 (UTC) Received: from serpens.de (spz@localhost [127.0.0.1]) by serpens.de (8.15.2/8.13.3) with ESMTPS id v04DQct4026739 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 4 Jan 2017 14:26:58 +0100 (MET) Received: (from spz@localhost) by serpens.de (8.15.2/8.12.11) id v04DQXVU015511; Wed, 4 Jan 2017 14:26:35 +0100 (MET) Date: Wed, 4 Jan 2017 14:26:31 +0100 From: "S.P.Zeidler" To: Ron Frederick Cc: ietf-ssh@NetBSD.org, michael+mindrot@stapelberg.de, simon@josefsson.org Subject: Re: Universal 2nd Factor (U2F) Authentication for Secure Shell? Message-ID: <20170104132629.GH4689@serpens.de> References: <20170103121647.GF4689@serpens.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-message-flag: Please send plain text messages only. Thank you. User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list Hi, Cc'ing the proposers, so keeping the mail unweeded: Thus wrote Ron Frederick (ronf@timeheart.net): > On Jan 3, 2017, at 4:16 AM, S.P.Zeidler wrote: > > I've encountered > > https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt > > and wondered if this august forum had an opinion both on making u2f > > available in SSH and the draft given. > > > There are multiple things that don’t make sense to me or that I’d want to change in this draft. > > First and foremost, I don’t think it makes sense for the RegisterRequest to be done inside an SSH_MSG_USERAUTH_REQUEST. This is not part of authenticating a client. It’s a step which would have to be done on the server machine by the owner of the account which is being logged into where they decide what U2F tokens they want to accept and they create appropriate entries in authorized_keys. I could imagine a took like ssh-keygen being augmented to speak the necessary protocol to generate the U2F registration request and retrieve the response and convert it into an appropriate form for insertion into authorized_keys, but I don’t see it as making sense during SSH client authentication. That step should only need to do the SignRequest/SignResponse handshake, assuming there was an appropriate U2F key entry which was trusted. > > That leads to the next issue, which is that there’s no description of what this authorized_key entry should look like. Also, since the authorized_key file is used today for public keys and certificates, is this really the right file? Perhaps registered U2F keys should be kept in a separate file designed specifically for this purpose. I don’t really see the advanced in combining the two, unless there is an intention of wanting to take advantage of the options available in authorized_keys. Some of those (like cert-authority and principals) don’t really make sense, though, and since U2F is designed to be used as a secondary authentication to strengthen other auth mechanisms, it’s not clear it makes sense for these keys to end up deciding things like what SSH features should be allowed to be used. If a combination of public key and U2F authentication is used, which set of options should apply to the resulting connection? > > In terms of the specifics of the proposed messages, it appears that the values SSH2_MSG_USERAUTH_INFO_REQUEST and SSH2_MSG_USERAUTH_INFO_RESPONSE defined for use in keyboard-interactive authentication are being repurposed here. I think it would be better to define new SSH2_MSG_USERAUTH values specific to U2F here, even if the assigned numbers are reused. For instance, the message names could be SSH2_MSG_USERAUTH_SIGN_REQUEST and SSH2_MSG_USERAUTH_SIGN_RESPONSE. If the registration is done out of band, there’s also no need for the “U2F mode” integer in the original USERAUTH request. > > Finally, setting both “origin” and “appId” to “ssh://localhost ” when creating the U2F tokens also doesn’t seem quite right. It seems to me like there might be some value in allowing tokens associated with specific user or host principals, similar to what is done for SSH certificates. However, I’m not all that familiar with U2F, so I don’t know how those fields are typically used. I would like to be able to discern targets for U2F too, i.e. list both the token logging in, and the user@host being logged in to, in their appropriate fields. > Was a prototype of this ever implemented? As patches against OpenSSH, with some discussion too: https://bugzilla.mindrot.org/show_bug.cgi?id=2319 regards, spz -- spz@serpens.de (S.P.Zeidler) From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jan 6 00:20:53 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03BDF129C59 for ; Fri, 6 Jan 2017 00:20:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 YiFmfIn3c52d for ; Fri, 6 Jan 2017 00:20:50 -0800 (PST) Received: from mail.netbsd.org (mail.NetBSD.org [IPv6:2001:470:a085:999::25]) (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 087E5129C55 for ; Fri, 6 Jan 2017 00:20:49 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id DAA0F855E1; Fri, 6 Jan 2017 08:20:48 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 9255985581; Fri, 6 Jan 2017 08:20:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id B337985606 for ; Thu, 5 Jan 2017 22:29:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([IPv6:::1]) by localhost (mail.netbsd.org [IPv6:::1]) (amavisd-new, port 10025) with ESMTP id z56kSU31m2GX for ; Thu, 5 Jan 2017 22:29:49 +0000 (UTC) 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 mail.netbsd.org (Postfix) with ESMTPS id 633F384CEE for ; Thu, 5 Jan 2017 22:29:47 +0000 (UTC) Received: from latte.josefsson.org ([IPv6:2001:9b0:104:42::17d]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v05MTTnL010706 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 5 Jan 2017 23:29:30 +0100 Date: Thu, 5 Jan 2017 23:29:22 +0100 From: Simon Josefsson To: "S.P.Zeidler" Cc: Ron Frederick , ietf-ssh@NetBSD.org, michael+mindrot@stapelberg.de Subject: Re: Universal 2nd Factor (U2F) Authentication for Secure Shell? Message-ID: <20170105232922.5ba00ef4@latte.josefsson.org> In-Reply-To: <20170104132629.GH4689@serpens.de> References: <20170103121647.GF4689@serpens.de> <20170104132629.GH4689@serpens.de> X-Mailer: Claws Mail 3.11.1 (GTK+ 2.24.25; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/Gpf+.coq0xkPAJH3CG55+7c"; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.99.2 at duva.sjd.se X-Virus-Status: Clean Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list --Sig_/Gpf+.coq0xkPAJH3CG55+7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, The draft is indeed an unfinished work, and the issues you bring up are relevant. I don't have cycles to drive this draft right now, but I'm happy to merge patches and publish new versions if someone wants to step up and become co-author. I'm happy to hand over control too. The draft is on gitlab: https://gitlab.com/jas/ietf-secsh-u2f /Simon > Hi, >=20 > Cc'ing the proposers, so keeping the mail unweeded: >=20 > Thus wrote Ron Frederick (ronf@timeheart.net): >=20 > > On Jan 3, 2017, at 4:16 AM, S.P.Zeidler wrote: > > > I've encountered > > > https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt > > > and wondered if this august forum had an opinion both on making > > > u2f available in SSH and the draft given. > >=20 > >=20 > > There are multiple things that don=E2=80=99t make sense to me or that I= =E2=80=99d > > want to change in this draft. > >=20 > > First and foremost, I don=E2=80=99t think it makes sense for the > > RegisterRequest to be done inside an SSH_MSG_USERAUTH_REQUEST. This > > is not part of authenticating a client. It=E2=80=99s a step which would > > have to be done on the server machine by the owner of the account > > which is being logged into where they decide what U2F tokens they > > want to accept and they create appropriate entries in > > authorized_keys. I could imagine a took like ssh-keygen being > > augmented to speak the necessary protocol to generate the U2F > > registration request and retrieve the response and convert it into > > an appropriate form for insertion into authorized_keys, but I don=E2=80= =99t > > see it as making sense during SSH client authentication. That step > > should only need to do the SignRequest/SignResponse handshake, > > assuming there was an appropriate U2F key entry which was trusted. > >=20 > > That leads to the next issue, which is that there=E2=80=99s no descript= ion > > of what this authorized_key entry should look like. Also, since the > > authorized_key file is used today for public keys and certificates, > > is this really the right file? Perhaps registered U2F keys should > > be kept in a separate file designed specifically for this purpose. > > I don=E2=80=99t really see the advanced in combining the two, unless th= ere > > is an intention of wanting to take advantage of the options > > available in authorized_keys. Some of those (like cert-authority > > and principals) don=E2=80=99t really make sense, though, and since U2F = is > > designed to be used as a secondary authentication to strengthen > > other auth mechanisms, it=E2=80=99s not clear it makes sense for these = keys > > to end up deciding things like what SSH features should be allowed > > to be used. If a combination of public key and U2F authentication > > is used, which set of options should apply to the resulting > > connection? > >=20 > > In terms of the specifics of the proposed messages, it appears that > > the values SSH2_MSG_USERAUTH_INFO_REQUEST and > > SSH2_MSG_USERAUTH_INFO_RESPONSE defined for use in > > keyboard-interactive authentication are being repurposed here. I > > think it would be better to define new SSH2_MSG_USERAUTH values > > specific to U2F here, even if the assigned numbers are reused. For > > instance, the message names could be SSH2_MSG_USERAUTH_SIGN_REQUEST > > and SSH2_MSG_USERAUTH_SIGN_RESPONSE. If the registration is done > > out of band, there=E2=80=99s also no need for the =E2=80=9CU2F mode=E2= =80=9D integer in the > > original USERAUTH request. > >=20 > > Finally, setting both =E2=80=9Corigin=E2=80=9D and =E2=80=9CappId=E2=80= =9D to =E2=80=9Cssh://localhost > > =E2=80=9D when creating the U2F tokens also doesn=E2= =80=99t seem > > quite right. It seems to me like there might be some value in > > allowing tokens associated with specific user or host principals, > > similar to what is done for SSH certificates. However, I=E2=80=99m not = all > > that familiar with U2F, so I don=E2=80=99t know how those fields are > > typically used. >=20 > I would like to be able to discern targets for U2F too, i.e. > list both the token logging in, and the user@host being logged in to, > in their appropriate fields. >=20 > > Was a prototype of this ever implemented? >=20 > As patches against OpenSSH, with some discussion too: > https://bugzilla.mindrot.org/show_bug.cgi?id=3D2319 >=20 > regards, > spz --Sig_/Gpf+.coq0xkPAJH3CG55+7c Content-Type: application/pgp-signature Content-Description: OpenPGP digital signatur -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYbsjCAAoJEIYLf7sy+BGdSAIH/1LMZyJXRMgMxTLeT2/Zyic+ DZQUOsjpzZnoZfzaiCBzy8PD7CYEJJnpwI6majvlM1U0jps4btcFVx07vbmsvmKr nYyeroIL1sUK2VTxSncm+XxMag77UPDoUYkpzEQx3o3GD57iMZZmlehirhfD8pBC cUCjtCLkdRlJmUxM5D7/ieq4AT0FghhWhlEcSRjI8yYRubl4e93VBD9V/K5I1n3E CXvXPizWddYlDJU16hWMjxyiABeDHpDSYbmjmwUNN4YBsFtbpmtmy+TxE69sObFd fP+VKzKe/z4s5sXtm0pXjwGgk46yecT13WRcVMlyUl145jEsVpFxYApfcNNwX+4= =4NG9 -----END PGP SIGNATURE----- --Sig_/Gpf+.coq0xkPAJH3CG55+7c-- From bounces-ietf-ssh-owner-secsh-tyoxbijeg7-archive=lists.ietf.org@NetBSD.org Fri Jan 6 00:22:03 2017 Return-Path: X-Original-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Delivered-To: ietfarch-secsh-tyoxbijeg7-archive@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72242129C59 for ; Fri, 6 Jan 2017 00:22:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, 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 2Y32AjVhIElC for ; Fri, 6 Jan 2017 00:22:02 -0800 (PST) Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200]) (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 33A0B129C58 for ; Fri, 6 Jan 2017 00:22:02 -0800 (PST) Received: by mail.netbsd.org (Postfix, from userid 605) id 9D45185606; Fri, 6 Jan 2017 08:22:01 +0000 (UTC) Delivered-To: ietf-ssh@netbsd.org Received: by mail.netbsd.org (Postfix, from userid 1347) id 5BCDC85604; Fri, 6 Jan 2017 08:22:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.netbsd.org (Postfix) with ESMTP id A98B285713 for ; Thu, 5 Jan 2017 13:52:42 +0000 (UTC) X-Virus-Scanned: amavisd-new at netbsd.org Received: from mail.netbsd.org ([127.0.0.1]) by localhost (mail.netbsd.org [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id lGMyGt673Kt4 for ; Thu, 5 Jan 2017 13:52:42 +0000 (UTC) Received: from Stone.Rodents-Montreal.ORG (Stone.Rodents-Montreal.ORG [98.124.61.89]) by mail.netbsd.org (Postfix) with ESMTP id BE53C855B3 for ; Thu, 5 Jan 2017 13:52:41 +0000 (UTC) Received: (from mouse@localhost) by Stone.Rodents-Montreal.ORG (8.8.8/8.8.8) id IAA09319; Thu, 5 Jan 2017 08:52:41 -0500 (EST) Date: Thu, 5 Jan 2017 08:52:41 -0500 (EST) From: Mouse Message-Id: <201701051352.IAA09319@Stone.Rodents-Montreal.ORG> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Erik-Conspiracy: There is no Conspiracy - and if there were I wouldn't be part of it anyway. X-Message-Flag: Microsoft: the company who gave us the botnet zombies. X-Composition-Start-Date: Thu, 5 Jan 2017 08:34:06 -0500 (EST) To: ietf-ssh@NetBSD.org Subject: Re: Universal 2nd Factor (U2F) Authentication for Secure Shell? In-Reply-To: References: <20170103121647.GF4689@serpens.de> Sender: ietf-ssh-owner@NetBSD.org List-Id: ietf-ssh.NetBSD.org Precedence: list >> https://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt Assuming this has the same content as http://www.ietf.org/archive/id/draft-josefsson-secsh-u2f-00.txt: It is misnamed. I see nothing "universal" about this. (Cf xkcd #927.) I agree that registration does not belong here, any more than editing authorized-keys or known-hosts records, or new key generation, belongs in the base protocol. The referenced fidoalliance document points to at least two references which are 404 (at least for me; given the content of the 404 page, this might be the usual nginx bogon, but the first document working suggests not). In any case, depending on external documents for implementability strikes me as a good way to not get implemented. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B