Re: Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1
Thanks very much! Your information was very much on target. (I was embarrassed to see that I had set a 256 key and asked for a 128 key.) There is the possible error in your reply that even changing the 'test' principal to have both aes128 and aes256 keys was not sufficient to make Apple's kinit work. But that was before adding the new keys for the krbtgt/. Adding new keys for krbtgt/ did the trick. Everything works now: $ /usr/bin/kinit -e aes128-cts-hmac-sha1-96 test@ test@'s password: $ /usr/bin/klist -v Credentials cache: API:503:2 Principal: test@ Cache version: 0 Server: krbtgt/@ Client: test@ Ticket etype: aes128-cts-hmac-sha1-96, kvno 2 Ticket length: 299 Auth time: Feb 12 12:50:15 2018 End time: Feb 12 22:50:12 2018 Ticket flags: enc-pa-rep, pre-authent, initial, forwardable Addresses: addressless Best regards, John Boyland ] On 02/12/2018 10:37 AM, John Tang Boyland wrote: ] > What's going on? Does MIT kerberos not actually support AES256? ] ] Check the keys for the krbtgt/ principal entry. The ticket will ] always be encrypted in the first of those keys. I suspect that key is des3. ] ] To explain your three different results: ] ] 1. When you use kinit normally, the KDC chooses aes256-cts to encrypt ] the reply (you can't see this), des3 to encrypt the ticket, and probably ] des3 for the session key. ] ] 2. When you use "kinit -e aes128-cts", the KDC can't find a match ] between the request enctypes and the client principal keys, since the ] client principal has only an aes256-cts key. The KDC should respond ] with a "KDC has no support for encryption type" error, but instead it ] says something nonsensical: "you have to do preauth, but I don't have ] any preauth mechs which will work". I will file a ticket for this KDC ] behavior. The Apple kinit has a special error message for this ] response, which could probably be improved (but not by a lot; it's hard ] to say something useful to a user in this case). ] ] 3. When you restrict the request enctypes to aes256-cts aes128-cts ] through configuration, the KDC can't select a session key enctype ] agreeable to both the request and the server (it assumes that the ] server, in this case krbtgt/, can only support ticket session ] keys matching the enctypes it has keys for). So it responds with a "KDC ] has no support for encryption type" error. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Preauth / AES / MIT Kerberos / TGT des3-cbc-sha1
Apple's kinit is now complaining if a KDC generates a des3 ticket: Encryption type des3-cbc-sha1(16) used for authentication is weak and will be deprecated If one uses the "-e" option, one gets the message: $ /usr/bin/kinit -e aes128-cts-hmac-sha1-96 test@ test@'s password: kinit: krb5_get_init_creds: Preauth required but no preauth options send by KDC But the principle in question has the REQUIRES_PRE_AUTH flag: kadmin: getprinc test Principal: test@ ... Maximum ticket life: 0 days 10:00:00 Maximum renewable life: 7 days 00:00:00 Failed password attempts: 0 Number of keys: 1 Key: vno 2, aes256-cts-hmac-sha1-96 MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] If I use kinit without the -e option, I get: $ /usr/bin/klist --verbose Credentials cache: API:D6263E03-4C49-46C2-80B5-9C72FF37009B Principal: test@ Cache version: 0 Server: krbtgt/@ Client: test@ Ticket etype: des3-cbc-sha1, kvno 1 Ticket length: 318 Auth time: Feb 12 08:23:42 2018 End time: Feb 12 18:23:37 2018 Ticket flags: enc-pa-rep, pre-authent, initial, forwardable Addresses: addressless When I describe the krb5-admin-server package on the admin server, I see Package: krb5-admin-server Architecture: amd64 Version: 1.13.2+dfsg-5ubuntu2 Priority: optional Section: universe/net Source: krb5 Origin: Ubuntu ... In an attempt to prevent krb5-kdc from using these insecure encryption types, I added the following to krb5.conf: default_tgs_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 default_tkt_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 permitted_enctypes = aes256-cts-hmac-sha1-96 aes128-cts-hmac-sha1-96 Then the client claims that KDC has no support for encryption type while getting initial credentials. (I also tried just using "aes" which the documentation also suggests) What's going on? Does MIT kerberos not actually support AES256? or is the online documentation that claims that these aes encryption types are supported wrong? Best regards, John Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Using AFS salt with Solaris and MIT (Was Re: Kerberos Digest, Vol 60, Issue 9)
We just installed Solaris 10 on our intel box and found out that the Sun-supplied pam_krb5 (as well as kinit) seg fault when given a principal with AFS3 salt. The server is MIT krb1.5.4 patched. It seg faults before asking for a password. Workaround? Use MIT kinit. Other workaround? Ask users to "change" passwords, where they don't actually need to use a new password... John Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb524 stops working (MIT 1.5.4 + 2007-005/6 patches + fakeka patch)
Tom Yu <[EMAIL PROTECTED]> writes:
] >>>>> "John" == John Tang Boyland <[EMAIL PROTECTED]> writes:
]
] John> I trussed it long enough (5-10 minutes?) to find two successive
increases in
] John> heap size. The requests that incurred these increases and the 6
] John> requests that were in between were all but identical (the only
] John> difference being the data read in and written out and the results of
] John> the time function). They consists of the following
] John> (where this example includes the requests for more heap space: the mmap
] John> with MAP_ANON below)
]
] John> poll(0xFFBEFA98, 1, 6) = 0
]
] This is not an incoming krb524 request, but a poll() (called through
] select()) timeout. When this timeout occurs, krb524d calls
] kadm5_flush() to close and reopen the database.
Ah. My mistake. Well, this is good news: it's not something that
happens because of outside actions.
] Did you have any
] examples of leaks accompanied by poll() returning non-zero?
No. Actually, this makes sense of some data that I hadn't mentioned:
I had forced 100 calls (using aklog) and noticed no memory size
change but then a minute later, the size started increasing again.
It would seem that the reason why other people don't notice the
problem is that they are using their krb524d more frequently!
] John> [...]
] John> stat("/opt/local/lib/krb5/plugins/kdb/db2.so", 0xFFBEF788) = 0
] John> open("/opt/local/lib/krb5/plugins/kdb/db2.so", O_RDONLY) = 4
] John> fstat(4, 0xFFBEF0CC)= 0
] John> mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xFEE7
] John> mmap(0x, 155648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) =
0xFEDE
] John> mmap(0xFEE04000, 4500, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED, 4, 81920) = 0xFEE04000
] John> munmap(0xFEDF6000, 57344) = 0
] John> memcntl(0xFEDE, 13900, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
] John> close(4)= 0
] John> mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_ANON, -1, 0) = 0xFD29
] John> munmap(0xFEE7, 8192)= 0
]
] Given that this munmap() refers to an address returned by the
] 8192-byte mmap() call from dlopen(), I'm inclined to believe that the
] mmap(MAP_ANON) which precedes it is actually part of the dlopen()
] implementation.
I have two questions:
1: Why would a plugin need to be loaded in over and over?
2: If it does load the plugin again, perhaps it forgot to dispose the old one?
John
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Re: krb524 stops working (MIT 1.5.4 + 2007-005/6 patches + fakeka patch)
After restarting krb524d, I saw that the process gradualy gets larger.
When first started, the SZ was about 3000 Kb, from from Friday 11/9 to
Monday 11/12, it had increased to about 8000 Kb. I then carefully
diff'ed the source with the defined krb5-1.5.4 distribution and
noticed that I had an old version of 2007-006-patch.txt (I can post
details if people are interested), and rebuilt a new version of the
binaries with the current patch (plus fakeka and kslave_update patches
neither of which is relevant). I got the same behavior: slowly
increasing footprint, probably because of a slow memory leak. I
prepared a truss session but noticed that it was not being able to
read /dev/urandom. As it happens /dev/*random was not installed in
this old version of Solaris 8. So I got the patch and rebooted, and
STILL get the same behavior. It gains about a megabyte or more a day:
I trussed it long enough (5-10 minutes?) to find two successive increases in
heap size. The requests that incurred these increases and the 6
requests that were in between were all but identical (the only
difference being the data read in and written out and the results of
the time function). They consists of the following
(where this example includes the requests for more heap space: the mmap
with MAP_ANON below)
poll(0xFFBEFA98, 1, 6) = 0
close(4)= 0
llseek(5, 0, SEEK_CUR) = 0
close(5)= 0
munmap(0xFEE04000, 4552)= 0
munmap(0xFEDE, 83139) = 0
time() = 1195164448
stat("/opt/local/var/krb5kdc/kdc.conf", 0xFFBEF788) = 0
time() = 1195164448
stat("/etc/krb5.conf", 0xFFBEF788) = 0
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
stat("/opt/local/lib/krb5/plugins/kdb/db2", 0xFFBEF788) Err#2 ENOENT
stat("/opt/local/lib/krb5/plugins/kdb/db2.so", 0xFFBEF788) = 0
open("/opt/local/lib/krb5/plugins/kdb/db2.so", O_RDONLY) = 4
fstat(4, 0xFFBEF0CC)= 0
mmap(0x, 8192, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xFEE7
mmap(0x, 155648, PROT_READ|PROT_EXEC, MAP_PRIVATE, 4, 0) = 0xFEDE
mmap(0xFEE04000, 4500, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED,
4, 81920) = 0xFEE04000
munmap(0xFEDF6000, 57344) = 0
memcntl(0xFEDE, 13900, MC_ADVISE, MADV_WILLNEED, 0, 0) = 0
close(4)= 0
mmap(0x, 8192, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANON,
-1, 0) = 0xFD29
munmap(0xFEE7, 8192)= 0
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
open("/opt/local/var/krb5kdc/principal", O_RDONLY) = 4
fcntl(4, F_SETFD, 0x0001) = 0
fstat(4, 0xFFBEF770)= 0
read(4, "[data removed from email]".., 24) = 24
fstat(4, 0xFFBEF628)= 0
lseek(4, 4096, SEEK_SET)= 4096
read(4, "[data removed from email]".., 4096)= 4096
close(4)= 0
open("/opt/local/var/krb5kdc/principal.ok", O_RDWR) = 4
fstat(4, 0xFFBEF018)= 0
access("/opt/local/var/krb5kdc/kdc.conf", 4)= 0
time() = 1195164448
access("/etc/krb5.conf", 4) = 0
time() = 1195164448
time() = 1195164448
stat("/opt/local/etc/krb5.conf", 0xFFBEE908)Err#2 ENOENT
open("/dev/urandom", O_RDONLY) = 5
fstat(5, 0xFFBEEE88)= 0
read(5, "10EE869D14841B\n 310 VFD".., 20) = 20
close(5)= 0
getpid()= 1897 [1]
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time() = 1195164448
time()
Re: krb524 stops working (MIT 1.5.4 + 2007-005/6 patches + fakeka patch)
] On Nov 9, 2007, at 11:14, John Tang Boyland wrote: ] > However, every once in a while, the krb524d stops responding to ] > requests. "ps augx" says: ] > ] > USER PID %CPU %MEM SZ RSS TT SSTART TIME COMMAND ] > root 12025 1.2 63.5184632156496 ?S Oct 15 382:56 / ] > opt/local/sbin/krb524d -m ] > ] > Last time this happened (apparently October 15th), I killed it and ] > started it up again, and it worked just fine. But now it stopped ] > working again. ] ] That's not something we've seen before... when it's in this state, ] could you try running strace on the process (for Linux, truss for ] Solaris, etc) while you're sending requests it's not responding to? It's Solaris. I tried "truss -p 12025" and nothing happens when I run the client (an old version of aklog) that tries to contact it. aklog times out, with error: ... Kerberos error code returned by get_cred: -1765328228 aklog: Couldn't get cs.uwm.edu AFS tickets: aklog: Cannot contact any KDC for requested realm while getting AFS tickets On the other hand, if I "truss -p" the fakeka process, I gets lots of appropriate debugging information. (Here I tested using "klog".) ] If you've built it with debug info, attaching the process under gdb ] to get a stack trace may help too, if strace doesn't show any ] activity. It wasn't built with debugging, but did at least show: ... Symbols already loaded for /usr/lib/libthread.so.1 Symbols already loaded for /usr/lib/nss_files.so.1 Symbols already loaded for /opt/local/lib/krb5/plugins/kdb/db2.so 0xfef9b75c in __lwp_sema_wait () (gdb) where #0 0xfef9b75c in __lwp_sema_wait () #1 0xfee89830 in _park () #2 0xfee89508 in _swtch () #3 0xfee8d960 in _reap_wait () #4 0xfee8d6b8 in _reaper () This is an ancient version of gdb, I'm afraid. ] Monitoring traffic to krb524d with tcpdump (ideally, recording the ] full packets) might be handy if you catch it at some point while it's ] growing massively like this. (Though on the off chance that someone ] has come up with a krb524d deathgram packet, please report the info ] to [EMAIL PROTECTED] so we could try to get a fix out before the ] means of killing it becomes too widespread.) I'll kill the process now and restart it. I'll see if I can catch krb524d when it's on a growth spurt. (and perhaps it is gradual.) ... OK, it's sane again now that I restarted it. USER PID %CPU %MEM SZ RSS TT SSTART TIME COMMAND root 20757 0.0 0.8 3704 1792 ?S 16:25:07 0:00 /opt/local/sbin/krb524d -m More in a week? Thanks, John Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
krb524 stops working (MIT 1.5.4 + 2007-005/6 patches + fakeka patch)
Hello, We're slowly transitioning our kerberos installation to remove krb4 functionality (we use kerberos for OpenAFS authentication). I built and installed MIT kerberos 1.5.4 with patches for security advisories 2007-005 and 2007-006 and for fakeka (from the AFS migration kit). However, every once in a while, the krb524d stops responding to requests. "ps augx" says: USER PID %CPU %MEM SZ RSS TT SSTART TIME COMMAND root 12025 1.2 63.5184632156496 ?S Oct 15 382:56 /opt/local/sbin/krb524d -m Last time this happened (apparently October 15th), I killed it and started it up again, and it worked just fine. But now it stopped working again. Is this a known problem with MIT krb5 1.5.4 ? Does krb524d have memory leaks and require weekly restarts? John Boyland Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
