Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt

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

Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]

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].\
> 
> 

Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt

On Sun, 2012-06-03 at 12:23 +0200, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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

Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]

On Sun, 2012-06-03 at 12:30 +0200, Leif Johansson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 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

Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]

>>>>> "Simo" == Simo Sorce <simo <at> redhat.com> writes:

    >> > 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.

    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
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

[Tobias Gondrom] AppsDir review of draft-ietf-krb-wg-kdc-model

From: Tobias Gondrom <tobias.gondrom <at> gondrom.org>
Subject: AppsDir review of draft-ietf-krb-wg-kdc-model
Date: 2012-06-04 14:41:58 GMT

Hello all,

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see  
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document shepherd 
or AD before posting a new version of the draft.

Document: draft-ietf-krb-wg-kdc-model-12
Title:  An information model for Kerberos version 5
Reviewer: Tobias Gondrom
Review Date: June-4 2012

Summary: This draft is almost ready for publication.

One basic question:
This draft aims for Standards Track, yet as far as I understood, it is 
not required that the used field names are in fact the same across 
different implementations but only that name-mappings exist. The ID also 
uses a modified RFC2119 language definition to allow that.
I would like to ask, whether possibly Informational Status would be more 
appropriate for this draft?

Minor issues:
- RFC2119 language in
4.1.1.2 and 4.1.1.3
s/MUST not/MUST NOT

- 4.4.2 sub-sections for policy:
in several sub-sections: IANA: still need to set the values and spaces 
for the OIDs
is marked for IANA in IANA considerations section 7, but why have the 
specific values not been put in the ID?

- section 5.1 and 5.2 and section 6
reference to expired ID: draft-ietf-krb-wg-kerberos-set-passwd
Am not so happy that the draft refers to drafts (which is expired in 
2009) for set/change password protocol. I lack the knowledge of the 
context of why the WG chose to expire this ID at the time and why it is 
now used as a reference here. Is there another resource you could refer 
to instead? Do you want to revive the set-passwd ID?
Especially as the reference is part of a mandatory part ("SHALL only") 
of the security considerations 6, I am having a hard time to see this as 
only "informational" and how to refer here to an expired draft....

Best regards, Tobias

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Re: AppsDir review of draft-ietf-krb-wg-kdc-model

On Mon, 2012-06-04 at 17:38 +0100, Tobias Gondrom wrote:
> On 04/06/12 17:02, Sam Hartman wrote:
> >>>>>> "Tobias" == Tobias Gondrom<tobias.gondrom <at> gondrom.org>  writes:
> >
> >      Tobias>  One basic question:
> >      Tobias>  This draft aims for Standards Track, yet as far as I understood, it is
> >      Tobias>  not required that the used field names are in fact the same across
> >      Tobias>  different implementations but only that name-mappings exist. The ID
> >      Tobias>  also uses a modified RFC2119 language definition to allow that.
> >      Tobias>  I would like to ask, whether possibly Informational Status would be
> >      Tobias>  more appropriate for this draft?
> >
> > My concern is that this does specify mandatory behavior of
> > implementations and that it's likely that a schema would want to
> > normatively refer to this document for semantics of attributes.
> Does it have to be Standards Track for that purpose?
> (note: I don't have a strong opinion on this, just feel uneasy with 
> using the watered down 2119 definitions in the draft and the 
> name-mapping, and then to go for Standards Track....)

The present document is a data model.  Its "implementations" are schemas
or the like; that is, other documents.  The RFC2119 language is in fact
not "watered down"; rather, it is the case that, for example, we may
REQUIRE a schema to include a particular field without requiring that
every implementation of that schema support that field.

The particular point you raised about names is not, in fact a problem.
Read with the understanding that an implementation of this document is a
schema or the like and _not_ a piece of software, the language in the
third paragraph of section 1 means that an LDAP schema or XML DTD based
on this document would not be required to use the same field names as
are used in the model, provided the document defining such a schema or
DTD makes clear which of its fields correspond to which fields in the
data model.

Yes, this document wants to be standards track.  It is intended to
define the semantics of data items used by the KDC and made visible in
one or more standards track management protocols.

> On a personal note: Would still be curious about the intentions for 
> draft-ietf-krb-wg-kerberos-set-passwd?

It is an item on our current charter, to which we intend eventually to
return.  Both the author and the working group have been concentrating
on other work for some time.

-- Jeff

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]

On 06/04/2012 09:20 AM, Sam Hartman wrote:
> 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.

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
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]

On Mon, Jun 4, 2012 at 2:20 PM, Greg Hudson <ghudson <at> mit.edu> wrote:
> On 06/04/2012 09:20 AM, Sam Hartman wrote:
>> 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.
>
> 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.

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

Nico
--
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

Re: Add. comments on Kdc model, WAS[Re: I-D Action: draft-ietf-krb-wg-kdc-model-12.txt]

>>>>> "Nico" == Nico Williams <nico <at> cryptonector.com> writes:

    Nico> On Mon, Jun 4, 2012 at 2:20 PM, Greg Hudson <ghudson <at> mit.edu> wrote:
    >> On 06/04/2012 09:20 AM, Sam Hartman wrote:
    >>> 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.
    >> 
    >> 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.

    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
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg