Subject: RE: PKINIT -20 and AES

From: Medvinsky Alexander-MGI1174 <[email-masked]>
Date: Thu, 22 Jul 2004 16:41:46 -0700

Clarifications has a general requirement to support the AES256-CTS-HMAC-SHA1-96 etype, so maybe PKINIT draft could be reworded to say:

"All PKINIT implementations MUST support the following algorithms:

    - Reply key (or DH-derived key): see CLARIFICATIONS for required etypes."

Sasha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Medvinsky Alexander-MGI1174
Sent: Thursday, July 22, 2004 3:53 PM
To: 'Nicolas Williams'; [email-masked]
Subject: RE: PKINIT -20 and AES

PKINIT draft has this in section 3.1.1:

"All PKINIT implementations MUST support the following algorithms:

    - Reply key (or DH-derived key): AES256-CTS-HMAC-SHA1-96 etype."

Sasha.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Nicolas Williams
Sent: Thursday, July 22, 2004 2:53 PM
To: [email-masked]
Subject: PKINIT -20 and AES

Why should the PKINIT I-D mention any requirements for reply key enctype support when clarifications already does?

Nico
--

---

From: Ken Raeburn <[email-masked]>
Date: Thu, 22 Jul 2004 21:40:01 -0400

On Jul 22, 2004, at 19:41, Medvinsky Alexander-MGI1174 wrote:
> Clarifications has a general requirement to support the 
> AES256-CTS-HMAC-SHA1-96 etype, so maybe PKINIT draft could be reworded 
> to say:
>

Would it work to require support for whatever algorithms the Kerberos 
implementation supports?

Ken

---

From: Wyllys Ingersoll <[email-masked]>
Date: Fri, 23 Jul 2004 13:00:06 -0400

Ken Raeburn wrote:

>> AES256-CTS-HMAC-SHA1-96 etype, so maybe PKINIT draft could be 
>> reworded to say:
>>
I looked back at the email exchange we had about this in February and
it seems that the issue of AES 128 was raised after the doc had
already gone to the IESG and we didn't want to further delay the process,
so thats why it didn't get inserted.

So, since AES-128 is not mentioned explicitly in the clarifications doc,
I think that it *should* be called mentioned in PKINIT as a RECOMMENDED
etype for interoperability in section 3.1.1

-Wyllys

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 23 Jul 2004 12:03:54 -0500

> so thats why it didn't get inserted.

Hmmm, ok.  But still, there a list of SHOULDs in clarifications and it
seems like a mistake not to have AES-128 in there, a mistake that can be
easily corrected, methinks.

> etype for interoperability in section 3.1.1

Well, I'm arguing that PKINIT shouldn't mention symmetric key enctypes
requirements directly, but indirectly by reference to clarifications.

---

From: Sam Hartman <[email-masked]>
Date: Sat, 24 Jul 2004 11:54:23 -0400

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

    Nicolas> On Fri, Jul 23, 2004 at 01:00:06PM -0400, Wyllys
    Nicolas> Ingersoll wrote:
    >> I looked back at the email exchange we had about this in
    >> February and it seems that the issue of AES 128 was raised
    >> after the doc had already gone to the IESG and we didn't want
    >> to further delay the process, so thats why it didn't get
    >> inserted.

    Nicolas> Hmmm, ok.  But still, there a list of SHOULDs in
    Nicolas> clarifications and it seems like a mistake not to have
    Nicolas> AES-128 in there, 

Agreed.

    Nicolas> a mistake that can be easily corrected,
    Nicolas> methinks.

I have no objection to correcting the mistake provided that it doesn't
delay the process at all.  I don't know how to accomplish it without
another IESG round trip though.