Subject: One Time Passwords and Kerberos Issues

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 20 Aug 2004 10:09:20 -0500

I would like to point the WG at this paper on One Time Passwords:

http://www.doegrids.org/CA/Research/OTP-final.pdf

It has some interesting comments on Kerberos, and the facts
that stolen credentials can be misused. This is similar to
the point I was making in my talk:  "Self Imposed Limitations
of Kerberos" at the IETF this month.

To keep Kerberos viable the WG (and vendors) need to address
the issues of:

  o User imposed limits on the use of credentials both
    initial and delegated.

  o The ability to move the granting of initial tickets to
    some hardware token/smartcard/pda/... thus avoiding many
    of the problems with maintenance of the user's workstation.

  o The ability of the user to require notification or
    approval of delegation of new credentials. This
    might require all delegated credentials to delegated
    via the above token/smartcard/pda/... or the workstation
    issuing the initial credential.

  o The tracking of delegated credentials, to keep track not
    only of what realms where involved, but what hosts where
    involved.

The intent of the above is to keep the single signon capabilities
for the user yet improve the security by limiting the damage
that could be done by compromised systems.

And if you think people can't get around OTPs check this out:
  http://fob.webhop.net/
and look at the FobCam Live!

-- 

  Douglas E. Engert  <[email-masked]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

---

From: Sam Hartman <[email-masked]>
Date: Fri, 20 Aug 2004 12:18:27 -0400

>>>>> "Douglas" == Douglas E Engert <[email-masked]> writes:

    Douglas>   o The ability to move the granting of initial tickets
    Douglas> to some hardware token/smartcard/pda/... thus avoiding
    Douglas> many of the problems with maintenance of the user's
    Douglas> workstation.
I pointed this out to Doug in person, but for the record I'll say it
here.  I think that having real host security is a better solution to
this problem than delegating functionality to some hardware token.
What we're effectively talking about is making parts of Kerberos be
inside the TCB.

I think Doug's argument is that today's operating systems don't have a
strong TCB boundary to speak of.

I think today's OS vendors realize they will not be long viable if
they cannot establish a reasonable TCB boundary.  I think that Redhat
has certainly made market decisions that make it clear they realize
this.  I believe Sun likewise is moving to improve host security.

How many compromises of Windows actually involve compromises of the
LSA?  I'd expect the answer is fairly small.

Vendors do need to take advantage of host security improvements as
they become available.  Not surprisingly, many aspects of this will be
similar to aspects of trying to implement moving Kerberos off onto
some smart token.

--Sam

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 20 Aug 2004 11:57:41 -0500

> strong TCB boundary to speak of.

Yes that is part of it. If current OSs had been harder to break then we
would not have this problem. But the same security protocols are being
run on older OS, or OSs which are not being patched.

So, how do the stake-holders in any authentication/authorization
decision know that the OS being used by the user has the improved
security?  They don't. So what they do is to force the use of
devices or methods which are outside the OS, such as smartcards or
OTP tokens. The devices can then be issued to the user, so the
stake-holder has reasonable confidence that it meets their security
needs.

> similar to aspects of trying to implement moving Kerberos off onto

Yes they are many of the same issues. In effect you are proposing that
the harding of the OS in effect could turn the OS in to the equivalent
of the smartcard or token, thus avoiding the need for these devices.

I am saying it may be to late because trust of the OS, the OS
vendors and trust in up to date maintenance of the OS has been lost
at least for now.

I am also saying that the trust of the device may be greater because
it is simpler, and it can be issued by a site, avoiding maintenance
issues or large OSs.

Kerberos needs to be part of what ever is the first device a user
uses for authentication, be it a token, or a harden OS.

--

---

From: Matt Crawford <[email-masked]>
Date: Fri, 20 Aug 2004 12:08:52 -0500

>  o User imposed limits on the use of credentials both

This would be a nice thing, but we can't expect users to make the 
necessary decisions.  Applications will have to help them out quite a 
bit.  And that means app writers can't take the lazy option of "always 
delegate, with full strength.

>    of the problems with maintenance of the user's workstation.

You mean the dongle holds the ticket and lets it be used when needed?  
What saves you from corrupt host software accessing the dongle 
maliciously?  Certainly not user alertness!

I don't think there's any amount of smartcard smartness that can save 
the average user from a compromised host.

---

From: "Douglas E. Engert" <[email-masked]>
Date: Fri, 20 Aug 2004 13:30:56 -0500

> delegate, with full strength.

Yes that is a problem. So traditionally the decisions are made for them,
The traditional approach is to have multiple  userids and passwords for
each site. Yet this has problems for the users too, they can use the
same password everywhere or send the passwords over the net to accomplish
some connection they can't normally do.

> You mean the dongle holds the ticket and lets it be used when needed?  

Sort of. Maybe the dongle has the TGT, and gets involved in any
delegation or issuance of a service ticket on behalf of the user.

The dongle may have some I/O and logging capability of its own.
current smartcards don't have either or a clock. They are at the
mercy of the device they are plugged into. At the other extreme is
the harden user's workstation does it all.  i.e. think of a PC booting
from a CD, of an X-term booting from ROM. These would be hard to
compromise.

One of our people has a cell phone with SSH! So why
can't a dongle have Kerberos, and have to get involved in
any issuance of a service ticket, or delegated credential?

The point is the dongle, or first point of security device
need to have some capabilities that can be trusted by stake-holders.

> the average user from a compromised host.

What saves him is that host has limited credentials. The damage is
limited to what can be done with the delegated credentials. The trick
is to decied how credentials are limited, or to control the
accesses of the host to what was intended by the user.

--