[11830] in Kerberos-V5-bugs
Re: [krbdev.mit.edu #6835] Re: accept_sec_context RFC4121 support bug
daemon@ATHENA.MIT.EDU (Derrick Brashear via RT)
Tue Dec 7 18:35:12 2010
Mail-followup-to: rt@krbdev.mit.edu
mail-copies-to: never
From: "Derrick Brashear via RT" <rt-comment@krbdev.MIT.EDU>
In-Reply-To: <rt-6835@krbdev.mit.edu>
Message-ID: <rt-6835-33595.7.1408141456957@krbdev.mit.edu>
To: "'AdminCc of krbdev.mit.edu Ticket #6835'":;"'AdminCc of krbdev.mit.edu Ticket #6835'":;@MIT.EDU
Date: Tue, 7 Dec 2010 18:35:09 -0500 (EST)
Reply-To: rt-comment@krbdev.MIT.EDU
Content-Type: multipart/mixed; boundary="===============0201737974=="
Errors-To: krb5-bugs-bounces@mit.edu
--===============0201737974==
On Tue, Dec 7, 2010 at 5:15 PM, Tom Yu via RT <rt-comment@krbdev.mit.edu> wrote:
> "Derrick Brashear via RT" <rt-comment@krbdev.mit.edu> writes:
>
>> Ah. You may disregard this, though the code should perhaps be
>> commented. RFC 4757 in defining rc4-hmac-exp explicitly
>> codifies the old token format, while not referring to RFC 4121.
>
> What should the comment say? Should it mention that RFC 4121
> accidentally omitted rc4-hmac-exp from the list of "not-newer"?
That would be my suggestion. I'd be less worried if there hadn't been deviances
from what is specified in versions of both MIT Kerberos and Heimdal.
> I think there would need to be comments both in accept_sec_context.c
> and util_crypt.c, because some of the RFC 4121 vs RFC 1964 selection
> logic moved to util_crypt.c.
That seems reasonable.
--
Derrick
--===============0201737974==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
--===============0201737974==--
