Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On Thu, 2009-11-05 at 11:53 -0800, Andrew Wnuk wrote: > >> CSR is parsed and validated by CA. > >> > > How does the CA know "Who" asked for a specific cert ? > > > > Simo. > > > > > CA authenticates IPA and validates CSR, IPA authenticates and > authorizes. Yes I know, this is the problem. IPA is almost blind about what's in the CSR (which comes straight from the client), and the RA trust IPA to make "correct" requests. So we need to verify within the IPA server that a client is not trying to sneak stuff in fields like subjectAltName and any other field a client may rely on for authentication/authorization purposes. Rob just opened a bug about that. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On 11/05/09 11:34, Simo Sorce wrote: On Thu, 2009-11-05 at 11:28 -0800, Andrew Wnuk wrote: On 11/05/09 11:22, Simo Sorce wrote: On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote: This is about right. What you're missing is storing the certificate in the service record. To do this we need to know what the target is. Nalin and I simply took two different approaches to sending this. We can easily support either method by making the principal an optional attribute and looking for it in the CSR if not provided (assuming I can get my head around PKCS#10 enough to grab attributes). Given we should prevent "tricks" from people the server side should really parse the CSR and validate it against the ACL IMO. Otherwise do we have any other part that checks that host foo.example.com is asking a certificate for itself and not for bar.example.com ? Simo. CSR is parsed and validated by CA. How does the CA know "Who" asked for a specific cert ? Simo. CA authenticates IPA and validates CSR, IPA authenticates and authorizes. Andrew. ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
Simo Sorce wrote: > On Thu, 2009-11-05 at 11:28 -0800, Andrew Wnuk wrote: > >> On 11/05/09 11:22, Simo Sorce wrote: >> >>> On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote: >>> >>> This is about right. What you're missing is storing the certificate in the service record. To do this we need to know what the target is. Nalin and I simply took two different approaches to sending this. We can easily support either method by making the principal an optional attribute and looking for it in the CSR if not provided (assuming I can get my head around PKCS#10 enough to grab attributes). >>> Given we should prevent "tricks" from people the server side should >>> really parse the CSR and validate it against the ACL IMO. >>> Otherwise do we have any other part that checks that host >>> foo.example.com is asking a certificate for itself and not for >>> bar.example.com ? >>> >>> Simo. >>> >>> >>> >> CSR is parsed and validated by CA. >> > > How does the CA know "Who" asked for a specific cert ? > > Simo. > > The server should look at the identity of the peer who authenticated when the connection was established. It can be admin using his password or a host using his keytab or OTP. I think Rob figured out how to factor this into the aci validation and the code to do it already there. Rob? -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On Thu, 2009-11-05 at 11:28 -0800, Andrew Wnuk wrote: > On 11/05/09 11:22, Simo Sorce wrote: > > On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote: > > > >> This is about right. What you're missing is storing the certificate > >> in > >> the service record. To do this we need to know what the target is. > >> > >> Nalin and I simply took two different approaches to sending this. We > >> can > >> easily support either method by making the principal an optional > >> attribute and looking for it in the CSR if not provided (assuming I > >> can > >> get my head around PKCS#10 enough to grab attributes). > >> > > Given we should prevent "tricks" from people the server side should > > really parse the CSR and validate it against the ACL IMO. > > Otherwise do we have any other part that checks that host > > foo.example.com is asking a certificate for itself and not for > > bar.example.com ? > > > > Simo. > > > > > CSR is parsed and validated by CA. How does the CA know "Who" asked for a specific cert ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
Simo Sorce wrote: > On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote: > >> This is about right. What you're missing is storing the certificate >> in >> the service record. To do this we need to know what the target is. >> >> Nalin and I simply took two different approaches to sending this. We >> can >> easily support either method by making the principal an optional >> attribute and looking for it in the CSR if not provided (assuming I >> can >> get my head around PKCS#10 enough to grab attributes). >> > > Given we should prevent "tricks" from people the server side should > really parse the CSR and validate it against the ACL IMO. > Otherwise do we have any other part that checks that host > foo.example.com is asking a certificate for itself and not for > bar.example.com ? > > Simo. > > This is a valid use case and if the ACIs on the server are not configured to allow host "foo" to get certs for host "bar", host "foo" will be denied regardless of the way it asked via CSR or not. -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On 11/05/09 11:22, Simo Sorce wrote: On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote: This is about right. What you're missing is storing the certificate in the service record. To do this we need to know what the target is. Nalin and I simply took two different approaches to sending this. We can easily support either method by making the principal an optional attribute and looking for it in the CSR if not provided (assuming I can get my head around PKCS#10 enough to grab attributes). Given we should prevent "tricks" from people the server side should really parse the CSR and validate it against the ACL IMO. Otherwise do we have any other part that checks that host foo.example.com is asking a certificate for itself and not for bar.example.com ? Simo. CSR is parsed and validated by CA. Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On Thu, 2009-11-05 at 13:21 -0500, Rob Crittenden wrote: > > This is about right. What you're missing is storing the certificate > in > the service record. To do this we need to know what the target is. > > Nalin and I simply took two different approaches to sending this. We > can > easily support either method by making the principal an optional > attribute and looking for it in the CSR if not provided (assuming I > can > get my head around PKCS#10 enough to grab attributes). Given we should prevent "tricks" from people the server side should really parse the CSR and validate it against the ACL IMO. Otherwise do we have any other part that checks that host foo.example.com is asking a certificate for itself and not for bar.example.com ? Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
Andrew Wnuk wrote: > On 11/04/09 16:16, Nalin Dahyabhai wrote: >> On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote: >> >>> Alternatively you can specify which host(s) can request a >>> certificate for a given service. Use the service-add-member command >>> to add hosts that can request certs for it. >>> >> That sounds reasonable. Is this new post-1.9.0? I can add members to >> various groups, but there's no service-add-member command yet. >> >> >>> A couple of tidbits: >>> >>> - In 1.9.0 we'll issue a certificate for any subject requested. >>> dogtag has a fix that we will be able to use once it's released that >>> will let us pull the CN from the request and use just that with the >>> subject and use a fixed value for the rest. >>> >> That sounds good -- the default request subject is just 'CN=hostname' >> unless it's told different. >> >> >>> - The management framework doesn't do anything to the CSR right now, >>> it literally just passes it onto the CA for processing. >>> - The whole ugly client IP thing has been ripped out post 1.9.0. >>> - I still compare the hostname in the subject with the hostname of >>> the service. This is unfortunately currently broken in python >>> 2.4-based systems. >>> >> If we're requiring that every certificate has an associated principal >> name, then ensuring it agrees with the hostname in the subject field >> makes a lot of sense. I'd kind of like to see both a dnsName and a >> Kerberos principal name added to the subjectAltName fields in the issued >> certificate, but that's as much because we can as anything else. >> >> >>> - I'm not opposed to including more "stuff" into the CSR itself we >>> just need to be sure the average admin who doesn't want to use >>> certmonger can still make a request too. >>> >> NSS's certutil can trivially add dns and email subjectAltName (SAN) >> values and extendedKeyUsage (EKU) values. I don't see a flag for adding >> a Kerberos principal name. OpenSSL's req command doesn't do most of >> that by default, but the configuration file can be used to tell it to do >> any of that. It could be scripted, for sure. >> >> >>> Right now the bar is pretty >>> low to understanding what is required IMHO with the exception of >>> pasting in the ugly one-line CSR :-( >>> >> Yeah, it took me a while to figure out that that was how we were >> supposed to pass it in. >> > Passing entire CSR as a parameter to ipa command could avoided if > XML-RPC framework would provide pre and post processing callbacks on > the client side. Parameters could be used to describe CSR (instead of > passing entire CSR), pre-processing callback could generate CSR based > on provided description, then XML-RPC call could submit generated CSR > and finally post-processing callback could properly place obtained > certificate. > I though we talked about these callbacks a year ago and planned to do them. Was this work ever finished? > Regards, > Andrew > > ___ > Freeipa-devel mailing list > Freeipa-devel@redhat.com > https://www.redhat.com/mailman/listinfo/freeipa-devel -- Thank you, Dmitri Pal Engineering Manager IPA project, Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Re: Certificate enrollment, principal names
On 11/04/09 16:16, Nalin Dahyabhai wrote: On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote: Alternatively you can specify which host(s) can request a certificate for a given service. Use the service-add-member command to add hosts that can request certs for it. That sounds reasonable. Is this new post-1.9.0? I can add members to various groups, but there's no service-add-member command yet. A couple of tidbits: - In 1.9.0 we'll issue a certificate for any subject requested. dogtag has a fix that we will be able to use once it's released that will let us pull the CN from the request and use just that with the subject and use a fixed value for the rest. That sounds good -- the default request subject is just 'CN=hostname' unless it's told different. - The management framework doesn't do anything to the CSR right now, it literally just passes it onto the CA for processing. - The whole ugly client IP thing has been ripped out post 1.9.0. - I still compare the hostname in the subject with the hostname of the service. This is unfortunately currently broken in python 2.4-based systems. If we're requiring that every certificate has an associated principal name, then ensuring it agrees with the hostname in the subject field makes a lot of sense. I'd kind of like to see both a dnsName and a Kerberos principal name added to the subjectAltName fields in the issued certificate, but that's as much because we can as anything else. - I'm not opposed to including more "stuff" into the CSR itself we just need to be sure the average admin who doesn't want to use certmonger can still make a request too. NSS's certutil can trivially add dns and email subjectAltName (SAN) values and extendedKeyUsage (EKU) values. I don't see a flag for adding a Kerberos principal name. OpenSSL's req command doesn't do most of that by default, but the configuration file can be used to tell it to do any of that. It could be scripted, for sure. Right now the bar is pretty low to understanding what is required IMHO with the exception of pasting in the ugly one-line CSR :-( Yeah, it took me a while to figure out that that was how we were supposed to pass it in. Passing entire CSR as a parameter to ipa command could avoided if XML-RPC framework would provide pre and post processing callbacks on the client side. Parameters could be used to describe CSR (instead of passing entire CSR), pre-processing callback could generate CSR based on provided description, then XML-RPC call could submit generated CSR and finally post-processing callback could properly place obtained certificate. Regards, Andrew ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Re: Certificate enrollment, principal names
On Wed, Nov 04, 2009 at 04:39:40PM -0500, Rob Crittenden wrote: > Alternatively you can specify which host(s) can request a > certificate for a given service. Use the service-add-member command > to add hosts that can request certs for it. That sounds reasonable. Is this new post-1.9.0? I can add members to various groups, but there's no service-add-member command yet. > A couple of tidbits: > > - In 1.9.0 we'll issue a certificate for any subject requested. > dogtag has a fix that we will be able to use once it's released that > will let us pull the CN from the request and use just that with the > subject and use a fixed value for the rest. That sounds good -- the default request subject is just 'CN=hostname' unless it's told different. > - The management framework doesn't do anything to the CSR right now, > it literally just passes it onto the CA for processing. > - The whole ugly client IP thing has been ripped out post 1.9.0. > - I still compare the hostname in the subject with the hostname of > the service. This is unfortunately currently broken in python > 2.4-based systems. If we're requiring that every certificate has an associated principal name, then ensuring it agrees with the hostname in the subject field makes a lot of sense. I'd kind of like to see both a dnsName and a Kerberos principal name added to the subjectAltName fields in the issued certificate, but that's as much because we can as anything else. > - I'm not opposed to including more "stuff" into the CSR itself we > just need to be sure the average admin who doesn't want to use > certmonger can still make a request too. NSS's certutil can trivially add dns and email subjectAltName (SAN) values and extendedKeyUsage (EKU) values. I don't see a flag for adding a Kerberos principal name. OpenSSL's req command doesn't do most of that by default, but the configuration file can be used to tell it to do any of that. It could be scripted, for sure. > Right now the bar is pretty > low to understanding what is required IMHO with the exception of > pasting in the ugly one-line CSR :-( Yeah, it took me a while to figure out that that was how we were supposed to pass it in. Thanks, Nalin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
[Freeipa-devel] Re: Certificate enrollment, principal names
Nalin Dahyabhai wrote: I think I'm getting closer to having certmonger (the provider of the ipa-getcert command) be useful enough to throw certificate enrollment requests at the IPA server, and I've got a couple of questions about how the server decides what it will issue and what it puts in the certificates that it issues. First, how we are we going to be expected to pass, to the server, information about the certificate we'd like it to issue? Until now, I've been storing the principal name in a subjectAltName value in an extensionRequest attribute in the signing request. I can actually put quite a bit of information in extensionRequests. It's not a lot of trouble to also provide that information along with the signing request (as 1.9.0 expects, at least for the Kerberos principal name), but if the server's going to be taking direction from the client on any of these things, it might be more future-proof if it could parse the request and validate its contents directly. This would make adding a requested dnsName subjectAltName possible without breaking any of the existing interfaces -- the client could request it, or not, or more than one value, and the server would pick and choose from everything that the client requested when deciding what to put into a certificate. The other question is about client authorization: have we set down the rules about which client identities are allowed to request what, and what they get? There are 2 options. There is a rolegroup called certadmin. Members of this role are allowed to call cert-request, others will be rejected. Alternatively you can specify which host(s) can request a certificate for a given service. Use the service-add-member command to add hosts that can request certs for it. I ask because I think that we'll have to use the client host's identity (via creds obtained using its keytab) to handle the case where the connection to the CA doesn't become available until long after the admin's logged out, but when I try that now, requests submitted using the host's identity are being denied by the access control mechanisms. Yes, the first access method is really designed for users/administrators. The second if you are binding as a host. Anyone have some insight to share here? A couple of tidbits: - In 1.9.0 we'll issue a certificate for any subject requested. dogtag has a fix that we will be able to use once it's released that will let us pull the CN from the request and use just that with the subject and use a fixed value for the rest. - The management framework doesn't do anything to the CSR right now, it literally just passes it onto the CA for processing. - The whole ugly client IP thing has been ripped out post 1.9.0. - I still compare the hostname in the subject with the hostname of the service. This is unfortunately currently broken in python 2.4-based systems. - I'm not opposed to including more "stuff" into the CSR itself we just need to be sure the average admin who doesn't want to use certmonger can still make a request too. Right now the bar is pretty low to understanding what is required IMHO with the exception of pasting in the ugly one-line CSR :-( rob smime.p7s Description: S/MIME Cryptographic Signature ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
