Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

Clint Chaplin <clint.chaplin@gmail.com> Sat, 27 August 2005 19:28 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96Li-0000Ql-Az; Sat, 27 Aug 2005 15:28:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E96Le-0000Qc-Mk for secmech@megatron.ietf.org; Sat, 27 Aug 2005 15:28:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26746 for <secmech@ietf.org>; Sat, 27 Aug 2005 15:28:12 -0400 (EDT)
Received: from wproxy.gmail.com ([64.233.184.203]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E96Me-0000LM-0B for secmech@ietf.org; Sat, 27 Aug 2005 15:29:16 -0400
Received: by wproxy.gmail.com with SMTP id 36so137241wra for <secmech@ietf.org>; Sat, 27 Aug 2005 12:28:01 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; 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 10.54.48.24 with SMTP id v24mr4801216wrv; Sat, 27 Aug 2005 12:28:00 -0700 (PDT)
Received: by 10.54.79.3 with HTTP; Sat, 27 Aug 2005 12:28:00 -0700 (PDT)
Message-ID: <d4083f6605082712282a55f198@mail.gmail.com>
Date: Sat, 27 Aug 2005 12:28:00 -0700
From: Clint Chaplin <clint.chaplin@gmail.com>
To: Bernard Aboba <aboba@internaut.com>
Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges
In-Reply-To: <Pine.LNX.4.61.0508242244440.1628@internaut.com>
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> <430CA545.3020109@uni-tuebingen.de> <Pine.LNX.4.61.0508241113420.16086@internaut.com> <20050824213010.GO10174@binky.Central.Sun.COM> <Pine.LNX.4.61.0508241436250.21720@internaut.com> <20050825042105.GW10174@binky.Central.Sun.COM> <Pine.LNX.4.61.0508242244440.1628@internaut.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027
Content-Transfer-Encoding: quoted-printable
Cc: secmech@ietf.org
X-BeenThere: secmech@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Security mechanisms BOF <secmech.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/secmech>
List-Post: <mailto:secmech@lists.ietf.org>
List-Help: <mailto:secmech-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/secmech>, <mailto:secmech-request@lists.ietf.org?subject=subscribe>
Sender: secmech-bounces@lists.ietf.org
Errors-To: secmech-bounces@lists.ietf.org

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 <aboba@internaut.com> 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:
> 
> MANDATORY
> 
>    [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.
> 
> RECOMMENDED
> 
>    [8]  Fragmentation.
>    [9]  End-user identity hiding.
> 
> OPTIONAL
> 
>    [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
> SECMECH@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/secmech
> 


-- 
Clint (JOATMON) Chaplin
Wireless Security Technologist
Wireless Standards Manager

_______________________________________________
SECMECH mailing list
SECMECH@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/secmech