[
https://issues.apache.org/jira/browse/DIRKRB-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909726#action_12909726
]
Richard Feezel commented on DIRKRB-27:
--------------------------------------
I am attaching a proposed patch for Crc32Checksum.java. I have run the tests,
shown as comments at the end of the file, and the values are correct. With
this patch applied I have run "mvn test -Dintegration" without error but I do
not believe that this code is actually tested by any of the JUnit tests. I'm
not sure how to go about created a test case that proves interoperability with
independent Kerberos clients. It seems to me that we need a set of tests which
exercise Kerberos authentication in all the supported cryptographic modes,
perhaps by using the Java javax.security.auth.login.LoginContext Kerberos
login. I'm not yet familiar enough with it, however, to know how to configure
the server and the client classes to accomplish this.
> [kerberos]org.apache.directory.server.kerberos.shared.crypto.encryption.DesCbcCrcEncryption
> shall not use java.util.zip.CRC32 to generate CRC32 checksum
> --------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DIRKRB-27
> URL: https://issues.apache.org/jira/browse/DIRKRB-27
> Project: Directory Kerberos
> Issue Type: Bug
> Affects Versions: 2.0.0
> Reporter: Leo Li
> Fix For: 2.0.0
>
>
> As in RFC3961 [Page 17]:
> 6.1.3. CRC-32 Checksum
> This CRC-32 checksum calculates a checksum based on a cyclic
> redundancy check as described in ISO 3309 [CRC] but modified as
> described below.
> ...
> The CRC-32 checksum used in the des-cbc-crc encryption mode is
> identical to the 32-bit FCS described in ISO 3309 with two
> exceptions: The sum with the all-ones polynomial times x**k is
> omitted, and the final remainder is not ones-complemented. ISO 3309
> describes the FCS in terms of bits, whereas this document describes
> the Kerberos protocol in terms of octets. To clarify the ISO 3309
> definition for the purpose of computing the CRC-32 in the des-cbc-crc
> encryption mode, the ordering of bits in each octet shall be assumed
> to be LSB first. Given this assumed ordering of bits within an
> octet, the mapping of bits to polynomial coefficients shall be
> identical to that specified in ISO 3309.
> And RFC 3961 also gives test data in its Appendix A.5:
> RFC 3961 Encryption and Checksum Specifications February 2005
> internally for such a number is irrelevant; the octet sequence
> generated is what is important.)
> mod-crc-32("foo") = 33 bc 32 73
> mod-crc-32("test0123456789") = d6 88 3e b8
> mod-crc-32("MASSACHVSETTS INSTITVTE OF TECHNOLOGY") = f7 80 41 e3
> mod-crc-32(8000) = 4b 98 83 3b
> mod-crc-32(0008) = 32 88 db 0e
> mod-crc-32(0080) = 20 83 b8 ed
> mod-crc-32(80) = 20 83 b8 ed
> mod-crc-32(80000000) = 3b b6 59 ed
> mod-crc-32(00000001) = 96 30 07 77
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
