Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Clint Chaplin <> Sat, 27 August 2005 19:28 UTC

Received: from localhost.localdomain ([] by with esmtp (Exim 4.32) id 1E96Li-0000Ql-Az; Sat, 27 Aug 2005 15:28:18 -0400
Received: from ([] by with esmtp (Exim 4.32) id 1E96Le-0000Qc-Mk for; Sat, 27 Aug 2005 15:28:16 -0400
Received: from (ietf-mx []) by (8.9.1a/8.9.1a) with ESMTP id PAA26746 for <>; Sat, 27 Aug 2005 15:28:12 -0400 (EDT)
Received: from ([]) by with esmtp (Exim 4.43) id 1E96Me-0000LM-0B for; Sat, 27 Aug 2005 15:29:16 -0400
Received: by with SMTP id 36so137241wra for <>; Sat, 27 Aug 2005 12:28:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=qexLjdC/+Mfu7px5B/TQmQnkfsSnxRfHEtkeGlCmVkVPQgSKiV52xJ/QbRL30IMvkrB9kn0jWI8hC+AaJS6u6msIOyN7xoV4+U2S6u3y9EwP3Ysyc78a5ra/K4o8XpytesIqd7WobrzV7EzpwOefx/mbbpKC5ecYDsrydZr3ZB0=
Received: by with SMTP id v24mr4801216wrv; Sat, 27 Aug 2005 12:28:00 -0700 (PDT)
Received: by with HTTP; Sat, 27 Aug 2005 12:28:00 -0700 (PDT)
Message-ID: <>
Date: Sat, 27 Aug 2005 12:28:00 -0700
From: Clint Chaplin <>
To: Bernard Aboba <>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <Pine.GSO.4.60.0508220801430.1114@ismene> <1DCACCAC04655B3AFE9733A8@cumulus> <Pine.GSO.4.60.0508221047001.1307@ismene> <20050822154044.GE7789@binky.Central.Sun.COM> <> <> <20050824213010.GO10174@binky.Central.Sun.COM> <> <20050825042105.GW10174@binky.Central.Sun.COM> <>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: quoted-printable
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Boy, does this all sound familiar....

I know of one IEEE 802.11i vendor that developed and sold a Kerberos
solution for security/authentication.

On 8/24/05, Bernard Aboba <> wrote:
> > No, I used "weak" to mean mechanisms that are subject to off-line
> > dictionary attacks by eavesdroppers or MITMs.
> If the EAP method generates a key and the tunneling mechanism supports
> cryptographic binding and satisfies the other RFC 4017
> requirements (e.g. key strength, etc.) then I don't think that offline
> dictionary or MITM attack should be possible.   Here is a brief summary of
> RFC 4017 requirements:
>    [1]  Key derivation.
>    [2]  Effective Key strength of at least 128-bits.
>    [3]  Mutual authentication.
>    [4]  Shared state equivalence.  See RFC 4017 for details.
>    [5]  Resistance to dictionary attacks.
>    [6]  Protection against man-in-the-middle attacks.
>    [7]  Protected ciphersuite negotiation.
>    [8]  Fragmentation.
>    [9]  End-user identity hiding.
>    [10] Channel binding.
>    [11] Fast reconnect.
> My guess is that Kerberos tunneled in TLS should be able to satisfy most
> if not all of these, assuming that cryptobinding is used.
> > 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
> > reasons.
> >From a technical perspective, there are some challenges
> to securely providing authentication simultaneously with fast handoff.
> One issue is how the EAP peer figures out what Kerberos principals
> it needs to request a ticket for.  Remember that EAP operates of a layer 2
> protocol such as 802.11, and since the peer doesn't yet have IP connectivity,
> it may not know the IP Address or name of the NAS it is trying to connect to.
> In 802.11i, all the station knows is the BSSID of the AP; it doesn't know what NAS
> that BSSID is associated with, let alone the IP address, service name,
> etc.
> In the original IEEE 802.11i documents, it was assumed that the peer
> would request a ticket to the "Network Access Service" but this required
> all NAS devices to share a secret with the KDC so that a ticket,
> once granted, could be reused with any NAS.  While this was very
> convenient for handoff, it was not so great from a shared secret hygene
> point of view.
> To enable the peer to figure out what tickets it needs, it seems like the
> AP would need to advertise its Kerberos Service Name, which might
> or might not be the same as the NAS-Identifier sent to the AAA server.
> Also, having to request a new ticket for each NAS, with a roundtrip to the
> KDC for each attempt, may not meet the stringent timing requirements of
> VOIP applications (handoff times <50 ms).  So I think you'd need to figure
> out how to optimize the exchange, such as allowing an EAP peer to
> simultaneously request tickets to multiple NAS devices.
> However, if you can figure all this out, there could be some tangible
> benefits -- in particular with Kerberos it is possible to ensure proper
> key binding, which is not easy to do with current approaches.  For
> example, a Kerberos ticket cannot easily be used by a NAS device other
> than the one it was created for.
> > 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.
> Remember that at one time Kerberos was mandatory to implement in IEEE
> 802.11i.  During that period there were lots of people will to work on
> Kerberos network access issues.  However after it became clear that
> Kerberos by itself could not meet the 802.11 security requirements, and
> also that work in the IETF was not moving forward at a reasonable pace,
> IEEE 802.11i voted to remove Kerberos as the mandatory to implement
> method.
> At this point, I doubt you will find much interest within the 802.11
> vendor community in revisiting Kerberos unless it can be demonstrated that
> Kerberos can provide some tangible benefit that isn't available
> with the fast handoff schemes being investigated in IEEE 802.11r.
> _______________________________________________
> SECMECH mailing list

Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager

SECMECH mailing list