Re: [Freeipa-devel] [PATCH] 0055 Fix tests which fail after ipa-adtrust-install

2013-08-09 Thread Tomas Babej 

On 08/09/2013 04:03 PM, Ana Krivokapic wrote:

On 08/09/2013 09:39 AM, Tomas Babej wrote:

On 08/08/2013 04:09 PM, Ana Krivokapic wrote:

Hello,

This patch should fix the failing unit tests.

https://fedorahosted.org/freeipa/ticket/3852



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


There are two tests failing on my machine when running the tests 
after ipa-adtrust-install with your patch applied:


You say there are two tests failing but I only see one below.



That was just debris from trying to break your patch too much, one of my 
comments rendered invalid in the end :)




==
FAIL: test_group[24]: group_find: Search for POSIX groups
--
Traceback (most recent call last):
[...]
AssertionError: assert_deepequal: dict keys mismatch.
  test_group[24]: group_find: Search for POSIX groups
  missing keys = []
  extra keys = ['ipantsecurityidentifier']
  expected = {'dn': 
ipapython.dn.DN('cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'), 
'cn': [u'editors'], 'objectclass': Fuzzy(None, None,  at 0x3768c08>), 'gidnumber': [Fuzzy('^\\d+$', 'basestring'>, None)], 'ipauniqueid': 
[Fuzzy('^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$', 
, None)], 'description': [u'Limited admins who can 
edit other users']}
  got = {'dn': 
u'cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com', 
'cn': (u'editors',), 'objectclass': (u'top', u'groupofnames', 
u'posixgroup', u'ipausergroup', u'ipaobject', u'nestedGroup', 
u'ipantgroupattrs'), 'ipantsecurityidentifier': 
(u'S-1-5-21-1457515837-642396627-3509099663-1002',), 'gidnumber': 
(u'180462',), 'ipauniqueid': 
(u'7c6e1672-0039-11e3-9567-001a4a2221fb',), 'description': (u'Limited 
admins who can edit other users',)}

  path = ('result', 1)

I think you need the wrap the dictionary discribing the editor's 
group entry with the add_sid wrapper, and its objectclasses using the 
add_oc wrapper.


[tbabej@vm-139 freeipa]$ git diff
diff --git a/ipatests/test_xmlrpc/test_group_plugin.py 
b/ipatests/test_xmlrpc/test_group_plugin.py

index d380fe5..14c70cd 100644
--- a/ipatests/test_xmlrpc/test_group_plugin.py
+++ b/ipatests/test_xmlrpc/test_group_plugin.py
@@ -447,14 +447,15 @@ class test_group(Declarative):
 objectclasses.posixgroup, 
u'ipantgroupattrs')),

 'ipauniqueid': [fuzzy_uuid],
 }),
-{
+add_sid({
 'dn': get_group_dn('editors'),
 'gidnumber': [fuzzy_digits],
 'cn': [u'editors'],
 'description': [u'Limited admins who can 
edit other users'],
-'objectclass': 
fuzzy_set_ci(objectclasses.posixgroup),

+'objectclass': fuzzy_set_ci(add_oc(
+objectclasses.posixgroup, 
u'ipantgroupattrs')),

 'ipauniqueid': [fuzzy_uuid],
-},
+}),
 dict(
 dn=get_group_dn(group1),
 cn=[group1],


These changes were sufficient for me to have the unit test suite run 
without errors.

--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org


I retested the patch and the tests are passing in my setup. The 
editors group definitely does not have the ipantsecurityidentifier 
attribute nor the ipantgroupattrs objectclass:


[akrivoka@vm-181 freeipa]$ ipa group-show editors --all
  dn: 
cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com

  Group name: editors
  Description: Limited admins who can edit other users
  GID: 197702
  ipauniqueid: 91b3597e-00f3-11e3-92ae-001a4a22217b
  objectclass: top, groupofnames, posixgroup, ipausergroup, ipaobject, 
nestedGroup


What I noticed though, is that if I delete and re-create the editors 
group (after ipa-adtrust-install has been run), it then gets the above 
mentioned attribute and objectclass. Maybe you did some similar 
manipulation in your setup, resulting in the test failing?


I think it does depend on whether you have ran the ipa-sidgen task when 
running the ipa-adtrust-install.


Do you think we can cover both cases here?



--
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.



--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org

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

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

2013-08-09 Thread Petr Spacek 

On 9.8.2013 15:12, Rob Crittenden wrote:

Simo Sorce wrote:

On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:

On 23.7.2013 10:55, Petr Spacek wrote:

On 19.7.2013 19:55, Simo Sorce wrote:

I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.

On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:


The most important question at the moment is "What can we postpone?
How
fragile it can be for shipping it as part of Fedora 20?" Could we
declare
DNSSEC support as "technology preview"/"don't use it for anything
serious"?


Until we figur out proper management in LDAP we will be a bit stuck, esp
if we want to consider usin the 'somthing' that stores keys instead of
toring them stright in LDAP.

So maybe we can start with allowing just one server to do DNSSEC and
source keys from files for now ?


The problem is that DNSSEC deployment *on single domain* is 'all or nothing':
All DNS servers have to support DNSSEC otherwise the validation on client
side
can fail randomly.

Note that *parent* zone indicates that the particular child zone is secured
with DNSSEC by sending DS (delegation signer) record to the client.
Validation
will fail if client receives DS record from the parent but no signatures are
present in data from 'child' zone itself.

This prevents downgrade (DNSSEC => plain DNS) attacks.

As a result, we have only two options: One DNS server with DNSSEC enabled or
arbitrary number DNS servers without DNSSEC, which is very unfortunate.


as soon as we have that workign we should also have clearer plans about
how we manage keys in LDAP (or elsewhere).


Dmitri, Martin and me discussed this proposal in person and the new plan is:
- Elect one super-master which will handle key generation (as we do with
special CA certificates)


I guess we can start this way, but how do you determine which one is
master ?
How do we select the 'super-master' for CA certificates? I would re-use the 
same logic (for now).



I do not really like to have all this 'super roles', it's brittle and
admins will be confused which means one day their whole infrastructure
will be down because the keys are expired and all the clients will
refuse to communicate with anything.


AFAIU keys don't expire, rather there is a rollover process. The problem would
be if the server that controlled the rollover went away the keys would never
roll, leaving you potentially exposed.
In DNSSEC it could be a problem. Each signature contains validity interval and 
validation will fail when it expires. It practically means that DNS will stop 
working if the keys are not rotated in time. (More keys can co-exists, so the 
roll-over process can be started e.g. a month before the current key really 
expires.)



I think it is ok as a first implementation, but I think this *must not*
be the final state. We can and must do better than this.
I definitely agree. IMHO the basic problem is the same or very similar for 
DNSSEC key generation & CA certificates, so we should solve both problems at 
once - one day.


I mean - we need to coordinate key & cert maintenance between multiple masters 
somehow - and this will be the common problem for CA & DNSSEC.



- Store generated DNSSEC keys in LDAP
- Encrypt stored keys with 'DNSSEC master key' shared by all servers


ok.


- Derive 'DNSSEC master key' from 'Kerberos master key' during server
install/upgrade and store it somewhere on the filesystem (as the Kerberos
master key, on each IPA server)


The Kerberos master key is not stored on disk, furthermore it could
change, so if you derive it at install time and install a replica after
Interesting. The master key is stored in the krbMKey attribute in 
cn=REALM,cn=kerberos,dc=your,dc=domain , I didn't know that.



it was changed everything will break. I think we need to store the key
in LDAP, encrypted, and dump it to disk when a new one is generated.

I agree.


Aside, DNSSEC uses pub/private key crypto so this would be a special
'master key' used exclusively to encrypt keys in LDAP ?
That was the original intention - generate a new 'DNSSEC master key'/'DNSSEC 
wrapping key' and let named+certmonger/oddjob to play with it.



- Consider certmonger or oddjob as key generation triggers


I do not understand this comment.
I mean: How hard would it be to extend certmonger/oddjob to take care of 
DNSSEC key maintenance?



He is trying to automate the key rollover. I don't think certmonger will work
as it is designed for X.509 certs. Are you proposing an additional attribute
to schedule the rollover? I thought that it was a good idea to have some
flexibility here to prevent timed DoS attacks for rollover time.
It definitely requires some changes in certmonger, I'm just exploring various 
possibilities.



I think that we should add one new thing - a 'salt' - used for Kerberos master
key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC
master key as necessary wi

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

2013-08-09 Thread Anthony Messina 
On Friday, August 09, 2013 08:49:29 AM Simo Sorce wrote:
> > Dmitri, Martin and me discussed this proposal in person and the new plan
> > is: - Elect one super-master which will handle key generation (as we do
> > with special CA certificates)
> 
> I guess we can start this way, but how do you determine which one is
> master ?
> I do not really like to have all this 'super roles', it's brittle and
> admins will be confused which means one day their whole infrastructure
> will be down because the keys are expired and all the clients will
> refuse to communicate with anything.
> 
> I think it is ok as a first implementation, but I think this *must not*
> be the final state. We can and must do better than this.

I've been "listening in" on the DNSSEC discussion and do not mean to derail 
the course of this thread, however...

>From a sysadmin's perspective, I agree with Simo's comments insofar as they 
relate to "not all masters being created equal".  Administratively, unequal 
masters have the potential to create single points of failure which may be 
difficult to resolve, especially on upgrade between minor versions and between 
replicas.

Small-time sysadmins like myself who may only run one (maybe two) FreeIPA 
instances incur a significant about of trouble when that already limited 
resource isn't working properly after some issue with file ownership or 
SELinux during a yum upgrade.

In addition, I realize FreeIPA wasn't probably designed with small-ish 
installs as the target use case.  But I would argue that since FreeIPA *is* so 
unified in how it handles Kerberos, LDAP, Certifiates, and DNS, it is a viable 
choice for small-timers (with the only exception being no real way to "back 
up" an instance without an "always-on" multi-master replica).

As a user who has just completed a "manual" migration/upgrade to F19 (after 
realizing that there really was no way to migrate/upgrade when the original 
install began on F17 2.1 on bare metal with the split slapd processes and 
Dogtag 9, through F18, to F19), I would like to see FreeIPA move forward but 
continue to deliver the above-mentioned services to the small-timers, who, 
without FreeIPA's unification, would never be able to manage or offer all of 
those services independently, like the big-timers might be able to.

Thanks.  -A

-- 
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E


signature.asc
Description: This is a digitally signed message part.
___
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Re: [Freeipa-devel] [PATCH] 0055 Fix tests which fail after ipa-adtrust-install

2013-08-09 Thread Ana Krivokapic 
On 08/09/2013 09:39 AM, Tomas Babej wrote:
> On 08/08/2013 04:09 PM, Ana Krivokapic wrote:
>> Hello,
>>
>> This patch should fix the failing unit tests.
>>
>> https://fedorahosted.org/freeipa/ticket/3852
>>
>>
>>
>> ___
>> Freeipa-devel mailing list
>> Freeipa-devel@redhat.com
>> https://www.redhat.com/mailman/listinfo/freeipa-devel
>
> There are two tests failing on my machine when running the tests after
> ipa-adtrust-install with your patch applied:

You say there are two tests failing but I only see one below.

>
> ==
> FAIL: test_group[24]: group_find: Search for POSIX groups
> --
> Traceback (most recent call last):
> [...]
> AssertionError: assert_deepequal: dict keys mismatch.
>   test_group[24]: group_find: Search for POSIX groups
>   missing keys = []
>   extra keys = ['ipantsecurityidentifier']
>   expected = {'dn':
> ipapython.dn.DN('cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'),
> 'cn': [u'editors'], 'objectclass': Fuzzy(None, None,  at
> 0x3768c08>), 'gidnumber': [Fuzzy('^\\d+$', , None)],
> 'ipauniqueid':
> [Fuzzy('^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$',  'unicode'>, None)], 'description': [u'Limited admins who can edit other 
> users']}
>   got = {'dn':
> u'cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com',
> 'cn': (u'editors',), 'objectclass': (u'top', u'groupofnames', u'posixgroup',
> u'ipausergroup', u'ipaobject', u'nestedGroup', u'ipantgroupattrs'),
> 'ipantsecurityidentifier':
> (u'S-1-5-21-1457515837-642396627-3509099663-1002',), 'gidnumber':
> (u'180462',), 'ipauniqueid': (u'7c6e1672-0039-11e3-9567-001a4a2221fb',),
> 'description': (u'Limited admins who can edit other users',)}
>   path = ('result', 1)
>
> I think you need the wrap the dictionary discribing the editor's group entry
> with the add_sid wrapper, and its objectclasses using the add_oc wrapper.
>
> [tbabej@vm-139 freeipa]$ git diff
> diff --git a/ipatests/test_xmlrpc/test_group_plugin.py
> b/ipatests/test_xmlrpc/test_group_plugin.py
> index d380fe5..14c70cd 100644
> --- a/ipatests/test_xmlrpc/test_group_plugin.py
> +++ b/ipatests/test_xmlrpc/test_group_plugin.py
> @@ -447,14 +447,15 @@ class test_group(Declarative):
>  objectclasses.posixgroup, u'ipantgroupattrs')),
>  'ipauniqueid': [fuzzy_uuid],
>  }),
> -{
> +add_sid({
>  'dn': get_group_dn('editors'),
>  'gidnumber': [fuzzy_digits],
>  'cn': [u'editors'],
>  'description': [u'Limited admins who can edit other
> users'],
> -'objectclass': 
> fuzzy_set_ci(objectclasses.posixgroup),
> +'objectclass': fuzzy_set_ci(add_oc(
> +objectclasses.posixgroup, u'ipantgroupattrs')),
>  'ipauniqueid': [fuzzy_uuid],
> -},
> +}),
>  dict(
>  dn=get_group_dn(group1),
>  cn=[group1],
>
>
> These changes were sufficient for me to have the unit test suite run without
> errors.
> -- 
> Tomas Babej
> Associate Software Engeneer | Red Hat | Identity Management
> RHCE | Brno Site | IRC: tbabej | freeipa.org

I retested the patch and the tests are passing in my setup. The editors group
definitely does not have the ipantsecurityidentifier attribute nor the
ipantgroupattrs objectclass:

[akrivoka@vm-181 freeipa]$ ipa group-show editors --all
  dn: 
cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com
  Group name: editors
  Description: Limited admins who can edit other users
  GID: 197702
  ipauniqueid: 91b3597e-00f3-11e3-92ae-001a4a22217b
  objectclass: top, groupofnames, posixgroup, ipausergroup, ipaobject, 
nestedGroup

What I noticed though, is that if I delete and re-create the editors group
(after ipa-adtrust-install has been run), it then gets the above mentioned
attribute and objectclass. Maybe you did some similar manipulation in your
setup, resulting in the test failing?


-- 
Regards,

Ana Krivokapic
Associate Software Engineer
FreeIPA team
Red Hat Inc.

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

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

2013-08-09 Thread Rob Crittenden 

Simo Sorce wrote:

On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:

On 23.7.2013 10:55, Petr Spacek wrote:

On 19.7.2013 19:55, Simo Sorce wrote:

I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.

On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:


The most important question at the moment is "What can we postpone?
How
fragile it can be for shipping it as part of Fedora 20?" Could we
declare
DNSSEC support as "technology preview"/"don't use it for anything
serious"?


Until we figur out proper management in LDAP we will be a bit stuck, esp
if we want to consider usin the 'somthing' that stores keys instead of
toring them stright in LDAP.

So maybe we can start with allowing just one server to do DNSSEC and
source keys from files for now ?


The problem is that DNSSEC deployment *on single domain* is 'all or nothing':
All DNS servers have to support DNSSEC otherwise the validation on client side
can fail randomly.

Note that *parent* zone indicates that the particular child zone is secured
with DNSSEC by sending DS (delegation signer) record to the client. Validation
will fail if client receives DS record from the parent but no signatures are
present in data from 'child' zone itself.

This prevents downgrade (DNSSEC => plain DNS) attacks.

As a result, we have only two options: One DNS server with DNSSEC enabled or
arbitrary number DNS servers without DNSSEC, which is very unfortunate.


as soon as we have that workign we should also have clearer plans about
how we manage keys in LDAP (or elsewhere).


Dmitri, Martin and me discussed this proposal in person and the new plan is:
- Elect one super-master which will handle key generation (as we do with
special CA certificates)


I guess we can start this way, but how do you determine which one is
master ?
I do not really like to have all this 'super roles', it's brittle and
admins will be confused which means one day their whole infrastructure
will be down because the keys are expired and all the clients will
refuse to communicate with anything.


AFAIU keys don't expire, rather there is a rollover process. The problem 
would be if the server that controlled the rollover went away the keys 
would never roll, leaving you potentially exposed.



I think it is ok as a first implementation, but I think this *must not*
be the final state. We can and must do better than this.


- Store generated DNSSEC keys in LDAP
- Encrypt stored keys with 'DNSSEC master key' shared by all servers


ok.


- Derive 'DNSSEC master key' from 'Kerberos master key' during server
install/upgrade and store it somewhere on the filesystem (as the Kerberos
master key, on each IPA server)


The Kerberos master key is not stored on disk, furthermore it could
change, so if you derive it at install time and install a replica after
it was changed everything will break. I think we need to store the key
in LDAP, encrypted, and dump it to disk when a new one is generated.

Aside, DNSSEC uses pub/private key crypto so this would be a special
'master key' used exclusively to encrypt keys in LDAP ?


- Consider certmonger or oddjob as key generation triggers


I do not understand this comment.


He is trying to automate the key rollover. I don't think certmonger will 
work as it is designed for X.509 certs. Are you proposing an additional 
attribute to schedule the rollover? I thought that it was a good idea to 
have some flexibility here to prevent timed DoS attacks for rollover time.



I think that we should add one new thing - a 'salt' - used for Kerberos master
key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC
master key as necessary without a change in the Kerberos master key.


Salts are not necessary, HKDF from a cryptographically random key does
not require it.


Does it make sense? Does anybody have any ideas/recommendations which
libraries we should use for key derivation and key material en/decryption?


openssl/nss I already have all the basic code we need for that.


I prefer the procedure just outlined in 
https://www.redhat.com/archives/freeipa-devel/2013-August/msg00089.html 
which just calls dnssec-keygen rather than trying to roll your own. I 
don't know what derivation really buys you.


rob

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

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

2013-08-09 Thread Simo Sorce 
On Fri, 2013-08-09 at 10:42 +0200, Petr Spacek wrote:
> On 23.7.2013 10:55, Petr Spacek wrote:
> > On 19.7.2013 19:55, Simo Sorce wrote:
> >> I will reply to the rest of the message later if necessary, still
> >> digesting some of your answers, but I wanted to address the following
> >> first.
> >>
> >> On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:
> >>>
> >>> The most important question at the moment is "What can we postpone?
> >>> How
> >>> fragile it can be for shipping it as part of Fedora 20?" Could we
> >>> declare
> >>> DNSSEC support as "technology preview"/"don't use it for anything
> >>> serious"?
> >>
> >> Until we figur out proper management in LDAP we will be a bit stuck, esp
> >> if we want to consider usin the 'somthing' that stores keys instead of
> >> toring them stright in LDAP.
> >>
> >> So maybe we can start with allowing just one server to do DNSSEC and
> >> source keys from files for now ?
> >
> > The problem is that DNSSEC deployment *on single domain* is 'all or 
> > nothing':
> > All DNS servers have to support DNSSEC otherwise the validation on client 
> > side
> > can fail randomly.
> >
> > Note that *parent* zone indicates that the particular child zone is secured
> > with DNSSEC by sending DS (delegation signer) record to the client. 
> > Validation
> > will fail if client receives DS record from the parent but no signatures are
> > present in data from 'child' zone itself.
> >
> > This prevents downgrade (DNSSEC => plain DNS) attacks.
> >
> > As a result, we have only two options: One DNS server with DNSSEC enabled or
> > arbitrary number DNS servers without DNSSEC, which is very unfortunate.
> >
> >> as soon as we have that workign we should also have clearer plans about
> >> how we manage keys in LDAP (or elsewhere).
> 
> Dmitri, Martin and me discussed this proposal in person and the new plan is:
> - Elect one super-master which will handle key generation (as we do with 
> special CA certificates)

I guess we can start this way, but how do you determine which one is
master ?
I do not really like to have all this 'super roles', it's brittle and
admins will be confused which means one day their whole infrastructure
will be down because the keys are expired and all the clients will
refuse to communicate with anything.

I think it is ok as a first implementation, but I think this *must not*
be the final state. We can and must do better than this.

> - Store generated DNSSEC keys in LDAP
> - Encrypt stored keys with 'DNSSEC master key' shared by all servers

ok.

> - Derive 'DNSSEC master key' from 'Kerberos master key' during server 
> install/upgrade and store it somewhere on the filesystem (as the Kerberos 
> master key, on each IPA server)

The Kerberos master key is not stored on disk, furthermore it could
change, so if you derive it at install time and install a replica after
it was changed everything will break. I think we need to store the key
in LDAP, encrypted, and dump it to disk when a new one is generated.

Aside, DNSSEC uses pub/private key crypto so this would be a special
'master key' used exclusively to encrypt keys in LDAP ?

> - Consider certmonger or oddjob as key generation triggers

I do not understand this comment.

> I think that we should add one new thing - a 'salt' - used for Kerberos 
> master 
> key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC 
> master key as necessary without a change in the Kerberos master key.

Salts are not necessary, HKDF from a cryptographically random key does
not require it.

> Does it make sense? Does anybody have any ideas/recommendations which 
> libraries we should use for key derivation and key material en/decryption?

openssl/nss I already have all the basic code we need for 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

[Freeipa-devel] certmonger/oddjob for DNSSEC key maintenance

2013-08-09 Thread Petr Spacek 

Hello,

I would like to get opinions about key maintenance for DNSSEC.

Problem summary:
- FreeIPA will support DNSSEC
- DNSSEC deployment requires <2,n> cryptographic keys for each DNS zone (i.e. 
objects in LDAP)

- The same keys are shared by all FreeIPA servers
- Keys have limited lifetime and have to be re-generated on monthly basics (in 
very first approximation, it will be configurable and the interval will differ 
for different key types)
- The plan is to store keys in LDAP and let 'something' (i.e. certmonger or 
oddjob?) to generate and store the new keys back into LDAP
- There are command line tools for key-generation (dnssec-keygen from the 
package bind-utils)
- We plan to select one super-master which will handle regular 
key-regeneration (i.e. do the same as we do for special CA certificates)
- Keys stored in LDAP will be encrypted somehow, most probably by some 
symmetric key shared among all IPA DNS servers


Could certmonger or oddjob do key maintenance for us? I can imagine something 
like this:

- watch some attributes in LDAP and wait until some key expires
- run dnssec-keygen utility
- read resulting keys and encrypt them with given 'master key'
- store resulting blobs in LDAP
- wait until another key reaches expiration timestamp

It is simplified, because there will be multiple keys with different 
lifetimes, but the idea is the same. All the gory details are in the thread 
'[Freeipa-devel] DNSSEC support design considerations: key material handling':

https://www.redhat.com/archives/freeipa-devel/2013-July/msg00129.html
https://www.redhat.com/archives/freeipa-devel/2013-August/msg00086.html

Nalin and others, what do you think? Is certmonger or oddjob the right place 
to do something like this?


Thank you for your time!

--
Petr^2 Spacek

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

Re: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search

2013-08-09 Thread Martin Kosek 
On 08/09/2013 12:02 PM, Tomas Babej wrote:
> On 08/08/2013 06:20 PM, Martin Kosek wrote:
>> On 08/07/2013 04:52 PM, Tomas Babej wrote:
>>> On 08/05/2013 05:59 PM, Martin Kosek wrote:
 On 07/17/2013 01:47 PM, Tomas Babej wrote:
>> I will release version 3.5 before end of this week. I have some small 
>> fixes
>> ready so it is worth to release it now.
>>
>> To summarize the discussion - please remove following options from
>> configuration file and LDAP schema:
>> cache_ttl
>> psearch (attribute idnsPersistentSearch in idnsConfigObject)
>> zone_refresh (attribute idnsZoneRefresh in idnsConfigObject)
>>
>> -- 
>> Petr^2 Spacek
> I have a patch ready, but it can't be tested until 3.5 is out.
>
> Tomas
>
 I did not test the patch yet, I just want to comment on one thing I just
 noticed.

 I is it a good idea to remove idnsZoneRefresh and idnsPersistentSearch
 attribute types and modify idnsConfigObject objectclass?

 This will affect not only new instances, but also the old ones (i.e. 
 RHEL-6.4)
 which may still use these attributes. DNS config object would suddenly 
 become
 unusable because DS would refuse to operate the entry as it does not follow
 the
 schema. The same applies for ACIs.

 I would personally not do these changes yet, I think just hiding and
 marking as
 DeprecatedParam is enough for now. Alexander, what do you think?

 Martin
>>> We discussed this with Martin. I agreed it would be less cumbersome to
>>> keep the attributes in schema for now.
>>>
>>> I retested the patches, updated versions attached.
>>>
>>> Petr, can bind-dyndb-ldap handle idnsConfigObject containing
>>> idnsPersistentSearch
>>> and idnsZoneRefresh attributes?
>>>
>> I still see some schema and aci changes:
>>
>> --- a/install/updates/10-bind-schema.update
>> +++ b/install/updates/10-bind-schema.update
>> @@ -44,7 +44,7 @@ add:attributeTypes:
>> SUBSTR caseIgnoreIA5SubstringsMatch
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
>> X-ORIGIN 'IPA v2' )
>> -add:attributeTypes:
>> +remove:attributeTypes:
>>   ( 2.16.840.1.113730.3.8.5.16
>> NAME 'idnsZoneRefresh'
>> DESC 'zone refresh interval'
>> @@ -52,7 +52,7 @@ add:attributeTypes:
>> SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
>> SINGLE-VALUE
>> X-ORIGIN 'IPA v2' )
>> -add:attributeTypes:
>> +remove:attributeTypes:
>>   ( 2.16.840.1.113730.3.8.5.17
>> NAME 'idnsPersistentSearch'
>> DESC 'allow persistent searches'
>> @@ -65,8 +65,7 @@ add:objectClasses:
>> NAME 'idnsConfigObject'
>> DESC 'DNS global config options'
>> STRUCTURAL
>> -  MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR $$
>> -idnsZoneRefresh $$ idnsPersistentSearch
>> +  MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR
>> ) )
>>   add:objectClasses:
>>   ( 2.16.840.1.113730.3.8.12.18
>>
>> AND
>>
>> -_write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy ||
>> idnsforwarders || idnsallowsyncptr || idnszonerefresh ||
>> idnspersistentsearch")(target = "ldap:///cn=dns,%(realm)s")(version 3.0;acl
>> "permission:Write DNS Configuration";allow (write) groupdn = 
>> "ldap:///cn=Write
>> DNS Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' %
>> dict(realm=api.env.basedn)]
>> +_write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy ||
>> idnsforwarders || idnsallowsyncptr")(target =
>> "ldap:///cn=dns,%(realm)s")(version 3.0;acl "permission:Write DNS
>> Configuration";allow (write) groupdn = "ldap:///cn=Write DNS
>> Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' %
>> dict(realm=api.env.basedn)]
>>
>> Besides these, patch worked fine on both upgrade and new installation. So 
>> when
>> you remove these chunks, it will be ack.
>>
>> Martin
> Updated patch attached.
> 
> Tomas
> 

ACK! Pushed to master.

Martin

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

Re: [Freeipa-devel] [PATCH 0073] Remove support for IPA deployments with no persistent search

2013-08-09 Thread Tomas Babej 

On 08/08/2013 06:20 PM, Martin Kosek wrote:

On 08/07/2013 04:52 PM, Tomas Babej wrote:

On 08/05/2013 05:59 PM, Martin Kosek wrote:

On 07/17/2013 01:47 PM, Tomas Babej wrote:

I will release version 3.5 before end of this week. I have some small fixes
ready so it is worth to release it now.

To summarize the discussion - please remove following options from
configuration file and LDAP schema:
cache_ttl
psearch (attribute idnsPersistentSearch in idnsConfigObject)
zone_refresh (attribute idnsZoneRefresh in idnsConfigObject)

--
Petr^2 Spacek

I have a patch ready, but it can't be tested until 3.5 is out.

Tomas


I did not test the patch yet, I just want to comment on one thing I just
noticed.

I is it a good idea to remove idnsZoneRefresh and idnsPersistentSearch
attribute types and modify idnsConfigObject objectclass?

This will affect not only new instances, but also the old ones (i.e. RHEL-6.4)
which may still use these attributes. DNS config object would suddenly become
unusable because DS would refuse to operate the entry as it does not follow the
schema. The same applies for ACIs.

I would personally not do these changes yet, I think just hiding and marking as
DeprecatedParam is enough for now. Alexander, what do you think?

Martin

We discussed this with Martin. I agreed it would be less cumbersome to
keep the attributes in schema for now.

I retested the patches, updated versions attached.

Petr, can bind-dyndb-ldap handle idnsConfigObject containing 
idnsPersistentSearch
and idnsZoneRefresh attributes?


I still see some schema and aci changes:

--- a/install/updates/10-bind-schema.update
+++ b/install/updates/10-bind-schema.update
@@ -44,7 +44,7 @@ add:attributeTypes:
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
X-ORIGIN 'IPA v2' )
-add:attributeTypes:
+remove:attributeTypes:
  ( 2.16.840.1.113730.3.8.5.16
NAME 'idnsZoneRefresh'
DESC 'zone refresh interval'
@@ -52,7 +52,7 @@ add:attributeTypes:
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE
X-ORIGIN 'IPA v2' )
-add:attributeTypes:
+remove:attributeTypes:
  ( 2.16.840.1.113730.3.8.5.17
NAME 'idnsPersistentSearch'
DESC 'allow persistent searches'
@@ -65,8 +65,7 @@ add:objectClasses:
NAME 'idnsConfigObject'
DESC 'DNS global config options'
STRUCTURAL
-  MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR $$
-idnsZoneRefresh $$ idnsPersistentSearch
+  MAY ( idnsForwardPolicy $$ idnsForwarders $$ idnsAllowSyncPTR
) )
  add:objectClasses:
  ( 2.16.840.1.113730.3.8.12.18

AND

-_write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy ||
idnsforwarders || idnsallowsyncptr || idnszonerefresh ||
idnspersistentsearch")(target = "ldap:///cn=dns,%(realm)s")(version 3.0;acl
"permission:Write DNS Configuration";allow (write) groupdn = "ldap:///cn=Write
DNS Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' %
dict(realm=api.env.basedn)]
+_write_dns_aci_entry = ['add:aci:\'(targetattr = "idnsforwardpolicy ||
idnsforwarders || idnsallowsyncptr")(target =
"ldap:///cn=dns,%(realm)s")(version 3.0;acl "permission:Write DNS
Configuration";allow (write) groupdn = "ldap:///cn=Write DNS
Configuration,cn=permissions,cn=pbac,%(realm)s";)\'' % 
dict(realm=api.env.basedn)]

Besides these, patch worked fine on both upgrade and new installation. So when
you remove these chunks, it will be ack.

Martin

Updated patch attached.

Tomas

--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org

From f8b98669ff91a2a5a9a83a7fadb100a0329dec66 Mon Sep 17 00:00:00 2001
From: Tomas Babej 
Date: Fri, 9 Aug 2013 11:55:49 +0200
Subject: [PATCH] Remove support for IPA deployments with no persistent search

Drops the code from ipa-server-install, ipa-dns-install and the
BindInstance itself. Also changed ipa-upgradeconfig script so
that it does not set zone_refresh to 0 on upgrades, as the option
is deprecated.

https://fedorahosted.org/freeipa/ticket/3632
---
 API.txt |   2 +-
 freeipa.spec.in |   2 +-
 install/share/bind.named.conf.template  |   2 -
 install/tools/ipa-dns-install   |  24 -
 install/tools/ipa-server-install|  24 -
 install/tools/ipa-upgradeconfig | 137 
 install/tools/man/ipa-dns-install.1 |   6 --
 install/tools/man/ipa-server-install.1  |   6 --
 install/ui/src/freeipa/dns.js   |   3 +-
 install/ui/test/data/dnsconfig_mod.json |   5 -
 install/ui/test/data/dnsconfig_show.json|   5 -
 install/ui/test/data/ipa_init_commands.json |  11 ---
 install/ui/test/data/ipa_init_objects.json  |  15 +--
 ipalib/plugins/dns.py   |  10 +-
 ipaserver/install/bindinstance.py   |  38 
 ipatests/test_xmlrpc/test_dns_plugin.py

Re: [Freeipa-devel] DNSSEC support design considerations: key material handling

2013-08-09 Thread Petr Spacek 

On 23.7.2013 10:55, Petr Spacek wrote:

On 19.7.2013 19:55, Simo Sorce wrote:

I will reply to the rest of the message later if necessary, still
digesting some of your answers, but I wanted to address the following
first.

On Fri, 2013-07-19 at 18:29 +0200, Petr Spacek wrote:


The most important question at the moment is "What can we postpone?
How
fragile it can be for shipping it as part of Fedora 20?" Could we
declare
DNSSEC support as "technology preview"/"don't use it for anything
serious"?


Until we figur out proper management in LDAP we will be a bit stuck, esp
if we want to consider usin the 'somthing' that stores keys instead of
toring them stright in LDAP.

So maybe we can start with allowing just one server to do DNSSEC and
source keys from files for now ?


The problem is that DNSSEC deployment *on single domain* is 'all or nothing':
All DNS servers have to support DNSSEC otherwise the validation on client side
can fail randomly.

Note that *parent* zone indicates that the particular child zone is secured
with DNSSEC by sending DS (delegation signer) record to the client. Validation
will fail if client receives DS record from the parent but no signatures are
present in data from 'child' zone itself.

This prevents downgrade (DNSSEC => plain DNS) attacks.

As a result, we have only two options: One DNS server with DNSSEC enabled or
arbitrary number DNS servers without DNSSEC, which is very unfortunate.


as soon as we have that workign we should also have clearer plans about
how we manage keys in LDAP (or elsewhere).


Dmitri, Martin and me discussed this proposal in person and the new plan is:
- Elect one super-master which will handle key generation (as we do with 
special CA certificates)

- Store generated DNSSEC keys in LDAP
- Encrypt stored keys with 'DNSSEC master key' shared by all servers
- Derive 'DNSSEC master key' from 'Kerberos master key' during server 
install/upgrade and store it somewhere on the filesystem (as the Kerberos 
master key, on each IPA server)

- Consider certmonger or oddjob as key generation triggers

I think that we should add one new thing - a 'salt' - used for Kerberos master 
key->DNSSEC master key derivation. It would allow us to re-generate DNSSEC 
master key as necessary without a change in the Kerberos master key.



Does it make sense? Does anybody have any ideas/recommendations which 
libraries we should use for key derivation and key material en/decryption?


Thank you for your time!

--
Petr^2 Spacek

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

Re: [Freeipa-devel] [PATCH] 0055 Fix tests which fail after ipa-adtrust-install

2013-08-09 Thread Tomas Babej 

On 08/08/2013 04:09 PM, Ana Krivokapic wrote:

Hello,

This patch should fix the failing unit tests.

https://fedorahosted.org/freeipa/ticket/3852



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


There are two tests failing on my machine when running the tests after 
ipa-adtrust-install with your patch applied:


==
FAIL: test_group[24]: group_find: Search for POSIX groups
--
Traceback (most recent call last):
[...]
AssertionError: assert_deepequal: dict keys mismatch.
  test_group[24]: group_find: Search for POSIX groups
  missing keys = []
  extra keys = ['ipantsecurityidentifier']
  expected = {'dn': 
ipapython.dn.DN('cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com'), 
'cn': [u'editors'], 'objectclass': Fuzzy(None, None,  
at 0x3768c08>), 'gidnumber': [Fuzzy('^\\d+$', , 
None)], 'ipauniqueid': 
[Fuzzy('^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$', 
, None)], 'description': [u'Limited admins who can edit 
other users']}
  got = {'dn': 
u'cn=editors,cn=groups,cn=accounts,dc=idm,dc=lab,dc=eng,dc=brq,dc=redhat,dc=com', 
'cn': (u'editors',), 'objectclass': (u'top', u'groupofnames', 
u'posixgroup', u'ipausergroup', u'ipaobject', u'nestedGroup', 
u'ipantgroupattrs'), 'ipantsecurityidentifier': 
(u'S-1-5-21-1457515837-642396627-3509099663-1002',), 'gidnumber': 
(u'180462',), 'ipauniqueid': 
(u'7c6e1672-0039-11e3-9567-001a4a2221fb',), 'description': (u'Limited 
admins who can edit other users',)}

  path = ('result', 1)

I think you need the wrap the dictionary discribing the editor's group 
entry with the add_sid wrapper, and its objectclasses using the add_oc 
wrapper.


[tbabej@vm-139 freeipa]$ git diff
diff --git a/ipatests/test_xmlrpc/test_group_plugin.py 
b/ipatests/test_xmlrpc/test_group_plugin.py

index d380fe5..14c70cd 100644
--- a/ipatests/test_xmlrpc/test_group_plugin.py
+++ b/ipatests/test_xmlrpc/test_group_plugin.py
@@ -447,14 +447,15 @@ class test_group(Declarative):
 objectclasses.posixgroup, 
u'ipantgroupattrs')),

 'ipauniqueid': [fuzzy_uuid],
 }),
-{
+add_sid({
 'dn': get_group_dn('editors'),
 'gidnumber': [fuzzy_digits],
 'cn': [u'editors'],
 'description': [u'Limited admins who can edit 
other users'],
-'objectclass': 
fuzzy_set_ci(objectclasses.posixgroup),

+'objectclass': fuzzy_set_ci(add_oc(
+objectclasses.posixgroup, u'ipantgroupattrs')),
 'ipauniqueid': [fuzzy_uuid],
-},
+}),
 dict(
 dn=get_group_dn(group1),
 cn=[group1],


These changes were sufficient for me to have the unit test suite run 
without errors.


--
Tomas Babej
Associate Software Engeneer | Red Hat | Identity Management
RHCE | Brno Site | IRC: tbabej | freeipa.org

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