AS_REP question - Kerberos

This is a discussion on AS_REP question - Kerberos ; I'm continuing work on our NeXauth Product ( http://www.nexauth.com ) and I'm having a problem duplicating the Kerberos process. In reading the RFC's it seems as though the encrypted data in the packet should be able to be decrypted if ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: AS_REP question

  1. AS_REP question

    I'm continuing work on our NeXauth Product (http://www.nexauth.com) and
    I'm having a problem duplicating the Kerberos process.

    In reading the RFC's it seems as though the encrypted data in the
    packet should be able to be decrypted if we have the proper password.
    However, the encrypted data changes with every attempt we send, and we
    can't figure out which variable is changing.

    Is the timestamp somehow used in the encryption of the packet data (not
    the Ticket)? Is there a variable we're missing here?

    We're very close to being able to move our product to the next level,
    and we're having a problem decrypting the enc-data part of the packet.

    Any assistance would be much appreciated.

    Respectfully,
    Chris


  2. Re: AS_REP question

    --On Wednesday, September 21, 2005 07:07:03 -0700 NetSteady
    wrote:

    > In reading the RFC's it seems as though the encrypted data in the
    > packet should be able to be decrypted if we have the proper password.
    > However, the encrypted data changes with every attempt we send, and we
    > can't figure out which variable is changing.


    The contents of the EncryptedData is an EncKDCRepPart. The first item in an
    EncKDCRepPart is the randomly chosen EncryptionKey that the KDC picked as
    the ticket session key. In addition, the EncryptedData contains a
    counfounder (a random block prepended to the plaintext in lieu of using an
    initial vector in the cipher). The confounder needs to be stripped off as
    part of the decryption operation (but, IIRC, after the checksum is
    verified).

    Also, have you verified your string-to-key transformation against the test
    vectors in rfc3961?

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


  3. Re: AS_REP question

    I'm actually speaking about the enc-part of the Kerberos packet itself,
    not in the ticket. Is this the part you were speaking of?

    Our problem is that we're trying to validate the password for the user
    when we receive the AS-REP packet, but for some reason, we cannot find
    where to get the encryption key for the enc-part. We've read the RFCs
    (many many times) and are still having issues finding this.

    Suggestions?


  4. Re: AS_REP question

    On Sep 29, 2005, at 14:32, NetSteady wrote:
    > I'm actually speaking about the enc-part of the Kerberos packet
    > itself,
    > not in the ticket. Is this the part you were speaking of?


    Any EncryptedData object. The specs in RFC 3961 specify how
    encryption is done. For all (I believe) currently defined encryption
    systems, one block of random data is stuck on the front before CBC-
    mode encryption is done.

    > Our problem is that we're trying to validate the password for the user
    > when we receive the AS-REP packet, but for some reason, we cannot find
    > where to get the encryption key for the enc-part. We've read the RFCs
    > (many many times) and are still having issues finding this.


    (1) RFC 4120 section 5.4.2 says that the ciphertext is encrypted
    using the user's long-term key, which (we specify elsewhere) is
    generally derived from the password.

    (2) Simply decrypting the AS-REP isn't sufficient to validate the
    password if you're going to grant access to important resources based
    on it, unless you've got an unspoofable connection to the KDC (say,
    you're already running on the box with the KDC in it). Check Google
    for "Zanarotti attack"; basically, an attacker could spoof the KDC
    response and provide a password chosen by the attacker, and the
    decryption would succeed. You would need a service key on the device
    doing the verification, and a TGS-REQ exchange to get a ticket for
    that service, as part of a possible validation process.

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


  5. Re: AS_REP question

    We are just trying to replicate the proceses that Kerberos for Windows
    goes through, and the only traffic that we see from a windows machine
    to a Kerberos KDC is the AS-REQ and AS-REP exchange. The process is
    supposed to be as simple and fast as possible for password validation,
    as our possible implementations will serve locations with up to 100,000
    credentials.

    The pasword validation will act as part of a three-factor
    authentication. Username validation is only one of the factors, and the
    other two are VERY hard to spoof.

    On the other hand, does anyone know of an existing DLL that will allow
    us to make calls to it, processing the credentials?

    Chris


  6. Re: AS_REP question

    NetSteady wrote:
    > We are just trying to replicate the proceses that Kerberos for Windows
    > goes through, and the only traffic that we see from a windows machine
    > to a Kerberos KDC is the AS-REQ and AS-REP exchange. The process is
    > supposed to be as simple and fast as possible for password validation,
    > as our possible implementations will serve locations with up to 100,000
    > credentials.
    >
    > The pasword validation will act as part of a three-factor
    > authentication. Username validation is only one of the factors, and the
    > other two are VERY hard to spoof.
    >
    > On the other hand, does anyone know of an existing DLL that will allow
    > us to make calls to it, processing the credentials?
    >
    > Chris


    KFW does not perform password validation. The tickets obtained by KFW
    are not used as a sign of permission to logon to the machine. The
    tickets can only be considered validated after they have been used to
    authenticate to a service that has decrypted the portion of the ticket
    encrypted in the service principal's long term key.

    If you are using the ticket as part of a password validation, you must
    have a key for a service principal and you must obtain a service ticket
    for that principal and validate that you can decrypt it with the service
    principal's long term key.

    Take a look at krb5_verify_init_creds()

    Jeffrey Altman



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

+ Reply to Thread