Subject: RE: GSSAPI/AES draft

From: "Liqiang(Larry) Zhu" <[email-masked]>
Date: Thu, 21 Aug 2003 03:16:17 -0700

Sam Hartman wrote:
>> Do we want to make this draft stand on its own and define context
>>establishment tokens, or do we want it to simply be an adjunct to RFC
1964?

As for now, it is an adjunct to RFC 1964. We would like to hear from WG
to see if this should be changed to let it stand on its own.

Thanks. Larry

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Sam Hartman
Sent: Wednesday, August 20, 2003 6:35 AM
To: JK Jaganathan
Cc: [email-masked]
Subject: Re: GSSAPI/AES draft

In general, this draft looks good.  I wouldn't object if the working
group decided to take this draft as the basis for our GSSAPI
direction.

I consider the following issues to be minor, but since I noticed them
I thought I would bring them up.

I'm not convinced the current draft handles block cipher alignment in
the general case, but I believe I have personal mail discussing that
issue.

There is inconsistent text on backwards compatibility.  Section 3
seems to assert a requirement that the new token formats not be used
with older algorithms.  Section 7 seems to allow it but discourages
it.

I think I prefer the approach in section 7.  i would recommend that we
require implementations support the new token formats even for old
algorithms, so that for example a pure extensions implementation of
Kerberos need not implement the old token formats.  I would also be OK
with consistently forbidding use of new tokens with old algorithms.

Do we want to make this draft stand on its own and define context
establishment tokens, or do we want it to simply be an adjunct to RFC
1964?

--Sam

---

From: Sam Hartman <[email-masked]>
Date: Thu, 21 Aug 2003 12:45:18 -0400

>>>>> "Liqiang(Larry)" == Liqiang(Larry) Zhu <[email-masked]> writes:

    Liqiang(Larry)> Sam Hartman wrote:
    >>> Do we want to make this draft stand on its own and define
    >>> context establishment tokens, or do we want it to simply be an
    >>> adjunct to RFC
    Liqiang(Larry)> 1964?

    Liqiang(Larry)> As for now, it is an adjunct to RFC 1964. We would
    Liqiang(Larry)> like to hear from WG to see if this should be
    Liqiang(Larry)> changed to let it stand on its own.

I think my preference is for pulling in the context setup description
but *not* the old token formats.  I.E. you never need to look at RFC
1964 unless you implement DES.