Subject: RE: GSSAPI/AES draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Mon, 18 Aug 2003 10:54:50 -0700

Nicolas Williams wrote:

>> One thing I note is that this draft does NOT require recalling
kcrypto
>> to add AEAD modes.  I would appreciate a clarification as to whether
you
>> still think that kcrypto needs recalling.  As far as I can tell,
neither
>> Sam, nor Ken (and certainly not I) support recalling kcrypto if
there's
>> any way to get a Kerberos V GSS-API that is generic to kcrypto
enctypes
>> without recalling kcrypto - something your draft seems to aim for and
>> achieve.

IIUC, it is always considered better to settle with some slight
inefficiency rather than recalling kcrypto to add AEAD at this stage.
The recall message was sent under the impression that we should "raise
an objection" and bring the issues to the attention of the WG. 

To clarify, AEAD is NOT required by our GSSAPI/AES draft.

The wording that I sent out for the recall comment created false
impression that it was a consensus to recall, rather than an objection
or that sort, among all the parties involved in the off-list discussions
and it was not intended that way. It was mostly Ken and I who wanted to
raise the objection.

Clarifications have also been sent to Douglas off-line (thanks to Sam).

Douglas, let me know if you want me to resend this message to the last
call comment message.

Thanks. Larry

---

From: Ken Raeburn <[email-masked]>
Date: Mon, 18 Aug 2003 15:36:20 -0400

> and it was not intended that way. It was mostly Ken and I who wanted to

To clarify, since my position is kind of fuzzy and on-the-fence:

I won't support having the working group withdraw the crypto draft to
add AEAD.  I also won't oppose it very strongly.

I won't push at the IETF last call for having AEAD added, but I won't
oppose it, and I'll support an argument that it isn't hard.

I proposed adding AEAD some time ago.  I think it'll provide useful
optimizations in some protocols, like the GSSAPI protocol changes
we've been discussing off-list, and perhaps even Kerberos extensions.
(Does the KRB-PRIV sequence number really need to be encrypted?  I
haven't really looked into changing Kerberos extensions, and I
understand and expect some of the "eww, let's not think about that"
type of reaction.)  I look at it as a qualitative improvement, similar
to but not quite on the order of using "encrypt with integrity
protection" instead of having application protocols use "encrypt" and
"checksum" and roll their own integrity protection for encrypted data.

The response from the others working with me on the document basically
amounted to "might be nice, but it's too late for a non-critical
change of that sort".  I was outvoted, so I dropped it.  And I think
having the working group, or the authors, ask the IESG to send back
the document now, after submission, would look pretty poor.

I do believe AEAD is easy to add.  One of the "big" issues, as Sam
pointed out to me, is the decision of whether the associated data
should be added to the front or end of the encrypted data being
checksummed.  And I don't think that's all that big.

As I recall, Larry was not very actively involved at the time of the
working group last call.  So, I suggested that if he thinks it's
important, he could raise the objection in the IETF last call (not WG
last call, which is over), since he effectively wasn't involved in the
working group last call, and we would see what the reaction from the
IETF at large is.

Ken