Re: [Freeipa-devel] Planning FreeIPA 4.0 GA

2014-06-28 Thread daiEric
Dearall :
if freeipa canbe installed on centos 6.5 or 7.0
?

发自我的 iPhone

 在 2014年6月27日,23:10,Martin Kosek mko...@redhat.com 写道:
 
 Hello team,
 
 As we are about to very soon release the FreeIPA 4.0, I triaged all the 
 pending
 tickets and divided them to following milestones:
 
 1) FreeIPA 4.0 GA - last work that is required for the release. When this
 milestone is completed, we will release. All tickets in this milestone are 
 thus
 the top priority for people working on 4.0 - this applies both for development
 and for reviews.
 
 2) FreeIPA 4.0.1 - stabilization tickets that do not affect the release in any
 significant way and can be done after GA.
 
 RFEs and bugs that did not make it to these buckets were pushed out to next
 releases - 4.1, 4.2 or even farther, based on their scope and importance. If I
 missed anything or you think that some ticket I pushed out must make it to 4.0
 (and you have a patch), please ping me.
 
 Thank you.
 
 -- 
 Martin Kosek mko...@redhat.com
 Supervisor, Software Engineering - Identity Management Team
 Red Hat Inc.
 
 ___
 Freeipa-devel mailing list
 Freeipa-devel@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-devel

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

Re: [Freeipa-devel] Planning FreeIPA 4.0 GA

2014-06-28 Thread Simo Sorce
On Sat, 2014-06-28 at 15:45 +0800, daiEric wrote:
 Dearall :
 if freeipa canbe installed on centos 6.5 or 7.0
 ?

Yes, it is called Identity Management on RHEL and derivatives:
yum install ipa-server

Simo.

 发自我的 iPhone
 
  在 2014年6月27日,23:10,Martin Kosek mko...@redhat.com 写道:
  
  Hello team,
  
  As we are about to very soon release the FreeIPA 4.0, I triaged all the 
  pending
  tickets and divided them to following milestones:
  
  1) FreeIPA 4.0 GA - last work that is required for the release. When this
  milestone is completed, we will release. All tickets in this milestone are 
  thus
  the top priority for people working on 4.0 - this applies both for 
  development
  and for reviews.
  
  2) FreeIPA 4.0.1 - stabilization tickets that do not affect the release in 
  any
  significant way and can be done after GA.
  
  RFEs and bugs that did not make it to these buckets were pushed out to next
  releases - 4.1, 4.2 or even farther, based on their scope and importance. 
  If I
  missed anything or you think that some ticket I pushed out must make it to 
  4.0
  (and you have a patch), please ping me.
  
  Thank you.
  
  -- 
  Martin Kosek mko...@redhat.com
  Supervisor, Software Engineering - Identity Management Team
  Red Hat Inc.
  
  ___
  Freeipa-devel mailing list
  Freeipa-devel@redhat.com
  https://www.redhat.com/mailman/listinfo/freeipa-devel
 
 ___
 Freeipa-devel mailing list
 Freeipa-devel@redhat.com
 https://www.redhat.com/mailman/listinfo/freeipa-devel


-- 
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] Planning FreeIPA 4.0 GA

2014-06-27 Thread Martin Kosek
Hello team,

As we are about to very soon release the FreeIPA 4.0, I triaged all the pending
tickets and divided them to following milestones:

1) FreeIPA 4.0 GA - last work that is required for the release. When this
milestone is completed, we will release. All tickets in this milestone are thus
the top priority for people working on 4.0 - this applies both for development
and for reviews.

2) FreeIPA 4.0.1 - stabilization tickets that do not affect the release in any
significant way and can be done after GA.

RFEs and bugs that did not make it to these buckets were pushed out to next
releases - 4.1, 4.2 or even farther, based on their scope and importance. If I
missed anything or you think that some ticket I pushed out must make it to 4.0
(and you have a patch), please ping me.

Thank you.

-- 
Martin Kosek mko...@redhat.com
Supervisor, Software Engineering - Identity Management Team
Red Hat Inc.

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


Re: [Freeipa-devel] Planning FreeIPA 4.0 GA

2014-06-27 Thread Alexander Bokovoy

On Fri, 27 Jun 2014, Martin Kosek wrote:

Hello team,

As we are about to very soon release the FreeIPA 4.0, I triaged all the pending
tickets and divided them to following milestones:

1) FreeIPA 4.0 GA - last work that is required for the release. When this
milestone is completed, we will release. All tickets in this milestone are thus
the top priority for people working on 4.0 - this applies both for development
and for reviews.

Endi found that with TOTP we don't yet enforce a requirement to prevent
reuse of OTP code multiple times within the same time step (you are able
to login with TOTP and reuse it for password change within 30 seconds,
for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT
allow this behavior.

I'll look into this case on Monday but so far this is a release blocker.
--
/ Alexander Bokovoy

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


Re: [Freeipa-devel] Planning FreeIPA 4.0 GA

2014-06-27 Thread Alexander Bokovoy

On Fri, 27 Jun 2014, Alexander Bokovoy wrote:

On Fri, 27 Jun 2014, Martin Kosek wrote:

Hello team,

As we are about to very soon release the FreeIPA 4.0, I triaged all the pending
tickets and divided them to following milestones:

1) FreeIPA 4.0 GA - last work that is required for the release. When this
milestone is completed, we will release. All tickets in this milestone are thus
the top priority for people working on 4.0 - this applies both for development
and for reviews.

Endi found that with TOTP we don't yet enforce a requirement to prevent
reuse of OTP code multiple times within the same time step (you are able
to login with TOTP and reuse it for password change within 30 seconds,
for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT
allow this behavior.

Err, RFC 6238, of course. http://tools.ietf.org/html/rfc6238#section-5.2

I'm off for weekend. :)

--
/ Alexander Bokovoy

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


Re: [Freeipa-devel] Planning FreeIPA 4.0 GA

2014-06-27 Thread Simo Sorce
On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote:
 On Fri, 27 Jun 2014, Martin Kosek wrote:
 Hello team,
 
 As we are about to very soon release the FreeIPA 4.0, I triaged all the 
 pending
 tickets and divided them to following milestones:
 
 1) FreeIPA 4.0 GA - last work that is required for the release. When this
 milestone is completed, we will release. All tickets in this milestone are 
 thus
 the top priority for people working on 4.0 - this applies both for 
 development
 and for reviews.
 Endi found that with TOTP we don't yet enforce a requirement to prevent
 reuse of OTP code multiple times within the same time step (you are able
 to login with TOTP and reuse it for password change within 30 seconds,
 for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT
 allow this behavior.
 
 I'll look into this case on Monday but so far this is a release blocker.

This is a well known limitation.

The reason we allow for it is due to performance issues with replication
if we did so, we do not have a good way to mark used values in a
distributed fashion.

It's for the same reason that we have not implemented HOTP yet.

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] Planning FreeIPA 4.0 GA

2014-06-27 Thread Alexander Bokovoy

On Fri, 27 Jun 2014, Simo Sorce wrote:

On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote:

On Fri, 27 Jun 2014, Martin Kosek wrote:
Hello team,

As we are about to very soon release the FreeIPA 4.0, I triaged all the pending
tickets and divided them to following milestones:

1) FreeIPA 4.0 GA - last work that is required for the release. When this
milestone is completed, we will release. All tickets in this milestone are thus
the top priority for people working on 4.0 - this applies both for development
and for reviews.
Endi found that with TOTP we don't yet enforce a requirement to prevent
reuse of OTP code multiple times within the same time step (you are able
to login with TOTP and reuse it for password change within 30 seconds,
for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT
allow this behavior.

I'll look into this case on Monday but so far this is a release blocker.


This is a well known limitation.

The reason we allow for it is due to performance issues with replication
if we did so, we do not have a good way to mark used values in a
distributed fashion.

Are we willing to release with this limitation? If so, it should be
stated quite clearly in the docs.
--
/ Alexander Bokovoy

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


Re: [Freeipa-devel] Planning FreeIPA 4.0 GA

2014-06-27 Thread Petr Vobornik

On 27.6.2014 19:00, Simo Sorce wrote:

On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote:

On Fri, 27 Jun 2014, Martin Kosek wrote:

Hello team,

As we are about to very soon release the FreeIPA 4.0, I triaged all the pending
tickets and divided them to following milestones:

1) FreeIPA 4.0 GA - last work that is required for the release. When this
milestone is completed, we will release. All tickets in this milestone are thus
the top priority for people working on 4.0 - this applies both for development
and for reviews.

Endi found that with TOTP we don't yet enforce a requirement to prevent
reuse of OTP code multiple times within the same time step (you are able
to login with TOTP and reuse it for password change within 30 seconds,
for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT
allow this behavior.

I'll look into this case on Monday but so far this is a release blocker.


This is a well known limitation.

The reason we allow for it is due to performance issues with replication
if we did so, we do not have a good way to mark used values in a
distributed fashion.




It's for the same reason that we have not implemented HOTP yet.


Not entirely true:
http://www.redhat.com/archives/freeipa-devel/2014-January/msg00069.html



Simo.


--
Petr Vobornik

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


Re: [Freeipa-devel] Planning FreeIPA 4.0 GA

2014-06-27 Thread Simo Sorce
On Fri, 2014-06-27 at 19:19 +0200, Petr Vobornik wrote:
 On 27.6.2014 19:00, Simo Sorce wrote:
  On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote:
  On Fri, 27 Jun 2014, Martin Kosek wrote:
  Hello team,
 
  As we are about to very soon release the FreeIPA 4.0, I triaged all the 
  pending
  tickets and divided them to following milestones:
 
  1) FreeIPA 4.0 GA - last work that is required for the release. When this
  milestone is completed, we will release. All tickets in this milestone 
  are thus
  the top priority for people working on 4.0 - this applies both for 
  development
  and for reviews.
  Endi found that with TOTP we don't yet enforce a requirement to prevent
  reuse of OTP code multiple times within the same time step (you are able
  to login with TOTP and reuse it for password change within 30 seconds,
  for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT
  allow this behavior.
 
  I'll look into this case on Monday but so far this is a release blocker.
 
  This is a well known limitation.
 
  The reason we allow for it is due to performance issues with replication
  if we did so, we do not have a good way to mark used values in a
  distributed fashion.
 
 
  It's for the same reason that we have not implemented HOTP yet.
 
 Not entirely true:
 http://www.redhat.com/archives/freeipa-devel/2014-January/msg00069.html

I should probably have said we have not implemented it *for* HOTP.

That said using HOTP is not really something I would recommend at this
point as each authentication will cause a replication event to be fired.
That is probably ok if you have very few users/authentications, but in
large domains it would quickly be problematic.

Responding to Alexander, yes we need to document that we have this
limitation.

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] Planning FreeIPA 4.0 GA

2014-06-27 Thread Nathaniel McCallum

On Jun 27, 2014, at 1:49 PM, Simo Sorce s...@redhat.com wrote:

 On Fri, 2014-06-27 at 19:19 +0200, Petr Vobornik wrote:
 On 27.6.2014 19:00, Simo Sorce wrote:
 On Fri, 2014-06-27 at 19:55 +0300, Alexander Bokovoy wrote:
 On Fri, 27 Jun 2014, Martin Kosek wrote:
 Hello team,
 
 As we are about to very soon release the FreeIPA 4.0, I triaged all the 
 pending
 tickets and divided them to following milestones:
 
 1) FreeIPA 4.0 GA - last work that is required for the release. When this
 milestone is completed, we will release. All tickets in this milestone 
 are thus
 the top priority for people working on 4.0 - this applies both for 
 development
 and for reviews.
 Endi found that with TOTP we don't yet enforce a requirement to prevent
 reuse of OTP code multiple times within the same time step (you are able
 to login with TOTP and reuse it for password change within 30 seconds,
 for example). RFC3268 part 5.2 clearly says that the verifier MUST NOT
 allow this behavior.
 
 I'll look into this case on Monday but so far this is a release blocker.
 
 This is a well known limitation.
 
 The reason we allow for it is due to performance issues with replication
 if we did so, we do not have a good way to mark used values in a
 distributed fashion.
 
 
 It's for the same reason that we have not implemented HOTP yet.
 
 Not entirely true:
 http://www.redhat.com/archives/freeipa-devel/2014-January/msg00069.html
 
 I should probably have said we have not implemented it *for* HOTP.
 
 That said using HOTP is not really something I would recommend at this
 point as each authentication will cause a replication event to be fired.
 That is probably ok if you have very few users/authentications, but in
 large domains it would quickly be problematic.
 
 Responding to Alexander, yes we need to document that we have this
 limitation.

+1, we need to clearly document it. I plan to work on this next week.

Just to outline the situation:

We currently implement two features: TOTP and HOTP. We currently only recommend 
deploying TOTP due to the aforementioned replication issues.

HOTP will not permit key reuse, but TOTP will. We call this feature for TOTP 
“high watermark.” The reasons for this are twofold.

First, we have a general concern about replication storms when recording the 
high watermark. We hope to solve this problem in the next release by defining a 
mechanism for high priority replication and, hopefully, custom replication 
conflict resolvers to prevent a possible scenario where the counter would move 
backwards.

Second, when using HOTP, a bug is triggered in SSSD password changing where a 
token is implicitly used twice in a row. Enabling high watermark support for 
TOTP also triggers this bug. Fixing this in SSSD is also high on the priority 
list for the next release.

So, in short, it is a known defect that is not a blocker for this release and 
that needs to be appropriately documented.

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