Offline password attacks on AS-REQ - Kerberos

This is a discussion on Offline password attacks on AS-REQ - Kerberos ; Hi, In my company, we're pitching a Kerberos-based solution to authenticate tens of thousands of Linux users to Active Directory. To increase the likelihood of approval by the higher-ups, we really need to eliminate all perceived security holes. Although preauthentication ...

+ Reply to Thread
Results 1 to 11 of 11

Thread: Offline password attacks on AS-REQ

  1. Offline password attacks on AS-REQ

    Hi,

    In my company, we're pitching a Kerberos-based solution to authenticate tens of thousands of Linux users to Active Directory. To increase the likelihood of approval by the higher-ups, we really need to eliminate all perceived security holes.

    Although preauthentication helps some, Kerberos version 5 is susceptible to offline, brute force, password attacks on the initial AS-REQ. I saw some discussion about this from a few years ago in the archives, but nothing recently. Is there a solution to this issue yet? If not, what progress has been made, and what direction is being taken? I do have some familiarity with MIT Kerberos source code internals, having interfaced some the library's low-level profile and DNS SRV functions to hack out support for Microsoft's extended version of DNS SRV. Depending on how big the task is, I might be able to spend some time at work to code a solution.

    Thanks.

    Brian
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Offline password attacks on AS-REQ

    On Wed, Jun 15, 2005 at 02:04:19PM +0000, brian.joh@comcast.net wrote:
    > AS-REQ. I saw some discussion about this from a few years ago in the
    > archives, but nothing recently. Is there a solution to this issue
    > yet? If not, what progress has been made, and what direction is being


    If I remember correctly, the advice given back then was:
    - use hardware authentication
    - use SRP (a patent discussion followed)
    - implement a strong password policy

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  3. Re: Offline password attacks on AS-REQ

    > If I remember correctly, the advice given back then was:
    > - use hardware authentication
    > - use SRP (a patent discussion followed)
    > - implement a strong password policy


    We have thousands of users to manage, so we're looking for
    a solution which is pretty much transparent to the existing
    Linux user base. We'd prefer not to change our password
    policy, and we definitely can't distribute hardware to each
    user.

    My knowledge of SRP is very limited, but it seems like it's
    another separate authentication protocol. How were they
    going to "use it"? Were they going to integrate certain
    features of SRP? I don't understand.

    Thanks!


  4. Re: Offline password attacks on AS-REQ

    brian.joh@comcast.net wrote:
    >> If I remember correctly, the advice given back then was:
    >> - use hardware authentication
    >> - use SRP (a patent discussion followed)
    >> - implement a strong password policy

    >
    >
    > We have thousands of users to manage, so we're looking for
    > a solution which is pretty much transparent to the existing
    > Linux user base. We'd prefer not to change our password
    > policy, and we definitely can't distribute hardware to each
    > user.
    >
    > My knowledge of SRP is very limited, but it seems like it's
    > another separate authentication protocol. How were they
    > going to "use it"? Were they going to integrate certain
    > features of SRP? I don't understand.
    >
    > Thanks!


    In order to remove the ability to perform an offline attack
    you must either use a pre-authentication mechanism that is not
    based on using a fixed key derived from the user's password
    or you must tunnel the AS-REQ within a secure channel that
    protected by some non-Kerberos based authentication.

    The suggestions to use hardware authentication and SRP as
    pre-authentication mechanisms avoid the use of a fixed key
    derived from the password.

    The suggestion to use a strong password policy is to ensure
    that the time it takes to perform an offline brute force
    attack is sufficiently longer than the lifetime of passwords
    in your organization.

    There have been other proposals made within the IETF Kerberos
    Working Group. Unfortunately, due to existing patents and
    the deployment strategies of some vendors we have not been
    able to reach consensus on a single approach that would be
    interoperable for all.

    Jeffrey Altman


    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  5. Re: Offline password attacks on AS-REQ

    Tunneling sounds like the best option.

    We have over 500 Windows 2000 and Windows 2003 domain
    controllers (KDCs in Active Directory), that we don't want to have
    to modify or install new software on. These domain controllers
    (KDCs) do have SSL properly configured, so I suppose, we could
    tunnel the AS-REQ and AS-REP inside of SSL. I'll try this unless
    anyone knows of a better way, keeping in mind no major changes
    can be made to these Domain Controllers.

    Thanks!


  6. Re: Offline password attacks on AS-REQ

    brian.joh@comcast.net wrote:
    > Tunneling sounds like the best option.
    >
    > We have over 500 Windows 2000 and Windows 2003 domain
    > controllers (KDCs in Active Directory), that we don't want to have
    > to modify or install new software on. These domain controllers
    > (KDCs) do have SSL properly configured, so I suppose, we could
    > tunnel the AS-REQ and AS-REP inside of SSL. I'll try this unless
    > anyone knows of a better way, keeping in mind no major changes
    > can be made to these Domain Controllers.
    >
    > Thanks!
    >

    so how would one change the KDC to support SSL? the current kinit
    process only talk to udp/tcp 88, is there other proposals to do kinit?

    -peter

  7. Re: Offline password attacks on AS-REQ

    brian.joh@comcast.net wrote:

    > Tunneling sounds like the best option.
    >
    > We have over 500 Windows 2000 and Windows 2003 domain
    > controllers (KDCs in Active Directory), that we don't want to have
    > to modify or install new software on. These domain controllers
    > (KDCs) do have SSL properly configured, so I suppose, we could
    > tunnel the AS-REQ and AS-REP inside of SSL. I'll try this unless
    > anyone knows of a better way, keeping in mind no major changes
    > can be made to these Domain Controllers.
    >
    > Thanks!
    >


    I'm not sure how you would force all AS-REQ and AS-REP across an
    SSL tunnel. If you are this concerned, you should probably require
    IPSec when talking to your Domain controllers.

    Jeffrey Altman


    --
    -----------------
    This e-mail account is not read on a regular basis.
    Please send private responses to jaltman at mit dot edu

  8. Re: Offline password attacks on AS-REQ

    Honestly, I don't know much about SSL right now, but it was
    suggested to me by a coworker. I'm open to other ideas like
    IPSec.


  9. Re: Offline password attacks on AS-REQ

    We're not using kinit. We're basically writing our own progams
    built on the Kerberos libraries. However, I've looked at the source
    code to kinit when I was learning how to use the MIT libraries, and
    it would not be hard to modify.


  10. Re: Offline password attacks on AS-REQ

    There is PKINIT also.

    We did a "sslk5" in 1999 to use SSL authenticaiton to a KDC, then return
    an unencrypted ticket protected by SSL to the client. In this case the
    user was using X509 certificates for authenticaiton and no password. It
    was last updated for krb5-1.2.2 and OpenSSL-0.9.6. It can be found at:

    ftp://achilles.ctd.anl.gov/pub/DEE/s...2-20010827.tar

    It would not take much to use only server side certificates with TLS,
    and the KDC would return the AS_REP as usual but protected by SSL.
    With PRE_AUTH this should eliminate guessing attack. But there may need
    to be some binding between the TLS and Kerberos to avoid some MITM attacks.

    This work was done as part of the Globus project so users could get a Kerberos
    V5 ticket. In 99% of the cases the ticket was for AFS. It was droped in
    favor of the gssklog that could use the Globus GSSAPI to get a AFS token
    without KRB5, as 80% of the sites that had AFS did not have krb5
    and at that time did not want to setup a krb5 realm.

    It was also expected that PKINIT would replace the need for sslk5
    within a short time.


    peter huang wrote:
    > brian.joh@comcast.net wrote:
    >
    >>Tunneling sounds like the best option.
    >>
    >>We have over 500 Windows 2000 and Windows 2003 domain
    >>controllers (KDCs in Active Directory), that we don't want to have
    >>to modify or install new software on. These domain controllers
    >>(KDCs) do have SSL properly configured, so I suppose, we could
    >>tunnel the AS-REQ and AS-REP inside of SSL. I'll try this unless
    >>anyone knows of a better way, keeping in mind no major changes
    >>can be made to these Domain Controllers.
    >>
    >>Thanks!
    >>

    >
    > so how would one change the KDC to support SSL? the current kinit
    > process only talk to udp/tcp 88, is there other proposals to do kinit?
    >
    > -peter
    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >
    >
    >


    --

    Douglas E. Engert
    Argonne National Laboratory
    9700 South Cass Avenue
    Argonne, Illinois 60439
    (630) 252-5444
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  11. Re: Offline password attacks on AS-REQ

    Thanks, I'll definitely check that out.


+ Reply to Thread