headers
Love Hörnquist Åstrand | 1 May 2009 05:37
Picon
Favicon

Re: CF2 test vectors for DES and 3DES


30 apr 2009 kl. 13:31 skrev Sam Hartman:

> I suspec Heimdal does the same thing as MIT here because we seem to
> interoperate for PKINIT and this issue comes up there too.

I don't think most people use DES with PK-INIT.

In heimdal DES3 does what you describe (uses 3 * 8), DES doesn't (uses  
8 bytes).

Love

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Permalink | Reply | 2 comments |
headers
Love Hörnquist Åstrand | 1 May 2009 05:38
Picon
Picon
Favicon

Re: CF2 test vectors for DES and 3DES


30 apr 2009 kl. 20:37 skrev Love Hörnquist Åstrand:

>
> 30 apr 2009 kl. 13:31 skrev Sam Hartman:
>
>> I suspec Heimdal does the same thing as MIT here because we seem to
>> interoperate for PKINIT and this issue comes up there too.
>
> I don't think most people use DES with PK-INIT.
>
> In heimdal DES3 does what you describe (uses 3 * 8), DES doesn't  
> (uses 8 bytes).

3 * 7 bytes for DES3

Love

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Permalink | Reply | 0 comments |
headers
Sam Hartman | 1 May 2009 10:43
Picon
Favicon

Re: CF2 test vectors for DES and 3DES

>>>>> "Love" == Love Hörnquist Åstrand <lha <at> apple.com> writes:

    Love> 30 apr 2009 kl. 13:31 skrev Sam Hartman:

    >> I suspec Heimdal does the same thing as MIT here because we
    >> seem to interoperate for PKINIT and this issue comes up there
    >> too.

    Love> I don't think most people use DES with PK-INIT.

    Love> In heimdal DES3 does what you describe (uses 3 * 8), DES
    Love> doesn't (uses 8 bytes).

I thought we had tested DES for pkinit--guess not.

So, if I'm understanding this correctly, unless one of us does
something special,then we will not interoperate for CF2 for DES
enctypes because of this issue, right?  If so, sounds like MIT should
be the one to change because we're the one not following the spec.

--Sam
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Permalink | Reply | 0 comments |
headers
Jeffrey Hutzelman | 1 May 2009 17:51
Picon
Favicon

Re: Des and 3DES PRF: 16 or 8 bytes

--On Thursday, April 30, 2009 04:25:09 PM -0400 Sam Hartman 
<hartmans-ietf <at> mit.edu> wrote:

>
>
> Folks, it was not clear in the discussion at IETf 74 whether we wanted
> to have the RFC 3961 PRF for 3DES change to be an 8-byte output or
> not.  Currently if you assume that the text says to truncate to the
> nearest multiple of m, then the 3DES PRF should be 16 bytes.

Hrm.  This goes directly back to the discussion of whether we want to 
truncate to the nearest multiple of the cipher block size, or to the block 
size itself.  I believe we've rather thoroughly had the discussion of the 
relative security merits of the two approaches, but we were rather focused 
on AES.

Now you are bringing up an interoperability issue relating to 3DES, which 
happens to be the only _other_ standardized simplified-profile CBC-mode 
enctype for which "truncate the output of H to the nearest multiple of m" 
does not mean the same thing as "truncate the output of H to c".  Of 
course, AFAIK it is also the only other standardized simplified-profile 
CBC-mode enctype, period.

I believe we have already come to the conclusion that "truncate to the 
nearest multiple of m" is the only reasonable interpretation of what 3961 
says, and so changing AES will involve updating 3961 and/or 3962.  Provided 
that we are satisfied that the 3961 behavior for 3DES is acceptable, or 
that the interop considerations are more important, I see no reason we 
cannot treat 3DES specially at that time, retaining the existing. 
truncate-to-128-bits behavior.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tom Yu | 1 May 2009 23:57
Picon
Favicon

Re: CF2 test vectors for DES and 3DES

Sam Hartman <hartmans-ietf <at> MIT.EDU> writes:

> Folks, there seems to be yet another inconsistency between RFC 3961
> and MIT regarding DES and presumably 3DES random2key operations.
>
> MIT assumes that DES random bit strings are 7 byte strings that are
> expanded with parity bits.  The RFC 3961 spec assumes that you take an
> eight byte string and do parity fix-up.

Actually, spec assumes both.  RFC 3961 says des-cbc-md5 uses
des_random_to_key, but des-cbc-md4 and des-cbc-crc use
copy-8-bytes-and-fix-parity.  It does say that the key generation seed
length is 8 bytes for all three, which is inconsistent with the use of
des_random_to_key (which takes 56 bits as input).  I suspect a
copy-and-paste error.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Permalink | Reply | 2 comments |
headers
Sam Hartman | 4 May 2009 21:22
Picon
Favicon

Re: CF2 test vectors for DES and 3DES

>>>>> "Tom" == Tom Yu <tlyu <at> MIT.EDU> writes:

    Tom> Sam Hartman <hartmans-ietf <at> MIT.EDU> writes:
    >> Folks, there seems to be yet another inconsistency between RFC
    >> 3961 and MIT regarding DES and presumably 3DES random2key
    >> operations.
    >> 
    >> MIT assumes that DES random bit strings are 7 byte strings that
    >> are expanded with parity bits.  The RFC 3961 spec assumes that
    >> you take an eight byte string and do parity fix-up.

    Tom> Actually, spec assumes both.  RFC 3961 says des-cbc-md5 uses
    Tom> des_random_to_key, but des-cbc-md4 and des-cbc-crc use
    Tom> copy-8-bytes-and-fix-parity.  It does say that the key
    Tom> generation seed length is 8 bytes for all three, which is
    Tom> inconsistent with the use of des_random_to_key (which takes
    Tom> 56 bits as input).  I suspect a copy-and-paste error.

OK, but the MIT code is still inconsistent with the spec.
We seem to do the same for all the DES enctypes.
_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg
Permalink | Reply | 1 comment |
headers
Tom Yu | 5 May 2009 00:26
Picon
Favicon

Re: CF2 test vectors for DES and 3DES

Sam Hartman <hartmans-ietf <at> MIT.EDU> writes:

>>>>>> "Tom" == Tom Yu <tlyu <at> MIT.EDU> writes:
>
>     Tom> Sam Hartman <hartmans-ietf <at> MIT.EDU> writes:
>     >> Folks, there seems to be yet another inconsistency between RFC
>     >> 3961 and MIT regarding DES and presumably 3DES random2key
>     >> operations.
>     >> 
>     >> MIT assumes that DES random bit strings are 7 byte strings that
>     >> are expanded with parity bits.  The RFC 3961 spec assumes that
>     >> you take an eight byte string and do parity fix-up.
>
>     Tom> Actually, spec assumes both.  RFC 3961 says des-cbc-md5 uses
>     Tom> des_random_to_key, but des-cbc-md4 and des-cbc-crc use
>     Tom> copy-8-bytes-and-fix-parity.  It does say that the key
>     Tom> generation seed length is 8 bytes for all three, which is
>     Tom> inconsistent with the use of des_random_to_key (which takes
>     Tom> 56 bits as input).  I suspect a copy-and-paste error.
>
> OK, but the MIT code is still inconsistent with the spec.
> We seem to do the same for all the DES enctypes.

RFC 3961 section 6.2:

   For generation of a key from a random bitstring, we start with a 56-
   bit string and, as with the string-to-key operation above, insert
   parity bits.  If the result is a weak or semi-weak key, we modify it
   by eXclusive-OR with the constant 0x00000000000000F0:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sam Hartman | 15 May 2009 01:46
Picon
Favicon

Re: fast and patypes in KRB-ERROR


[I think these points need to be considered in a broader context than just the MIT implementation.
I think I've included enough context.]

>>>>> "Srinivas" == Srinivas Cheruku <Srinivas.Cheruku <at> CyberSafe.com> writes:

    Srinivas> 2.  PA-FX-COOKIE (not sure why this is required ??
    Srinivas> anyway, I think MIT uses some dummy cookie)

Per discussion on the ietf-krb-wg list, a KDC confirming to the
pre-auth framework should include a cookie whenever it wants to
continue a conversation.  This should becomes a must if FAST is being
used.  I *think* that's in the current draft, but it is definitely in
my working copy.  Larry and I had some internal slowness; I'll be
publishing a new version quite shortly.

    Srinivas> I think it might be good to include
    Srinivas> PA-ENCRYPTED-CHALLENGE also when user principal requires
    Srinivas> pre-authentication.

    Srinivas> This would means that fast enabled kinit can do the
    Srinivas> following:

    Srinivas> 1.  kinit can send a non-fast request to KDC

    Srinivas> 2.  KDC replies with KRB-ERROR containing the above
    Srinivas> pa-types along with PA-ENCRYPTED-CHALLENGE (for user
    Srinivas> principals having pre-auth required set)

    Srinivas> 3.  kinit can check for PA-FX-FAST and
(Continue reading)

Permalink | Reply | 0 comments |
headers
Srinivas Cheruku | 15 May 2009 06:08
Picon

Re: fast and patypes in KRB-ERROR


    Srinivas> 2.  PA-FX-COOKIE (not sure why this is required ??
    Srinivas> anyway, I think MIT uses some dummy cookie)

Per discussion on the ietf-krb-wg list, a KDC confirming to the
pre-auth framework should include a cookie whenever it wants to
continue a conversation.  This should becomes a must if FAST is being
used. 

[Srinivas Cheruku] Yes, I understand that cookie is a must when FAST is used
to continue conversation. But why should it be included in a non-fast
initial request to KDC? Does this mean that FAST enabled KDC sends the
cookie always irrespective of the request uses FAST or not? For me, as the
request doesn't use FAST, there is no need of any cookie. 

 I *think* that's in the current draft, but it is definitely in
my working copy.  Larry and I had some internal slowness; I'll be
publishing a new version quite shortly.

[Srinivas Cheruku] ok

    Srinivas> I think it might be good to include
    Srinivas> PA-ENCRYPTED-CHALLENGE also when user principal requires
    Srinivas> pre-authentication.

    Srinivas> This would means that fast enabled kinit can do the
    Srinivas> following:

    Srinivas> 1.  kinit can send a non-fast request to KDC
(Continue reading)

Permalink | Reply | 0 comments |
headers
Srinivas Cheruku | 15 May 2009 09:01
Picon

Re: fast and patypes in KRB-ERROR

Sam wrote:...
>Probably this is more of an IETF issue than an MIT issue.  My concern
>about doing this is that the negotiation of which fast factors are
>supported would be unprotected.

[Srinivas Cheruku] I was thinking on this more. 
What affect would it have if the negotiation of fast factors is not
protected? 
When non-fast request is sent to KDC, it returns KRB-ERROR e-data containing
PA-FX-FAST. This is also not protected PA-FX-FAST can also be deleted from
initial unprotected error. If this happens, the client would send non-fast
request containing enc-timestamp instead of generating a fast request. It
depends on the KDC policy to allow non-fast requests or not.

If we take the case of adding PA-ENCRYPTED-CHALLENGE or PA-OTP-CHALLENGE
along with PA-FX-FAST to unprotected error, then if these are deleted in
transit, then client maynot send OTP or ENC-CHALLENGE, but if the KDC is
configured so that the client requires these, then it won't generate the
ticket and would again asks for the same.

So, where do we see a potential risk of sending PA-ENCRYPTED-CHALLENGE or
PA-OTP-CHALLENGE along with PA-FX-FAST in unprotected error. Am I
overlooking something?

Thanks,
Srini

_______________________________________________
ietf-krb-wg mailing list
ietf-krb-wg <at> lists.anl.gov
(Continue reading)

Permalink | Reply | 0 comments |

Gmane