Re: On PKINIT padata
On Wed, 16 Apr 2014, arpit.orb wrote: Hi All, 1. What apis in MIT Kerberos lib are called when the pkinit is successful. Shouldkrb5_get_init_creds_password be called in case of pkinit ? I'm not sure I understand the question. For one, is this anonymous pkinit nor non-anonymous? 2. What does PADATA UNKNOWN 149 means ? (I am getting that in AS REQ and PRE-AUTH REQUIRED packets) From krb5.h, 149 is KRB5_ENCPADATA_REQ_ENC_PA_REP, from RFC 6806. Perhaps your client krb5 implementation is too old to have this support (but it looks like it was first added in 1.8, which is a bit old at this point)? -Ben Kaduk Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Puppet remctl module
On 2014-04-11 09:59, Remi Ferrand wrote: > Hi everyone, > > At CC-IN2P3, we've released a puppet module for remctl deployment. Very cool, thanks! > It is available from the puppet forge: > http://www.puppetforge.com/ccin2p3/remctl. For the sake of completeness I'd like to mention that there is also https://github.com/NMTCC/puppet-remctl which seems to work fine as well (though I haven't deployed it in production yet). Not by me, I just contributed the Debian defaults. I find it great that two remctl modules have been developed apparently independently of each other in the span of the last four months. Choice is good :) Andreas signature.asc Description: OpenPGP digital signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, Apr 15, 2014 at 4:48 PM, Will Fiveash wrote: > On Tue, Apr 15, 2014 at 02:34:11PM -0500, Nico Williams wrote: >> What should happen is that there should be a way to enroll a device. > > If a keytab is really needed. On the otherhand, if a laptop is only > acting as a client then why bother? Assuming the logged-in user has a > way of acquiring their krb cred that's all they should need if the > laptop is acting as a NFS, ssh or any other client that tries to do > gss/krb auth. Sure, that's a fair thing to do in the short-term. In the long term I suspect you'll have many reasons to want to enroll a device (e.g., to do FAST w/o PKINIT). And in order to make this short-term fix workable you need a way to configure the system to make the user's Kerberos credential also be the system's (root's). Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, Apr 15, 2014 at 02:34:11PM -0500, Nico Williams wrote: > On Tue, Apr 15, 2014 at 2:22 PM, Will Fiveash wrote: > > But if this is a work laptop, which is typically a single user system > > and operates as a client in various contexts, requiring IT provision it > > with a keytab seems onerous to me. Note that a Solaris NFS v3 client > > does not require root have a krb cred to operation, even when > > automounting -- it only requires the user that triggered the automount > > have a krb cred. > > What should happen is that there should be a way to enroll a device. If a keytab is really needed. On the otherhand, if a laptop is only acting as a client then why bother? Assuming the logged-in user has a way of acquiring their krb cred that's all they should need if the laptop is acting as a NFS, ssh or any other client that tries to do gss/krb auth. -- Will Fiveash Oracle Solaris Software Engineer Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, Apr 15, 2014 at 2:48 PM, Tomas Kuthan wrote: > On 04/15/14 21:16, Nico Williams wrote: >> That said, it's best practice to key all devices. Still, nothing in >> NFSv4 requires such keys to be named in host-based ways. > > Makes sense ... but still, basing on host is a nifty way of constructing > unique principal name. Is there a meaningful alternative for mobile devices? But it isn't nifty. You quickly run into the issue that the hostname has to have a record in whatever manages your DNS zones, else someone might use that hostname and now some device has keys for its principal. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On 04/15/14 21:16, Nico Williams wrote: > That said, it's best practice to key all devices. Still, nothing in > NFSv4 requires such keys to be named in host-based ways. Makes sense ... but still, basing on host is a nifty way of constructing unique principal name. Is there a meaningful alternative for mobile devices? Tomas Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, Apr 15, 2014 at 2:22 PM, Will Fiveash wrote: > But if this is a work laptop, which is typically a single user system > and operates as a client in various contexts, requiring IT provision it > with a keytab seems onerous to me. Note that a Solaris NFS v3 client > does not require root have a krb cred to operation, even when > automounting -- it only requires the user that triggered the automount > have a krb cred. What should happen is that there should be a way to enroll a device. That could be as simple as a kadm5 (or HTTP, or RFC3244 extension) API that allows a user to create and key a principal of a form such as device//@ or just device/@. The should have no periods and should be illegal as a hostname, and it should mostly be a base64 encoding of a few bytes of /dev/urandom output. (Roland's tools have a mechanism for joining a host to a realm using multi-party ECDH to key it, and a site-local procedure for "blessing" a host principal. A similar but simplified approach could work here.) > I think part of the problem is that the gss security context protecting > the channel along with the user's krb cred could expire at any time. I > think that's why they wanted root to use a key stored in the keytab (I > could be wrong of course). No, that is a problem. NFSv4.1 does something to address this, IIRC, though I forget the details. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, Apr 15, 2014 at 03:13:09PM -0400, Simo Sorce wrote: > On Tue, 2014-04-15 at 13:48 -0500, Will Fiveash wrote: > > On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote: > > > Will, > > > > > > Mobile devices don't really have stable hostnames, so the system > > > should support non-hostbased host/root credentials. > > > > If you are referring to the NFS v4 client requiring root have a krb cred > > in order to function as I described in an earlier e-mail I would ask why > > NFS v4 clients require root to have a krb cred in the first place (NFS > > v3 doesn't as you may recall)? As you can imagine, many IT departments > > would balk (putting it mildly) if they were asked to provision keytabs > > on laptops or other mobile devices that need access to krb protected NFS > > v4 shares. > > > > As to how that requirement happened, according to one of the NFSv4 > > developers here that regularly attends Connectathon, the consensus among > > the NFS v4 implementors for various Linux platforms was that a properly > > configured NFS v4 client meant it had a keytab containing host service > > princ keys which could then be leveraged to protect the lease renewal > > traffic. My opinion is that unless there is a very good reason to > > protect that traffic, krb protection for lease renewal traffic should be > > optional, depending on configuration. > > > There is a good reason to require a keytab on a client if you use > kerberos for authentication to the machine, and that is that you need > validation for login. > > You also need a host key if you want to allow to use gssapi > authentication for ssh. > > So it is not too far fetched to expect to find a host key on every > machine participating to a kerberos REALM. But if this is a work laptop, which is typically a single user system and operates as a client in various contexts, requiring IT provision it with a keytab seems onerous to me. Note that a Solaris NFS v3 client does not require root have a krb cred to operation, even when automounting -- it only requires the user that triggered the automount have a krb cred. > That said it is unclear to me why the NFSv4 server should try to use a > new channel to communicate with the client instead of just using the > existing channel the client opened against the server. I think part of the problem is that the gss security context protecting the channel along with the user's krb cred could expire at any time. I think that's why they wanted root to use a key stored in the keytab (I could be wrong of course). -- Will Fiveash Oracle Solaris Software Engineer Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
There is nothing in NFSv4 requiring the use of any sort of client credentials other than user credentials. However, for multi-user clients it's important to have a credential for some session state and for callbacks. For single-user clients there's no need to have any device credentials at all for NFSv4 -- if you have none then the device should use the one user's credentials for all NFSv4 purposes. That said, it's best practice to key all devices. Still, nothing in NFSv4 requires such keys to be named in host-based ways. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, Apr 15, 2014 at 11:54 AM, Simo Sorce wrote: > On Tue, 2014-04-15 at 11:36 -0500, Nico Williams wrote: >> Will, >> >> Mobile devices don't really have stable hostnames, so the system >> should support non-hostbased host/root credentials. > > The hostname is pretty stable, unless you allow dhcp to push an hostname > unto you (bad idea). > I think what you mean is that not all mobile devices can use dyndns to > update the name -> ip map, but this shouldn't be a problem in the NFS > case. Sure. But there's no need for the client to have any particular sort of name for itself, so why pretend that it's name is host-based? (For the share -o root=... option Solaris really wants a root/hostname credential that it then checks against the reverse lookup on the client IP address. I'm not too hot on this, but at least that's only for root-equivalent access, not for general access.) Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, 2014-04-15 at 13:48 -0500, Will Fiveash wrote: > On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote: > > Will, > > > > Mobile devices don't really have stable hostnames, so the system > > should support non-hostbased host/root credentials. > > If you are referring to the NFS v4 client requiring root have a krb cred > in order to function as I described in an earlier e-mail I would ask why > NFS v4 clients require root to have a krb cred in the first place (NFS > v3 doesn't as you may recall)? As you can imagine, many IT departments > would balk (putting it mildly) if they were asked to provision keytabs > on laptops or other mobile devices that need access to krb protected NFS > v4 shares. > > As to how that requirement happened, according to one of the NFSv4 > developers here that regularly attends Connectathon, the consensus among > the NFS v4 implementors for various Linux platforms was that a properly > configured NFS v4 client meant it had a keytab containing host service > princ keys which could then be leveraged to protect the lease renewal > traffic. My opinion is that unless there is a very good reason to > protect that traffic, krb protection for lease renewal traffic should be > optional, depending on configuration. There is a good reason to require a keytab on a client if you use kerberos for authentication to the machine, and that is that you need validation for login. You also need a host key if you want to allow to use gssapi authentication for ssh. So it is not too far fetched to expect to find a host key on every machine participating to a kerberos REALM. That said it is unclear to me why the NFSv4 server should try to use a new channel to communicate with the client instead of just using the existing channel the client opened against the server. Opening back channels from servers have been proven brittle (firewalls, NAT, etc.. all get in the way) time and again since ages, seem someone hasn't learned their lesson. Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
On PKINIT padata
Hi All, 1. What apis in MIT Kerberos lib are called when the pkinit is successful. Shouldkrb5_get_init_creds_password be called in case of pkinit ? 2. What does PADATA UNKNOWN 149 means ? (I am getting that in AS REQ and PRE-AUTH REQUIRED packets) Arpit Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS via /net automounter with kinit only (no /etc/krb5.conf access)
Here is a response to your questions from a Solaris NFS developer: > - Forwarded message from Wang Shouhua - > > Date: Mon, 14 Apr 2014 20:55:10 +0200 > From: Wang Shouhua > Subject: Re: Accessing Kerberos NFS via /net automounter with kinit only (no > /etc/krb5.conf access) > To: Wang Shouhua,Kerberos@mit.edu, Will > Fiveash > Message-ID: > > On 13 April 2014 21:59, Will Fiveash wrote: >> On Sat, Apr 12, 2014 at 09:50:25AM +0200, Wang Shouhua wrote: >>> We are talking about NFS version 4 (NFSv4) on Solaris only. Why does >>> NFSv4 have such extra requirements? NFS4 clients must maintain a state lease with each NFS4 server. The scope of the lease covers all state created by all users for all mounts from a NFS4 server. For the Solaris and Linux kernel NFS4 client implementations, state renewal is performed by a kernel thread using the root credential. This is of course problematic for kerberos mounts since a user principal does not typically exist in the KDC for the root user. To enable NFS4 lease renewal traffic for kerberos mounts, a host service principal is needed in the NFS4 client's keytab file. This is not simply a Solaris NFS4 client implementation issue. It is also a documented requirement for Linux NFS4 clients: Linux NFS4 client kerberos config/setup: http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA#Setup_Kerberos_principals Here's a link to Solaris docs explaining how to configure a kerberos client for NFS4: http://docs.oracle.com/cd/E19253-01/816-4557/setup-341/index.html scroll down to "6. start kadmin" section "c. Create a host principal and add the principal to the server's keytab file." >>> What we hoped is that if a machine has Kerberos5 enabled it can >>> connect to *any* other Keberos5 (krb5p/krb5i) filesystem, not only >>> those in the current Kerberos5 realm, if kinit can be provided with >>> the correct tickets. If it doesn't work then it looks like a bug to us >>> (speaking for MOST.GOV.CN). >>> >>> How can we get this fixed? If you cannot provision host service pricipals on Solaris NFS4 clients, then your only option is to mount using NFS3. >> The NFS4 client’s lease renewal thread runs as root (kcred), > 1. Is that just root/ or does that include host/ or nfs/ creds, too? Solaris NFS4 clients need host/@realm. nfs/@realm is required for NFS4 servers. If a system will access and share kerberos mounts using NFS4, add both host/ and nfs/ to the keytab. > 2. If you look at > http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/fs.d/nfs/nfsd/ > where is the code which does that state update? NFS4 lease renewal happens in the kernel in nfs4_client.c [nfs4_renew_lease_thread()]. > 3. Does nfsd log any errors if the state lease cannot be renewed? No, nfsd runs only on the server. The client logs an (unfortunately) cryptic and unhelpful message along the lines of "protocol error". An enhancement request exists to improve error reporting related to NFS kerberos mounts. We are working to remove the requirement for provisioning Solaris NFS4 clients with host service principals, Another planned (Solaris) enhancement to remove the NFS4client's need for a host service principal, but I cannot comment on a timeframe for delivery. -- Will Fiveash Oracle Solaris Software Engineer Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, Apr 15, 2014 at 11:36:34AM -0500, Nico Williams wrote: > Will, > > Mobile devices don't really have stable hostnames, so the system > should support non-hostbased host/root credentials. If you are referring to the NFS v4 client requiring root have a krb cred in order to function as I described in an earlier e-mail I would ask why NFS v4 clients require root to have a krb cred in the first place (NFS v3 doesn't as you may recall)? As you can imagine, many IT departments would balk (putting it mildly) if they were asked to provision keytabs on laptops or other mobile devices that need access to krb protected NFS v4 shares. As to how that requirement happened, according to one of the NFSv4 developers here that regularly attends Connectathon, the consensus among the NFS v4 implementors for various Linux platforms was that a properly configured NFS v4 client meant it had a keytab containing host service princ keys which could then be leveraged to protect the lease renewal traffic. My opinion is that unless there is a very good reason to protect that traffic, krb protection for lease renewal traffic should be optional, depending on configuration. -- Will Fiveash Oracle Solaris Software Engineer Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
On Tue, 2014-04-15 at 11:36 -0500, Nico Williams wrote: > Will, > > Mobile devices don't really have stable hostnames, so the system > should support non-hostbased host/root credentials. The hostname is pretty stable, unless you allow dhcp to push an hostname unto you (bad idea). I think what you mean is that not all mobile devices can use dyndns to update the name -> ip map, but this shouldn't be a problem in the NFS case. Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Accessing Kerberos NFS version 4 (not 2, 3) via /net automounter with kinit only (no /etc/krb5.conf access)
Will, Mobile devices don't really have stable hostnames, so the system should support non-hostbased host/root credentials. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
