Encryption and Checksum Specifications for Kerberos 5
draft-ietf-krb-wg-crypto-07

[Ballot discuss]
This is a "discuss" Discuss -

  This document does NOT indicate which
  mechanisms may be considered "required to implement".

Since draft-ietf-krb-wg-kerberos-clarifications also does not
specify which mechanisms are required to implement, should
this document be asked to do so?  It has some strong advice, so
it seems that it would not be stretching so far

Russ responds on 21 Jan:

The requirements are a matter for the Kerberos protocol specs.
The document is nearly complete, and the IESG should see it soon.

So I clear my Discuss.
.

[Ballot discuss]
This is a fairly weak discuss, but...


The IANA Considerations could be more  clear.

>    Two registries for numeric values should be created: Kerberos
>    Encryption Type Numbers and Kerberos Checksum Type Numbers.  These
>    are signed 32-bit values in twos-complement form.  Positive values up
>    to 2**31-1 inclusive should be assigned only for algorithms specified
>    in accordance with this specification for use with Kerberos or
>    related protocols.  Negative values through -2**31 are for private
>    use; local and experimental algorithms should use these values.  Zero
>    is reserved and may not be assigned.

Why not use decimal numbers? For IANA (and web readers)
twos-complement is hard to understand. I would understand the need for
this if there was backwards compatability issues with on-the-wire
stuff, but can't the numbers be described independent of encoding? (I
can't recall right off a single IANA registry dealing with two's
complement values...)

>    Specifications in Informational RFCs may be assigned values after
>    Expert Review.  A non-IETF specification may be assigned values by

What about experimental RFCs? Better:

s/informational/non-standards track/

>    Draft IETF specifications should not include values for encryption
>    and checksum type numbers.  Instead, they should indicate that values

s/Draft IETF ../ Internet-Drafts / or some such

>    Smaller encryption type values, which encode to smaller octet strings
>    under ASN.1, should be used for IETF standards-track mechanisms, and
>    much higher values (hex 0x1000000 and above) for other mechanisms.
>    No other guidance into allocation order is given.

Can this be made more simple for IANA?

[Ballot comment]
The IMPLEMENTATION NOTE under the definition of initial cipher
state talks about "This new specification"  preventing applications from
setting the DES CBC initial cipher state themselves.  It's hard to tell if the
author means the present document, which doesn't specify processing
to that level, or kerberos-clarifications, which also doesn't seem to
do so.  If the author wants to use the present spec to direct new rules
for handling algorithms, that seems fine, but the language needs to
be more directive.

This spec doesn't have draft-ietf-krb-wg-kerberos-clarifications in its
references, unless I've missed something.

[Ballot discuss]
This is a "discuss" Discuss -

  This document does NOT indicate which
  mechanisms may be considered "required to implement".

Since draft-ietf-krb-wg-kerberos-clarifications also does not
specify which mechanisms are required to implement, should
this document be asked to do so?  It has some strong advice, so
it seems that it would not be stretching so far.

[Ballot comment]
Section 6.2 says:

  The DES specifications [DESI81] identify four 'weak' and twelve
  'semi-weak' keys; those keys shall not be used for encrypting
  messages for use in Kerberos.

Is this a SHALL NOT equivalent statement?

That same section says:

  One common extension is to support the "AFS string-to-key" algorithm,
  which is not defined here, if the type value above is one (1).

Is there an available reference for the "AFS string-to-key" algorithm?

In general, I find the string-to-key text a little light.  In the terminology
section it is given as:

        string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
        This function generates a key from two UTF-8 strings and an
        opaque octet string.  One of the strings is normally the
        principal's pass phrase, but is in general merely a secret
        string. 

While this seems to be fine in principle, I wonder if there might not be
an early step "somestring-to-utf8string" for cases where the overall
system was not provided the initial string in UTF-8.  I am not suggesting
that this document should cover that ground, but it does seem like
explicit recognition of that step might reinforce the idea that string-to-key
starts from a UTF-8 string *not* from a locale-specific encoding.
See also 6.3.1, which might be taken to imply that all passwords are UTF-8.

In Section A.4, The draft has this example:

  salt:  "ATHENA.MIT.EDUJuri" + s-caron + "i" + c-acute
    passwd: eszett
    key:    16d5a40e1ce3bacb61b9dce00470324c831973a7b952feb0


Assuming that the salt given actually intends to represent UTF-8 characters
outside the ASCII range (rather than the literal text "c-acute" and so forth),
I would suggest using the U+XXXX method of referencing the input characters.
That would result in a line like:
salt:  "ATHENA.MIT.EDUJuri"+"U+0161" + "i" + "U+0107"

rendering the whole thing U+XXXX format would also be possible, if a bit tedious.

[Ballot comment]
Section 6.2 says:

  The DES specifications [DESI81] identify four 'weak' and twelve
  'semi-weak' keys; those keys shall not be used for encrypting
  messages for use in Kerberos.

Is this a SHALL NOT equivalent statement?

That same section says:

  One common extension is to support the "AFS string-to-key" algorithm,
  which is not defined here, if the type value above is one (1).

Is there an available reference for the "AFS string-to-key" algorithm?

In general, I find the string-to-key text a little light.  In the terminology
section it is given as:

        string-to-key (UTF-8 string, UTF-8 string, opaque)->(protocol-key)
        This function generates a key from two UTF-8 strings and an
        opaque octet string.  One of the strings is normally the
        principal's pass phrase, but is in general merely a secret
        string. 

While this seems to be fine in principle, I wonder if there might not be
an early step "somestring-to-utf8string" for cases where the overall
system was not provided the initial string in UTF-8.  I am not suggesting
that this document should cover that ground, but it does seem like
explicit recognition of that step might reinforce the idea that string-to-key
starts from a UTF-8 string *not* from a locale-specific encoding.