KINK comments

Here is my comments for KINK.
I'd also like to act a reviewer.

Please note that I'm not a Kerberos expert and there may be
some misunderstandings.


1) Sec 8 says "prf is the same hash algorithm found in the session ticket's
etype", but krb-wg-crypto-07 defines hash as unkeyed.
Fortunately krb-wg-crypto-07 defines a PRF for each etype, so KINK
should use this PRF.


2) The format of the encrypted part of KINK_ENCRYPT (Sec 5.1.8) is
vague.  I think of using the output of raw encryption algorithms or
using EncryptedData.

case A)
  I have interpreted the format as the output of encryption algorithms.
  In the word of krb-wg-crypto, E(confounder | plaintext | pad).
  krb-wg-crypto seems to have at least two different types of encryption
  functions.  One is des-cbc-* which places unkeyed checksum in the
  input of encryption, and another is one using simplified profile
  which places HMAC after the output of encryption.
  In either case, when we exclude a checksum from their formats,
  the result is E(confounder | plaintext | pad).

  I think case A is the original author's idea.

case B)
  Some people seem to have interpreted it as EncryptedData.
  If this is the way to go, I agree that it should not be
  decomposed.


3) Sec 7.1 says the checksum in the KRB-ERROR message is not used,
but Sec 5.1.4 says that KINK implementation MUST make use of
keyed Kerberos errors.  But KRB-ERROR does not have checksum in it (at
least with RFC 1510 or kerberos-clarifications).
I think a correct phrase here is "KINK implementations MUST make use of
a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate
service key is available."


4) This may be a naive question but
is there any situation that one host acts as two different
principal in one realm?
If there is, should KINK_TGT_REQ contain principal name (not only
realm name)?


5) With regard to server principal authentication problem in
user-to-user mode which Mr. Hartman noted,
doesn't the KDC check the sname in the TGS_REQ with one in the
additional-ticket when the ENC-TKT-IN-SKEY option is specified?
If it does, I think there is no problem because the client
must know in advance the principal name which she would like
to talk with.  Otherwise, returned principal name or TGT in
the KINK_TGT_REP must be indeed authenticated but I have no idea
for how.


6) Mr. Raeburn said that Kerberos checksum does not necessarily
requires fixed checksum size.  If that is the case and KINK should
support such checksums, the KINK packet format should be changed and
the comments below may be useless.

Kerberos checksum is not deterministic as already pointed out.
The spec should describe how to verify checksum as follows.

To verify the checksum, the checksum is saved, and the
checksum field is zeroed out.  The resulting message and the saved
checksum are passed to the verification function.  If the verification
fails, the message MUST be dropped.


7) If KINK also supports IKEv2 features, at least the following items
should be considered.

- IKEv2 does not have DOI, so how to handle the DOI field in the KINK
  packet header should be described.
- Use TS (Traffic Selector) instead of ID (Identification).
- KEYMAT calculation is changed.
- How to handle REKEY_SA Notify type.


8) In implementor's point of view, I'd like to see initiator's
behavior in receiving KINK_ERROR to be defined.
For example:
- When KINK_OK is received, initiator MAY act as if the KINK_ERROR
  payload was not included in the messaged.
- When KINK_BADQMVERS is received and the Cksum is verified,
  initiator MAY retry in other Quick Mode version.
- When one of other error codes is received and the Cksum is verified,
  initiator SHOULD abort the negotiation.

Honestly, behavior against KINK_KRB_ERROR is welcome, but
it is the scope of Kerberos document (not KINK) so I don't insist on
including it in KINK.


Regards,
-- 
KAMADA Ken'ichi <[email protected]>