Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade

2014-07-07 Thread Simo Sorce
On Mon, 2014-07-07 at 16:10 +0200, Petr Spacek wrote:
> On 30.6.2014 17:38, Simo Sorce wrote:
> > On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote:
> >> On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote:
> >>> On 23.6.2014 17:49, Martin Basti wrote:
>  On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote:
> > Hello,
> > I have following issues:
> >
> > #1 Upgrading existing replicas to support DNSSEC won't work for current
> > design (replica-file as storage for temporal replica key).
> > Temporal private key needs to be copied to replica, and no encrypted
> > master-key for replica is prepared in LDAP, because user doesn't need to
> > run ipa-replica-prepare.
> >
> > After discussion with Petr2, the solution is:
> > a) Each replica (except first - which generates master-key) generates
> > replica public and private keys.
> > b) Replica uploads public key to LDAP
> > c) Replica with generated master key, use the public key (b) to encrypt
> > master-key and store it to LDAP. Replica with master-key must detect, if
> > there is any new public replica key.
> > d) Replica (b) is now able to get master-key using own private replica
> > key
> >
> >
> > #2 We need to choose only one replica which will generate, (rotate, ...)
> > DNSSEC keys.
>  and generate master key too
> 
> > My proposal is to test during installation/upgrade if any dnssec/master
> > keys are in LDAP. If no key was found, the first server is
> > installed/upgraded and DNSSEC key generator is required.
> >
> > But there is issue with parallel upgrade multiple replicas (or if
> > replication temporarily doesn't work). There is no guarantee if replicas
> > will be able to detect if any replica became DNSSEC key generator.
> >>>
> >>> Let me add that we are going to use syncrepl anyway so the overall latency
> >>> should be minimal (if replication works).
> >>>
> >>
> >> Simo what do you think about it, could you tell us your opinion?
> >
> > I think DNSSEC should not be enabled by default, so on upgrade no action
> > should be taken. Activation/upgrade of DNSSEC feature should be manual
> > so that no conflict can arise.
> 
> I think we can do a compromise.
> 
> First of all, DNSSEC will not be enabled until admin explicitly decides to do 
> so. It is per-zone setting exposed in API/CLI/Web UI. Clients will not see 
> any 
> change if the "DNSSEC checkbox" is not enabled for at least one DNS zone.
> 
> IMHO it is reasonable to automatically install dependencies we need during 
> upgrade. I.e. to install softhsm package to every replica by default and also 
> generate replica keys (wrapping keys) by default.
> 
> I agree that key-master-server election (used in IPA 4.1) can be done 
> manually. I.e. all replica keys will be generated automatically but admin has 
> to run something like ipa-dns-install --dnssec-master on one replica to 
> explicitly mark one replica as key generator. This replica will run 
> OpenDNSSEC 
> daemon responsible for key maintenance.
> 
> This approach will save us terrible headache from manual dependency 
> installation and situations where DNSSEC-feature-dependencies were installed 
> on some replicas but are not present on all of them etc.
> 
> Do you agree?

Sounds reasonable.

Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade

2014-07-07 Thread Petr Spacek

On 30.6.2014 17:38, Simo Sorce wrote:

On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote:

On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote:

On 23.6.2014 17:49, Martin Basti wrote:

On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote:

Hello,
I have following issues:

#1 Upgrading existing replicas to support DNSSEC won't work for current
design (replica-file as storage for temporal replica key).
Temporal private key needs to be copied to replica, and no encrypted
master-key for replica is prepared in LDAP, because user doesn't need to
run ipa-replica-prepare.

After discussion with Petr2, the solution is:
a) Each replica (except first - which generates master-key) generates
replica public and private keys.
b) Replica uploads public key to LDAP
c) Replica with generated master key, use the public key (b) to encrypt
master-key and store it to LDAP. Replica with master-key must detect, if
there is any new public replica key.
d) Replica (b) is now able to get master-key using own private replica
key


#2 We need to choose only one replica which will generate, (rotate, ...)
DNSSEC keys.

and generate master key too


My proposal is to test during installation/upgrade if any dnssec/master
keys are in LDAP. If no key was found, the first server is
installed/upgraded and DNSSEC key generator is required.

But there is issue with parallel upgrade multiple replicas (or if
replication temporarily doesn't work). There is no guarantee if replicas
will be able to detect if any replica became DNSSEC key generator.


Let me add that we are going to use syncrepl anyway so the overall latency
should be minimal (if replication works).



Simo what do you think about it, could you tell us your opinion?


I think DNSSEC should not be enabled by default, so on upgrade no action
should be taken. Activation/upgrade of DNSSEC feature should be manual
so that no conflict can arise.


I think we can do a compromise.

First of all, DNSSEC will not be enabled until admin explicitly decides to do 
so. It is per-zone setting exposed in API/CLI/Web UI. Clients will not see any 
change if the "DNSSEC checkbox" is not enabled for at least one DNS zone.


IMHO it is reasonable to automatically install dependencies we need during 
upgrade. I.e. to install softhsm package to every replica by default and also 
generate replica keys (wrapping keys) by default.


I agree that key-master-server election (used in IPA 4.1) can be done 
manually. I.e. all replica keys will be generated automatically but admin has 
to run something like ipa-dns-install --dnssec-master on one replica to 
explicitly mark one replica as key generator. This replica will run OpenDNSSEC 
daemon responsible for key maintenance.


This approach will save us terrible headache from manual dependency 
installation and situations where DNSSEC-feature-dependencies were installed 
on some replicas but are not present on all of them etc.


Do you agree?

--
Petr^2 Spacek

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade

2014-06-30 Thread Simo Sorce
On Mon, 2014-06-30 at 17:13 +0200, Martin Basti wrote:
> On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote:
> > On 23.6.2014 17:49, Martin Basti wrote:
> > > On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote:
> > >> Hello,
> > >> I have following issues:
> > >>
> > >> #1 Upgrading existing replicas to support DNSSEC won't work for current
> > >> design (replica-file as storage for temporal replica key).
> > >> Temporal private key needs to be copied to replica, and no encrypted
> > >> master-key for replica is prepared in LDAP, because user doesn't need to
> > >> run ipa-replica-prepare.
> > >>
> > >> After discussion with Petr2, the solution is:
> > >> a) Each replica (except first - which generates master-key) generates
> > >> replica public and private keys.
> > >> b) Replica uploads public key to LDAP
> > >> c) Replica with generated master key, use the public key (b) to encrypt
> > >> master-key and store it to LDAP. Replica with master-key must detect, if
> > >> there is any new public replica key.
> > >> d) Replica (b) is now able to get master-key using own private replica
> > >> key
> > >>
> > >>
> > >> #2 We need to choose only one replica which will generate, (rotate, ...)
> > >> DNSSEC keys.
> > > and generate master key too
> > >
> > >> My proposal is to test during installation/upgrade if any dnssec/master
> > >> keys are in LDAP. If no key was found, the first server is
> > >> installed/upgraded and DNSSEC key generator is required.
> > >>
> > >> But there is issue with parallel upgrade multiple replicas (or if
> > >> replication temporarily doesn't work). There is no guarantee if replicas
> > >> will be able to detect if any replica became DNSSEC key generator.
> > 
> > Let me add that we are going to use syncrepl anyway so the overall latency 
> > should be minimal (if replication works).
> > 
> 
> Simo what do you think about it, could you tell us your opinion?

I think DNSSEC should not be enabled by default, so on upgrade no action
should be taken. Activation/upgrade of DNSSEC feature should be manual
so that no conflict can arise.

Simo.



___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade

2014-06-30 Thread Martin Basti
On Tue, 2014-06-24 at 11:49 +0200, Petr Spacek wrote:
> On 23.6.2014 17:49, Martin Basti wrote:
> > On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote:
> >> Hello,
> >> I have following issues:
> >>
> >> #1 Upgrading existing replicas to support DNSSEC won't work for current
> >> design (replica-file as storage for temporal replica key).
> >> Temporal private key needs to be copied to replica, and no encrypted
> >> master-key for replica is prepared in LDAP, because user doesn't need to
> >> run ipa-replica-prepare.
> >>
> >> After discussion with Petr2, the solution is:
> >> a) Each replica (except first - which generates master-key) generates
> >> replica public and private keys.
> >> b) Replica uploads public key to LDAP
> >> c) Replica with generated master key, use the public key (b) to encrypt
> >> master-key and store it to LDAP. Replica with master-key must detect, if
> >> there is any new public replica key.
> >> d) Replica (b) is now able to get master-key using own private replica
> >> key
> >>
> >>
> >> #2 We need to choose only one replica which will generate, (rotate, ...)
> >> DNSSEC keys.
> > and generate master key too
> >
> >> My proposal is to test during installation/upgrade if any dnssec/master
> >> keys are in LDAP. If no key was found, the first server is
> >> installed/upgraded and DNSSEC key generator is required.
> >>
> >> But there is issue with parallel upgrade multiple replicas (or if
> >> replication temporarily doesn't work). There is no guarantee if replicas
> >> will be able to detect if any replica became DNSSEC key generator.
> 
> Let me add that we are going to use syncrepl anyway so the overall latency 
> should be minimal (if replication works).
> 

Simo what do you think about it, could you tell us your opinion?

-- 
Martin^2 Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade

2014-06-24 Thread Petr Spacek

On 23.6.2014 17:49, Martin Basti wrote:

On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote:

Hello,
I have following issues:

#1 Upgrading existing replicas to support DNSSEC won't work for current
design (replica-file as storage for temporal replica key).
Temporal private key needs to be copied to replica, and no encrypted
master-key for replica is prepared in LDAP, because user doesn't need to
run ipa-replica-prepare.

After discussion with Petr2, the solution is:
a) Each replica (except first - which generates master-key) generates
replica public and private keys.
b) Replica uploads public key to LDAP
c) Replica with generated master key, use the public key (b) to encrypt
master-key and store it to LDAP. Replica with master-key must detect, if
there is any new public replica key.
d) Replica (b) is now able to get master-key using own private replica
key


#2 We need to choose only one replica which will generate, (rotate, ...)
DNSSEC keys.

and generate master key too


My proposal is to test during installation/upgrade if any dnssec/master
keys are in LDAP. If no key was found, the first server is
installed/upgraded and DNSSEC key generator is required.

But there is issue with parallel upgrade multiple replicas (or if
replication temporarily doesn't work). There is no guarantee if replicas
will be able to detect if any replica became DNSSEC key generator.


Let me add that we are going to use syncrepl anyway so the overall latency 
should be minimal (if replication works).


--
Petr^2 Spacek

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


Re: [Freeipa-devel] DNSSEC: IPA Installation/Upgrade

2014-06-23 Thread Martin Basti
On Mon, 2014-06-23 at 17:44 +0200, Martin Basti wrote:
> Hello,
> I have following issues:
> 
> #1 Upgrading existing replicas to support DNSSEC won't work for current
> design (replica-file as storage for temporal replica key).
> Temporal private key needs to be copied to replica, and no encrypted
> master-key for replica is prepared in LDAP, because user doesn't need to
> run ipa-replica-prepare.
> 
> After discussion with Petr2, the solution is:
> a) Each replica (except first - which generates master-key) generates
> replica public and private keys.
> b) Replica uploads public key to LDAP
> c) Replica with generated master key, use the public key (b) to encrypt
> master-key and store it to LDAP. Replica with master-key must detect, if
> there is any new public replica key.
> d) Replica (b) is now able to get master-key using own private replica
> key
> 
> 
> #2 We need to choose only one replica which will generate, (rotate, ...)
> DNSSEC keys.
and generate master key too

> My proposal is to test during installation/upgrade if any dnssec/master
> keys are in LDAP. If no key was found, the first server is
> installed/upgraded and DNSSEC key generator is required.
> 
> But there is issue with parallel upgrade multiple replicas (or if
> replication temporarily doesn't work). There is no guarantee if replicas
> will be able to detect if any replica became DNSSEC key generator.
> 
> 
> Please write me your opinions.
> 


-- 
Martin^2 Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel


[Freeipa-devel] DNSSEC: IPA Installation/Upgrade

2014-06-23 Thread Martin Basti
Hello,
I have following issues:

#1 Upgrading existing replicas to support DNSSEC won't work for current
design (replica-file as storage for temporal replica key).
Temporal private key needs to be copied to replica, and no encrypted
master-key for replica is prepared in LDAP, because user doesn't need to
run ipa-replica-prepare.

After discussion with Petr2, the solution is:
a) Each replica (except first - which generates master-key) generates
replica public and private keys.
b) Replica uploads public key to LDAP
c) Replica with generated master key, use the public key (b) to encrypt
master-key and store it to LDAP. Replica with master-key must detect, if
there is any new public replica key.
d) Replica (b) is now able to get master-key using own private replica
key


#2 We need to choose only one replica which will generate, (rotate, ...)
DNSSEC keys.

My proposal is to test during installation/upgrade if any dnssec/master
keys are in LDAP. If no key was found, the first server is
installed/upgraded and DNSSEC key generator is required.

But there is issue with parallel upgrade multiple replicas (or if
replication temporarily doesn't work). There is no guarantee if replicas
will be able to detect if any replica became DNSSEC key generator.


Please write me your opinions.

-- 
Martin^2 Basti

___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel