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

From: "Salowey, Joe" <[email-masked]>
Date: Fri, 19 Aug 2005 10:31:51 -0700

> From: Nicolas Williams [mailto:[email-masked]] 
> On Wed, Aug 17, 2005 at 06:14:07PM -0400, Charles Clancy wrote:
> > Mechanism Bridges sounds like a hack to me.
> > 
> > IMHO, Framework Bindings sounds like the way to go.  It 
> gives you more 
> > control over which mechanisms are used in which frameworks.  Each 
> > framework has a different threat model, and not all mechanisms from 
> > one framework may be good in another.  For example, using 
> basic krb5 
> > in 802.11i-EAP is a bad idea because of dictionary attacks.
> 
> Sure, but you could always do 
> krb5-over-TLS-with-cryptographic-bindings.
>

[Joe] How would this be instantiated?  Currently EAP does not run over a
specific security layer.  There are EAP mechanisms that provide a secure
tunnel for running other mechanisms.  Would an EAP to GSS bridge have to
be a tunneling method?

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Aug 2005 13:05:40 -0500

On Fri, Aug 19, 2005 at 10:31:51AM -0700, Salowey, Joe wrote:
> [Joe] How would this be instantiated?  

Aren't there EAP methods for tunnelling over TLS?

Also, Kerberos V w/ PKINIT addresses the dictionary attacks issue as
well; I should have mentioned that earlier.

(Kerberos V pre-auth is extensible; the dictionary attacks on password
pre-auth issue is specific to one type of Kerberos V pre-auth, the one
standard type, of course, but PKINIT is another type.)

>                                        Currently EAP does not run over a
> tunnel for running other mechanisms.

That's what I was referring to.  Aren't these mechanisms there precisely
to provide protection to other mechanisms that otherwise would be unsafe
to use?

>                                       Would an EAP to GSS bridge have to
> be a tunneling method?

No.  But if some mechanism for which a bridge is being used requires
additional protection then tunnelling it over TLS or what have you would
be important.

Nico
--

---

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

On Fri, 19 Aug 2005, Salowey, Joe wrote:

>>> IMHO, Framework Bindings sounds like the way to go.  It gives you more 
>>> one framework may be good in another.  For example, using basic krb5 

Whatever happened to EAP-GSS?

http://www.drizzle.com/~aboba/IEEE/draft-aboba-pppext-eapgss-12.txt

"krb5->GSS-API->EAP-GSS->EAP-TTLS->EAP" would work.  Of course, the length 
of that string should be a motivator for bindings over bridges.

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

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 19 Aug 2005 16:03:08 -0500

> Whatever happened to EAP-GSS?

Dunno, but as I recall some of the KITTEN WG work is, in part, aimed at
making EAP-GSS possible, specifically the GSS_Pseudo_random() extension.

> of that string should be a motivator for bindings over bridges.

Yes, but replace 'krb5' with 'IAKERB' or soemthing like it.

Using slightly different (clearer?) notation, w/o PKINIT we have these
options (and maybe more):

EAP{EAP-TLS{EAP-GSS{GSS-API{GSS-IAKERB}}}}

or

EAP{EAP-GSS{GSS-API{GSS-TUNNEL{GSS-TLS,GSS-IAKERB}}}}

Where "GSS-IAKERB" is a GSS-API mechanism that does Kerberos V KDC
exchange proxying as necessary in order to establish service tickets for
Kerberos AP exchanges.  And where GSS-API channel bindings are used in
both cases to bind the Kerberos V AP exchanges to the TLS (or whatever)
tunnel.

Of course, with PKINIT no tunnelling would be necessary:

EAP{EAP-GSS{GSS-API{GSS-IAKERB}}}

Nico
--

---

From: Shumon Huque <[email-masked]>
Date: Fri, 19 Aug 2005 23:10:35 -0400

> Yes, but replace 'krb5' with 'IAKERB' or soemthing like it.

So for a standardized EAP method that supports Kerberos 
authentication, we are awaiting the following:

	- an updated GSS-API (for the pseudo random function)
	- an updated EAP-GSS mechanism that uses it
	- an updated IAKERB (for the AS and TGS exchanges)

And potentially running inside TLS to address the dictionary attack
vulnerability of the AS exchange.

I am very concerned that Kerberos sites are being pushed to deploy
network access authentication today, and there is no suitable option 
in sight for the forseeable future.

Regarding dictionary attack, is it the case that we won't standardize 
an EAP method that is vulnerable to it? Or is the objection motivated
by the fact that EAP is expected to be commonly used for wireless
LAN authentication? I hope it isn't the latter, because it is almost
as easy to eavesdrop on wired ethernets with ARP spoofing for example.

Kerberos has always assumed that the network is completely insecure
and the general defense against offline dictionary attack is strong
passwords. I agree that perhaps this isn't enough anymore. But then, 
I think the Kerberos community needs to work on standardizing password 
based pre-authentication mechanisms invulnerable to dictionary attack 
(perhaps EKE, AEKE, SPEKE, SRP etc). Hardware pre-authentication
mitigates the threat somewhat. But PKINIT isn't really an option for 
the many sites that don't plan to authenticate users with public key 
credentials (or deploy PKI).

At one time, some of us were talking about an EAP method that
transported Kerberos messages directly. It seems to me that putting
some effort into completing that work would be immediately useful
to Kerberos sites that need to deploy 802.1X or 802.11i soon.

---
Shumon Huque				3401 Walnut Street, Suite 221A,
Network Engineering			Philadelphia, PA 19104-6228, USA.
Information Systems & Computing		(215)898-2477, (215)898-9348 (Fax)
University of Pennsylvania / MAGPI.	E-mail: shuque -at- isc.upenn.edu

---

From: Nicolas Williams <[email-masked]>
Date: Sat, 20 Aug 2005 00:58:41 -0500

> passwords. I agree that perhaps this isn't enough anymore. But then, 

That's fair for Kerberos IV, but Kerberos V always allowed for new
pre-authentication methods, while Kerberos IV lacked even pre-auth.

> credentials (or deploy PKI).

Did you attend the SACRED WG meeting at IETF 63?

> to Kerberos sites that need to deploy 802.1X or 802.11i soon.

Indeed.  That would be an example of framework bindings of a security
mechanisms, as opposed to EAP-GSS, which would be a bridge.

Nico
--

---

From: Charles Clancy <[email-masked]>
Date: Sat, 20 Aug 2005 11:42:46 -0400

> 	- an updated IAKERB (for the AS and TGS exchanges)

A standardized tunneling method would be nice too.

Or, a generic Kerberos method secured with some KDC certificate, with 
bindings to EAP.

> vulnerability of the AS exchange.

Right.

> in sight for the forseeable future.

There are plenty of provisioning options.  For example, EAP-PAX could be 
bootstrapped by a kerberos password.  I've heard that MIT bootstraps PKI 
creds using a kerberos password -- those could be used for EAP-TLS.

Though, I agree no easy, out-of-the-box solution exists.

> as easy to eavesdrop on wired ethernets with ARP spoofing for example.

EAP methods vulnerable to dictionary attacks cannot be used with WLAN. 
See RFC 4017.  I don't think people are against standardizing a kerberos 
method, as long as people know it should be run in a tunnel -- much like 
EAP-MSCHAPv2.

> (perhaps EKE, AEKE, SPEKE, SRP etc). 

There are many intellectual property problems with these protocols. 
There are more complex protocols that don't suffer from the IP problems 
(http://eprint.iacr.org/2001/031.pdf) but they're more theoretical than 
practical.  Everything else requires a server-side certificate.

> to Kerberos sites that need to deploy 802.1X or 802.11i soon.

I've heard the same thing from other people as well.  Just make sure it 
runs in a tunneling method, or these directly transported kerberos 
messages are protected... DTLS maybe?

I think this is exactly the sort of thing SECMECH should be working on.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 22 Aug 2005 00:18:08 -0400

> Did you attend the SACRED WG meeting at IETF 63?

No, but I just read a summary of their session. The credential
mobility stuff isn't really relevant to (non PKINIT) Kerberos
sites. So I assume you are referring to the IPR issues with those
protocols. It sounds like there might be some hope though!

> mechanisms, as opposed to EAP-GSS, which would be a bridge.

Agreed.

Some folks at Penn are interested in working on an EAP-Kerberos 
method. Is there anyone else interested in this?

Thanks!
---

---

From: Shumon Huque <[email-masked]>
Date: Mon, 22 Aug 2005 00:42:55 -0400

> method, as long as people know it should be run in a tunnel -- much like 

I've read RFC 4017. My discomfort comes from the observation that
it is at best incomplete to point this out only for wireless LANs, 
since many of these vulnerabilities are applicable to other link 
layers too. If I use an EAP method that supports Kerberos on a 
wired ethernet for example, the dictionary attack threat still
exists. I do not find the differential magnitude of the threat a 
very convincing argument. It makes more sense to design security 
mechanisms with the uniform assumption that the network is always 
hostile.

This puts us in a position of having to say (whether we're using
EAP or not): "use Kerberos normally, except when running over 
link layers X, Y and Z, in which case you should run it only in 
a protected, cryptographically bound tunnel". If we need to address 
the dictionary attack problem, I think we should discuss how to 
do so in the Kerberos protocol directly. Perhaps that discussion 
belongs in another group though ..

I'm also not a fan of automatically assuming that a tunnel is the 
right solution for many problems. If we are tunnelling in TLS for 
example, I now have additional issues to deal with. Such as how to 
query up-to-date certificate revocation status, and whether my 
users are properly validating the certificates etc.

---

---

From: Charles Clancy <[email-masked]>
Date: Mon, 22 Aug 2005 08:36:44 -0400 (EDT)

On Mon, 22 Aug 2005, Shumon Huque wrote:

> I've read RFC 4017. My discomfort comes from the observation that it is 
> at best incomplete to point this out only for wireless LANs, since many 
> of these vulnerabilities are applicable to other link layers too. If I 
> use an EAP method that supports Kerberos on a wired ethernet for 
> example, the dictionary attack threat still exists. I do not find the 
> differential magnitude of the threat a very convincing argument. It 
> makes more sense to design security mechanisms with the uniform 
> assumption that the network is always hostile.

As a responsible cryptographer, I would never advocate using an 
authentication protocol vulnerable to dictionary attacks over any PHY. 
However, I recognize more than just crypto goes into deciding what 
protocol to deploy.  Were this true, everything would be one big PKI, and 
working groups like BTNS wouldn't exist.  If people want to shoot 
themselves in the foot, it would be nice to minimize the damage.

> belongs in another group though ..

I think something like "You SHOULD Kerberos in a cryptographically bound 
tunnel.  If you don't, you're vulnerable to offline dictionary attacks. 
These types of attacks are significantly easier to execute in some link 
layers, e.g. X, Y, and Z."

> users are properly validating the certificates etc.

I don't think SECMECH should try to change Kerberos, so all we can do is 
wrap something around it.  The two basic ways to fix dictionary attacks is 
public-key crypto with a server-side cert, or the IPR-riddled 
EKE/SPEKE/SRP protocols.  The latter would require Kerberos protocol 
changes.  Personally, I think a native EAP-Kerberos method that utilizes 
DTLS is the way to go.  In 802.11, it would look something like:

STA          AP           AAA          KDC
|------------|-------------|-------------|

       EAP(DTLS(krb5))           krb5
<-------------------------><------------->

     802.1X         AAA          krb5
<------------><-----------><------------->

As for CRLs, it's likely that one's AAA server and KDC will be of similar 
configuration, on the same subnet, or even the same machine.  If someone 
compromises your EAP server's private key, your KDC master secret won't be 
far behind.  So, if you're ever at a point where you need to worry about 
CRLs, you have bigger problems.  (Though, this argument doesn't 
necessarily apply to cross-real authentication, roaming, etc.)

---

From: Josh Howlett <[email-masked]>
Date: Mon, 22 Aug 2005 14:57:35 +0100

--On Monday, August 22, 2005 08:36:44 -0400 Charles Clancy 
<[email-masked]> wrote:
> Personally, I think a native EAP-Kerberos method that utilizes
> DTLS is the way to go.

Why not take something like TTLSv1 and define a Kerberos binding to it?

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: Mon, 22 Aug 2005 10:19:53 -0400 (EDT)

On Mon, 22 Aug 2005, Josh Howlett wrote:

> On Mon, 22 Aug 2005, Charles Clancy <[email-masked]> wrote:
>
>> Personally, I think a native EAP-Kerberos method that utilizes DTLS is 
>> the way to go.
>

I guess it's a tradeoff between outside dependencies and reinventing the 
wheel.  TTLS hasn't been on the list of EAP methods seeking 
standards-track action.  Regardless, this is another approach I personally 
would be willing to support.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 22 Aug 2005 15:49:42 +0100

--On Monday, August 22, 2005 10:19:53 -0400 Charles Clancy 
<[email-masked]> wrote:

> standards-track action.  Regardless, this is another approach I
> personally would be willing to support.

Out of curiousity, what are the advantages of using native Kerberos, rather 
than PAP inside a tunneled method which the AAA server verifies against the 
KDC? (this is how FreeRADIUS currently implements "Kerberos" 
authentication).

Perhaps I'm being a bit dim, but I feel like I'm missing the point.

Or is the point simply to define a mechanism that EAP and GSS can share?

josh.

---

From: Charles Clancy <[email-masked]>
Date: Mon, 22 Aug 2005 10:48:45 -0400 (EDT)

On Mon, 22 Aug 2005, Josh Howlett wrote:

> KDC? (this is how FreeRADIUS currently implements "Kerberos" authentication).
>

I'm not very familiar with this mechanism, but it doesn't like like you 
could get a TGT as a result of your authentication.

---

From: Josh Howlett <[email-masked]>
Date: Mon, 22 Aug 2005 16:00:59 +0100

> could get a TGT as a result of your authentication.

D'oh.

I was being dim :-)

thanks, josh.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 22 Aug 2005 11:06:04 -0400

On Mon, Aug 22, 2005 at 10:48:45AM -0400, Charles Clancy wrote:
> >Out of curiousity, what are the advantages of using native Kerberos, 
> >rather than PAP inside a tunneled method which the AAA server verifies 
> >against the KDC? (this is how FreeRADIUS currently implements "Kerberos" 
> >authentication).
> >

That's right. TTLS+PAP used in this way is performing Kerberos
password verification via the AAA server. It isn't native
Kerberos authentication. I know that it's commonly done, but
many consider it to be a misuse of Kerberos.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 Aug 2005 10:30:19 -0500

> protocols. It sounds like there might be some hope though!

The SACRED protocol wasn't the centerpiece of the meeting.  The issues
around strong password protocols, and alternatives, were.

> method. Is there anyone else interested in this?

I'd help review, of course.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 Aug 2005 10:38:16 -0500

> belongs in another group though ..

BTW, and for the benefit of lurkers and future readers of this list, the
password cracking issues, for Kerberos V apply only to the AS KDC
exchanges, and only when using PA-ENC-TIMESTAMP pre-auth.  And that's
relevant to EAP only because we all agree that we'd want to tunnel KDC
exchanges through EAP as that would be the only way to reach the KDC for
EAP client in many, many cases.

> users are properly validating the certificates etc.

Agreed.  But you can do other things too.  Like: ignore this issue at
first and do cryptographic binding between the inner and tunnel layers
and, if the result succeeds in real-time (assuming that offline password
dictionary attacks can't be done in real-time), "learn" the server cert;
the problem is what to do if the password-based mechanism fails...
(e.g., tell the user to call his/her helpdesk, which need not be as
easy for the user to do, or as likely that the user would actually do
it, as one might hope).

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 22 Aug 2005 10:40:44 -0500

> could get a TGT as a result of your authentication.

Exactly.  Plus, you don't get the benefit of new Kerberos V pre-auth
mechanisms, (e.g., PKINIT).

Nico
--

---

From: Ali Fessi <[email-masked]>
Date: Wed, 24 Aug 2005 18:50:13 +0200

Dear all,

I still don't get the point for using Kerberos as EAP method.

- 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?

- 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?

- 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?

- 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?

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.

Any comments are welcome!
Thanks,
Ali.
-- 
Ali Fessi
Computer Networks and Internet
Wilhelm Schickard Institute for Computer Science
University of Tuebingen, Germany
Phone: +49 7071 29-70534 / Fax: +49 7071 29-5220
EMail: [email-masked]
Web: http://net.informatik.uni-tuebingen.de/~fessi/

---

From: Charles Clancy <[email-masked]>
Date: Wed, 24 Aug 2005 13:45:19 -0400 (EDT)

> new requirement for 802.11?

Not only would it allow you to obtain a TGT, it would also allow you to 
use an existing TGT to get a "service ticket" for network access.  This is 
probably the less-likely scenario though, since talking to a KDC requires 
network access in the first place.

Consider the case of Win32 AFS on a laptop.  You sign onto the wireless 
network, and you can get a service ticket for AFS without having to 
reauthenticate to the KDC.

Another interesting idea would be to treat each 802.11i AP as a service, 
and you could obtain service tickets for them as you roam.

> cryptography. But isn't this already covered by EAP-TLS?

Well it gets you a TGT.  As long as you think getting a TGT is a good 
idea, then PKINIT would seem useful.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 13:27:05 -0500

> network access in the first place.

Think fast reconnection...  Not such an unlikely scenario, IMO :)

But the TGT could, and I expect would be useful after all the EAP
business is done.

Think of an IPsec VPN client that uses IKEv2 w/ EAP w/ EAP-IAKERB to
connect to the SG and which then also needs a TGT for other services in
the private network once the tunnel is up.  Here Kerberos V credentials
are useful for obtaining network access and also for obtaining access to
many other services one the network is up.

> and you could obtain service tickets for them as you roam.

Again, "fast reconnect."  The first connection requires an AS exchange
to get a TGT and a TGS exchange to get a service ticket, plus an AP
exchange to authenticate with the AP (oops, too many meanings for 'AP');
subsequent connections to the same AP prior to service ticket expiration
require only an AP exchange.

> idea, then PKINIT would seem useful.

Indeed.

Nico
--

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 11:59:41 -0700 (PDT)

> - 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. 

> different authentication mechanisms as intended by secmech. But I just would
> like to have some clarification, why this would be useful.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 12:03:43 -0700 (PDT)

> Not only would it allow you to obtain a TGT, it would also allow you to use an
> existing TGT to get a "service ticket" for network access.  This is probably
> the less-likely scenario though, since talking to a KDC requires network
> access in the first place.
 
EAP-GSS permitted an EAP peer to talk to the Kerberos server as part of 
the process of obtaining network access. 

> Another interesting idea would be to treat each 802.11i AP as a service, and
> you could obtain service tickets for them as you roam.

That's not a particularly appealing if each NAS requires a distinct 
TGS and each TGS requires a roundtrip between the peer and KDC.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 16:30:11 -0500

> a) Kerberos did not meet the security criteria of RFC 4017 without PKINIT.

Does tunnelling various other weak mechanisms over TLS meet said
criteria?

> b) IEEE 802.11i did not want to require use of certificates. 

Certificates != PKI, PKINIT does not require a PKI.

>    IEEE 802.l1i to satisfy its IETF dependencies since EAP-GSS depended

CAT WG closed years ago...

>    generate an MSK/EMSK with the properties required by RFC 3748. 

That's almost fixed.

Nico
--

---

From: Josh Howlett <[email-masked]>
Date: Wed, 24 Aug 2005 23:11:18 +0100

> TGS and each TGS requires a roundtrip between the peer and KDC.  

Does this also preclude RADIUS cross-realm roaming, unless there was a 
corresponding Kerberos cross-realm arrangement as well?

josh.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 15:40:17 -0700 (PDT)

> Does tunnelling various other weak mechanisms over TLS meet said

If "weak" means mechanisms that do not generate a key (e.g. 
MD5-Challenge), then these would violate RFC 4017 mandatory 
requirement 6:

   [6]  Protection against man-in-the-middle attacks.  This corresponds
        to the "Cryptographic binding", "Integrity protection", "Replay
        protection", and "Session independence" security claims defined
        in [RFC3748], Section 7.2.1.

> CAT WG closed years ago...

It appears that responsibility for IAKERB transitioned to the Kerberos WG 
once CAT WG was closed. 

The last version of IAKERB was submitted in October 2002:
http://www.watersprings.org/pub/id/draft-ietf-cat-iakerb-09.txt

The last version of EAP GSS was submitted in April 2002:
http://www.watersprings.org/pub/id/draft-aboba-pppext-eapgss-12.txt

On March 17, 2003 an IESG Draft Tracker entry shows that IAKERB was moved 
from the "Waiting for Writeup" state to the "AD is watching  :: Revised ID 
Needed" by Russ Housley, who inherited the document from Jeff Schiller. 

Another entry on March 17, 2003 shows that IAKERB was "Sent back 
to the WG for revision based on request that was received during the IETF 
56 session."  Minutes of the IETF 56 Kerberos WG are enclosed below. 

On February 13, 2004 another entry was entered indicating that "IAKERB is 
not going to come back to the IESG.  There is not any interest in the 
KRB-WG since the general solution is to use the Kerberos EAP mechanism."
On that same date, the status changed to "DEAD" from AD is Watching::ID 
Needed".  

-------------------------------------------------------------------------
Minutes of the Kerberos WG at IETF 56 San Francisco 

The Kerberos WG met on 3/17/2003 for about 1 and a half hours. In 
attendance where approximately 53 people. 

I talked on the IAKERB  about how it had been before the IESG, for over a 
year, but there has been some concerns about it.  It has being 
withdrawn, and will be considered again if there is  substantial 
interest. It should be update with regards to Extensions.  (Since then I 
realize I should not have made this statement.  I and the AD have been in 
contact with the author on this, and it is expected the draft will be 
resubmitted.) 

Sam further commented: 

"I don't believe that iakerb is likely to have any issues with 
clarifications, but the mode of iakerb that has reduced number of round 
trips is likely to be incompatible with extensions because extensions will 
integrity-protect  the request to make sure no changes are made."

"I believe that one of iakerb, EAP krb5, , EAP GSS should actually go 
forward.  Eap krb5 has been sketched out (although not publicly) but does 
not really exist within the IETF context.  EAP GSS has significant 
security issues and I hope it does not go forward at all.  Iakerb has 
significant esthetic issues that we have discussed to death here.  I think 
we should wait until there is clear interest either from the wireless or 
dialup community that they want to use Kerberos and then work on one of 
these mechanisms."

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 15:57:20 -0700 (PDT)

> > That's not a particularly appealing if each NAS requires a distinct TGS
> > and each TGS requires a roundtrip between the peer and KDC.  
> 

I think that also might be an issue, yes.

---

From: Charles Clancy <[email-masked]>
Date: Wed, 24 Aug 2005 20:13:31 -0400

Bernard Aboba wrote:
 >         to the "Cryptographic binding", "Integrity protection",
 >         "Replay protection", and "Session independence" security
 >         claims defined in [RFC3748], Section 7.2.1.

I guess there are two points of view -- one where the AP is the service, 
and one where the EAP server is the service.

If the EAP server is the service, then it can do a passthrough Kerberos 
authentication for the EAP client.  The client can obtain a TGT and a 
service ticket for the EAP server, and then authenticate to the EAP 
server using the service ticket.  The key contained within that service 
ticket is known only by the client and the EAP server, so it could 
theoretically then be used to bootstrap an EAP key derivation, including 
the info needed by TTLS to do the crypto binding.  TTLS would then 
augment the security of these keys using its own entropy, and poof.

... or am I missing something?

---

From: Charles Clancy <[email-masked]>
Date: Wed, 24 Aug 2005 21:28:21 -0400

Bernard Aboba wrote:
>>authentication for the EAP client.  The client can obtain a TGT and a service
>>ticket for the EAP server, and then authenticate to the EAP server using the
>>service ticket.  The key contained within that service ticket is known only by
>>the client and the EAP server, so it could theoretically then be used to
>>bootstrap an EAP key derivation, including the info needed by TTLS to do the
>>crypto binding.  TTLS would then augment the security of these keys using its
>>own entropy, and poof.
>>
> EAP methods need to be "mode independent" which implies that they need to 
> work the same way regardless of whether an authentication server is 
> present or not.  If an AS is not present, then the EAP server resides on 
> the NAS, and the EAP peer would be providing a clear text password to the 
> NAS. 
> 
> "AAA Key Management" (draft-housley-aaa-key-mgmt-00.txt) talks about 
> preventing cascading vulnerabilities.  One of the requirements is that 
> compromise of one NAS not compromise long-term credentials. 
> 
> Providing a cleartext password to a NAS seems like it would violate that 
> requirement. 

Why would the cleartext password ever end up on a NAS?

Maybe a picture would help:

EAP Client          EAP Server           KDC
--------------------------------------------

     TTLS Negotiation
<----------------------->

krb5 authentication (EAP server is passthrough)
<------------------------------------------>

                          TGT, service ticket
<-------------------------------------------

       service auth
<----------------------->

{MK,MSK} = PRF(service key)

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 17:30:09 -0700 (PDT)

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 19:03:21 -0700 (PDT)

> Why would the cleartext password ever end up on a NAS?

If the NAS terminates the TTLS tunnel, and PAP is negotiated within TTLS 
this can happen. 

> EAP Client          EAP Server           KDC

Is the assumption here that an EAP-Kerberos method is run within the TTLS 
tunnel, thereby protecting the Kerberos exchange?  If so, then this mode 
of interaction protects the Kerberos exchange from dictionary attack.

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 23:13:50 -0500

> the NAS, and the EAP peer would be providing a clear text password to the 

So, there could (should?) be a standard framework for transporting key
material from the EAP server to the NAS, yes?  Is this covered in the
EAP key management I-D?  Or does every EAP method have to provide its
own EAP-server-->NAS key transport protocol?

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 24 Aug 2005 23:21:06 -0500

> MD5-Challenge), then these would violate RFC 4017 mandatory 

No, I used "weak" to mean mechanisms that are subject to off-line
dictionary attacks by eavesdroppers or MITMs.

> [...]

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.

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.

> dialup community that they want to use Kerberos and then work on one of 

The EAP GSS issues Sam mentions are addressed by KITTEN WG work, namely
GSS_Pseudo_random() (which reminds me, I have to update that I-D so we
can finish WGLC on that already).

The last IAKERB I-D turns out to have problems with Kerberos V
extensions exactly as Sam described them way back at IETF 56.  But
there's no reason that we couldn't fix this.

Nico
--

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 16:53:08 +0300

>own EAP-server-->NAS key transport protocol?
EAP keying framework explains how the system works
regarding methods, eap, clients, nases, an authentication
servers. It also analyses the security properties. But the
actual key transport is defined in the AAA space. There's
only one proposed standard for this (Diameter EAP), and
one old vendor-specific attribute for RADIUS.

So, from the point of view of the methods, they just export
a key, and AAA will transport it to the NAS.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 25 Aug 2005 16:53:37 +0300

>users are properly validating the certificates etc.
Given choice, I'd rather have a well-design fully
capable mechanisms than a tunnel + a mechanism
that needs to run inside the tunnel.

--Jari

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 22:44:22 -0700 (PDT)

> own EAP-server-->NAS key transport protocol?

The mechanisms for transporting EAP keying material from the AAA server to 
the NAS are described in RFC 4072 (Diameter EAP) and RFC 2548.  
These former is a Proposed Standard; the latter describes RADIUS VSAs that 
are in widespread usage.  These mechanisms are independent of the EAP 
method. 

The principle of method independence (and other EAP key  management 
issues) are described in the EAP Key Management Framework document.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Aug 2005 23:26:15 -0700 (PDT)

> 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. 

>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. 

> 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.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 25 Aug 2005 11:19:23 -0400

> that needs to run inside the tunnel.

I completely agree. However, current options don't look good 
for Kerberos 5, unless a strong password based pre-authentication
mechanism is developed. So, I'm willing to endorse the scheme
of running Kerberos inside TLS, at least as an interim measure
(ala Tom Clancy's recent diagram).

--Shumon.

---

From: Josh Howlett <[email-masked]>
Date: Thu, 25 Aug 2005 16:33:11 +0100

> (ala Tom Clancy's recent diagram).

IIRC, it was inside TTLS. However, it might it still be worth considering 
an EAP-Kerberos so as not to preclude the option of running it inside PEAP 
as well (even if native EAP-Kerberos is a Bad Idea over 802.11). It might 
also provide the basis for a subsequent improved Kerberos EAP method that 
could be used natively.

josh.

---

From: Clint Chaplin <[email-masked]>
Date: Sat, 27 Aug 2005 12:28:00 -0700

Boy, does this all sound familiar....

I know of one IEEE 802.11i vendor that developed and sold a Kerberos
solution for security/authentication.

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

---

From: "1und1" <[email-masked]>
Date: Sun, 28 Aug 2005 12:14:00 +0200

> From: "Clint Chaplin" <[email-masked]>
> To: "Bernard Aboba" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Saturday, August 27, 2005 9:28 PM
> Subject: Re: [SECMECH] Framework Bindings Vs. Mechanism Bridges

> solution for security/authentication.

Which company is this? Symbol?

Symbol.com sells a Kerberos-based solution, but it seems to be proprietary
and
not  compliant with IEEE 802.11i.

I asked in Juli sth for EAP-Kerberos, Tim Alsop answered
( http://www.mail-archive.com/[email-masked]/msg08763.html )

<snip>
Thomas,

Perhaps you need to look at the solution implemented by Symbol
(www.symbol.com). Their WLAN products already use kerberos for WLAN
authentication and key management as an alternative to WEP. The normal
approach with WEP is to share a secret between the AP and WLAN client,
but with Kerberos the session key can be used instead. The WLAN
connection to the network through the access point should not be
accepted until the user has authenticated to the AP. This is the Symbol
approach, but they are not using EAP. Instead they have implemented
Kerberos in the firmware of their products. I would love to see Kerberos
implemented for same solution using EAP-GSS so that more WLAN vendors
can take advantage and gain SSO and strong key management for WLAN
authentication.

Regards, Tim
</snip>

---

From: Charles Clancy <[email-masked]>
Date: Sun, 28 Aug 2005 14:15:21 -0400

1und1 wrote:

> and not compliant with IEEE 802.11i.
> 

Hmm... I doubt they're protecting their Kerberos with TLS... proprietary 
password-based wireless authentication mechanisms likely vulnerable to 
dictionary attacks... LEAP deja vu?