Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

[Bernard Aboba <[e-mail]>]

> - What is the benefit of having a TGT as a result of the authentication for
> EAP?!! With native Kerberos, the TGT is used to get a service ticket from the
> TGS to access kerberized services. What would be here the kerberized service?!
> is it just the "network access"?! or is anyone planning to realize different
> kerberized services at layer 2? Is this a new requirement for 802.11?

IEEE 802.11i at one point mandated the use of Kerberos for network 
access using EAP-GSS and IAKERB.  The model was for the EAP peer to obtain 
both a TGT and TGS via EAP-GSS, then for the peer to authenticate to the 
NAS using the TGS.  This required the NAS devices (APs) to support 
Kerberos.

There was some discussion about whether the TGS would apply only to a 
single NAS, or to the "Network Access Service" in general.  That is, 
whether a TGS obtained for one NAS could be used at another NAS.  
If the TGS were reusable at multiple NASes, this would imply that those 
NASes shared a secret with the Kerberos server which represents poor 
hygene.  If the TGS is not reusable, then this implies that the EAP peer 
would need to obtain a new TGS for each NAS it wished to connect to, 
requiring a round-trip to the Kerberos server. 

In any case, after a great deal of investigation and negotiation with the 
IETF, IEEE 802.11i decided to remove mandatory support for Kerberos.  
Since this required a 75% vote, very strong sentiment against Kerberos was 
required for this.  As a result, I doubt that you will see 802.11 wishing 
to revisit Kerberos support in the near future. 

> - What would be the benefit of such a EAP-Kerberos (or EAP-IAKERB) method
> compared to existing EAP methods that are currently used, e.g. EAP-TTLS+PAP
> with a radius/diameter server at the end (except that this method might be a
> "misuse" of kerberos as mentioned earlier in this mailing list). What would be
> the arguments that would motivate operators to substitute their infrastructure
> with a new one supporting EAP-Kerberos or EAP-IAKERB?

EAP-Kerb/IAKERB/GSS is inherently different other EAP methods 
because it requires support for the method on the NAS.  That is, the NAS 
needs to support Kerberos for a peer to be able to submit a TGS to the NAS 
in order to obtain network access. 

Once an EAP peer has obtained a TGS and authenticated to one 
NAS, if proper Kerberos hygene is required, then for the EAP peer to do 
a handoff it needs to obtain TGSes for other NASes in the vicinity.  If 
there were a way to obtain multiple TGSes in an efficient way (as part of 
the original EAP authentication, or via a single request), then this could 
be the foundation of an approach to low latency handoff. 

However at this point, this is all water under the bridge, since Kerberos 
without PKINIT does not meet the security requirements of RFC 4017, and 
thus is not permitted within IEEE 802.11i.  This leaves vendors with 
little motivation to support it. 

> - Would PKINIT really be an advantage for EAP?! The point with PKINIT is that
> it supports authentication of the client with public key cryptography. But
> isn't this already covered by EAP-TLS?

PKINIT is the only acceptable Kerberos usage mode within RFC 4017.  
However, EAP-GSS with PKINIT requires changes to the NAS, 
which EAP-TLS does not.

> - Wouldn't be helpful to talk to the authors of the EAP GSS draft (Aboba) and
> find out why they stopped to work on this document?

We stopped work on the document because:

a) Kerberos did not meet the security criteria of RFC 4017 without PKINIT.
b) IEEE 802.11i did not want to require use of certificates. 
c) The CAT WG refused to advance IAKERB even after it had been included as 
   an implementation requirement within IEEE 802.11i and had been 
   implemented by at least one vendor.  This made it impossible for
   IEEE 802.l1i to satisfy its IETF dependencies since EAP-GSS depended
   on IAKERB. 
d) GSSAPI did not include a PRF function, which made it difficult to 
   generate an MSK/EMSK with the properties required by RFC 3748. 

> IMHO, it seems that it makes sense to combine different frameworks with
> different authentication mechanisms as intended by secmech. But I just would
> like to have some clarification, why this would be useful.

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