IETF Logo Mail Archive

Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec

"Cantor, Scott" <cantor.2@osu.edu> Tue, 11 March 2014 23:27 UTC

Return-Path: <cantor.2@osu.edu>
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 B4D551A0845 for <kitten@ietfa.amsl.com>; Tue, 11 Mar 2014 16:27:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yN_Pd60JSB4U for <kitten@ietfa.amsl.com>; Tue, 11 Mar 2014 16:27:27 -0700 (PDT)
Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0D4351A0825 for <kitten@ietf.org>; Tue, 11 Mar 2014 16:27:23 -0700 (PDT)
Received: from mail168-tx2-R.bigfish.com (10.9.14.244) by TX2EHSOBE010.bigfish.com (10.9.40.30) with Microsoft SMTP Server id 14.1.225.22; Tue, 11 Mar 2014 23:27:18 +0000
Received: from mail168-tx2 (localhost [127.0.0.1]) by mail168-tx2-R.bigfish.com (Postfix) with ESMTP id D92AD2A0191; Tue, 11 Mar 2014 23:27:17 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:164.107.81.222; KIP:(null); UIP:(null); IPV:NLI; H:cio-tnc-pf08; RD:none; EFVD:NLI
X-SpamScore: 3
X-BigFish: VPS3(zzbb2dI98dI9371I1432Izz1f42h1d77h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzd9hz1de098h1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2476h2487h24d7h2516h2545h255eh25cch25f6h2605h1b1cn1b1bi1155h)
Received-SPF: pass (mail168-tx2: domain of osu.edu designates 164.107.81.222 as permitted sender) client-ip=164.107.81.222; envelope-from=cantor.2@osu.edu; helo=cio-tnc-pf08 ; cio-tnc-pf08 ;
Received: from mail168-tx2 (localhost.localdomain [127.0.0.1]) by mail168-tx2 (MessageSwitch) id 1394580435738166_15073; Tue, 11 Mar 2014 23:27:15 +0000 (UTC)
Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.246]) by mail168-tx2.bigfish.com (Postfix) with ESMTP id A4716120098; Tue, 11 Mar 2014 23:27:15 +0000 (UTC)
Received: from cio-tnc-pf08 (164.107.81.222) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 11 Mar 2014 23:27:15 +0000
Received: from CIO-KRC-HT01.osuad.osu.edu (localhost [127.0.0.1]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by cio-tnc-pf08 (Postfix) with ESMTPS id B827A2E0076; Tue, 11 Mar 2014 19:27:14 -0400 (EDT)
Received: from CIO-KRC-D1MBX01.osuad.osu.edu ([fe80::450b:35e6:80f4:f3e0]) by CIO-KRC-HT01.osuad.osu.edu ([fe80::6d8f:7dea:5691:1620%12]) with mapi id 14.03.0174.001; Tue, 11 Mar 2014 19:27:14 -0400
From: "Cantor, Scott" <cantor.2@osu.edu>
To: Jeffrey Hutzelman <jhutz@cmu.edu>
Thread-Topic: [kitten] comments on draft-ietf-kitten-sasl-saml-ec
Thread-Index: AQHPPJGI5mV+TEdtgEiWvASeMKVPmZra1dwAgAHMM4D///hrgA==
Date: Tue, 11 Mar 2014 23:27:13 +0000
Message-ID: <CF451227.9B27%cantor.2@osu.edu>
References: <tsllhwhq46t.fsf@mit.edu> <CF439102.4B49C%cantor.2@osu.edu> <1394571259.25748.22.camel@minbar.fac.cs.cmu.edu>
In-Reply-To: <1394571259.25748.22.camel@minbar.fac.cs.cmu.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [65.31.0.111]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0AFBB8B3DBE4BD428004D6FB12D8B79C@osu.edu>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Forward
X-OriginatorOrg: osu.edu
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
Archived-At: http://mailarchive.ietf.org/arch/msg/kitten/LvAixkozJIzExYKqWtBZwLX1gOU
Cc: "kitten@ietf.org" <kitten@ietf.org>, Sam Hartman <hartmans-ietf@mit.edu>
Subject: Re: [kitten] comments on draft-ietf-kitten-sasl-saml-ec
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, 11 Mar 2014 23:27:30 -0000

On 3/11/14, 4:54 PM, "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote:
>
>It's not necessary for a mechanism to say "if we didn't assert
>mutual_state, then we didn't do mutual auth, and if the app cares, then
>it had better do something about it".  That is a property of the
>abstraction and is true for _every_ mechanism.

Ah, ok. Will fix/adjust, thanks.

>However, we have introduced the notion of channel bindings.  It's only
>safe for an application to rely on CB if mutual authentication has
>happened.  This is why GS2 required mutual auth, and why a new version
>of GS2 which relaxes this requirement must be careful to specify that
>-PLUS mechanisms must not be advertised unless mutual auth is possible,
>and must not succeed if mutual auth does not happen.
>
>So no, in the abstract, there's not really any machinery in SASL to
>signal whether mutual auth happened, except for the implied indication
>when channel bindings are in use.

Got it.

>Please use the numbers; that's the namespace we've actually
>standardized.

Ok. I don't think there are any implications back on the SAML material I
wrote for this at OASIS, but I will review that as part of fixing this.

>A typical behavior would be to prefer an acceptor subkey if one was
>sent, followed by an initiator subkey if one was sent, followed by the
>Kerberos ticket session key.  However, this can get a bit complicated,
>because an initiator does not know whether the acceptor sent a subkey
>until it processes the acceptor's AP_REP.  That means you either need to
>avoid the initiator having to choose until it has seen that message, or
>having some way to know which key to use when.  Doing the first is not
>bad, but can result in extra round trips depending on what you're doing.

Is there actually an AP_REP here? Or do you mean that euphemistically? I
didn't think reuse of those formats and encryption types implied actual
Kerberos-defined messages anywhere, but this is definitely not anything
I'm familiar with directly.

-- Scott

v2.23.0 | Report a Bug | By Email