Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote:
>Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +:
>> John-Mark Gurney wrote:
>> [lots of stuff snipped]
>> >Rick Macklem wrote:
>> >> I had originally planned on some "secret" in the certificate (like a CN
>> >> name
>> >> that satisfies some regular expression or ???) but others convinced me
>> >> that
>> >> that wouldn't provide anything beyond knowing that the certificate was
>> >> signed by the appropriate CA, so I have not implemented anything.
>> >
>> >Yeah, having a "secret" in the CN doesn't make sense, but what does make
>> >sense is allowing the exports line to specify what the CN should contain
>> >to be authenticated...
>> >
>> >Say as a corp, you issue personal certificates to everyone. This is
>> >because you require everyone to sign and/or encrypt their email w/
>> >S/MIME. Each cert includes the email address of that person, so you
>> >could simply do something like:
>> >/home/alice -tlscert -tlsroot /etc/company.pem -email al...@example.com
>> >
>> >And anyone who has the certificate w/ al...@example.com that was signed
>> >by the public key in /etc/company.pem would be granted access to the
>> >export /home/alice.
>> >
>> >If it allowed ANY cert signed by the CA specified, then that introduces
>> >an authentication problem, as now if Malory is a coworker of Alice
>> >could also access Alice's home directory...
>> >
>> >IMO, this is one auth feature that MUST be supported...
Here's what I have just coded up:
- If an option is set for the server TLS handshake daemon and it gets a verified
certificate from the client
- It looks at the CN and if it is of the form "user@domain", it tries to
translate
"user@domain" to a POSIX using the same mechanism that
nfsuserd(8) currently uses. ("user@domain" is what NFSv4 uses for a file
Owner.)
- Then all RPCs on this TCP connection are done using the
above,
ignoring the authenticator in the RPC message header. (Yes, similar to
the
-mapall exports option.)
I have also added a "-tlscnuser" exports option that would require all clients
to have the above form of certificate. (Without this exports option, the above
would work assuming the daemon option is set, but other mounts would be
allowed as well.)
The problem of handling multiple "user" domains has never been solved.
(That is what your -tlsroot option was intended to do assuming a 1 to 1
relationship between CA root and username domains, I think?)
The problem is that getpwnam(3) needs to know how to look up user names
for these different "domain" values. (Now, both nfsused(8) and this daemon
only strips off the default domain, if it matches, and then hands the rest of
the string to getpwnam(2).)
Although "user@domain" isn't exactly an email address, they often are the
same string in practice.
I have not yet posted to nf...@ietf.org to see what they think.
However, I don't think there is any changes in the draft required to do this.
Also, I think interoperability should be ok, since it is controlled by whoever
issues the certificate for the client and the NFS client will normally just
handle this certificate opaquely.
Btw, the server TLS handshake daemon does do a SSL_CTX_set_client_CA_list(),
so it tells the client which CA (usually only one) that it wants a certificate
for.
>> The draft does not address user authentication, only machine authentication.
>> --> ie. The certificate is used to decide if a system can do a mount.
>> Users are still identified via user credentials in the RPC message
>> header.
>> For AUTH_SYS, that still means .
>> Otherwise, you need to use Kerberos (sec=krb5[ip]).
>> You could use "tls,sec=krb5" for a mount, but the only advantage that
>> might have over "sec=krb5p" is performance, if there is hardware assist
>> for TLS or something like that.
>>
>> >Now that I reread your comments, it sounds like any certificate would be
>> >allowed in #2 as long as it is valid, and that would only be marginally
>> >better than verification by IP, and in some ways worse, in that now any
>> >user could pretend to be any other user, or you have to do something
>> >crazy like have a CA per user.
>> The case where I see #2 is useful is where this discussion started some
>> weeks ago.
>> The example I started with was:
>> /home -tls -network 192.168.1.0 -mask 255.255.255.0
>> /home -tlscert
>>
>> This says that machines on the local lan can mount and do not need to have
>> certificates, but must use TLS so data is encrypted on the wire.
>> Mounts from anywhere else (presumably laptops) are allowed so long as they
>> have a
>> certificate signed by me (as in the site local CA).
>> I trust these machines enough that I am willing to allow them to use
>> AUTH_SYS,
>> which is what 99.9...% of NFS mounts do now.
>> (So, I'd agree that the site local certificate is not a lot better than IP
>> address
>> for client machine identity, just that it is an alternative that
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote this message on Thu, Mar 26, 2020 at 14:33 +: > John-Mark Gurney wrote: > [lots of stuff snipped] > >Rick Macklem wrote: > >> I had originally planned on some "secret" in the certificate (like a CN > >> name > >> that satisfies some regular expression or ???) but others convinced me that > >> that wouldn't provide anything beyond knowing that the certificate was > >> signed by the appropriate CA, so I have not implemented anything. > > > >Yeah, having a "secret" in the CN doesn't make sense, but what does make > >sense is allowing the exports line to specify what the CN should contain > >to be authenticated... > > > >Say as a corp, you issue personal certificates to everyone. This is > >because you require everyone to sign and/or encrypt their email w/ > >S/MIME. Each cert includes the email address of that person, so you > >could simply do something like: > >/home/alice -tlscert -tlsroot /etc/company.pem -email al...@example.com > > > >And anyone who has the certificate w/ al...@example.com that was signed > >by the public key in /etc/company.pem would be granted access to the > >export /home/alice. > > > >If it allowed ANY cert signed by the CA specified, then that introduces > >an authentication problem, as now if Malory is a coworker of Alice > >could also access Alice's home directory... > > > >IMO, this is one auth feature that MUST be supported... > The draft does not address user authentication, only machine authentication. > --> ie. The certificate is used to decide if a system can do a mount. > Users are still identified via user credentials in the RPC message > header. > For AUTH_SYS, that still means . > Otherwise, you need to use Kerberos (sec=krb5[ip]). > You could use "tls,sec=krb5" for a mount, but the only advantage that > might have over "sec=krb5p" is performance, if there is hardware assist > for TLS or something like that. > > >Now that I reread your comments, it sounds like any certificate would be > >allowed in #2 as long as it is valid, and that would only be marginally > >better than verification by IP, and in some ways worse, in that now any > >user could pretend to be any other user, or you have to do something > >crazy like have a CA per user. > The case where I see #2 is useful is where this discussion started some weeks > ago. > The example I started with was: > /home -tls -network 192.168.1.0 -mask 255.255.255.0 > /home -tlscert > > This says that machines on the local lan can mount and do not need to have > certificates, but must use TLS so data is encrypted on the wire. > Mounts from anywhere else (presumably laptops) are allowed so long as they > have a > certificate signed by me (as in the site local CA). > I trust these machines enough that I am willing to allow them to use AUTH_SYS, > which is what 99.9...% of NFS mounts do now. > (So, I'd agree that the site local certificate is not a lot better than IP > address > for client machine identity, just that it is an alternative that can be > useful. > Without TLS, a line like "/home" allows anyone to mount /home from anywhere > and I think you'd agree that few NFS admins. will want to do that. I'm > assuming > no external firewall for this example.) > > Now, your suggestion of identifying a user via the CN and then having the > server do all RPCs for the mount as that user is an interesting one. > My concern w.r.t. implementing it would be interoperability. > Put another way, if other servers such as Linux, Netapp,... don't adopt it > (and they won't until there is a draft/RFC specifying it), it would be > FreeBSD server specific and I'd like to avoid that. > There was some discussion w.r.t. user authentication via certificates > during development of the draft, but they decided to defer that work for > now, so they could get something in place for machine authentication first. > (If I understood the discussion on nf...@ietf.org.) There's a fine line between machine and user authentication when you can add -mapall=someuser. :) Yes, a certificate may be used to identify a machine, but if any machine can be identified by any cert as it appears that #2 is proposed to do, then you're not actually identifying a machine, you're identifying group of machines... Though per the draft, this is explicitly allowed. It'd be nice to be able to identify particular machines though, and be able to set the options based upon that.. > >I'm wonder if your use of the term secret was the problem, and not the > >idea... Anything that goes in the client cert is by definition public... > >TLS prior to 1.3 sends the client cert in clear text... But keying > >based upon the contents of the cert is fine, as that's the point of > >what a cert is.. It's trusting the CA to say that the CN and other > >fields in the cert corresponds to this user, and you can use parts of > >the cert, like the CN to decide which user the public key in the cert > >corresponds to. Rick
Re: TLS certificates for NFS-over-TLS floating client
Sorry about the top post, but I thought of a few things to add to my last post to this thread... 1 - I agree that for systems like laptops, the line between machine and user authentication is fuzzy. 2 - I do like your idea of having an exports(5) option that specifies a CN that identifies a user and then does all RPCs as that user. I'm not sure if an issuer needs to be specified (or even can be specified), since the CAfile argument to the rpctlssd daemon determines if a certificate from a particular CA will verify and the verification must happen before the exports(5) export options can be applied. (Basically, certificate verification happens via a NULL RPC that does a STARTTLS when a TCP connection to the server is first established.) 3 - I'll post to nf...@ietf.org to see what others think of this, since it would not require any changes to the draft/RFC. 4 - Although it does require a revision to the export_args structure, I think it is worth doing even if others don't implement it. Again, thanks for your comments, rick From: owner-freebsd-curr...@freebsd.org on behalf of Rick Macklem Sent: Thursday, March 26, 2020 10:33 AM To: John-Mark Gurney Cc: Alexander Leidinger; freebsd-current@FreeBSD.org Subject: Re: TLS certificates for NFS-over-TLS floating client John-Mark Gurney wrote: [lots of stuff snipped] >Rick Macklem wrote: >> I had originally planned on some "secret" in the certificate (like a CN name >> that satisfies some regular expression or ???) but others convinced me that >> that wouldn't provide anything beyond knowing that the certificate was >> signed by the appropriate CA, so I have not implemented anything. > >Yeah, having a "secret" in the CN doesn't make sense, but what does make >sense is allowing the exports line to specify what the CN should contain >to be authenticated... > >Say as a corp, you issue personal certificates to everyone. This is >because you require everyone to sign and/or encrypt their email w/ >S/MIME. Each cert includes the email address of that person, so you >could simply do something like: >/home/alice -tlscert -tlsroot /etc/company.pem -email al...@example.com > >And anyone who has the certificate w/ al...@example.com that was signed >by the public key in /etc/company.pem would be granted access to the >export /home/alice. > >If it allowed ANY cert signed by the CA specified, then that introduces >an authentication problem, as now if Malory is a coworker of Alice >could also access Alice's home directory... > >IMO, this is one auth feature that MUST be supported... The draft does not address user authentication, only machine authentication. --> ie. The certificate is used to decide if a system can do a mount. Users are still identified via user credentials in the RPC message header. For AUTH_SYS, that still means . Otherwise, you need to use Kerberos (sec=krb5[ip]). You could use "tls,sec=krb5" for a mount, but the only advantage that might have over "sec=krb5p" is performance, if there is hardware assist for TLS or something like that. >Now that I reread your comments, it sounds like any certificate would be >allowed in #2 as long as it is valid, and that would only be marginally >better than verification by IP, and in some ways worse, in that now any >user could pretend to be any other user, or you have to do something >crazy like have a CA per user. The case where I see #2 is useful is where this discussion started some weeks ago. The example I started with was: /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert This says that machines on the local lan can mount and do not need to have certificates, but must use TLS so data is encrypted on the wire. Mounts from anywhere else (presumably laptops) are allowed so long as they have a certificate signed by me (as in the site local CA). I trust these machines enough that I am willing to allow them to use AUTH_SYS, which is what 99.9...% of NFS mounts do now. (So, I'd agree that the site local certificate is not a lot better than IP address for client machine identity, just that it is an alternative that can be useful. Without TLS, a line like "/home" allows anyone to mount /home from anywhere and I think you'd agree that few NFS admins. will want to do that. I'm assuming no external firewall for this example.) Now, your suggestion of identifying a user via the CN and then having the server do all RPCs for the mount as that user is an interesting one. My concern w.r.t. implementing it would be interoperability. Put another way, if other servers such as Linux, Netapp,... don't adopt it (and they won't until there is a draft/RFC specifying it), it would be FreeBSD server specific and I'd lik
Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote: [lots of stuff snipped] >Rick Macklem wrote: >> I had originally planned on some "secret" in the certificate (like a CN name >> that satisfies some regular expression or ???) but others convinced me that >> that wouldn't provide anything beyond knowing that the certificate was >> signed by the appropriate CA, so I have not implemented anything. > >Yeah, having a "secret" in the CN doesn't make sense, but what does make >sense is allowing the exports line to specify what the CN should contain >to be authenticated... > >Say as a corp, you issue personal certificates to everyone. This is >because you require everyone to sign and/or encrypt their email w/ >S/MIME. Each cert includes the email address of that person, so you >could simply do something like: >/home/alice -tlscert -tlsroot /etc/company.pem -email al...@example.com > >And anyone who has the certificate w/ al...@example.com that was signed >by the public key in /etc/company.pem would be granted access to the >export /home/alice. > >If it allowed ANY cert signed by the CA specified, then that introduces >an authentication problem, as now if Malory is a coworker of Alice >could also access Alice's home directory... > >IMO, this is one auth feature that MUST be supported... The draft does not address user authentication, only machine authentication. --> ie. The certificate is used to decide if a system can do a mount. Users are still identified via user credentials in the RPC message header. For AUTH_SYS, that still means . Otherwise, you need to use Kerberos (sec=krb5[ip]). You could use "tls,sec=krb5" for a mount, but the only advantage that might have over "sec=krb5p" is performance, if there is hardware assist for TLS or something like that. >Now that I reread your comments, it sounds like any certificate would be >allowed in #2 as long as it is valid, and that would only be marginally >better than verification by IP, and in some ways worse, in that now any >user could pretend to be any other user, or you have to do something >crazy like have a CA per user. The case where I see #2 is useful is where this discussion started some weeks ago. The example I started with was: /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert This says that machines on the local lan can mount and do not need to have certificates, but must use TLS so data is encrypted on the wire. Mounts from anywhere else (presumably laptops) are allowed so long as they have a certificate signed by me (as in the site local CA). I trust these machines enough that I am willing to allow them to use AUTH_SYS, which is what 99.9...% of NFS mounts do now. (So, I'd agree that the site local certificate is not a lot better than IP address for client machine identity, just that it is an alternative that can be useful. Without TLS, a line like "/home" allows anyone to mount /home from anywhere and I think you'd agree that few NFS admins. will want to do that. I'm assuming no external firewall for this example.) Now, your suggestion of identifying a user via the CN and then having the server do all RPCs for the mount as that user is an interesting one. My concern w.r.t. implementing it would be interoperability. Put another way, if other servers such as Linux, Netapp,... don't adopt it (and they won't until there is a draft/RFC specifying it), it would be FreeBSD server specific and I'd like to avoid that. There was some discussion w.r.t. user authentication via certificates during development of the draft, but they decided to defer that work for now, so they could get something in place for machine authentication first. (If I understood the discussion on nf...@ietf.org.) rick >I'm wonder if your use of the term secret was the problem, and not the >idea... Anything that goes in the client cert is by definition public... >TLS prior to 1.3 sends the client cert in clear text... But keying >based upon the contents of the cert is fine, as that's the point of >what a cert is.. It's trusting the CA to say that the CN and other >fields in the cert corresponds to this user, and you can use parts of >the cert, like the CN to decide which user the public key in the cert >corresponds to. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote this message on Wed, Mar 25, 2020 at 23:50 +: > John-Mark Gurney wrote: > >Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +: > >> Alexander Leidinger wrote: > >> John-Mark Gurney wrote: > >> >>Rick Macklem wrote: > >> >>> to be the best solution. The server can verify that the certificate > >> >>> was issued by > >> >>> the local CA. Unfortunately, if the client is compromised and the > >> >>> certificate is copied > >> >>> to another client, that client would gain access. > >> >> > >> >> This is why CRLs/OSCP is necessary, but there isn't anything you can do > >> >> to prevent that. This is both a better situation than what we have > >> >> today (no auth/confidentiality), and if you tie the cert to an IP, it's > >> >> of limited use, and better than today... > >> > > >> >There are multiple ways to handle that: > >> > - First of all, you can just validate based upon "cert is signed by > >> >trusted CA". > >> > - Then you can require that the CN matches the hostname and the > >> >reverse lookup matches. > >> > - Or (similar to browsers today) you can ignore the CN and require > >> >that the hostnames of the client matches one of the subject > >> >alternative name (SAN) entries (requires reverse DNS lookup to work > >> >and match). > >> At this point, I have three variants in the code (strictest to less > >> strict): > >> 1 - A "-h" command line option on the server handshake daemon (called > >> rpctlssd). > >> This requires that all clients have > >> certificates that validate and have the FQDN acquired via reverse DNS > >> of > >> the IP address of the client for the TCP connection > >> (getnameinfo(NI_NAMEREQD)) > >> in either the subjectAltName or CommonName. (I call X509_check_host() > >> and this is what I understand it checks.) > >> --> This case implies that the NFS server admin. does not "trust" the > >> client's IP address enough to apply exports(5) line(s)to it to > >> decide to > >> allow the client to do an NFS mount. > >> (An NFS server *might* be willing to allow client(s) to mount via any > >> IP address > >> for the #2 case below and not use this option.) > >> 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to > >> indicate > >> if the client provided a certificate and whether or not it verified. > >> Then the "-tlscert" option on the appropriate exports(5) line(s) > >> indicates that the client must have provided a certificate that > >> verified. > >> --> For this case (and #3), the server admin. is willing to "trust" > >> the client's > >> IP address enough to apply exports(5) rules to it. > >> --> This is the case where a floating (no fixed IP) laptop could have > >> a > >>certificate signed by a site local CA. > >> 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s). > >> In this case, the client must use TLS so that data is encrypted on > >> the wire, > >> but does not need to have a certificate. > >> --> The NFS server admin. "trusts" the client IP address enough that > >> they > >>are willing to allow the client to mount based on that IP, but > >> wants the > >>data to be encrypted on the wire. > >>- Avoids the bother of generating certificates for the > >> client(s). > >> > >> A part of this (as discussed in the IETF draft) is to make this easy > >> enough to > >> use that it does get used. (sec=krb5p achieves both user authentication and > >> data encryption on the wire, but does not get widely used, due to the need > >> to run a KDC, etc). > >> > >> Comments on the above options is welcome, since this does need to be > >> reviewed by users. > > > >Maybe I'm missing the option where the cert needs to be authenticated, > >but matching against IP/dns name does not need to be done. Or is this > >a case of #2. I'm just confused by the first point of #2 in that the > >server admin is wiling to trust the IP address... > Yes, that is #2. "trust the IP address" probably wasn't a good way to > express it. I was simply trying to say "the NFS server admin. is willing to > use the client IP address to select rules via the exports(5) file". > > >I'd like to see where CN or other field is freeform/provided by exports > >entry, and validated to gain access to those resources... i.e. it > >doesn't matter what IP or DNS name the client is, it's based solely on > >the certificate. This would allow roaming users.. This maybe be > >addressed by #2 point 2, but it isn't clear in your description that > >it isn't dns tied or something else... > Yes, for #2 the daemon only validates the certificate (actually uses the > openssl > default verification library function). It does not filter the certificate's > CN or > other fields in any way. (It does have the implication that all the NFS > clients > could use the same certificate. I'm not
Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote: >Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +: >> Alexander Leidinger wrote: >> John-Mark Gurney wrote: >> >>Rick Macklem wrote: >> >>> to be the best solution. The server can verify that the certificate >> >>> was issued by >> >>> the local CA. Unfortunately, if the client is compromised and the >> >>> certificate is copied >> >>> to another client, that client would gain access. >> >> >> >> This is why CRLs/OSCP is necessary, but there isn't anything you can do >> >> to prevent that. This is both a better situation than what we have >> >> today (no auth/confidentiality), and if you tie the cert to an IP, it's >> >> of limited use, and better than today... >> > >> >There are multiple ways to handle that: >> > - First of all, you can just validate based upon "cert is signed by >> >trusted CA". >> > - Then you can require that the CN matches the hostname and the >> >reverse lookup matches. >> > - Or (similar to browsers today) you can ignore the CN and require >> >that the hostnames of the client matches one of the subject >> >alternative name (SAN) entries (requires reverse DNS lookup to work >> >and match). >> At this point, I have three variants in the code (strictest to less strict): >> 1 - A "-h" command line option on the server handshake daemon (called >> rpctlssd). >> This requires that all clients have >> certificates that validate and have the FQDN acquired via reverse DNS of >> the IP address of the client for the TCP connection >> (getnameinfo(NI_NAMEREQD)) >> in either the subjectAltName or CommonName. (I call X509_check_host() >> and this is what I understand it checks.) >> --> This case implies that the NFS server admin. does not "trust" the >> client's IP address enough to apply exports(5) line(s)to it to >> decide to >> allow the client to do an NFS mount. >> (An NFS server *might* be willing to allow client(s) to mount via any >> IP address >> for the #2 case below and not use this option.) >> 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indicate >> if the client provided a certificate and whether or not it verified. >> Then the "-tlscert" option on the appropriate exports(5) line(s) >> indicates that the client must have provided a certificate that >> verified. >> --> For this case (and #3), the server admin. is willing to "trust" the >> client's >> IP address enough to apply exports(5) rules to it. >> --> This is the case where a floating (no fixed IP) laptop could have a >>certificate signed by a site local CA. >> 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s). >> In this case, the client must use TLS so that data is encrypted on the >> wire, >> but does not need to have a certificate. >> --> The NFS server admin. "trusts" the client IP address enough that >> they >>are willing to allow the client to mount based on that IP, but >> wants the >>data to be encrypted on the wire. >>- Avoids the bother of generating certificates for the client(s). >> >> A part of this (as discussed in the IETF draft) is to make this easy enough >> to >> use that it does get used. (sec=krb5p achieves both user authentication and >> data encryption on the wire, but does not get widely used, due to the need >> to run a KDC, etc). >> >> Comments on the above options is welcome, since this does need to be >> reviewed by users. > >Maybe I'm missing the option where the cert needs to be authenticated, >but matching against IP/dns name does not need to be done. Or is this >a case of #2. I'm just confused by the first point of #2 in that the >server admin is wiling to trust the IP address... Yes, that is #2. "trust the IP address" probably wasn't a good way to express it. I was simply trying to say "the NFS server admin. is willing to use the client IP address to select rules via the exports(5) file". >I'd like to see where CN or other field is freeform/provided by exports >entry, and validated to gain access to those resources... i.e. it >doesn't matter what IP or DNS name the client is, it's based solely on >the certificate. This would allow roaming users.. This maybe be >addressed by #2 point 2, but it isn't clear in your description that >it isn't dns tied or something else... Yes, for #2 the daemon only validates the certificate (actually uses the openssl default verification library function). It does not filter the certificate's CN or other fields in any way. (It does have the implication that all the NFS clients could use the same certificate. I'm not sure that would be a good plan, since revoking the certificate would revoke it for all clients and having it on N clients would increase the risk of it being compromised, but ...) --> The only way I can see that the server can enforce each client to use a separate certificate
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote this message on Mon, Mar 23, 2020 at 23:53 +: > Alexander Leidinger wrote: > John-Mark Gurney wrote: > >>Rick Macklem wrote: > >>> to be the best solution. The server can verify that the certificate > >>> was issued by > >>> the local CA. Unfortunately, if the client is compromised and the > >>> certificate is copied > >>> to another client, that client would gain access. > >> > >> This is why CRLs/OSCP is necessary, but there isn't anything you can do > >> to prevent that. This is both a better situation than what we have > >> today (no auth/confidentiality), and if you tie the cert to an IP, it's > >> of limited use, and better than today... > > > >There are multiple ways to handle that: > > - First of all, you can just validate based upon "cert is signed by > >trusted CA". > > - Then you can require that the CN matches the hostname and the > >reverse lookup matches. > > - Or (similar to browsers today) you can ignore the CN and require > >that the hostnames of the client matches one of the subject > >alternative name (SAN) entries (requires reverse DNS lookup to work > >and match). > At this point, I have three variants in the code (strictest to less strict): > 1 - A "-h" command line option on the server handshake daemon (called > rpctlssd). > This requires that all clients have > certificates that validate and have the FQDN acquired via reverse DNS of > the IP address of the client for the TCP connection > (getnameinfo(NI_NAMEREQD)) > in either the subjectAltName or CommonName. (I call X509_check_host() > and this is what I understand it checks.) > --> This case implies that the NFS server admin. does not "trust" the > client's IP address enough to apply exports(5) line(s)to it to > decide to > allow the client to do an NFS mount. > (An NFS server *might* be willing to allow client(s) to mount via any IP > address > for the #2 case below and not use this option.) > 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indicate > if the client provided a certificate and whether or not it verified. > Then the "-tlscert" option on the appropriate exports(5) line(s) > indicates that the client must have provided a certificate that verified. > --> For this case (and #3), the server admin. is willing to "trust" the > client's > IP address enough to apply exports(5) rules to it. > --> This is the case where a floating (no fixed IP) laptop could have a >certificate signed by a site local CA. > 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s). > In this case, the client must use TLS so that data is encrypted on the > wire, > but does not need to have a certificate. > --> The NFS server admin. "trusts" the client IP address enough that they >are willing to allow the client to mount based on that IP, but > wants the >data to be encrypted on the wire. >- Avoids the bother of generating certificates for the client(s). > > A part of this (as discussed in the IETF draft) is to make this easy enough to > use that it does get used. (sec=krb5p achieves both user authentication and > data encryption on the wire, but does not get widely used, due to the need > to run a KDC, etc). > > Comments on the above options is welcome, since this does need to be > reviewed by users. Maybe I'm missing the option where the cert needs to be authenticated, but matching against IP/dns name does not need to be done. Or is this a case of #2. I'm just confused by the first point of #2 in that the server admin is wiling to trust the IP address... I'd like to see where CN or other field is freeform/provided by exports entry, and validated to gain access to those resources... i.e. it doesn't matter what IP or DNS name the client is, it's based solely on the certificate. This would allow roaming users.. This maybe be addressed by #2 point 2, but it isn't clear in your description that it isn't dns tied or something else... As the CA admin, they control what is valid/gets signed in the CN or other fields, so this is safe to do... If you can't trust your CA to sign only valid (to your policy) certs, then you shouldn't be using that CA.. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Alexander Leidinger wrote: John-Mark Gurney wrote: >>Rick Macklem wrote: >>> to be the best solution. The server can verify that the certificate >>> was issued by >>> the local CA. Unfortunately, if the client is compromised and the >>> certificate is copied >>> to another client, that client would gain access. >> >> This is why CRLs/OSCP is necessary, but there isn't anything you can do >> to prevent that. This is both a better situation than what we have >> today (no auth/confidentiality), and if you tie the cert to an IP, it's >> of limited use, and better than today... > >There are multiple ways to handle that: > - First of all, you can just validate based upon "cert is signed by >trusted CA". > - Then you can require that the CN matches the hostname and the >reverse lookup matches. > - Or (similar to browsers today) you can ignore the CN and require >that the hostnames of the client matches one of the subject >alternative name (SAN) entries (requires reverse DNS lookup to work >and match). At this point, I have three variants in the code (strictest to less strict): 1 - A "-h" command line option on the server handshake daemon (called rpctlssd). This requires that all clients have certificates that validate and have the FQDN acquired via reverse DNS of the IP address of the client for the TCP connection (getnameinfo(NI_NAMEREQD)) in either the subjectAltName or CommonName. (I call X509_check_host() and this is what I understand it checks.) --> This case implies that the NFS server admin. does not "trust" the client's IP address enough to apply exports(5) line(s)to it to decide to allow the client to do an NFS mount. (An NFS server *might* be willing to allow client(s) to mount via any IP address for the #2 case below and not use this option.) 2 - Without "-h" the rpctlssd daemon passes flags into the kernel to indicate if the client provided a certificate and whether or not it verified. Then the "-tlscert" option on the appropriate exports(5) line(s) indicates that the client must have provided a certificate that verified. --> For this case (and #3), the server admin. is willing to "trust" the client's IP address enough to apply exports(5) rules to it. --> This is the case where a floating (no fixed IP) laptop could have a certificate signed by a site local CA. 3 - Similar to #2, but uses the "-tls" option on the exports(5) line(s). In this case, the client must use TLS so that data is encrypted on the wire, but does not need to have a certificate. --> The NFS server admin. "trusts" the client IP address enough that they are willing to allow the client to mount based on that IP, but wants the data to be encrypted on the wire. - Avoids the bother of generating certificates for the client(s). A part of this (as discussed in the IETF draft) is to make this easy enough to use that it does get used. (sec=krb5p achieves both user authentication and data encryption on the wire, but does not get widely used, due to the need to run a KDC, etc). Comments on the above options is welcome, since this does need to be reviewed by users. rick At this point you prevent simple cert theft as additionally you require that someone also has to be able to modify the DNS (or NFS server hosts file, but then he probably can already add an additional cert to the truststore of nfsd). Additional protection is possible by also adding the IP to the SAN. I haven't put an effort into evaluating if either IP or DNS is enough from a security point of view, or if it makes a difference if the "IP in SAN" case has an additional benefit in terms of security if it is in addition to the reverse DNS requirement. Yes this makes it more inconvenient to change the IP of a host, but if all the policy possibilities are up to the admin to configure (e.g. "cert is signed by trusted CA" as a default, and all the other possibilities as an option for nfsd), it is up to the admin and the security requirement. In general, all the possibilities are can either be distinct, or accumulative. There is also the possibility that you do not go with any CA but configure X self-signed certs for X clients as being trusted and the cert of the client needs to be an exact match with one of the X self-signed certs in the truststore. Whatever the policy(/ies) is/are in nfsd, I suggest to make it explicit in the docs what is required and what is checked for each policy. And even if it may be obvious for you Rick, please also print out why a client was rejected. Unfortunately I've seen a lot of cases where the error is a simple/frustrating "certificate rejected", but no info which part of the certificate check failed. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org
Re: TLS certificates for NFS-over-TLS floating client
Quoting John-Mark Gurney (from Fri, 20 Mar 2020 12:29:23 -0700): to be the best solution. The server can verify that the certificate was issued by the local CA. Unfortunately, if the client is compromised and the certificate is copied to another client, that client would gain access. This is why CRLs/OSCP is necessary, but there isn't anything you can do to prevent that. This is both a better situation than what we have today (no auth/confidentiality), and if you tie the cert to an IP, it's of limited use, and better than today... There are multiple ways to handle that: - First of all, you can just validate based upon "cert is signed by trusted CA". - Then you can require that the CN matches the hostname and the reverse lookup matches. - Or (similar to browsers today) you can ignore the CN and require that the hostnames of the client matches one of the subject alternative name (SAN) entries (requires reverse DNS lookup to work and match). At this point you prevent simple cert theft as additionally you require that someone also has to be able to modify the DNS (or NFS server hosts file, but then he probably can already add an additional cert to the truststore of nfsd). Additional protection is possible by also adding the IP to the SAN. I haven't put an effort into evaluating if either IP or DNS is enough from a security point of view, or if it makes a difference if the "IP in SAN" case has an additional benefit in terms of security if it is in addition to the reverse DNS requirement. Yes this makes it more inconvenient to change the IP of a host, but if all the policy possibilities are up to the admin to configure (e.g. "cert is signed by trusted CA" as a default, and all the other possibilities as an option for nfsd), it is up to the admin and the security requirement. In general, all the possibilities are can either be distinct, or accumulative. There is also the possibility that you do not go with any CA but configure X self-signed certs for X clients as being trusted and the cert of the client needs to be an exact match with one of the X self-signed certs in the truststore. Whatever the policy(/ies) is/are in nfsd, I suggest to make it explicit in the docs what is required and what is checked for each policy. And even if it may be obvious for you Rick, please also print out why a client was rejected. Unfortunately I've seen a lot of cases where the error is a simple/frustrating "certificate rejected", but no info which part of the certificate check failed. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpLDrnpofywd.pgp Description: Digitale PGP-Signatur
Re: TLS certificates for NFS-over-TLS floating client
Miroslav Lachman wrote: >Rick Macklem wrote on 2020/03/19 03:09: >> Miroslav Lachman wrote: >>> >> [...] > >>> NFS (or any other server) should check list of revoked certificates too. >>> Otherwise you will not be able to deny access to user which you no >>> longer want to have an access. >> Yes, good point. >> I won't claim to understand this stuff, but from what I can see, all that is >> done is the CRL is appended to the CAfile (the one with the CA certificates >> are in being used for certificate verification via >> SSL__CTX_load_verify_locations(). >> >(https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html >> shows a CAfile and CRLfile being concatenated and then used to verify a >> certificate.) >> >> There is code in sendmail that loads a CRL file separately, but it seems to >> just put it in the X509 store returned by SSL_CTX_get_cert_store(), which >> is the one where the CAfile certificates are stored via >> SSL_CTX_load_verify_locations(), >> I think? >> (It just seems easier to append it to CAfile than do this. The sendmail code >> uses >> poorly documented functions where the man page says >> "SSL_CTX_load_verify_locations()" normally takes care of this.) >> >> Does this sound right? rick > >I think it would be better to have it in a separate file as Apache does >https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcarevocationfile > >Seems more convenient to have CA file write protected (read only) and >then separate file for list of revoked client certificates, maybe >somewhere else than CA certificate. Done. (Actually, the SSL_CTX_load_verify_locations() failed when the CRL was appended to the CAfile, so I needed to use a separate file to get it working.) I found X509_load_crl_file(), which does all the glop in sendmail's tls.c file to do it. (And it looks like the sendmail code only handles a CRL file with a single entry in it.) Thanks for the comments, rick Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Jan Bramkamp wrote: >On 20.03.20 02:44, Russell L. Carter wrote: >> Here I commit heresy, by A) top posting, and B) by just saying, why >> not make it easy, first, to tunnel NFSv4 sessions through >> e.g. net/wireguard or sysutils/spiped? NFS is point to point. >> Security infrastructure that actually works understands the shared >> secret model. > >Why not use IPsec in transport mode instead of a tunnel? It avoids >unnecessary overhead and is already implemented in the kernel. It should >be enough to "just" require IPsec for TCP port 2049 and run a suitable >key exchange daemon. I think the problem with these suggestions is interoperability. The draft (that should soon become an RFC) describes use of RPC-over-TLS and since the authors are both Linux NFS developers, I expect Linux to implement this someday. Once the Linux client can do it, the NFS server vendors will implement it. NFS isn't great, but it is supported by a variety of vendors/systems and I see that as one of its main features. rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
On 20.03.20 20:45, John-Mark Gurney wrote: Jan Bramkamp wrote this message on Fri, Mar 20, 2020 at 18:51 +0100: On 20.03.20 02:44, Russell L. Carter wrote: Here I commit heresy, by A) top posting, and B) by just saying, why not make it easy, first, to tunnel NFSv4 sessions through e.g. net/wireguard or sysutils/spiped? NFS is point to point. Security infrastructure that actually works understands the shared secret model. VPN tunneling doesn't provide the security that most people thinks it does... It requires complicated configuration, and often doesn't provide e2e protections. I fully agree that IPsec is a bitch to configure, but IPsec tranport mode between NFSv4 client and server would provide end to end encryption. Why not use IPsec in transport mode instead of a tunnel? It avoids unnecessary overhead and is already implemented in the kernel. It should be enough to "just" require IPsec for TCP port 2049 and run a suitable key exchange daemon. Because IPsec is a PITA to configure and work, and lots of consumer OSes don't make it at all easy. Does any consumer OS support NFSv4 over TLS? Also, you forget that FreeBSD has ktls, which usees the same crypto offload engine that IPsec does, so it will effectively have similar overhead, and might actually perform better due to TLS having a 16k record encryption size vs IPsec limiting itself to packet size, usually 1500, though possibly 9k if you're using jumbo frames... I compared IPsec to userspace tunnels like spiped or wireguard-go not kTLS. If kTLS can use LRO/TSO etc. it would avoid even more overhead. I fully support doing NFS over TLS. I would love to run NFS over TLS, but it isn't implemented yet and afaik kTLS only accelerates TLS sending and would require a userspace proxy to receive TLS at the moment while IPsec transport mode is just a nasty fight with strongSwan away. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote on 2020/03/20 20:29: Rick Macklem wrote this message on Thu, Mar 19, 2020 at 23:41 +: [...] Without a problem statement or what you're trying to accomplish, it's hard to say if it is. The problem I was/am trying to solve was a way for NFS clients without a fixed IP/DNS name could have a certificate to allow access to the NFS server. As suggested by others, having a site local CA created by the NFS admin. seemed Yes, I totally agree w/ this as the best solution. It also allows private hostnames to be used w/o leaking outside the org.. It'd be nice to have better tooling around the CA though. I still haven't found any good tools that make a CA simple to use for small installs... (and by simple, I mean single init command, and single command to issue a cert or generate a key/cert pair, all of them are like, make all thesse directories, edit these files, and run these comlicated commands) security/easy-rsa is very close to this. # easyrsa init-pki # easyrsa build-ca # easyrsa build-server-full # easyrsa build-client-full # easyrsa build-client-full # easyrsa build-client-full or # easyrsa build-client-full nopass And usually # easyrsa gen-dh With "build-ca" you will create key and certificate for you private CA With "build-server-full" you will create key and certificate for your server With "build-client-full" you will create key and certificate for clients It also supports "revoke" and "gen-crl" to revoke compromised certificate and update CRL. Yes, it could be made a bit simpler and run init-pki in the background if build-ca is run for the first time so you can save one step. I don't say easy-rsa is the best choice. I am able to use full openssl commands or write my own tools / scripts around it I choose easy-rsa on machines where somebody else needs to work with certs. [...] Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Jan Bramkamp wrote this message on Fri, Mar 20, 2020 at 18:51 +0100: > On 20.03.20 02:44, Russell L. Carter wrote: > > Here I commit heresy, by A) top posting, and B) by just saying, why > > not make it easy, first, to tunnel NFSv4 sessions through > > e.g. net/wireguard or sysutils/spiped? NFS is point to point. > > Security infrastructure that actually works understands the shared > > secret model. VPN tunneling doesn't provide the security that most people thinks it does... It requires complicated configuration, and often doesn't provide e2e protections. > Why not use IPsec in transport mode instead of a tunnel? It avoids > unnecessary overhead and is already implemented in the kernel. It should > be enough to "just" require IPsec for TCP port 2049 and run a suitable > key exchange daemon. Because IPsec is a PITA to configure and work, and lots of consumer OSes don't make it at all easy. Also, you forget that FreeBSD has ktls, which usees the same crypto offload engine that IPsec does, so it will effectively have similar overhead, and might actually perform better due to TLS having a 16k record encryption size vs IPsec limiting itself to packet size, usually 1500, though possibly 9k if you're using jumbo frames... I fully support doing NFS over TLS. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote this message on Thu, Mar 19, 2020 at 23:41 +: > John-Mark Gurney wrote: > >Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: > >> I am slowly trying to understand TLS certificates and am trying to figure > >> out how to do the following: > >> -> For an /etc/exports file with... > >> /home -tls -network 192.168.1.0 -mask 255.255.255.0 > >> /home -tlscert > > > >Are you looking at implementing draft-cel-nfsv4-rpc-tls? > Yes. The 2 week out of date (I can only do commits once in a while these > days) can > be found in FreeBSD's subversion under base/projects/nfs-over-tls. Nifty. And looks like you know about the ktls stuff, nice... > >> This syntax isn't implemented yet, but the thinking is that clients on the > >> 192.168.1 subnet would use TLS, but would not require a certificate. > >> For access from anywhere else, the client(s) would be required to have a > >> certificate. > >> > >> A typical client mounting from outside of the subnet might be my laptop, > >> which is using wifi and has no fixed IP/DNS name. > >> --> How do you create a certificate that the laptop can use, which the NFS > >>server can trust enough to allow the mount? > >> My thinking is that a "secret" value can be put in the certificate that > >> the NFS > >> server can check for. > >> The simplest way would be a fairly long list of random characters in the > >> organizationName and/or organizationUnitName field(s) of the subject name. > >> Alternately, it could be a newly defined extension for X509v3, I think? > >> > >> Now, I'm not sure, but I don't think this certificate can be created via > >> a trust authority such that it would "verify". However, the server can > >> look for the "secret" in the certificate and allow the mount based on that. > >> > >> Does this sound reasonable? > > > >Without a problem statement or what you're trying to accomplish, it's > >hard to say if it is. > The problem I was/am trying to solve was a way for NFS clients without a > fixed IP/DNS name could have a certificate to allow access to the NFS server. > As suggested by others, having a site local CA created by the NFS admin. > seemed Yes, I totally agree w/ this as the best solution. It also allows private hostnames to be used w/o leaking outside the org.. It'd be nice to have better tooling around the CA though. I still haven't found any good tools that make a CA simple to use for small installs... (and by simple, I mean single init command, and single command to issue a cert or generate a key/cert pair, all of them are like, make all thesse directories, edit these files, and run these comlicated commands) Another option is to just use self sign certs and manually add each one for a host, not sure how difficult this would be in code... This would probably be easiest w/ a small number of clients, eliminates the difficulty of doing a CRL/OSCP, as if a client gets compromised, you just delete their cert till a new one is issued... > to be the best solution. The server can verify that the certificate was > issued by > the local CA. Unfortunately, if the client is compromised and the certificate > is copied > to another client, that client would gain access. This is why CRLs/OSCP is necessary, but there isn't anything you can do to prevent that. This is both a better situation than what we have today (no auth/confidentiality), and if you tie the cert to an IP, it's of limited use, and better than today... > --> I've thought of having the client keep the certificate encrypted in a > file and >require the "user" of the client type in a passphrase to unencrypt the > certificate >so that it can be used by the daemon in the client that handles the > client side >of the TLS handshake, but I have not implemented this. >--> This would at least subvert the simple case of the certificate > file being copied > to a different client and being used to mount the NFS server, > but if the > client is compromised, then the passphrase could be captured > and... Exactly. Just make sure that it's clear how to handle a revoked certificate when this happens, and you're good... > >> Also, even if the NFS client/server have fixed IP addresses with well known > >> DNS names, it isn't obvious to me how signed certificates can be acquired > >> for them? > >> (Lets Encrypt expects the Acme protocol to work and that seems to be > >> web site/http specific?) > > > >There is DNS challenges that can be used. I use them to obtain certs > >for SMTP and SIP servers... using nsupdate, this is relatively easy to > >automate pushing the challenges to a DNS server, and I now use DNS > >challenges for everything, including https. > Since my internet connection is a single dynamically assigned IP from the > phone > company, I doubt this would work for me (which I why I say I don't know how > to do this). I suspect there are ways and it would be nice if you
Re: TLS certificates for NFS-over-TLS floating client
On 20.03.20 02:44, Russell L. Carter wrote: Here I commit heresy, by A) top posting, and B) by just saying, why not make it easy, first, to tunnel NFSv4 sessions through e.g. net/wireguard or sysutils/spiped? NFS is point to point. Security infrastructure that actually works understands the shared secret model. Why not use IPsec in transport mode instead of a tunnel? It avoids unnecessary overhead and is already implemented in the kernel. It should be enough to "just" require IPsec for TCP port 2049 and run a suitable key exchange daemon. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
So ok, it's good to code to RFCs. OTOH, state actors are a thing now. Alice & Bob's protocols need to be perfect. State actors watch for mistakes. Here I commit heresy, by A) top posting, and B) by just saying, why not make it easy, first, to tunnel NFSv4 sessions through e.g. net/wireguard or sysutils/spiped? NFS is point to point. Security infrastructure that actually works understands the shared secret model. Not going to argue further. I'm a grateful letsencrypt consumer. Rick is a hero for his NFS work. I use his code every day. Best, Russell On 2020-03-19 16:41, Rick Macklem wrote: John-Mark Gurney wrote: Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: I am slowly trying to understand TLS certificates and am trying to figure out how to do the following: -> For an /etc/exports file with... /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert Are you looking at implementing draft-cel-nfsv4-rpc-tls? Yes. The 2 week out of date (I can only do commits once in a while these days) can be found in FreeBSD's subversion under base/projects/nfs-over-tls. This syntax isn't implemented yet, but the thinking is that clients on the 192.168.1 subnet would use TLS, but would not require a certificate. For access from anywhere else, the client(s) would be required to have a certificate. A typical client mounting from outside of the subnet might be my laptop, which is using wifi and has no fixed IP/DNS name. --> How do you create a certificate that the laptop can use, which the NFS server can trust enough to allow the mount? My thinking is that a "secret" value can be put in the certificate that the NFS server can check for. The simplest way would be a fairly long list of random characters in the organizationName and/or organizationUnitName field(s) of the subject name. Alternately, it could be a newly defined extension for X509v3, I think? Now, I'm not sure, but I don't think this certificate can be created via a trust authority such that it would "verify". However, the server can look for the "secret" in the certificate and allow the mount based on that. Does this sound reasonable? Without a problem statement or what you're trying to accomplish, it's hard to say if it is. The problem I was/am trying to solve was a way for NFS clients without a fixed IP/DNS name could have a certificate to allow access to the NFS server. As suggested by others, having a site local CA created by the NFS admin. seemed to be the best solution. The server can verify that the certificate was issued by the local CA. Unfortunately, if the client is compromised and the certificate is copied to another client, that client would gain access. --> I've thought of having the client keep the certificate encrypted in a file and require the "user" of the client type in a passphrase to unencrypt the certificate so that it can be used by the daemon in the client that handles the client side of the TLS handshake, but I have not implemented this. --> This would at least subvert the simple case of the certificate file being copied to a different client and being used to mount the NFS server, but if the client is compromised, then the passphrase could be captured and... Also, even if the NFS client/server have fixed IP addresses with well known DNS names, it isn't obvious to me how signed certificates can be acquired for them? (Lets Encrypt expects the Acme protocol to work and that seems to be web site/http specific?) There is DNS challenges that can be used. I use them to obtain certs for SMTP and SIP servers... using nsupdate, this is relatively easy to automate pushing the challenges to a DNS server, and I now use DNS challenges for everything, including https. Since my internet connection is a single dynamically assigned IP from the phone company, I doubt this would work for me (which I why I say I don't know how to do this). I suspect there are ways and it would be nice if you could document this, so I can put it in a howto document. - An actual example using the nsupdate command would be nice. Thanks, rick Thanks for any help with this, rick Let me know if you'd like to hop on a call about this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
John-Mark Gurney wrote: >Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: >> I am slowly trying to understand TLS certificates and am trying to figure >> out how to do the following: >> -> For an /etc/exports file with... >> /home -tls -network 192.168.1.0 -mask 255.255.255.0 >> /home -tlscert > >Are you looking at implementing draft-cel-nfsv4-rpc-tls? Yes. The 2 week out of date (I can only do commits once in a while these days) can be found in FreeBSD's subversion under base/projects/nfs-over-tls. >> This syntax isn't implemented yet, but the thinking is that clients on the >> 192.168.1 subnet would use TLS, but would not require a certificate. >> For access from anywhere else, the client(s) would be required to have a >> certificate. >> >> A typical client mounting from outside of the subnet might be my laptop, >> which is using wifi and has no fixed IP/DNS name. >> --> How do you create a certificate that the laptop can use, which the NFS >>server can trust enough to allow the mount? >> My thinking is that a "secret" value can be put in the certificate that the >> NFS >> server can check for. >> The simplest way would be a fairly long list of random characters in the >> organizationName and/or organizationUnitName field(s) of the subject name. >> Alternately, it could be a newly defined extension for X509v3, I think? >> >> Now, I'm not sure, but I don't think this certificate can be created via >> a trust authority such that it would "verify". However, the server can >> look for the "secret" in the certificate and allow the mount based on that. >> >> Does this sound reasonable? > >Without a problem statement or what you're trying to accomplish, it's >hard to say if it is. The problem I was/am trying to solve was a way for NFS clients without a fixed IP/DNS name could have a certificate to allow access to the NFS server. As suggested by others, having a site local CA created by the NFS admin. seemed to be the best solution. The server can verify that the certificate was issued by the local CA. Unfortunately, if the client is compromised and the certificate is copied to another client, that client would gain access. --> I've thought of having the client keep the certificate encrypted in a file and require the "user" of the client type in a passphrase to unencrypt the certificate so that it can be used by the daemon in the client that handles the client side of the TLS handshake, but I have not implemented this. --> This would at least subvert the simple case of the certificate file being copied to a different client and being used to mount the NFS server, but if the client is compromised, then the passphrase could be captured and... >> Also, even if the NFS client/server have fixed IP addresses with well known >> DNS names, it isn't obvious to me how signed certificates can be acquired >> for them? >> (Lets Encrypt expects the Acme protocol to work and that seems to be >> web site/http specific?) > >There is DNS challenges that can be used. I use them to obtain certs >for SMTP and SIP servers... using nsupdate, this is relatively easy to >automate pushing the challenges to a DNS server, and I now use DNS >challenges for everything, including https. Since my internet connection is a single dynamically assigned IP from the phone company, I doubt this would work for me (which I why I say I don't know how to do this). I suspect there are ways and it would be nice if you could document this, so I can put it in a howto document. - An actual example using the nsupdate command would be nice. Thanks, rick > Thanks for any help with this, rick Let me know if you'd like to hop on a call about this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 +: > I am slowly trying to understand TLS certificates and am trying to figure > out how to do the following: > -> For an /etc/exports file with... > /home -tls -network 192.168.1.0 -mask 255.255.255.0 > /home -tlscert Are you looking at implementing draft-cel-nfsv4-rpc-tls? > This syntax isn't implemented yet, but the thinking is that clients on the > 192.168.1 subnet would use TLS, but would not require a certificate. > For access from anywhere else, the client(s) would be required to have a > certificate. > > A typical client mounting from outside of the subnet might be my laptop, > which is using wifi and has no fixed IP/DNS name. > --> How do you create a certificate that the laptop can use, which the NFS >server can trust enough to allow the mount? > My thinking is that a "secret" value can be put in the certificate that the > NFS > server can check for. > The simplest way would be a fairly long list of random characters in the > organizationName and/or organizationUnitName field(s) of the subject name. > Alternately, it could be a newly defined extension for X509v3, I think? > > Now, I'm not sure, but I don't think this certificate can be created via > a trust authority such that it would "verify". However, the server can > look for the "secret" in the certificate and allow the mount based on that. > > Does this sound reasonable? Without a problem statement or what you're trying to accomplish, it's hard to say if it is. > Also, even if the NFS client/server have fixed IP addresses with well known > DNS names, it isn't obvious to me how signed certificates can be acquired > for them? > (Lets Encrypt expects the Acme protocol to work and that seems to be > web site/http specific?) There is DNS challenges that can be used. I use them to obtain certs for SMTP and SIP servers... using nsupdate, this is relatively easy to automate pushing the challenges to a DNS server, and I now use DNS challenges for everything, including https. > Thanks for any help with this, rick Let me know if you'd like to hop on a call about this. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote on 2020/03/19 03:09: Miroslav Lachman wrote: [...] NFS (or any other server) should check list of revoked certificates too. Otherwise you will not be able to deny access to user which you no longer want to have an access. Yes, good point. I won't claim to understand this stuff, but from what I can see, all that is done is the CRL is appended to the CAfile (the one with the CA certificates are in being used for certificate verification via SSL__CTX_load_verify_locations(). (https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html shows a CAfile and CRLfile being concatenated and then used to verify a certificate.) There is code in sendmail that loads a CRL file separately, but it seems to just put it in the X509 store returned by SSL_CTX_get_cert_store(), which is the one where the CAfile certificates are stored via SSL_CTX_load_verify_locations(), I think? (It just seems easier to append it to CAfile than do this. The sendmail code uses poorly documented functions where the man page says "SSL_CTX_load_verify_locations()" normally takes care of this.) Does this sound right? rick I think it would be better to have it in a separate file as Apache does https://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcarevocationfile Seems more convenient to have CA file write protected (read only) and then separate file for list of revoked client certificates, maybe somewhere else than CA certificate. Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Miroslav Lachman wrote: >Hiroki Sato wrote on 2020/03/04 05:35: > [...] > >> I do not think it is a good idea to use a certificate with an >> embedded secret for authentication and/or authorization. >> >> In the case that the client offers a certificate upon establishing a >> TLS connection for authentication purpose, the authenticity will be >> checked on the server usually by using the CA certificate which was >> used to issue the client certificate. The CA cert must be put to >> somewhere the NFS server can read. >> >> The CA cert is secret. So if the NFS server can check the client >> certificate by the CA certificate, it means the NFS server can >> trust the client. I think no additional information is required. > >NFS (or any other server) should check list of revoked certificates too. >Otherwise you will not be able to deny access to user which you no >longer want to have an access. Yes, good point. I won't claim to understand this stuff, but from what I can see, all that is done is the CRL is appended to the CAfile (the one with the CA certificates are in being used for certificate verification via SSL__CTX_load_verify_locations(). (https://raymii.org/s/articles/OpenSSL_manually_verify_a_certificate_against_a_CRL.html shows a CAfile and CRLfile being concatenated and then used to verify a certificate.) There is code in sendmail that loads a CRL file separately, but it seems to just put it in the X509 store returned by SSL_CTX_get_cert_store(), which is the one where the CAfile certificates are stored via SSL_CTX_load_verify_locations(), I think? (It just seems easier to append it to CAfile than do this. The sendmail code uses poorly documented functions where the man page says "SSL_CTX_load_verify_locations()" normally takes care of this.) Does this sound right? rick > Authorization such as which mount point can be mounted by using the > client cert can be implemented by using the CN field or other X.509 > attributes, of course. It can be just a clear text. > > I think this is one of the most reliable and straightforward ways > because in most cases both NFS servers and the clients are under the > sysadmin's control. > > rm> Now, I'm not sure, but I don't think this certificate can be created via > rm> a trust authority such that it would "verify". However, the server can > rm> look for the "secret" in the certificate and allow the mount based on > that. > > In the way described above, to use TLS client authentication, the NFS > server admin has to have a certificate which allows to sign another > certificate. This means that the admin must be a CA or trusted > authority. > > In practice, one can generate a self-signed certificate by using > openssl(1) and use it as its CA certificate. He can issue > certificates signed by it for the NFS clients, and put his CA > certificate to somewhere the NFS server can read. Take a look on easy-rsa https://www.freshports.org/security/easy-rsa/ It is used for example by OpenVPN to create private CA and sign certificates of clients. It is good starting point to understand what and how can work. > rm> Also, even if the NFS client/server have fixed IP addresses with well > known > rm> DNS names, it isn't obvious to me how signed certificates can be acquired > rm> for them? > rm> (Lets Encrypt expects the Acme protocol to work and that seems to be > rm> web site/http specific?) > > TLS certificates do not always have (or do not need to have) a domain > name as an attribute. Data in attributes are restricted depending on > the purpose, so certificates issued by Let's Encrypt can have only > domain names (CN or Subject Alternative Name), for example. An > example which is not supported by Let's Encrypt is a certificate for > S/MIME email encryption which has an email address. Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote: >Benjamin Kaduk wrote: >>Rick Macklem wrote: [stuff snipped] >>> A typical client mounting from outside of the subnet might be my laptop, >>> which is using wifi and has no fixed IP/DNS name. >>> --> How do you create a certificate that the laptop can use, which the NFS >>>server can trust enough to allow the mount? >> >>You can give your laptop a certificate for an arbitrary name, provided that >>the NFS server knows to "validate" that name in an appropriate fashion. (I >>don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.) The draft seems to just refer to RFC5280 and it seems to allow a local CA (Page 12, 2nd (a) section on page). It does not seem to specify details w.r.t. validation beyond that. >As you note below, creating a site local CA is probably appropriate and the >server should be able to check that the certificates were signed by this. >(I haven't quite figured out how to do this yet. I think I've created the CA >and used to sign a client certificate, but haven't yet gotten the server daemon >to verify it. (Playing with SSL_set_verify_locations() to try to get it to >work.;-) Just fyi, I got this working. My mistake yesterday was that I created a certificate for the client that had a SubjectName identical to the IssuerName. It happened because I test on one machine (client and server) and I used the hostname as the CN. --> This resulted in SSL_get_verify_results() returning "self-signed". Once I created a client certificate with a different CN in the SubjectName, it validated ok. Thanks everyone for your help sofar, rick >> My thinking is that a "secret" value can be put in the certificate that the >> NFS >> server can check for. >> The simplest way would be a fairly long list of random characters in the >> organizationName and/or organizationUnitName field(s) of the subject name. >> Alternately, it could be a newly defined extension for X509v3, I think? > >It would be better to just make a site-local CA and trust everything it >issues (which, admittedly, is not the greatest option itself.) I had thought this would be too much work, but it seems fairly straightforward, so this is what I am now working on. >> Now, I'm not sure, but I don't think this certificate can be created via >> a trust authority such that it would "verify". However, the server can >> look for the "secret" in the certificate and allow the mount based on that. >> >> Does this sound reasonable? > >I'm not sure what goal you're trying to achieve by this "security through >obscurity". Yes. I now see it is the CA stuff that can stay secret. >> Also, even if the NFS client/server have fixed IP addresses with well known >> DNS names, it isn't obvious to me how signed certificates can be acquired >> for them? >> (Lets Encrypt expects the Acme protocol to work and that seems to be >> web site/http specific?) > >RFC 8738 specifies the ACME protocol for validating IP addresses. I had looked at an older RFC, where it seemed to be web site specific. Since none of my stuff has fixed well known DNS names, I'm not going to worry about using an established CA for now. Thanks to everyone for their comments. I may respond to some of the other posts, but I'm figuring things out for now. rick -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Benjamin Kaduk wrote: >On Wed, Mar 04, 2020 at 03:15:48AM +, Rick Macklem wrote: >> Hi, >> >> I am slowly trying to understand TLS certificates and am trying to figure >> out how to do the following: >> -> For an /etc/exports file with... >> /home -tls -network 192.168.1.0 -mask 255.255.255.0 >> /home -tlscert >> >> This syntax isn't implemented yet, but the thinking is that clients on the >> 192.168.1 subnet would use TLS, but would not require a certificate. >> For access from anywhere else, the client(s) would be required to have a >> certificate. > >My gut reaction: that doesn't sound like a good idea. Yep, I thought that the stuff in the certificate was encrypted in a way that the client couldn't see it. I now see that isn't the case. >Trusting the local network to be secure is pretty risky, in general. Well, for my personal case, the subnet has a few machines plugged into it around my desk and wifi isn't enabled on the modem/NAT gateway, so I'm fairly confident the local machines are ok. To be honest, I don't need encryption on the wire, but since the phone company uses Huawei technology, I could see some wanting the data encrypted on the wire, if the data were sensitive. This case is meant to be easy to do, since the clients don't have to have certificates. I am trying to provide whatever people might need/want when I implement this. The rest is obviously up to them. >> A typical client mounting from outside of the subnet might be my laptop, >> which is using wifi and has no fixed IP/DNS name. >> --> How do you create a certificate that the laptop can use, which the NFS >>server can trust enough to allow the mount? > >You can give your laptop a certificate for an arbitrary name, provided that >the NFS server knows to "validate" that name in an appropriate fashion. (I >don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.) As you note below, creating a site local CA is probably appropriate and the server should be able to check that the certificates were signed by this. (I haven't quite figured out how to do this yet. I think I've created the CA and used to sign a client certificate, but haven't yet gotten the server daemon to verify it. (Playing with SSL_set_verify_locations() to try to get it to work.;-) >> My thinking is that a "secret" value can be put in the certificate that the >> NFS >> server can check for. >> The simplest way would be a fairly long list of random characters in the >> organizationName and/or organizationUnitName field(s) of the subject name. >> Alternately, it could be a newly defined extension for X509v3, I think? > >It would be better to just make a site-local CA and trust everything it >issues (which, admittedly, is not the greatest option itself.) I had thought this would be too much work, but it seems fairly straightforward, so this is what I am now working on. >> Now, I'm not sure, but I don't think this certificate can be created via >> a trust authority such that it would "verify". However, the server can >> look for the "secret" in the certificate and allow the mount based on that. >> >> Does this sound reasonable? > >I'm not sure what goal you're trying to achieve by this "security through >obscurity". Yes. I now see it is the CA stuff that can stay secret. >> Also, even if the NFS client/server have fixed IP addresses with well known >> DNS names, it isn't obvious to me how signed certificates can be acquired >> for them? >> (Lets Encrypt expects the Acme protocol to work and that seems to be >> web site/http specific?) > >RFC 8738 specifies the ACME protocol for validating IP addresses. I had looked at an older RFC, where it seemed to be web site specific. Since none of my stuff has fixed well known DNS names, I'm not going to worry about using an established CA for now. Thanks to everyone for their comments. I may respond to some of the other posts, but I'm figuring things out for now. rick -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Hiroki Sato wrote on 2020/03/04 05:35: [...] I do not think it is a good idea to use a certificate with an embedded secret for authentication and/or authorization. In the case that the client offers a certificate upon establishing a TLS connection for authentication purpose, the authenticity will be checked on the server usually by using the CA certificate which was used to issue the client certificate. The CA cert must be put to somewhere the NFS server can read. The CA cert is secret. So if the NFS server can check the client certificate by the CA certificate, it means the NFS server can trust the client. I think no additional information is required. NFS (or any other server) should check list of revoked certificates too. Otherwise you will not be able to deny access to user which you no longer want to have an access. Authorization such as which mount point can be mounted by using the client cert can be implemented by using the CN field or other X.509 attributes, of course. It can be just a clear text. I think this is one of the most reliable and straightforward ways because in most cases both NFS servers and the clients are under the sysadmin's control. rm> Now, I'm not sure, but I don't think this certificate can be created via rm> a trust authority such that it would "verify". However, the server can rm> look for the "secret" in the certificate and allow the mount based on that. In the way described above, to use TLS client authentication, the NFS server admin has to have a certificate which allows to sign another certificate. This means that the admin must be a CA or trusted authority. In practice, one can generate a self-signed certificate by using openssl(1) and use it as its CA certificate. He can issue certificates signed by it for the NFS clients, and put his CA certificate to somewhere the NFS server can read. Take a look on easy-rsa https://www.freshports.org/security/easy-rsa/ It is used for example by OpenVPN to create private CA and sign certificates of clients. It is good starting point to understand what and how can work. rm> Also, even if the NFS client/server have fixed IP addresses with well known rm> DNS names, it isn't obvious to me how signed certificates can be acquired rm> for them? rm> (Lets Encrypt expects the Acme protocol to work and that seems to be rm> web site/http specific?) TLS certificates do not always have (or do not need to have) a domain name as an attribute. Data in attributes are restricted depending on the purpose, so certificates issued by Let's Encrypt can have only domain names (CN or Subject Alternative Name), for example. An example which is not supported by Let's Encrypt is a certificate for S/MIME email encryption which has an email address. Kind regards Miroslav Lachman ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
On Wed, 04 Mar 2020 13:35:15 +0900 (JST) Hiroki Sato h...@freebsd.org said Rick Macklem wrote in : rm> Hi, rm> rm> I am slowly trying to understand TLS certificates and am trying to figure rm> out how to do the following: rm> -> For an /etc/exports file with... rm> /home -tls -network 192.168.1.0 -mask 255.255.255.0 rm> /home -tlscert rm> rm> This syntax isn't implemented yet, but the thinking is that clients on the rm> 192.168.1 subnet would use TLS, but would not require a certificate. rm> For access from anywhere else, the client(s) would be required to have a rm> certificate. rm> rm> A typical client mounting from outside of the subnet might be my laptop, rm> which is using wifi and has no fixed IP/DNS name. rm> --> How do you create a certificate that the laptop can use, which the NFS rm> server can trust enough to allow the mount? rm> My thinking is that a "secret" value can be put in the certificate that the NFS rm> server can check for. I do not think it is a good idea to use a certificate with an embedded secret for authentication and/or authorization. In the case that the client offers a certificate upon establishing a TLS connection for authentication purpose, the authenticity will be checked on the server usually by using the CA certificate which was used to issue the client certificate. The CA cert must be put to somewhere the NFS server can read. The CA cert is secret. So if the NFS server can check the client certificate by the CA certificate, it means the NFS server can trust the client. I think no additional information is required. Authorization such as which mount point can be mounted by using the client cert can be implemented by using the CN field or other X.509 attributes, of course. It can be just a clear text. I think this is one of the most reliable and straightforward ways because in most cases both NFS servers and the clients are under the sysadmin's control. rm> Now, I'm not sure, but I don't think this certificate can be created via rm> a trust authority such that it would "verify". However, the server can rm> look for the "secret" in the certificate and allow the mount based on that. In the way described above, to use TLS client authentication, the NFS server admin has to have a certificate which allows to sign another certificate. This means that the admin must be a CA or trusted authority. In practice, one can generate a self-signed certificate by using openssl(1) and use it as its CA certificate. He can issue certificates signed by it for the NFS clients, and put his CA certificate to somewhere the NFS server can read. rm> Also, even if the NFS client/server have fixed IP addresses with well known rm> DNS names, it isn't obvious to me how signed certificates can be acquired rm> for them? rm> (Lets Encrypt expects the Acme protocol to work and that seems to be rm> web site/http specific?) TLS certificates do not always have (or do not need to have) a domain name as an attribute. Data in attributes are restricted depending on the purpose, so certificates issued by Let's Encrypt can have only domain names (CN or Subject Alternative Name), for example. An example which is not supported by Let's Encrypt is a certificate for S/MIME email encryption which has an email address. FWIW here's an example from the headers coming from this list. Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 1B07B7E9A8; Wed, 4 Mar 2020 04:37:12 + (UTC) (envelope-from owner-freebsd-curr...@freebsd.org) Not sure if it would help with your intent here. But there it is. :) --Chris -- Hiroki ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
Rick Macklem wrote in : rm> Hi, rm> rm> I am slowly trying to understand TLS certificates and am trying to figure rm> out how to do the following: rm> -> For an /etc/exports file with... rm> /home -tls -network 192.168.1.0 -mask 255.255.255.0 rm> /home -tlscert rm> rm> This syntax isn't implemented yet, but the thinking is that clients on the rm> 192.168.1 subnet would use TLS, but would not require a certificate. rm> For access from anywhere else, the client(s) would be required to have a rm> certificate. rm> rm> A typical client mounting from outside of the subnet might be my laptop, rm> which is using wifi and has no fixed IP/DNS name. rm> --> How do you create a certificate that the laptop can use, which the NFS rm>server can trust enough to allow the mount? rm> My thinking is that a "secret" value can be put in the certificate that the NFS rm> server can check for. I do not think it is a good idea to use a certificate with an embedded secret for authentication and/or authorization. In the case that the client offers a certificate upon establishing a TLS connection for authentication purpose, the authenticity will be checked on the server usually by using the CA certificate which was used to issue the client certificate. The CA cert must be put to somewhere the NFS server can read. The CA cert is secret. So if the NFS server can check the client certificate by the CA certificate, it means the NFS server can trust the client. I think no additional information is required. Authorization such as which mount point can be mounted by using the client cert can be implemented by using the CN field or other X.509 attributes, of course. It can be just a clear text. I think this is one of the most reliable and straightforward ways because in most cases both NFS servers and the clients are under the sysadmin's control. rm> Now, I'm not sure, but I don't think this certificate can be created via rm> a trust authority such that it would "verify". However, the server can rm> look for the "secret" in the certificate and allow the mount based on that. In the way described above, to use TLS client authentication, the NFS server admin has to have a certificate which allows to sign another certificate. This means that the admin must be a CA or trusted authority. In practice, one can generate a self-signed certificate by using openssl(1) and use it as its CA certificate. He can issue certificates signed by it for the NFS clients, and put his CA certificate to somewhere the NFS server can read. rm> Also, even if the NFS client/server have fixed IP addresses with well known rm> DNS names, it isn't obvious to me how signed certificates can be acquired rm> for them? rm> (Lets Encrypt expects the Acme protocol to work and that seems to be rm> web site/http specific?) TLS certificates do not always have (or do not need to have) a domain name as an attribute. Data in attributes are restricted depending on the purpose, so certificates issued by Let's Encrypt can have only domain names (CN or Subject Alternative Name), for example. An example which is not supported by Let's Encrypt is a certificate for S/MIME email encryption which has an email address. -- Hiroki pgp4efev_ZHYw.pgp Description: PGP signature
Re: TLS certificates for NFS-over-TLS floating client
On Wed, 4 Mar 2020 03:15:48 + Rick Macklem rmack...@uoguelph.ca said Hi, I am slowly trying to understand TLS certificates and am trying to figure out how to do the following: -> For an /etc/exports file with... /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert This syntax isn't implemented yet, but the thinking is that clients on the 192.168.1 subnet would use TLS, but would not require a certificate. For access from anywhere else, the client(s) would be required to have a certificate. A typical client mounting from outside of the subnet might be my laptop, which is using wifi and has no fixed IP/DNS name. --> How do you create a certificate that the laptop can use, which the NFS server can trust enough to allow the mount? My thinking is that a "secret" value can be put in the certificate that the NFS server can check for. The simplest way would be a fairly long list of random characters in the organizationName and/or organizationUnitName field(s) of the subject name. Alternately, it could be a newly defined extension for X509v3, I think? Now, I'm not sure, but I don't think this certificate can be created via a trust authority such that it would "verify". However, the server can look for the "secret" in the certificate and allow the mount based on that. Does this sound reasonable? Also, even if the NFS client/server have fixed IP addresses with well known DNS names, it isn't obvious to me how signed certificates can be acquired for them? (Lets Encrypt expects the Acme protocol to work and that seems to be web site/http specific?) I can only speak to the LetsEncrypt part of your question(s); There are additional verification methods available beyond www/httpd(s). But I found in the case of (e)mail; that the cert(s) issued by LetsEncrypt also work well for all my MXs. Hope this is helpful! Thanks for any help with this, rick --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: TLS certificates for NFS-over-TLS floating client
On Wed, Mar 04, 2020 at 03:15:48AM +, Rick Macklem wrote: > Hi, > > I am slowly trying to understand TLS certificates and am trying to figure > out how to do the following: > -> For an /etc/exports file with... > /home -tls -network 192.168.1.0 -mask 255.255.255.0 > /home -tlscert > > This syntax isn't implemented yet, but the thinking is that clients on the > 192.168.1 subnet would use TLS, but would not require a certificate. > For access from anywhere else, the client(s) would be required to have a > certificate. My gut reaction: that doesn't sound like a good idea. Trusting the local network to be secure is pretty risky, in general. > A typical client mounting from outside of the subnet might be my laptop, > which is using wifi and has no fixed IP/DNS name. > --> How do you create a certificate that the laptop can use, which the NFS >server can trust enough to allow the mount? You can give your laptop a certificate for an arbitrary name, provided that the NFS server knows to "validate" that name in an appropriate fashion. (I don't remember what draft-ietf-nfsv4-rpc-tls says about this validation.) > My thinking is that a "secret" value can be put in the certificate that the > NFS > server can check for. > The simplest way would be a fairly long list of random characters in the > organizationName and/or organizationUnitName field(s) of the subject name. > Alternately, it could be a newly defined extension for X509v3, I think? It would be better to just make a site-local CA and trust everything it issues (which, admittedly, is not the greatest option itself.) > Now, I'm not sure, but I don't think this certificate can be created via > a trust authority such that it would "verify". However, the server can > look for the "secret" in the certificate and allow the mount based on that. > > Does this sound reasonable? I'm not sure what goal you're trying to achieve by this "security through obscurity". > Also, even if the NFS client/server have fixed IP addresses with well known > DNS names, it isn't obvious to me how signed certificates can be acquired > for them? > (Lets Encrypt expects the Acme protocol to work and that seems to be > web site/http specific?) RFC 8738 specifies the ACME protocol for validating IP addresses. -Ben ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
TLS certificates for NFS-over-TLS floating client
Hi, I am slowly trying to understand TLS certificates and am trying to figure out how to do the following: -> For an /etc/exports file with... /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home -tlscert This syntax isn't implemented yet, but the thinking is that clients on the 192.168.1 subnet would use TLS, but would not require a certificate. For access from anywhere else, the client(s) would be required to have a certificate. A typical client mounting from outside of the subnet might be my laptop, which is using wifi and has no fixed IP/DNS name. --> How do you create a certificate that the laptop can use, which the NFS server can trust enough to allow the mount? My thinking is that a "secret" value can be put in the certificate that the NFS server can check for. The simplest way would be a fairly long list of random characters in the organizationName and/or organizationUnitName field(s) of the subject name. Alternately, it could be a newly defined extension for X509v3, I think? Now, I'm not sure, but I don't think this certificate can be created via a trust authority such that it would "verify". However, the server can look for the "secret" in the certificate and allow the mount based on that. Does this sound reasonable? Also, even if the NFS client/server have fixed IP addresses with well known DNS names, it isn't obvious to me how signed certificates can be acquired for them? (Lets Encrypt expects the Acme protocol to work and that seems to be web site/http specific?) Thanks for any help with this, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
