Subject: RE: [SECMECH] Framework Bindings Vs. Mechanism Bridges

From: "Salowey, Joe" <[email-masked]>
Date: Thu, 25 Aug 2005 20:48:57 -0700

> 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. 
> 
[Joe] I'm not quite sure what you mean. If a AAA server is not involved
then this is not really any different than terminating EAP-TLS on a NAS.
It could also be possible to still involve a AAA and have it terminate
the method and talk to the KDC. If you are trying to implement a method
that is evaluated by both the NAS and the AAA in the same transaction
you are really doing something other than EAP. 

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

---

From: Nicolas Williams <[email-masked]>
Date: Thu, 25 Aug 2005 23:50:52 -0500

> you are really doing something other than EAP. 

I agree.  It isn't even the case that the peer's realm would have to
have a cross-realm Kerberos V path to the NAS's realm; if there was an
x-realm path from the EAP peer to the NAS then the NAS could just be the
EAP server.  And if there be no such x-realm path then the NAS need not
even know a thing about Kerberos V.

Or am I missing some way in which EAP-Kerb/IAKERB/GSS is fundamentally
different from existing EAP methods [in some bad way]?

Nico
--

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Aug 2005 23:40:04 -0700 (PDT)

> then this is not really any different than terminating EAP-TLS on a NAS.

It's different because the NAS needs to support Kerberos even if it is 
operating in "Pass-through" mode.  In contrast, a NAS operating in 
pass-through mode for EAP-TLS doesn't need to validate the client 
certificate. 

> you are really doing something other than EAP. 

In all the EAP Kerberos proposals I've seen the method is terminated on
either the NAS or AAA server, but not both.  But in any scenario, the
NAS still needs to support Kerberos, in order to validate the "network
access" service ticket.

---

From: Shumon Huque <[email-masked]>
Date: Fri, 26 Aug 2005 10:32:14 -0400

> NAS still needs to support Kerberos, in order to validate the "network

The AAA server could perform the service ticket validation on
behalf of the NAS. This requires another round trip with the 
AAA server, but I don't think this is too much of a problem.
If we need the NAS to support Kerberos, then I think the barrier 
to practical deployment is too high. Or am I missing something?

---

From: Josh Howlett <[email-masked]>
Date: Fri, 26 Aug 2005 15:34:43 +0100

> NAS still needs to support Kerberos, in order to validate the "network

Just to clarify - it would be possible for the AAA server to authenticate 
against the KDC and return an EAP-Success to the NAS as per other EAP 
types, without the NAS needing to understand Kerberos. However, the NAS 
would need to understand Kerberos in order to allow a service ticket to be 
used for, ie, fast reconnect (...which is undesirable for secret hygene).

Right?

josh.

-- 
-----------------------------------------------------------
Josh Howlett, Networking & Digital Communications,
Information Systems & Computing, University of Bristol, U.K.
'phone: 0117 928 7850 email: [email-masked]
------------------------------------------------------------

---

From: Charles Clancy <[email-masked]>
Date: Fri, 26 Aug 2005 10:43:27 -0400 (EDT)

On Fri, 26 Aug 2005, Josh Howlett wrote:

> against the KDC and return an EAP-Success to the NAS as per other EAP types, 
> without the NAS needing to understand Kerberos. However, the NAS would need 
> to understand Kerberos in order to allow a service ticket to be used for, ie, 
> fast reconnect (...which is undesirable for secret hygene).

Using NAS-terminated Kerberos for fast handoff/reconnect is probably not a 
good idea due to the round trips, unless the NAS service ticket could be 
preemptively acquired.

I think EAP-Kerberos should be terminated at the AAA server.  Your service 
ticket is for "network access", not a particular NAS.  The key contained 
within the service ticket could be used to bootstrap the traditional EAP 
keying.  If you wanted fast reconnect or fast handoff, you could build it 
into the method by computing something like:

   initial key generation:
     MK = PRF(service key, "master key", nonces)
     MSK_1 = PRF(MK, "master session key", nonces)

   handoff:
     MSK_2 = PRF(MK, "new master session key", MSK_1 + nonces)

Then the NAS doesn't need to know anything about Kerberos.

[ t. charles clancy ]--[ [email-masked] ]--[ www.cs.umd.edu/~clancy ]
[ computer science ]-----[ university of maryland | college park ]

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 08:00:41 -0700 (PDT)

> AAA server, but I don't think this is too much of a problem.

How does the EAP peer figure out the scope of usage of the "network access 
service" ticket?  If each NAS is a separate Kerberos principal, then the 
peer needs a distinct ticket for each NAS;  if the AAA server is the 
principal, then it can submit the same ticket to any NAS. 

> to practical deployment is too high. Or am I missing something?

I think that the NAS needs to be modified even in the case where the AAA 
server is the Kerberos principal, in order to be able to securely inform 
the EAP peer of the ticket scope.  Otherwise, the EAP peer can't know when 
it needs to acquire another ticket.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 08:06:14 -0700 (PDT)

> without the NAS needing to understand Kerberos. However, the NAS would need to
> understand Kerberos in order to allow a service ticket to be used for, ie,

Yes, if the NAS needs to act as a Kerberos principal, it needs to support 
Kerberos.  Note that "fast handoff" typically refers to situations in 
which the AAA server does not need to be contacted during a handoff.  If 
the EAP peer needs to obtain a new ticket for each NAS, and each ticket 
request requires a round-trip to the KDC, that is not "fast handoff" as 
the term is normally used.  If in addition the NAS needs a round-trip to 
the AAA server in order to validate each ticket (e.g. the case where the 
AAA server is the service principal) then an EAP-Kerberos scheme will 
perform more poorly than existing EAP methods.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 08:14:54 -0700 (PDT)

> keying.  If you wanted fast reconnect or fast handoff, you could build it into
> the method by computing something like:
> 
> initial key generation:

This scheme allows for reuse of the initial Kerberos ticket, at the 
expense of a round-trip between the NAS and AAA server on each handoff. 

However, the Kerberos session key is no longer bound to a 
particular NAS -- this is the "Key binding" requirement in 
draft-housley-aaa-key-mgmt-00.txt.  

Also, the AAA server now needs to keep a cache of Kerberos session keys.

---

From: Charles Clancy <[email-masked]>
Date: Fri, 26 Aug 2005 14:16:51 -0400 (EDT)

> Also, the AAA server now needs to keep a cache of Kerberos session keys.

The Kerberos session key and consequently MK is bound to the EAP server, 
as the Kerberos is terminated at the EAP server, right?  It's a service 
ticket for the EAP server, not a particular NAS, so that would seem 
logical.  The MSKs can be bound to the individual NASes.  Should the NAI 
(or some other identifier) of the NAS be explicitly included in the PRF?

Personally, I don't see how this is any different than any other EAP 
method, once you generate the MK.  Fast handoff in an EAP method, and not 
at the link layer, would have to involve AAA.  Otherwise you would need 
Diffie-Hellman to provide the forward secrecy.  Without it, any NAS 
through which a client roamed would be able to derive their future keys 
and decrypt their sessions.

As for maintaining a cache -- the AAA server would have to maintain a 
cache of MKs for authenticated clients, presumably with some associated 
lifetime.  I'd think any fast reconnect scheme would require something 
similar, unless you were going to authenticate from scratch.

Or, am I missing the point?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 11:54:56 -0700 (PDT)

> The Kerberos session key and consequently MK is bound to the EAP server, as
> the Kerberos is terminated at the EAP server, right?  It's a service ticket
> for the EAP server, not a particular NAS, so that would seem logical.  The
> MSKs can be bound to the individual NASes.  Should the NAI (or some other
> identifier) of the NAS be explicitly included in the PRF?
> 
> Personally, I don't see how this is any different than any other EAP method,
> once you generate the MK.  Fast handoff in an EAP method, and not at the link
> layer, would have to involve AAA.  Otherwise you would need Diffie-Hellman to
> provide the forward secrecy.  Without it, any NAS through which a client
> roamed would be able to derive their future keys and decrypt their sessions.
> 
> As for maintaining a cache -- the AAA server would have to maintain a cache of
> MKs for authenticated clients, presumably with some associated lifetime.  I'd
> think any fast reconnect scheme would require something similar, unless you
> were going to authenticate from scratch.
> 

As noted in the EAP Key Framework document, the EAP layer does not cache 
exported EAP keying material, either on the client or the server.  Caching 
is only permitted in the lower layer (AAA is a lower layer from the EAP 
perspective). 

Several proposed fast handoff schemes require caching on the AAA server, 
including pre-emptive handoff and key request. 
  
However, AAA servers today do not cache EAP keying parameters  -- they discard 
all EAP keying material (not just the transported keying material) once they 
send the MSK to the NAS.  So asking the AAA server to implement a key 
cache is a significant change from the existing architecture. 

This doesn't mean it can't or shouldn't be done -- but a change that 
substantial shouldn't be done on an adhoc basis.  Some open questions:

a. How does the peer know what AAA server it is dealing with?  The EAP Key 
Framework has added the Server-ID parameter to enable the peer to know 
this, but not all EAP methods define this parameter.  Do we want fast 
handoff to only be supported for methods with a defined Server-ID? 

b. How does the peer request that the NAS contact a particular AAA server 
(either for requesting a key or validating a ticket)?  Does it include the 
Server-ID in the message? 

c. How does the AAA server validate that the ticket is being used by the 
EAP peer that it granted access to?  Do we require that the peer NAI be 
the same as the Kerberos Principal name of the peer?  Do we require that 
the Server-ID be the same as the Kerberos Principal name of the AAA 
server? 

d. How does the peer know whether a particular NAS is configured to 
connect to a AAA server from whom it has received a ticket?

---

From: Charles Clancy <[email-masked]>
Date: Fri, 26 Aug 2005 15:19:15 -0400 (EDT)

> exported EAP keying material, either on the client or the server. 
> Caching is only permitted in the lower layer (AAA is a lower layer from 
> the EAP perspective).

Ah, there was the point I missed.

> However, AAA servers today do not cache EAP keying parameters -- they 
> discard all EAP keying material (not just the transported keying 
> material) once they send the MSK to the NAS.  So asking the AAA server 
> to implement a key cache is a significant change from the existing 
> architecture.

I've implemented fast handoff using PMK caching for EAP-TLS on FreeRADIUS 
with minimal difficulty.  Your points extend beyond the functionality 
offered by my previous efforts in that it allows for an architecture where 
a NAS could contact multiple AAA servers.

> a. How does the peer know what AAA server it is dealing with?  The EAP 
> Key Framework has added the Server-ID parameter to enable the peer to 
> know this, but not all EAP methods define this parameter.  Do we want 
> fast handoff to only be supported for methods with a defined Server-ID?

Well so far we've been talking about fast handoff in EAP-Kerberos.  So, 
I'd imagine EAP-Kerberos would need to implement the Server-ID field.

Although note that my protocol sketch below doesn't require using the 
Server-ID field.

> b. How does the peer request that the NAS contact a particular AAA 
> server (either for requesting a key or validating a ticket)?  Does it 
> include the Server-ID in the message?

The EAP-Response/Identity could be formatted in some way to include the 
desired AAA server.  Personally, I say we shouldn't worry about this case. 
If someone roams to a NAS that has a different default AAA server, then 
they should reauthenticate.  This functionality could also be added later, 
if deemed necessary, since it seems outside the scope of the method, and 
would involve changes in EAP itself.

> the Server-ID be the same as the Kerberos Principal name of the AAA

Assuming the AAA server has cached the MK, I'd imagine something similar 
to:

   (Client <- Server) ID Request
   (Client -> Server) ID Response
   (Client <- Server) EAP-Krb5(fast reconn available, keyid=hash(MK),
                               A=nonce)

Then if client has keyid cached:

   (Client) {MSK,K} = PRF(A,B,MK)
   (Client -> Server) EAP-Krb5(fast reconn ACK, B=nonce, hash(A,B,K))
   (Server) {MSK,K} = PRF(A,B,MK)
   (Client <- Server) EAP-Krb5(ACK, hash(B,K))
   (Client -> Server) EAP-Krb5(ACK)
   (Client <- Server) EAP-Success
   (NAS <- Server) AAA(MSK)

Or if keyid is not found:

   (Client -> Server) EAP-Krb5(fast reconn NACK)
   (Client <-> Server) EAP-Krb5(full kerberos authentication)

> connect to a AAA server from whom it has received a ticket?

I say it shouldn't know.  If the NAS connects to the right AAA server, 
then the above will happen.  Otherwise it won't.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 26 Aug 2005 12:36:19 -0700 (PDT)

> I say it shouldn't know.  If the NAS connects to the right AAA server, then
> the above will happen.  Otherwise it won't.

In order to minimize handoff times, the EAP peer needs to know which NASes 
it has a valid key for, so that it can choose to roam to those NASes in 
preference to ones it has no key for. 

Having said that, IEEE 802.11r is currently looking at advertising that 
kind of information (e.g. NAS-Identifer, other scope parameters).  So it 
is conceivable that the EAP peer could know whether a given NAS could talk 
to a given AAA server before attempting to use a ticket with it.