Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

[Bernard Aboba <[e-mail]>]

> 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