kadmin ktadd -e keysaltlist for des-cbc-md5 - Kerberos

This is a discussion on kadmin ktadd -e keysaltlist for des-cbc-md5 - Kerberos ; I'm trying to get a keytab with des-cbc-md5 encryption (no salt) from our kerberos 1.5 realm for a CyberSafe client. How do I specify the ktadmin ktadd command's "-e keysaltlist" parameter? I tried variations on "ktadd -k -e ENCTYPE_DES_CBC_MD5:NONE", but ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: kadmin ktadd -e keysaltlist for des-cbc-md5

  1. kadmin ktadd -e keysaltlist for des-cbc-md5

    I'm trying to get a keytab with des-cbc-md5 encryption (no salt) from our
    kerberos 1.5 realm for a CyberSafe client. How do I specify the ktadmin
    ktadd command's "-e keysaltlist" parameter? I tried variations on "ktadd -k
    -e ENCTYPE_DES_CBC_MD5:NONE", but get the same error:

    kadmin: ktadd -k host.TESTMIT.keytab -e ENCTYPE_DES_CBC_MD5:NOSALT
    ktadd: Invalid argument while parsing keysalts ENCTYPE_DES_CBC_MD5
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. RE: kadmin ktadd -e keysaltlist for des-cbc-md5

    Tom,

    Using MIT krb5 1.5.1, I tried this :

    kadmin.local: addprinc -randkey test/princ@FLIK.LOCAL
    WARNING: no policy specified for test/princ@FLIK.LOCAL; defaulting to no
    policy
    Principal "test/princ@FLIK.LOCAL" created.
    kadmin.local: ktadd -e DES-CBC-MD5:NORMAL test/princ
    Entry for principal test/princ with kvno 3, encryption type DES cbc mode
    with RSA-MD5 added to keytab WRFILE:/etc/krb5.keytab.
    kadmin.local:

    As you can see, this works fine, and I don't get any errors like you
    did.

    I then used CyberSafe client to test the principal in KDC is ok ?

    I first requested a TGT from the MIT KDC :

    # kinit talsop@FLIK.LOCAL
    Password for talsop@FLIK.LOCAL:
    #

    Then, using kinit -S I was able to get a service ticket with DES-CBC-MD5
    (etype 3) session key using the principal just created. As you can see
    below, this works :

    # kinit -S test/princ@FLIK.LOCAL
    # klist -e
    Cache Type: Kerberos V5 Credentials Cache
    Cache File: /krb5/tmp/cc/krb5cc_0
    Cache Version: 0504
    Default Principal: talsop@FLIK.LOCAL

    Valid From Expires Service
    Principal
    ---------------------------- ----------------------------
    -----------------
    Tue 12 Sep 2006 22:52:19 BST Wed 13 Sep 2006 06:52:19 BST
    krbtgt/FLIK.LOCAL@FLIK.LOCAL
    Session Key EType: 23 (ARCFOUR-HMAC-MD5)
    Ticket EType: 23 (ARCFOUR-HMAC-MD5)
    Tue 12 Sep 2006 22:52:25 BST Wed 13 Sep 2006 06:52:19 BST
    test/princ@FLIK.LOCAL
    Session Key EType: 1 (DES-CBC-CRC)
    Ticket EType: 3 (DES-CBC-MD5)
    #

    I hope this helps.

    Regards,
    Tim

    -----Original Message-----
    From: kerberos-bounces@mit.edu [mailto:kerberos-bounces@mit.edu] On
    Behalf Of Tom Simons
    Sent: 12 September 2006 22:18
    To: kerberos@mit.edu
    Subject: kadmin ktadd -e keysaltlist for des-cbc-md5

    I'm trying to get a keytab with des-cbc-md5 encryption (no salt) from
    our
    kerberos 1.5 realm for a CyberSafe client. How do I specify the ktadmin
    ktadd command's "-e keysaltlist" parameter? I tried variations on
    "ktadd -k
    -e ENCTYPE_DES_CBC_MD5:NONE", but get the same error:

    kadmin: ktadd -k host.TESTMIT.keytab -e ENCTYPE_DES_CBC_MD5:NOSALT
    ktadd: Invalid argument while parsing keysalts ENCTYPE_DES_CBC_MD5
    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos

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


  3. Re: kadmin ktadd -e keysaltlist for des-cbc-md5

    "Tom Simons" writes:
    > I'm trying to get a keytab with des-cbc-md5 encryption (no salt) from our
    > kerberos 1.5 realm for a CyberSafe client. How do I specify the ktadmin
    > ktadd command's "-e keysaltlist" parameter? I tried variations on "ktadd -k
    > -e ENCTYPE_DES_CBC_MD5:NONE", but get the same error:
    >
    > kadmin: ktadd -k host.TESTMIT.keytab -e ENCTYPE_DES_CBC_MD5:NOSALT
    > ktadd: Invalid argument while parsing keysalts ENCTYPE_DES_CBC_MD5


    "Tim Alsop" replied:
    > kadmin.local: ktadd -e DES-CBC-MD5:NORMAL test/princ


    Case of the strings doesn't matter (I've always used lower-case).
    The names of the encryption types vary slightly between releases
    and between mit & heimdal. These are fairly reliable:
    des-cbc-crc
    des-cbc-md4
    des-cbc-md5
    [1]des-hmac-sha1
    des3-cbc-sha1 des3-hmac-sha1 des3-cbc-sha1-kd
    rc4-hmac arcfour-hmac arcfour-hmac-md5
    [1]rc4-hmac-exp
    aes128-cts aes128-cts-hmac-sha1-96
    aes256-cts aes256-cts-hmac-sha1-96

    [1] = not in heimdal

    I've often wished the mit code had a way to spit these strings out.
    They can be found in MIT source in krb5/src/lib/crypto/etypes.c
    In heimdal, look at lib/krb5/crypto.c (/enctype_null/).

    Salt strings:

    MIT HEIMDAL
    normal pw-salt
    v4
    norealm
    onlyrealm
    special
    afs3 afs3-salt

    MIT source: krb5/src/lib/krb5/krb/str_conv.c
    Heimdal source: lib/krb5/crypto.c (/^static struct salt_type/)

    In MIT, key salt pair parsing is done in krb5_string_to_keysalts,
    krb5/src/lib/kadm5/str_conv.c
    and has very wonky separator logic.
    pairs may be separated by , \t
    and the enctype & salt may be spearated by one of :.-
    (the default separators aren't used, look at krb5/src/kadmin/cli/{kadmin,keytab}.c)
    Since - can be either embedded inside an enctype string or separate the enc
    and salt types, things get very interesting in the code (and error reporting
    becomes just as confusing to you the user.)

    Heimdal appears to have very different and even more interesting
    key salt pair parsing rules. You get to name the salt, if you want,
    which replaces most of the special cases in MIT. This does require
    that the salt be something you can type.

    You'll note there is no "none" salt type. In order to see "no salt"
    from kadmin, you have to examine an entry that has a "key_data_ver ==
    1" in the kdb, most likely because you generated a random key. "no
    salt" is literally true - data_ver==1 also means there's no salt type
    or string stored in the database. If you generate a key from a
    password, it has to have salt (in theory). The salt type & string are
    part of the string to key conversion algorithm. If you add or change
    the keys for a principal using "-randkey" in MIT, you'll discover that
    (a) the salt magically disappears, and (b) if you mention duplicate
    encryption types with different salt, they get merged together. In
    short, it *ignores* the salts you name, except for making sure they're
    valid salt types.

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


+ Reply to Thread