Decrypt integrity check failed after sending several correct messages
Hi, I'm kerberizing a distributed application using the GSS-API and Kerberos version 1.6.1. It consists of several processes running on several hosts. There are two kind of processes: sender processes and receiver processes. The application works as follows: processes are grouped as pair of processes so that a sender process and a receiver process exchange a fixed number of encrypted messages (currently 1000). The point is that when a lot of process pairs are running (more than 700, i.e, 1400 processes) there is always a random pair (or more than one) that fails. After exchanging (and also encrypting and decrypting) some messages one of the agents that are part of that pair fails when trying to decrypt the message received, but it has decrypted all the previous messages without errors. The failure is allways the same, when i call to gss_unwrap to decrypt the message i get these errors: Major status: A token had an invalid Message Integrity Check (MIC) Minor status: Decrypt integrity check failed The problem is solved if i retry to call gss_unwrap with the same message after waiting for 10 or 20 milliseconds once it has failed for the first time. Is there anyone knowing what happens? Could i avoid waiting and retrying gss_unwrap? Thanks Jose M. Such Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberized NFS on OS X (gssd problem)
> "JC" == John Caruso <[EMAIL PROTECTED]> writes: JC> On 2008-01-18, Richard E. Silverman <[EMAIL PROTECTED]> wrote: >> I'm trying to use a Leopard machine as a kerberized NFSv4 client. >> I get this: >> >> $ mount -v -t nfs -o vers=4.0alpha -o sec=krb5 server:/foo /foo >> mount_nfs: /Users/res/foo: Authentication error >> >> and I get this in the system log: >> >> Jan 18 00:15:59 darwin kernel[0]: nfs_gss_clnt_gssd_upcall: gssd >> port not valid Jan 18 00:15:59 darwin kernel[0]: nfs4_setclientid >> failed, 80 JC> I'm attempting the same thing and getting the same result. Did JC> you ever manage to resolve this issue? JC> - John I'm afraid not; I have a bug open with Apple on it right now. I have found that kerberized NFSv3 does work, though. Of course, it *does* say the NFSv4 code is alpha... -- Richard Silverman [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: kerberized NFS on OS X (gssd problem)
On 2008-01-18, Richard E. Silverman <[EMAIL PROTECTED]> wrote: > I'm trying > to use a Leopard machine as a kerberized NFSv4 client. I get this: > > $ mount -v -t nfs -o vers=4.0alpha -o sec=krb5 server:/foo /foo > mount_nfs: /Users/res/foo: Authentication error > > and I get this in the system log: > > Jan 18 00:15:59 darwin kernel[0]: nfs_gss_clnt_gssd_upcall: gssd port not > valid > Jan 18 00:15:59 darwin kernel[0]: nfs4_setclientid failed, 80 I'm attempting the same thing and getting the same result. Did you ever manage to resolve this issue? - John Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberos MIT SSH Solaris 9
Andrea wrote: > Hi all, > > I'm experiencing some problem on kerberizing ssh on Solaris 9 with MIT > Kerberos, > > I have the following setting: > > 1. Sun Solaris 5.9 > > 2. MIT Kerberos KDC 1.6.3 ( I use just the kdc from the MIT Kerberos) > > 3. On Kerberos client side I used the one from Solaris from the > following packet: SUNWkrbu > > 4. Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f I don't believe the Solars 9 sshd supports GSSAPI which is what you are looking for. On Solaris 9 we use OpenSSH and the MIT Kerberos. (/usr/bin/ldd /usr/lib/ssh/sshd does not show any Kerberos or gssapi libs.) But On Solairs 10, The Sun ssh/sshd does support GSSAPI, and works well with GSSAPI using the Sun Kerberos. > > This is my pam.conf: > # PAM configuration > # > # Customized to try pam_unix, then pam_krb5 > # > # Unless explicitly defined, all services use the modules > # defined in the "other" section. > # > # Modules are defined with relative pathnames, i.e., they are > # relative to /usr/lib/security/$ISA. Absolute path names, as > # present in this file in previous releases are still acceptable. > # > # Authentication > # > # passwd command (explicit because of a different authentication > module) > # > passwd auth required pam_passwd_auth.so.1 > # > # Default definition for Authentication management > # Used when service name is not explicitly mentioned for > authentication > # management > # > other auth requisite pam_authtok_get.so.1 > other auth sufficient pam_unix_auth.so.1 > other auth required pam_krb5.so.1 use_first_pass debug > # > # Account > # > # cron service (explicit because of non-usage of pam_roles.so.1) > # > cronaccount requiredpam_projects.so.1 > cronaccount requiredpam_unix_account.so.1 > # See notes about pam_krb5 in "other" section below > cronaccount optionalpam_krb5.so.1 debug > # > # Default definition for Account management > # Used when service name is not explicitly mentioned for account > management > # > other account requisite pam_roles.so.1 > other account requiredpam_projects.so.1 > other account requiredpam_unix_account.so.1 > # According to the pam_krb5 man page, this checks for password > expiration. > # I'm not sure this does anything since I've flagged it as optional. > # I'm not sure if I can make it required because of root. > other account optionalpam_krb5.so.1 debug > # > # Session > # > # Default definition for Session management > # Used when service name is not explicitly mentioned for session > management > # > other session optionalpam_krb5.so.1 debug > other session requiredpam_unix_session.so.1 > # > # Password > # > # (Don't list pam_krb5 here, this section is only for root. Regular > # users must use the centralized department password changing > mechanism.) > # > # Default definition for Password management > # Used when service name is not explicitly mentioned for password > management > # > other password requisite pam_authtok_get.so.1 > other password requisite pam_authtok_check.so.1 > other password required pam_authtok_store.so.1 > # > > I can ssh into the machine using the password from kerberos, when I > let in I have the two tickets (TGT and TGS), but if I try to ssh on > the same machine I have to retype the password, hence single sign on > seems not working. > > Anyone can suggest me where am i wrong??? > Is the pam.conf correct? > Does native Solaris ssh supports well gssapi delegation credentials?? It does on Solaris 10! > > My goal is to obtain single sign on with as much as possible native > solaris tool, with just an exception use MIT KERBEROS KDC SERVER! We do that on Solaris 10 but using Windows AD as the KDC. > > Thanks in advance! > > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Douglas E. Engert <[EMAIL PROTECTED]> 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
Kerberos MIT SSH Solaris 9
Hi all, I'm experiencing some problem on kerberizing ssh on Solaris 9 with MIT Kerberos, I have the following setting: 1. Sun Solaris 5.9 2. MIT Kerberos KDC 1.6.3 ( I use just the kdc from the MIT Kerberos) 3. On Kerberos client side I used the one from Solaris from the following packet: SUNWkrbu 4. Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090700f This is my pam.conf: # PAM configuration # # Customized to try pam_unix, then pam_krb5 # # Unless explicitly defined, all services use the modules # defined in the "other" section. # # Modules are defined with relative pathnames, i.e., they are # relative to /usr/lib/security/$ISA. Absolute path names, as # present in this file in previous releases are still acceptable. # # Authentication # # passwd command (explicit because of a different authentication module) # passwd auth required pam_passwd_auth.so.1 # # Default definition for Authentication management # Used when service name is not explicitly mentioned for authentication # management # other auth requisite pam_authtok_get.so.1 other auth sufficient pam_unix_auth.so.1 other auth required pam_krb5.so.1 use_first_pass debug # # Account # # cron service (explicit because of non-usage of pam_roles.so.1) # cronaccount requiredpam_projects.so.1 cronaccount requiredpam_unix_account.so.1 # See notes about pam_krb5 in "other" section below cronaccount optionalpam_krb5.so.1 debug # # Default definition for Account management # Used when service name is not explicitly mentioned for account management # other account requisite pam_roles.so.1 other account requiredpam_projects.so.1 other account requiredpam_unix_account.so.1 # According to the pam_krb5 man page, this checks for password expiration. # I'm not sure this does anything since I've flagged it as optional. # I'm not sure if I can make it required because of root. other account optionalpam_krb5.so.1 debug # # Session # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # other session optionalpam_krb5.so.1 debug other session requiredpam_unix_session.so.1 # # Password # # (Don't list pam_krb5 here, this section is only for root. Regular # users must use the centralized department password changing mechanism.) # # Default definition for Password management # Used when service name is not explicitly mentioned for password management # other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 # I can ssh into the machine using the password from kerberos, when I let in I have the two tickets (TGT and TGS), but if I try to ssh on the same machine I have to retype the password, hence single sign on seems not working. Anyone can suggest me where am i wrong??? Is the pam.conf correct? Does native Solaris ssh supports well gssapi delegation credentials?? My goal is to obtain single sign on with as much as possible native solaris tool, with just an exception use MIT KERBEROS KDC SERVER! Thanks in advance! Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: [OpenAFS] kerberos ticket length and IP addresses
Cesar Garcia wrote: [this is largely a kerberos question, but I am cross posting in case anyone on the openafs mailing list may have had a similar experience] We are having two problems with larger krb5 afs/service tickets. Specifically when krb5_creds.ticket.length exceeds order of about 350 bytes we run into these two problems (the length tolerence differs slightly between the two issues): 1 - we are still running openafs 1.2.13 fileservers which don't seem to like the larger tickets, they treat requests as if the request came from: #define ANONYMOUSID 32766 so in effect, the tokens are useless Correct. You must use OpenAFS 1.4 servers in order to support tickets larger than 344 bytes. (Actually 1.3.65 or above.) Here is the diff. It can be applied to 1.2 servers provided you can recompile. http://www.openafs.org/cgi-bin/cvsweb.cgi/openafs/src/rxkad/rxkad.p.h.diff?r1=1.10&r2=1.8 2 - on machines running older versions of the openafs client, ktc_SetToken fails as follows: nptest05:/u/cesarg$ aklog aklog: unable to obtain tokens for cell b.ny.ms.com (status: 11862789). nptest05:/u/cesarg# translate_et 11862789 11862789 (ktc).5 = AFS kernel pioctl doesn't exist Similar problem. The pioctl buffer isn't large enough to hold the input. Rebuilding is required if you want to support the larger ticket sizes. Upgrading openafs servers is well under way, but realistically another 6 months before completion. Upgrading openafs clients is unfortunately much more difficult for us to do - largely due to [let's call it] political factors, that upgrade schedule is much much longer. We see these problems on client machines that have many (>7 or 8) interfaces, as the TGTs we obtain are addressful - removing IP addresses (e.g., kinit -A) works, but unfortunately is not a short term option for us as this causes problems for legacy/interal apps built with *very* old krb5 libs - and unfortunately my team doesn't own those apps. As a workaround, we attempted to obtain afs service tickets via krb5_get_cred_via_tkt(), specifying an empty set of addresses (arg 4), but this doesn't seem to have any impact on the length of the resulting afs service ticket (cred.ticket.length). The address list comes from the TGT. In fact if we request 0, 50, or 100 IPs via arg 4, it still doesn't seem to influence the length of the afs service ticket. The afs ticket length seems to be tied to the length of the tgt in all cases. Exactly. Is this expected? I've yet to go deep enough into the relevent tgs req code to understand why this happens. Yes. Is there something else we could do that will result in smaller tickets. I realize our real problem is political, a short term answer for us unfortunately cannot require that we strip IPs from our TGTs, or require openafs client and server upgrades - these contraints are horrible - believe me, none of us are happy about it ... not looking for sympathy :-) Are there any additional details we can provide that would help. I suppose it is possible our code/workaround is simply coded incorrectly. I'd be willing to send out code if someone thinks that is the case. Any help in understanding this is greatly appreciated. Hacking the KDC to strip addresses for the AFS service principal or using the krb524d (Kerberos v4 tickets will only support a single address and will always be small enough.) Jeffrey Altman Secure Endpoints Inc. smime.p7s Description: S/MIME Cryptographic Signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
kerberos ticket length and IP addresses
[this is largely a kerberos question, but I am cross posting in case anyone on the openafs mailing list may have had a similar experience] We are having two problems with larger krb5 afs/service tickets. Specifically when krb5_creds.ticket.length exceeds order of about 350 bytes we run into these two problems (the length tolerence differs slightly between the two issues): 1 - we are still running openafs 1.2.13 fileservers which don't seem to like the larger tickets, they treat requests as if the request came from: #define ANONYMOUSID 32766 so in effect, the tokens are useless 2 - on machines running older versions of the openafs client, ktc_SetToken fails as follows: nptest05:/u/cesarg$ aklog aklog: unable to obtain tokens for cell b.ny.ms.com (status: 11862789). nptest05:/u/cesarg# translate_et 11862789 11862789 (ktc).5 = AFS kernel pioctl doesn't exist Upgrading openafs servers is well under way, but realistically another 6 months before completion. Upgrading openafs clients is unfortunately much more difficult for us to do - largely due to [let's call it] political factors, that upgrade schedule is much much longer. We see these problems on client machines that have many (>7 or 8) interfaces, as the TGTs we obtain are addressful - removing IP addresses (e.g., kinit -A) works, but unfortunately is not a short term option for us as this causes problems for legacy/interal apps built with *very* old krb5 libs - and unfortunately my team doesn't own those apps. As a workaround, we attempted to obtain afs service tickets via krb5_get_cred_via_tkt(), specifying an empty set of addresses (arg 4), but this doesn't seem to have any impact on the length of the resulting afs service ticket (cred.ticket.length). In fact if we request 0, 50, or 100 IPs via arg 4, it still doesn't seem to influence the length of the afs service ticket. The afs ticket length seems to be tied to the length of the tgt in all cases. Is this expected? I've yet to go deep enough into the relevent tgs req code to understand why this happens. Is there something else we could do that will result in smaller tickets. I realize our real problem is political, a short term answer for us unfortunately cannot require that we strip IPs from our TGTs, or require openafs client and server upgrades - these contraints are horrible - believe me, none of us are happy about it ... not looking for sympathy :-) Are there any additional details we can provide that would help. I suppose it is possible our code/workaround is simply coded incorrectly. I'd be willing to send out code if someone thinks that is the case. Any help in understanding this is greatly appreciated. Thanks. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
