Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Nicolas Williams <> Thu, 25 August 2005 04:21 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E89El-0002CI-UZ; Thu, 25 Aug 2005 00:21:11 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E89Ej-0002CD-JO for; Thu, 25 Aug 2005 00:21:09 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id AAA14027 for <>; Thu, 25 Aug 2005 00:21:07 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E89FA-0004jq-JI for; Thu, 25 Aug 2005 00:21:38 -0400
Received: from centralmail2brm.Central.Sun.COM ([]) by (8.12.10/8.12.9) with ESMTP id j7P4L6HT014444 for <>; Wed, 24 Aug 2005 21:21:06 -0700 (PDT)
Received: from binky.Central.Sun.COM (binky.Central.Sun.COM []) by centralmail2brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j7P4L6LE008611 for <>; Wed, 24 Aug 2005 22:21:06 -0600 (MDT)
Received: from binky.Central.Sun.COM (localhost []) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j7P4L6EN013913; Wed, 24 Aug 2005 23:21:06 -0500 (CDT)
Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j7P4L6Yd013912; Wed, 24 Aug 2005 23:21:06 -0500 (CDT)
Date: Wed, 24 Aug 2005 23:21:06 -0500
From: Nicolas Williams <>
To: Bernard Aboba <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
Message-ID: <20050825042105.GW10174@binky.Central.Sun.COM>
References: <Pine.GSO.4.60.0508220801430.1114@ismene> <35850EE42DFD2824F0DDBBC8@cumulus> <Pine.GSO.4.60.0508221008260.1174@ismene> <1DCACCAC04655B3AFE9733A8@cumulus> <Pine.GSO.4.60.0508221047001.1307@ismene> <20050822154044.GE7789@binky.Central.Sun.COM> <> <> <20050824213010.GO10174@binky.Central.Sun.COM> <>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.7i
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

On Wed, Aug 24, 2005 at 03:40:17PM -0700, Bernard Aboba wrote:
> > Does tunnelling various other weak mechanisms over TLS meet said
> > criteria?
> If "weak" means mechanisms that do not generate a key (e.g. 
> MD5-Challenge), then these would violate RFC 4017 mandatory 
> requirement 6:

No, I used "weak" to mean mechanisms that are subject to off-line
dictionary attacks by eavesdroppers or MITMs.

>    [6]  Protection against man-in-the-middle attacks.  This corresponds
>         to the "Cryptographic binding", "Integrity protection", "Replay
>         protection", and "Session independence" security claims defined
>         in [RFC3748], Section 7.2.1.
> > CAT WG closed years ago...
> It appears that responsibility for IAKERB transitioned to the Kerberos WG 
> once CAT WG was closed. 
> [...]

Summary: IAKERB and EAP-GSS are dead at this time, mostly for lack of
people willing to do the work, not for any political or technical

I.e., I'm pretty sure there'd be no opposition from the IETF, the
Internet Security Area Directors or the IESG as a whole to a revival of
IAKERB and/or EAP-GSS, provided someone does the work.  See below.

> Sam further commented: 
> "I don't believe that iakerb is likely to have any issues with 
> clarifications, but the mode of iakerb that has reduced number of round 
> trips is likely to be incompatible with extensions because extensions will 
> integrity-protect  the request to make sure no changes are made."
> "I believe that one of iakerb, EAP krb5, , EAP GSS should actually go 
> forward.  Eap krb5 has been sketched out (although not publicly) but does 
> not really exist within the IETF context.  EAP GSS has significant 
> security issues and I hope it does not go forward at all.  Iakerb has 
> significant esthetic issues that we have discussed to death here.  I think 
> we should wait until there is clear interest either from the wireless or 
> dialup community that they want to use Kerberos and then work on one of 
> these mechanisms." 

The EAP GSS issues Sam mentions are addressed by KITTEN WG work, namely
GSS_Pseudo_random() (which reminds me, I have to update that I-D so we
can finish WGLC on that already).

The last IAKERB I-D turns out to have problems with Kerberos V
extensions exactly as Sam described them way back at IETF 56.  But
there's no reason that we couldn't fix this.


SECMECH mailing list