Subject: [Ietf-krb-wg] Setting up an IANA registry for pre-authentication methods in the preauth framework

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jan 2009 13:20:13 -0500

I'm wondering whether we want to set up a padata IANA registry in the
pre-authentication framework document.  If we can get significant
support for doing so in the next couple of days and general agreement
on the registration requirements I'll do the necessary work.
Otherwise I suggest we don't do it.

Proposed registration requirements:

Expert review for pre-authentication mechanisms designed to
authenticate users, KDCs, or establish the reply key.  The expert
first determines that the purpose of the method is to authenticate
clients, KDCs, or to establish the reply key.  If so, expert review is
appropriate.  The expert evaluates the security and interoperability
of the specification.

IETF review is required if the expert believes that the
pre-authentication method is broader than these three areas.
Pre-authentication methods that change the Kerberos state machine or
otherwise make significant changes to the Kerberos protocol should be
standards track RFCs.  A concern that a particular method needs to be
a standards track RFC may be raised as an objection during IETF
review.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 26 Jan 2009 13:39:38 -0500

> on the registration requirements I'll do the necessary work.

I think we should set up a registry, whether or not it's done via the  
preauth framework document.  Your proposed requirements sound fine to  
me.

Ken

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jan 2009 14:15:12 -0500

> a standards track RFC may be raised as an objection during IETF

What about PA-DATA types that are not related to a preauth method?

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jan 2009 14:24:30 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> --On Monday, January 26, 2009 01:20:13 PM -0500 Sam
    Jeffrey> Hartman
    Jeffrey> <[email-masked]> wrote:

    >> authenticate users, KDCs, or establish the reply key.  The
    >> expert first determines that the purpose of the method is to
    >> authenticate clients, KDCs, or to establish the reply key.  If
    >> so, expert review is appropriate.  The expert evaluates the
    >> security and interoperability of the specification.
    >> 
    >> Pre-authentication methods that change the Kerberos state
    >> machine or otherwise make significant changes to the Kerberos
    >> protocol should be standards track RFCs.  A concern that a
    >> particular method needs to be a standards track RFC may be
    >> raised as an objection during IETF review.

    Jeffrey> What about PA-DATA types that are not related to a
    Jeffrey> preauth method?
The structure is called method-data.  I think all pa-data types form a
method.  So, basically anything that is not user auth, kdc auth or
reply key and that uses pa-data would require IETF review.  We hope
that the IETF would bounce anything big up to standards action.  If
you don't think that is clear from the above, suggest clarification.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jan 2009 14:56:05 -0500

> you don't think that is clear from the above, suggest clarification.

I think you misunderstand.  I'm not worried about big things not getting 
enough review; I'm worried about being too restrictive of small things. 
PA-DATA is the one and only typed hole we have in KDC requests.  Just 
because this hole is named "PA-DATA" or has a structure called 
"method-data" does not mean that all uses of it will be for preauth 
methods.  I believe this is something we accepted long ago, when discussing 
the question of where such holes were missing in the protocol.

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jan 2009 15:07:46 -0500

>>>>> "Jeffrey" == Jeffrey Hutzelman <[email-masked]> writes:

    Jeffrey> I think you misunderstand.  I'm not worried about big
    Jeffrey> things not getting enough review; I'm worried about being
    Jeffrey> too restrictive of small things. PA-DATA is the one and
    Jeffrey> only typed hole we have in KDC requests.  Just because
    Jeffrey> this hole is named "PA-DATA" or has a structure called
    Jeffrey> "method-data" does not mean that all uses of it will be
    Jeffrey> for preauth methods.  I believe this is something we
    Jeffrey> accepted long ago, when discussing the question of where
    Jeffrey> such holes were missing in the protocol.

Ah.  I agree it is the typed hole to use, but I basically believe that
any use of it for things other than pre-authentication are big enough
to need IETF review.  If we find classes that are fairly small, then
we can move those over to expert review in the future.

*sigh* I was hoping that we could agree on registration requirements.
I think though that unless others pop up relatively soon, we won't get
done soon enough that I could put in the work to do this now.

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 26 Jan 2009 15:58:14 -0500

> we can move those over to expert review in the future.

OK, I suppose that's reasonable.  Looking at the list of PA-DATA numbers 
that have been assigned so far, almost all of them either fit into one of 
the cases you listed previously or are things for which I'd have wanted 
IETF review or even a standards track document.  So I guess we can stick 
with what you describe unless/until it proves unworkable.

However, the numbers for PA-DATA and typed error data items are currently 
drawn from the same namespace.  We probably need to provide some guidance 
in this area, either in the form of defining requirements for registering 
typed error data items or of splitting the namespaces (is that even 
workable?).

> done soon enough that I could put in the work to do this now.

I too would like to see others chime in fairly soon, though to be fair, 
it's only been three hours since your post...

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Mon, 26 Jan 2009 16:11:38 -0500

>> believe that any use of it for things other than
    >> pre-authentication are big enough to need IETF review.  If we
    >> find classes that are fairly small, then we can move those over
    >> to expert review in the future.

    Jeffrey> OK, I suppose that's reasonable.  Looking at the list of
    Jeffrey> PA-DATA numbers that have been assigned so far, almost
    Jeffrey> all of them either fit into one of the cases you listed
    Jeffrey> previously or are things for which I'd have wanted IETF
    Jeffrey> review or even a standards track document.  So I guess we
    Jeffrey> can stick with what you describe unless/until it proves
    Jeffrey> unworkable.

I'd be happy to add "controlling what kdc-issued authorization data
should be included" to the expert review list.

    Jeffrey> However, the numbers for PA-DATA and typed error data
    Jeffrey> items are currently drawn from the same namespace.  We
    Jeffrey> probably need to provide some guidance in this area,
    Jeffrey> either in the form of defining requirements for
    Jeffrey> registering typed error data items or of splitting the
    Jeffrey> namespaces (is that even workable?).

If we can decide to keep these from the same name space, we can remove
some complexity.  The padata spec wants to say that MethodData is
always used in errors and has some complexity for handling TypedData .  

I propose that we just treat them as the same, understanding that the
sequence will have somewhat different encoding depending on what type
is used, but that they are both typed holes with the same (lack of)
semantics.

So, draft-ietf-krb-wg-preauth-framework-09 will lose PA_FX_TYPED_DATA.

Does that work for people
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg