Subject: Re: [Ietf-krb-wg] I-D Action: draft-ietf-krb-wg-kdc-model-12.txt

From: Leif Johansson <[email-masked]>
Date: Sun, 03 Jun 2012 12:23:31 +0200

On 05/30/2012 07:13 PM, Simo Sorce wrote:
> On Wed, 2012-05-30 at 13:00 -0400, Sam Hartman wrote:
>> I'd like to call the working group's attention to the new text 
>> surrounding RFc 2119 language.  In particular in this draft,
>> MUST features in the information model MUST be representable in
>> schema *and* MUST be supported by all implementations of the
>> information model.  That last was intended by Leif but was new to
>> me.
> 
> Thanks for bringing this up Sam.
> 
> 
> I am reading the doc now and I have a question as to why we have a
> MUST on the syntax of attributes like principalNotUsedBefore.
> 
> It says it MUST use "Internet Date/Time Format from [RFC3339]"
> 
> This is problematic as LDAP uses generalizedTime defined in
> RFC4517. It is a representation of ISO8061 just like RFC3339, but a
> *different* representation.
> 
> Trying to force all implementations to use the RFC3339 definition
> seem wrong. What implementation, today, uses RFC3339 ?
> 
> I would rather suggest that the document does not mandate the
> specific representation discussed in RFC3339 but allow any ISO8601
> based representation.
> 
> If it is felt that one representation really needs to be chosen
> then I'd ask to use the generalizedTime representation as defined
> by RFC4517 instead of the one in RFC3339.

So this was a WG decision at the time. Maybe we should say "Internet
Date/Time format MUST be based on ISO8601 and SHOULD be based on either
RFC4517 or RFC3339". In practice the or doesn't result in interop issues
since it is unlikely that an LDAP client be used to talk to a SOAP
server :-)

	Cheers Leif
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Leif Johansson <[email-masked]>
Date: Sun, 03 Jun 2012 12:30:19 +0200

On 05/30/2012 07:45 PM, Simo Sorce wrote:
> I have additional comments.
> 
> 
> These following 3 attribute definitions bind the implementer to a
> very special way to address counting failed authentication
> attempts.
> 
> 4.1.1.5.  principalNumberOfFailedAuthenticationAttempts
> 
> This single-valued integer attribute contains a count of the
> number of times an authentication attempt was unsuccessful for
> this Principal.  Implementations SHOULD NOT allow this counter to
> be reset.
> 
> 4.1.1.6.  principalLastFailedAuthentication
> 
> This single-valued attribute contains the time and date for the
> last failed authentication attempt for this Principal.  The syntax
> of the attribute MUST be Internet Date/Time Format from [RFC3339].
> 
> 4.1.1.7.  principalLastSuccessfulAuthentication
> 
> This single-valued attribute contains the time and date for the
> last successful authentication attempt for this principal.  The
> syntax of the attribute MUST be Internet Date/Time Format from
> [RFC3339].\
> 
> 
> They force a mechanism where you have a specific counter. It seems
> to prevent instead an implementation that may have a multi-valued
> attribute where all failed attempts are recorded in order to have
> an audit trail, and the number of failed attempts is computed by
> counting these values.

I don't see why. You can have additional attributes if you like and
producing a count from that audit-trail is probably easy, right?!

> 
> However assuming that this scheme is really preferred, then I do
> not understand how it can be implemented if 4.1.1.5 says that the
> counter should not be reset. I think implementations need to reset
> it when a successful authentication happens. I think that should be
> explicitly said, rather than a blanket 'SHOULD NOT reset'.
> 

This was discussed in the WG. I don't think we should go back on that
decision wo clear consensus.

> 
> I would like to make 4.1.1.8, 4.1.1.9 a SHOULD, not a MUST
> 

Same answer there. Major change at this point should come with a WG
consensus.

> The way 4.1.1.10 is worded makes it impossible to reuse the 
> modifyTimestamp attribute normally present in LDAP directories, as 
> Kerberos implementations cannot force the directory not to update
> the timestamp on credential changes, so please drop the exclusion,
> I do not see what's the point anyways.
> 

So why isn't a separate timestamp an option?

> In 4.2, it is unclear what 'MUST facilitate, to the extent
> possible, an administrator's ability to place more restrictive
> access controls ...' will end up being interpreted. How do you
> measure if an implementation complies with this mandate ?
> 

Do you have a suggested modification to the text?

> I am not sure I understand 4.3.
> 
> 4.3.1.5 and 4.3.1.6 are not consistent with the rest of the
> document about how the date format is mandated. (Will need to be
> fixed to whatever we decide after discussion about date format I
> opened in a separate thread)

Can you suggest a modified text based on my suggested re-formulation
of the time/date format requirement in the other thread?

> 
> Also keyNotUsedBefore keyNotUsedAfter keyIsDisabled are not
> something normally associated to key attributes today generally
> they are associated to keysets, is there a MUST implied in these
> having to be available per key, and not per keyset ?
> 

A valid question. I'm not 100% sure this was discussed but I'm
also uncomfortable making the change wo a clear WG consensus to
change it.

> 
> I find the part on policy a bit hand-wavy, what is the point of 
> identifying specific, yet undefined, policies with OIDs if they
> are opaque in the end ?

Again this was discussed in the WG. Please go back and review the
threads on policy.

	Cheers Leif

---

From: Simo Sorce <[email-masked]>
Date: Sun, 03 Jun 2012 08:48:44 -0400

On Sun, 2012-06-03 at 12:23 +0200, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> RFC4517 or RFC3339".

That would probably work.

>  In practice the or doesn't result in interop issues

Indeed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

---

From: Simo Sorce <[email-masked]>
Date: Sun, 03 Jun 2012 08:57:23 -0400

> producing a count from that audit-trail is probably easy, right?!

Ok, I did re-read the introductory paragraph and there is space for
translation of schema models between this document and actual
implementations, so I guess this is possible.

> decision wo clear consensus.

Point is, I am trying to understand what that paragraph means. As is
written I can't see how to implement something that works and respects
the letter of the document, feel free to explain to me what I am reading
wrong.

> So why isn't a separate timestamp an option?

I guess it is.

> Do you have a suggested modification to the text?

Not really, it seem quite difficult to substantiate this desire.

> of the time/date format requirement in the other thread?

The text you proposed in the other mail would probably work fine.

> Again this was discussed in the WG. Please go back and review the

ok,
Simo.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Jun 2012 09:20:33 -0400

>>>>> "Simo" == Simo Sorce <[email-masked]> writes:

    >> decision wo clear consensus.

    Simo> Point is, I am trying to understand what that paragraph means. As is
    Simo> written I can't see how to implement something that works and respects
    Simo> the letter of the document, feel free to explain to me what I am reading
    Simo> wrong.

I'd like to ask the WG whether we want to support lockouts depending on
how many failed authentications there have been since last successful
authentication.

I cannot think of a way to implement that consistent with the current
text.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Greg Hudson <[email-masked]>
Date: Mon, 04 Jun 2012 15:20:03 -0400

> how many failed authentications there have been since last successful

MIT krb5 does this and Active Directory does this (I believe), so yes, I
think it's important to support that if we're going to be talking about
lockout counters in the information model.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Mon, 4 Jun 2012 14:24:50 -0500

> lockout counters in the information model.

But it's not exact.  At least not for AD and not for MIT with a db2 backend.

Nico

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Jun 2012 10:32:14 -0400

>>>>> "Nico" == Nico Williams <[email-masked]> writes:

    >> lockout counters in the information model.

    Nico> But it's not exact.  At least not for AD and not for MIT with a db2 backend.

Nico, I'm confused because I'd like to interpret your message in the
context of whether the information model should support lockouts based
on number of successful authentications, but I cannot understand how to
do so. You may be saying that it's OK because the current model supports
an in-exact form of this.
I don't think it does though.
I think  that the current model doesn't support this in any form.

Alternatively you may be saying that since the feature is in-exact in
existing implementations we should not support it.

Would you be willing to clarify what you are proposing with regard to
whether the information model needs to support this form of lockout?
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Nico Williams <[email-masked]>
Date: Tue, 5 Jun 2012 09:46:32 -0500

I'm saying that the text should not demand exact
N-strikes-you're-locked when implementations today cannot match that
and for good reasons.

Nico

---

From: Leif Johansson <[email-masked]>
Date: Tue, 05 Jun 2012 20:40:37 +0200

> I think  that the current model doesn't support this in any form.

I'd have to agree with this. The model only supports an counter that
is never reset. This would call for a counter that is reset on each
successful login.

Those are two different and non-conflicting requirements. As an
editor I'm happy to add the new attribute but that clearly implies
doing a new WGLC.

	Cheers Leif

---

From: "Henry B. Hotz" <[email-masked]>
Date: Tue, 5 Jun 2012 17:58:33 -0700

> how many failed authentications there have been since last successful

I, for one, have a generic expectation that that should be supported, however. . .

> I cannot think of a way to implement that consistent with the current

I am less than convinced that such behavior is necessarily efficiently implementable across multiple kdc's, or even "best".  

As a thought experiment, consider a proposal made by Howard Chu:  instead of a lockout, how about a slow-down?  The real purpose of the lockout is to make it uneconomic for a cracker to use the KDC as an oracle for a systematic search.  The existence of an ongoing cracking attempt does not mean the valid user no longer exists or no longer deserves service.  If you slow down responses to that username sufficiently, then the real user can still authenticate, but the cracker has still been thwarted.

I'm not making any specific recommendations, just providing a viewpoint.

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[email-masked], or [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Wed, 06 Jun 2012 09:00:37 -0400

OK, at this point, I think we have seen enough support for lockouts
based on number of failed auths since last successful auth that we need
to re-open that previous discussion as Simo requested. I'm hoping that
Simo and Leif can both or individually propose a solution for the WG to
consider. Given that we seem to want to solve this it's a fairly low bar
to accept the change.

Sam Hartman
Kerberos co-chair

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Jun 2012 09:58:07 +0200

On 06/06/2012 03:00 PM, Sam Hartman wrote:
> OK, at this point, I think we have seen enough support for
> lockouts based on number of failed auths since last successful auth
> that we need to re-open that previous discussion as Simo requested.
> I'm hoping that Simo and Leif can both or individually propose a
> solution for the WG to consider. Given that we seem to want to
> solve this it's a fairly low bar to accept the change.

I'm collecting some other post WGLC comments (mostly minor nits) and was
going to push out -13 (lucky 13??) with those included. I'll propose a
new attribute numberOfRecentFailedAuhnRequests (or something shorter...)
to represent the proposed semantic.

	Cheers Leif