Re: [kitten] SPAKE Preauth

Simo Sorce <ssorce@redhat.com> Tue, 05 May 2015 17:56 UTC

Return-Path: <ssorce@redhat.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725781A902B for <kitten@ietfa.amsl.com>; Tue, 5 May 2015 10:56:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.612
X-Spam-Level:
X-Spam-Status: No, score=-3.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdvBRLwvrlVw for <kitten@ietfa.amsl.com>; Tue, 5 May 2015 10:55:57 -0700 (PDT)
Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (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 687541A9042 for <kitten@ietf.org>; Tue, 5 May 2015 10:55:39 -0700 (PDT)
Received: from zmail17.collab.prod.int.phx2.redhat.com (zmail17.collab.prod.int.phx2.redhat.com [10.5.83.19]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t45HtcnW046515; Tue, 5 May 2015 13:55:38 -0400
Date: Tue, 5 May 2015 13:55:38 -0400 (EDT)
From: Simo Sorce <ssorce@redhat.com>
To: Ken Hornstein <kenh@pobox.com>
Message-ID: <1132502056.11486843.1430848538821.JavaMail.zimbra@redhat.com>
In-Reply-To: <20150505041736.7CC3741428@pb-smtp1.pobox.com>
References: <20150505041736.7CC3741428@pb-smtp1.pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Originating-IP: [10.4.164.1, 10.5.101.130]
X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF37 (Linux)/8.0.6_GA_5922)
Thread-Topic: SPAKE Preauth
Thread-Index: RIU8AvY0wishdOx8KlNZizxEeQN0kw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/9NjiXAkGLzxedJ2XxzM3u0gCKXE>
Cc: kitten@ietf.org
Subject: Re: [kitten] SPAKE Preauth
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2015 17:56:02 -0000

----- Original Message -----
> From: "Ken Hornstein" <kenh@pobox.com>
> To: kitten@ietf.org
> Sent: Tuesday, May 5, 2015 12:17:34 AM
> Subject: Re: [kitten] SPAKE Preauth
> 
> >> I do not quite understand your point ... are you saying that your I-D
> >> should completely specify how all 2FA systems work with SPAKE?  And
> >> personally I'd vote to keeping SPAKESecondFactor an Int32 rather than
> >> an OID.
> >
> >No. I'm saying a vendor can define their own 2FA and assign it an
> >enterprise OID number and use it out of the box. No standardization
> >required.
> >
> >Then we would create some IETF OIDs for open protocols (such as OATH
> >and U2F).
> 
> I'm wondering how that is better than the "normal" Kerberos scheme where
> vendors can register their 2FA or whatever with IANA.
> 
> And on further thought ... I realize that I'm strongly with Nico in that
> a generic OTP should be specified somewhere.  I know you mentioned U2F,
> but that just seems like an additional unnecessary layer (also, the U2F
> protocol seems to be web-specific, in that it mentions adding the origin
> URL and TLS channel ID to the authentication flow).  Sure, if people
> want to use U2F no objections here, but it just seems lousy that the
> initial specification(s) don't mention a generic OTP protocol; like Nico
> said, there are a ton of these devices.

If by "genric" protocol you mena TOTP or HOTP tokens we'll definitely provide that.
I think Nico meant "generic" as in really "free form as long as it is a text string" type of generic which I would object too(it would require sending prompts from the KDC. See previous message about why that is not ok.

Simo.

-- 
Simo Sorce * Red Hat, Inc. * New York