Subject: [Ietf-krb-wg] Proposed change to RFC 6112: indicating support for anonymous

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Feb 2011 10:27:19 -0500

Folks, I'd like to propose a specific text change in order for us to
discover whether someone is a final implementation of RFC 6112.
This will allow MIT to discover which format it should use.

Take a look at http://www.rfc-editor.org/authors/rfc6112.txt                                                                  ; this is the auth48 copy of the RFC.

I propose

Section 4.1.1:

old:
   A KDC that supports anonymous PKINIT MUST indicate the support of
      PKINIT, according to Section 3.4 of [RFC4556].

new: A KDC that supports anonymous PKINIT MUST indicate the support of
   PKINIT, according to Section 3.4 of [RFC4556]. In addition, such a
   KDC MUST indicate support for anonymous PKINIT by including a
   padata element of padata-type PA_PKINIT_KX and empty padata-value
   when including PA-PK-AS-REQ in an error reply.

People may esthetically object to overloading the PA_PKINIT_KX padata item because
it's not strictly only for anonymous. It can be included for any DH
reply. My rationale is purely pragmatic. At this point in the process
it's more complicated if we need a new padata type. I also don't see
any harm in this use and would rather move forward quickly.

If we can get a couple of people to chime in and say they like this proposal then I'll ask Jeff to last call it and get Tim in the loop
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Feb 2011 17:51:56 -0500

>>>>> "Sam" == Sam Hartman <[email-masked]> writes:

    Sam> Folks, I'd like to propose a specific text change in order for
    Sam> us to discover whether someone is a final implementation of RFC
    Sam> 6112.  This will allow MIT to discover which format it should
    Sam> use.

    Sam> Take a look at http://www.rfc-editor.org/authors/rfc6112.txt ;
    Sam> this is the auth48 copy of the RFC.

    Sam> I propose

    Sam> Section 4.1.1:

    Sam> old: A KDC that supports anonymous PKINIT MUST indicate the
    Sam> support of PKINIT, according to Section 3.4 of [RFC4556].

    Sam> new: A KDC that supports anonymous PKINIT MUST indicate the
    Sam> support of PKINIT, according to Section 3.4 of [RFC4556]. In
    Sam> addition, such a KDC MUST indicate support for anonymous PKINIT
    Sam> by including a padata element of padata-type PA_PKINIT_KX and
    Sam> empty padata-value when including PA-PK-AS-REQ in an error
    Sam> reply.

Martin suggests that  if we are going to overload PA_PKINIT_KX in this
way, we should explain.
How an additional sentence:
When included in a KDC error, PA_PKINIT_KX indicates support for
anonymous PKINIT. As discussed in section 7, when included in an AS-REP,
PA_PKINIT_KX proves that the KDC and client both contributed to the
session key for any use of Diffie-Hellman key agreement with PKINIT.
_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 16 Feb 2011 18:46:13 -0500

>    when including PA-PK-AS-REQ in an error reply.

How does this help?

As I understand it, a new KDC can choose to accept both forms.  An existing 
client talking to an existing KDC will work or not; there is nothing we can 
do about it.

So, with your proposal, a new client can tell the difference between a new 
KDC and an old one, but not between an existing MIT-style KDC and an 
existing draft-12 KDC.  That means that a new client can interoperate with 
an existing MIT-style KDC, at the expense of _not_ interoperating with an 
existing draft-12 KDC.

Is that right?
Is it possible to find a way for a new client to be able to interoperate 
with both MIT-style and draft-12 KDC's?

-- Jeff

---

From: Sam Hartman <[email-masked]>
Date: Wed, 16 Feb 2011 20:27:31 -0500

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

    Jeffrey> As I understand it, a new KDC can choose to accept both
    Jeffrey> forms.  An existing client talking to an existing KDC will
    Jeffrey> work or not; there is nothing we can do about it.

    Jeffrey> So, with your proposal, a new client can tell the
    Jeffrey> difference between a new KDC and an old one, but not
    Jeffrey> between an existing MIT-style KDC and an existing draft-12
    Jeffrey> KDC.  

I'm not aware of any draft-12 KDCs, so I'm not really sure I care
whether a client can detect one:-).
Heimdal is not draft 12; it is something earlier possibly 9, at least as
far as I know.
I'm not aware of other shipping implementations.

my goal is to find a way for MIT to continue to work with MIT while
providing a transition mechanism to work with RFC 6112.
I don't care whether MIT ends up working with draft-12 in significant
part because I don't believe draft 12 exists.

    Jeffrey> That means that a new client can interoperate with an
    Jeffrey> existing MIT-style KDC, at the expense of _not_
    Jeffrey> interoperating with an existing draft-12 KDC.

    Jeffrey> Is that right?  Is it possible to find a way for a new
    Jeffrey> client to be able to interoperate with both MIT-style and
    Jeffrey> draft-12 KDC's?

I haven't seen anything particularly obvious that is attractive.  I've
rejected sending multiple requests because I believe the option I
propose is better.  You could try including multiple PK-AS-REQs; I'm not
sure whethre that works.
I would not want to rely on that.

---

From: Greg Hudson <[email-masked]>
Date: Thu, 17 Feb 2011 18:22:01 -0500

> This will allow MIT to discover which format it should use.

I think this is a reasonable way around the interoperability issue with
minimal impact on the elegance of the standard, so I support this.

---

From: Larry Zhu <[email-masked]>
Date: Sat, 19 Feb 2011 01:01:22 +0000

Ditto. I also support this proposal.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Hudson
Sent: Thursday, February 17, 2011 3:22 PM
To: Sam Hartman
Cc: [email-masked]
Subject: Re: [Ietf-krb-wg] Proposed change to RFC 6112: indicating support for anonymous

> This will allow MIT to discover which format it should use.

I think this is a reasonable way around the interoperability issue with minimal impact on the elegance of the standard, so I support this.