Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

[Clint Chaplin <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/secmech
> 


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

_______________________________________________
SECMECH mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/secmech