KAMADA Ken'ichi
2005-02-10 08:41:10 UTC
not yet analyzed: 3
open: 17
solution proposed: 12
waiting revised i-d: 7
closed: 2
---------------------------
total: 41
[**] Indicates an issue considered substantive.
[-] Indicates an editorial issue.
(2401bis) Indicates it depends on 2401 vs 2401bis.
#1 [**] Versioning
(solution proposed)
what happens when a receiver receives a major or
minor version of the kink or qm that is inconsistent with this
document? What about unknown payload types? (Sam Hartman)
QM version is discussed in section 12 (Forward Compatibility
Considerations).
Proposed solution:
- KINK version
return error KINK_INVMAJ when major version mismatch.
WRT minor version,
a) remove the minor version, or
b) return KINK_INVMIN when mismatch (both lower and higher)
- QM versoin
already specified in section 12.
- KINK payload type
return error (KINK_PROTOERR)
- ISAKMP payload type
return error (ISAKMP INVALID-PAYLOAD-TYPE)
(describe each Notify type usage like ikev2 spec.)
Specify the behavior when the error is not authenticated
in the Security Consideration section.
Related thread: Message-Id: <***@kame.net>
#2 [**] U2U
(not yet analyzed)
I think we need to look at how u2u works at various parts of
the protocol. In particular I'm concerned about choosing the right
u2u principal, dealing with cross-realm u2u and dealing with
recovering from reboots. We should confirm all these work out.
(Sam Hartman)
#3 [**] user-to-user (section 3, 4.2, and 5.1.2)
(not yet analyzed)
It seems like the
server tells the client what principal to authenticate to, but this
principal is not properly authorized. (Sam Hartman)
More examination of user-to-user case, especially situations where
it might *not* be two PKINIT clients, which section 3 says is possible.
(BTW, in the Kerberos docs, it's "user-to-user", not "user-user".)
(Ken Raeburn)
Verifying remotely supplied identity, as Sam raised earlier.
(Ken Raeburn)
In the user-to-user case with TGTs, I think the KINK draft may be
over-specifying things that should be dealt with at the Kerberos level.
If things are underspecified in Kerberos Clarifications, let's deal
with that. (Ken Raeburn)
Section 4.2:
[**] How will the initiator determine whether it will be able to get a
TGT? I think policy considerations of when to use u2u and
authorization considerations of what u2u principals are authorized are
underspecified in the draft.
(Sam Hartman)
[**] Make sure the descriptions of u2u work correctly in the
cross-realm case.
(Sam Hartman)
Section 5.1.2:
[**] How do I authorize which service I'm talking to in the u2u case.
I.E. how do I know what principals are authorized for a particular SPD
entry? (Sam Hartman)
#4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3)
(closed)
I need explicit review from the IPsec reviewer of this section to
make sure it is compatible with 2401bis.
Closed: being discussed with #37
#37 [**] Difference between IKE and KINK on CREATE command (section 4.3)
IN addition, any differences
between how this works and how IKE would set up the same SA need to be
called out. It is fine for there to be differences, but I want to
make sure the working group explicitly decided the differences are a
good thing.
I'm somewhat concerned that 4.3 is not specific enough to describe
exactly what key gets set up. I.E. I'm concerned it may not be
detailed enough for interoperable implementations.
(Sam Hartman)
- What keys are used for the resulting SA on the each side?
(Sam Hartman, Message-ID: <***@cz.mit.edu>)
Answer: Message-ID: <20050204170451BM%***@nanohz.org>
- Doesn't the timing when to add in/out SAs conflict with IKE?
(Sam Hartman, Message-ID: <***@cz.mit.edu>)
Related thread: Message-ID: <20050204170454BO%***@nanohz.org>
- How about when to add SAs and which SAs to add when 3-way.
(Message-ID: <20050204170454BO%***@nanohz.org>)
#5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3)
(solution proposed)
Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the
nonce should be used. If the circumstances they're describing are
different, that's okay, but if so, I missed it on first reading.
(Ken Raeburn)
They are talking the same situation and the requirement levels should
be aligned. I think SHOULD is appropriate because non-returning
responder's nonce does not break interoperabilities.
(Message-ID: <20050127171441FF%***@nanohz.org>)
If the initiator receives a responder's nonce, she MUST use
it in the KEYMAT calculation.
I think it is also editorial issue. anyway, the behavior depends on
condition. if a responder does not agree with the initiator's proposal,
AND if the responder wants to continue the transaction, then the responder
MUST send back a message with ACK request bit, and MAY contain a nonce.
There is a case when the responder wants to use same KEYMAT of the
initiator, but just doesn't want to use the initiator's proposal.
It is not always required to add a nonce.
(Message-Id: <***@kame.net>)
#6 [*] Half open (section 4.4)
(solution proposed)
IPsec does not allow half-open security associations any more as far
as I can tell in 2401bis. So it's not just for simplicity, but for
model conformance. (Sam Hartman)
Proposed solution:
remove the phrase "for simplicity".
(Message-ID: <***@cz.mit.edu>)
#7 [**] DPD & STATUS (section 4.4.2 and 4.5)
[**] Discuss status message, rebooting peers and u2u. This looks a
lot like the IKE case where you lose all cryptographic context to me.
(Sam Hartman)
I don't understand what you want here. Are you saying
that this doesn't work in the u-u case? I don't
understand what u-u has to do with anything here. (Michael Thomas)
OK. I was unclear . When sending a status message, what happens if
the peer has gotten a new TGT? How do I realize I need to use this
TGT rather than the one I have? (Sam Hartman)
#8 [*] CksumLen (section 5)
(solution proposed)
Diagram indicates one octet for cksumlen, but the text (and
kcrypto specifications) say it should be two.
Clarify that you mean the padding discussed in 5.1 (KINK Padding
Rules), not crypto-system padding. (Sam Hartman)
Use 2 octets for CksumLen field in accordance with kcrypto.
See also: #9
#9 [**] etype does not directly indicate checksum type (section 5)
(solution proposed)
a key's encryption type does not directly indicate
a checksum type, it indicates an encryption(-with-integrity-protection)
scheme, which does include a required-to-implement checksum type
(Ken Raeburn)
Proposed solutions are:
- Use required-to-implement checksum type determined by the etype.
- Use get_mic or verify_mic function to generate or verify the checksum.
- Omit the checksum field before calculation.
- The Length field is filled with the packet length without checksum and
the CksumLen field is zeroed out before the calculation.
- Move the Cksum field to the end of the message.
(maybe without padding between the last payload and checksum?)
(Message-ID: <20050131093509FD%***@nanohz.org>)
#10 [**] Kerberos allows variable length checksum (section 5)
(solution proposed)
I'd have to go back and check, but I don't think we require that
a given checksum type have a fixed output size, so "leave X amount of
space and fill it with zero for computing the checksum" is questionable
too. (Ken Raeburn)
Proposed solution: look at #9
#11 [*] Kerberos checksum is not deterministic (section 5)
(solution proposed)
The Kink description of how to verify a checksum assumes that
Kerberos checksums are deterministic; this is not strictly required.
(Sam Hartman)
let kcrypto specify how
to verify a checksum, as they're not required to be deterministic, so
the "compute it again and compare" approach specified in section 5 is
wrong (Ken Raeburn)
Proposed solution: look at #9
#12 [**] Subsession keys (section 5 and 8)
Are subsession keys ignored? (Ken Raeburn)
The description of the checksum says that the session key of the
ticket is used. That's a way to do it, but the working group should
explain why it has chosen to ignore the subsession key.
(Sam Hartman)
Related thread: Message-ID: <20050127171703FZ%***@nanohz.org>
#13 [**] Replay protection (section 5)
(closed)
The document claims that the transaction id is not used for
replay detection because Kerberos provides that. How is that true?
The authenticator is protected against replays but how is the rest of
the message bound to that specific authenticator instead of to a
session key of a ticket?
(Sam Hartman)
Closed: (Message-ID: <***@cz.mit.edu>)
#14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5)
(waiting revised i-d)
must be zero on send, must be ignored by receiver.
#15 [**] Principal name of KINK service (section 5.1.2)
How do I discover the FQDN of my remote peer? SPD
entries are configured in terms of IP addresses. If you want to
store an identity in the PAD, why not store a principal instead of a
hostname.
I interpreted the text as a naming convention, not how a implementation
get a peer's principal name. So I think it is an implementation issue
whether a principal name is generated from a FQDN or got directly from
the PAD.
(KAMADA Ken'ichi, <20050131095154FY%***@nanohz.org>)
#16 [*] EPOCH (section 5.1.2)
Perhaps you need a description of the time stamp? I recall there
being such a description in draft-housley-binarytime-xx.
(Sam Hartman)
Related thread: Message-ID: <20050210154348XQ%***@nanohz.org>
#17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1)
(solution proposed)
Section 7.1 says the checksum in the KRB-ERROR message is not used,
but section 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).
Remove following paragraph from section 5.1.4. (Sam Hartman)
KINK implementations MUST make use of keyed Kerberos errors when the
appropriate service key is available as specified in [KRBREVS]. In
particular, clock skew errors MUST be integrity protected. For
unauthenticated Kerberos errors, the receiver MAY choose to act on
them, but SHOULD take precautions against make-work kinds of attacks.
Replace the above paragraph with the following: (kamada)
KINK implementations MUST make use of
a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate
service key is available.
Drop reference to krb-error checksum from section 7.1. (Sam Hartman)
defined in the following sections. The checksum in the KRB-ERROR
message is not used, since the KINK header already contains a check-
sum field.
#18 [**] Kerberos error type limitations (section 5.1.4)
Why should a sender send only those errors? I'm mostly asking
for an explanation to be given to me or to be added to the document
rather than liberalization of the requirement. (Sam Hartman)
Related thread: Message-Id: <***@kame.net>
#19 [**] Cross-realm and U2U (section 5.1.5)
(not yet analyzed)
Please Consider how this works in the cross-realm case.
I.E. make sure you end up with the right ticket on the right side. I
believe this text assumes that you need a ticket in a realm close to
the client; I think that for things to work you actually need a realm
close to the server. Work through the message flows and make sure the
KDC doing the decryption actually has the necessary keys and then
adjust the document if necessary so the right KDC is used.
The document needs to clearly indicate what error code is used in the
case when the responder cannot get a ticket because some cross-realm
key is missing. In general we want it to be possible for an initiator
to try several identities until the initiator finds the right one that
has a shared key. (Sam Hartman)
#20 [**] KINK_ENCRYPT format (section 5.1.8)
(solution proposed)
The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is
vague. I think of using the output of raw encryption algorithms
(i.e. E(confounder | plaintext | pad)) or using EncryptedData.
treat "encryption with
integrity protection" output as a whole, don't peek under the covers to
find a "checksum" part you can throw away (Ken Raeburn)
drop references to the initialization vector (Ken Raeburn)
Please use the output of the kcrypto encrypt
operation directly. Of most importance is to make sure that all
kcrypto enctypes will work even if it is not possible to decompose the
kcrypto checksum from the encrypted data. This probably means that in
some cases you will have double checksums.
You also need to deal with making sure you can determine the length of
the plaintext. (Sam Hartman)
Related thread: Message-Id: <***@kame.net>
Proposed solution:
Use the output of the kcrypto encryption.
#21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8)
(solution proposed)
Text should probably indacte that next payload must be none.
Proposed solution:
The section 5.1 describes it,
however it would be better to describe explicitly so.
reader does not has trouble even if the text is described repeatedly.
(Message-Id: <***@kame.net>)
#22 [*] Kerberos PFS (section 6.8)
(solution proposed)
Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat
questionable whether a system which is heavily relying on Kerberos
benefits from PFS." First, that sounds like it might be Security
Considerations material. Second, I don't follow; explain please?
(Ken Raeburn)
Related thread: Message-Id: <***@kame.net>
- (Current) Kerberos doesn't provide PFS.
- KINK optionally provides PFS.
- KINK PFS has benefits but is not mandatory because of the
computational cost.
so editorial fix (or even removing this sentence) would be
enough.
#23 [*] KE interoperability (section 6.8)
What happens if a peer that implements the KE payloads communicates
with a peer that does not. Specify the behavior in sufficient detail
to guarantee interoperability. (Sam Hartman)
Releated thread: Message-Id: <***@kame.net>
#24 [*] MUST/SHOULD in clock skew (section 7.1)
The time difference MUST be computed and SHOULD be stored
and used? Why the different requirement levels? (And is this sort of
thing in the domain of KINK or Kerberos?) (Ken Raeburn)
Related thread: Message-ID: <***@miyazawa.org>
#25 [**] prf (section 8)
Section 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.
Use a prf
from kcrypto, don't assume the checksum operations are deterministic
hash functions (Ken Raeburn)
Section 6.1 (the description of hash algorithm):
This checksum may not be deterministic and is probably not
appropriate for use in setting up a key. A PRF is provided, although
depending on how the hash is used the PRF may or may not be a suitable
replacement. There has been significant discussion within krb-wg on
when the PRF is appropriate and when it is not. This discussion
centered around key determination in pkinit. (Sam Hartman)
Message-ID: <20050210161443XN%***@nanohz.org>
#26 [*] Key derivation (section 8)
The key derivation seems inconsistent with the crypto framework
document. (Sam Hartman)
I don't understand what this section says well enough to determine
whether it works with kcrypto. (Sam Hartman)
#27 [*](2401bis) SPD Considerations (section 10.1)
This should not go in the security considartions section. It is
really more about IPsec architectural considerations than security
considerations.
This text needs to take into account 2401bis. In particular it needs
to be properly split between SPD considerations and PAD
considerations. (Sam Hartman)
Related thread: Message-ID: <***@miyazawa.org>
#28 [*] Key usage
Usage of kink should specify the key usage numbers for kerberos
encryption. (Sam Hartman)
You can assign the numbers out of the space reserved for applications
if principals used for kink will not be used for other purposes. If
principals used for kink will be used for other purposes it is
probably desirable to talk to Tom Yu and get a key usage number added
to 1510ter. You'll also want to add the same key usage number to Kink
to avoid a normative reference to 1510ter.
(Sam Hartman, Message-ID: <***@cz.mit.edu>)
#29 [*](2401bis) Rekeying (section 4.4.1)
section 4.4.1:
Please make sure this discussion is aligned with 2401bis. I think it
may change small details but they seem to have adopted much of the
same strategy kink uses. The area wher I believe they speak to this
issue is when you should rekey (timers etc). (Sam Hartman)
#30 [*](2401bis) IKEv2
Should we adopt IKEv2?
If we should...
- 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.
#31 [*] behavior on KINK_ERROR
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.
when does the responder generate these errors?
#32 [-] I-D nits
(waiting revised i-d)
Review the I-D nits and RFC authors docs. I spotted a lot of
mechanical things (number of lines per page; avoid hyphenation; use
ragged right margin; need two spaces after sentence-ending period; fix
page numbers in table of contents; add section numbers to TOC) most of
which I think are specified in one of those documents.
(Ken Raeburn)
the document needs to meet all the ID nits when it is
submitted. (Sam Hartman)
#33 [-] IANA considerations (section 11)
I think the correct terminology is "port
number", not "port", and they're "assigned", not "created". This
section says no new registries are required in the first paragraph, and
the third one specifies that IANA must create one (but without the
associated procedural data that is required nowadays). Are the KINK
payload types and ISAKMP payload types actually ever used in the same
field? If not, I don't think they need to come out of the same
registry. (Ken Raeburn)
Needs work. You may want to stop by tthe IANA office hours and ask
them for advice. They are generally quite good at working with
authors to figure out how things need to be specified.
(Sam Hartman)
#38 [-] Terminology
(waiting revised i-d)
Section 2 and 10.1.
Kerberos is now using the term user-user rather than user-to-user.
(Sam Hartman)
Section 2.
Principals are not either client or service principals;
they can and often do fill both roles. (Sam Hartman)
#40 [-] Wording
(waiting revised i-d)
Section 2, last paragraph. "Between" is generally non-directional,
but in this case, a direction seems to be intended to be inferred; try
"from...to" instead. (Ken Raeburn)
#41 [-] Wording in section 3, Protocol Overview
Section 3, English usage/grammar problems with the first two paragraphs.
(Sam Hartman)
Section 3.
which allows a final acknowledgment message when the respondent needs
a full three-way handshake. This is only needed when the optimistic
keying route is not taken, though it is expected that that will not
be the norm. KINK also provides rekeying and dead peer detection as
What is expected not to be the norm? Please reword.
(Sam Hartman)
#42 [-] Wording
(waiting revised i-d)
Section 4.3, discussing attributes, mixes singular and plural
indications. The word "lone" appears to be popular with the author,
too. :-) (Ken Raeburn)
#43 [-] Wording
(waiting revised i-d)
Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn)
#35 [-] References
(solution proposed)
The reference to [PKCROSS] is unnecessary, and only happens once, in
the introduction. I'd suggest dropping it. That's one less
unpublished I-D in the references section. (Ken Raeburn)
[KRBREVS] is referenced but not listed in the references section.
(Ken Raeburn)
Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the
protocol) fuzzy about use of different SAs, or is it "[IKE]" (the
document)? (Ken Raeburn)
Section 1:
Remove the reference to pkcross or cite something outside the IETF.
It's an expired ID without and active editor. (Sam Hartman)
Section 1:
Add an informative reference to IKE. (Sam Hartman)
Section 2:
Cite a reference for DER. (Sam Hartman)
Section 5: DOI
Cite a specific registry please. IANA registries are typically
named, and a URL reference would probably be appropriate.
#36 [-] Typos
(waiting revised i-d)
4.4.2. Dead Peer Detection
In the fourth paragraph, "loose" is to be "lose".
5.1 KINK Payloads
In the first item, the length of the Next Payload should be
one octet instead of two.
5.1.1. KINK Padding Rules
In the second item, "other other" is to be "other".
5.1.1. KINK Padding Rules
The first item in the list should end with a period like
the others. (Ken Raeburn)
5.1.5. KINK_TGT_REQ Payload
In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/***@REALM".
5.1.6. KINK_TGT_REP Payload
In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP".
7.3. CREATE
"IPspec" is to be "IPsec".
7.5. STATUS
In the last paragraph, "REPLY KINK Header" should be in one line.
In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]".
overall:
"'s" is used in some places where I'd use "s" for a plural form.
open: 17
solution proposed: 12
waiting revised i-d: 7
closed: 2
---------------------------
total: 41
[**] Indicates an issue considered substantive.
[-] Indicates an editorial issue.
(2401bis) Indicates it depends on 2401 vs 2401bis.
#1 [**] Versioning
(solution proposed)
what happens when a receiver receives a major or
minor version of the kink or qm that is inconsistent with this
document? What about unknown payload types? (Sam Hartman)
QM version is discussed in section 12 (Forward Compatibility
Considerations).
Proposed solution:
- KINK version
return error KINK_INVMAJ when major version mismatch.
WRT minor version,
a) remove the minor version, or
b) return KINK_INVMIN when mismatch (both lower and higher)
- QM versoin
already specified in section 12.
- KINK payload type
return error (KINK_PROTOERR)
- ISAKMP payload type
return error (ISAKMP INVALID-PAYLOAD-TYPE)
(describe each Notify type usage like ikev2 spec.)
Specify the behavior when the error is not authenticated
in the Security Consideration section.
Related thread: Message-Id: <***@kame.net>
#2 [**] U2U
(not yet analyzed)
I think we need to look at how u2u works at various parts of
the protocol. In particular I'm concerned about choosing the right
u2u principal, dealing with cross-realm u2u and dealing with
recovering from reboots. We should confirm all these work out.
(Sam Hartman)
#3 [**] user-to-user (section 3, 4.2, and 5.1.2)
(not yet analyzed)
It seems like the
server tells the client what principal to authenticate to, but this
principal is not properly authorized. (Sam Hartman)
More examination of user-to-user case, especially situations where
it might *not* be two PKINIT clients, which section 3 says is possible.
(BTW, in the Kerberos docs, it's "user-to-user", not "user-user".)
(Ken Raeburn)
Verifying remotely supplied identity, as Sam raised earlier.
(Ken Raeburn)
In the user-to-user case with TGTs, I think the KINK draft may be
over-specifying things that should be dealt with at the Kerberos level.
If things are underspecified in Kerberos Clarifications, let's deal
with that. (Ken Raeburn)
Section 4.2:
[**] How will the initiator determine whether it will be able to get a
TGT? I think policy considerations of when to use u2u and
authorization considerations of what u2u principals are authorized are
underspecified in the draft.
(Sam Hartman)
[**] Make sure the descriptions of u2u work correctly in the
cross-realm case.
(Sam Hartman)
Section 5.1.2:
[**] How do I authorize which service I'm talking to in the u2u case.
I.E. how do I know what principals are authorized for a particular SPD
entry? (Sam Hartman)
#4 [**](2401bis) CREATE command from the aspect of 2401bis (section 4.3)
(closed)
I need explicit review from the IPsec reviewer of this section to
make sure it is compatible with 2401bis.
Closed: being discussed with #37
#37 [**] Difference between IKE and KINK on CREATE command (section 4.3)
IN addition, any differences
between how this works and how IKE would set up the same SA need to be
called out. It is fine for there to be differences, but I want to
make sure the working group explicitly decided the differences are a
good thing.
I'm somewhat concerned that 4.3 is not specific enough to describe
exactly what key gets set up. I.E. I'm concerned it may not be
detailed enough for interoperable implementations.
(Sam Hartman)
- What keys are used for the resulting SA on the each side?
(Sam Hartman, Message-ID: <***@cz.mit.edu>)
Answer: Message-ID: <20050204170451BM%***@nanohz.org>
- Doesn't the timing when to add in/out SAs conflict with IKE?
(Sam Hartman, Message-ID: <***@cz.mit.edu>)
Related thread: Message-ID: <20050204170454BO%***@nanohz.org>
- How about when to add SAs and which SAs to add when 3-way.
(Message-ID: <20050204170454BO%***@nanohz.org>)
#5 [*] When 3-way, is responder's nonce MUST or SHOULD? (section 4.3 and 7.3)
(solution proposed)
Sec 4.3 and 7.3 use SHOULD and MUST respectively regarding when the
nonce should be used. If the circumstances they're describing are
different, that's okay, but if so, I missed it on first reading.
(Ken Raeburn)
They are talking the same situation and the requirement levels should
be aligned. I think SHOULD is appropriate because non-returning
responder's nonce does not break interoperabilities.
(Message-ID: <20050127171441FF%***@nanohz.org>)
If the initiator receives a responder's nonce, she MUST use
it in the KEYMAT calculation.
I think it is also editorial issue. anyway, the behavior depends on
condition. if a responder does not agree with the initiator's proposal,
AND if the responder wants to continue the transaction, then the responder
MUST send back a message with ACK request bit, and MAY contain a nonce.
There is a case when the responder wants to use same KEYMAT of the
initiator, but just doesn't want to use the initiator's proposal.
It is not always required to add a nonce.
(Message-Id: <***@kame.net>)
#6 [*] Half open (section 4.4)
(solution proposed)
IPsec does not allow half-open security associations any more as far
as I can tell in 2401bis. So it's not just for simplicity, but for
model conformance. (Sam Hartman)
Proposed solution:
remove the phrase "for simplicity".
(Message-ID: <***@cz.mit.edu>)
#7 [**] DPD & STATUS (section 4.4.2 and 4.5)
[**] Discuss status message, rebooting peers and u2u. This looks a
lot like the IKE case where you lose all cryptographic context to me.
(Sam Hartman)
I don't understand what you want here. Are you saying
that this doesn't work in the u-u case? I don't
understand what u-u has to do with anything here. (Michael Thomas)
OK. I was unclear . When sending a status message, what happens if
the peer has gotten a new TGT? How do I realize I need to use this
TGT rather than the one I have? (Sam Hartman)
#8 [*] CksumLen (section 5)
(solution proposed)
Diagram indicates one octet for cksumlen, but the text (and
kcrypto specifications) say it should be two.
Clarify that you mean the padding discussed in 5.1 (KINK Padding
Rules), not crypto-system padding. (Sam Hartman)
Use 2 octets for CksumLen field in accordance with kcrypto.
See also: #9
#9 [**] etype does not directly indicate checksum type (section 5)
(solution proposed)
a key's encryption type does not directly indicate
a checksum type, it indicates an encryption(-with-integrity-protection)
scheme, which does include a required-to-implement checksum type
(Ken Raeburn)
Proposed solutions are:
- Use required-to-implement checksum type determined by the etype.
- Use get_mic or verify_mic function to generate or verify the checksum.
- Omit the checksum field before calculation.
- The Length field is filled with the packet length without checksum and
the CksumLen field is zeroed out before the calculation.
- Move the Cksum field to the end of the message.
(maybe without padding between the last payload and checksum?)
(Message-ID: <20050131093509FD%***@nanohz.org>)
#10 [**] Kerberos allows variable length checksum (section 5)
(solution proposed)
I'd have to go back and check, but I don't think we require that
a given checksum type have a fixed output size, so "leave X amount of
space and fill it with zero for computing the checksum" is questionable
too. (Ken Raeburn)
Proposed solution: look at #9
#11 [*] Kerberos checksum is not deterministic (section 5)
(solution proposed)
The Kink description of how to verify a checksum assumes that
Kerberos checksums are deterministic; this is not strictly required.
(Sam Hartman)
let kcrypto specify how
to verify a checksum, as they're not required to be deterministic, so
the "compute it again and compare" approach specified in section 5 is
wrong (Ken Raeburn)
Proposed solution: look at #9
#12 [**] Subsession keys (section 5 and 8)
Are subsession keys ignored? (Ken Raeburn)
The description of the checksum says that the session key of the
ticket is used. That's a way to do it, but the working group should
explain why it has chosen to ignore the subsession key.
(Sam Hartman)
Related thread: Message-ID: <20050127171703FZ%***@nanohz.org>
#13 [**] Replay protection (section 5)
(closed)
The document claims that the transaction id is not used for
replay detection because Kerberos provides that. How is that true?
The authenticator is protected against replays but how is the rest of
the message bound to that specific authenticator instead of to a
session key of a ticket?
(Sam Hartman)
Closed: (Message-ID: <***@cz.mit.edu>)
#14 [-] Reserved (15 bits) -- Reserved and must be zero (section 5)
(waiting revised i-d)
must be zero on send, must be ignored by receiver.
#15 [**] Principal name of KINK service (section 5.1.2)
How do I discover the FQDN of my remote peer? SPD
entries are configured in terms of IP addresses. If you want to
store an identity in the PAD, why not store a principal instead of a
hostname.
I interpreted the text as a naming convention, not how a implementation
get a peer's principal name. So I think it is an implementation issue
whether a principal name is generated from a FQDN or got directly from
the PAD.
(KAMADA Ken'ichi, <20050131095154FY%***@nanohz.org>)
#16 [*] EPOCH (section 5.1.2)
Perhaps you need a description of the time stamp? I recall there
being such a description in draft-housley-binarytime-xx.
(Sam Hartman)
Related thread: Message-ID: <20050210154348XQ%***@nanohz.org>
#17 [**] Checksum when KRB-ERROR occured (section 5.1.4 and 7.1)
(solution proposed)
Section 7.1 says the checksum in the KRB-ERROR message is not used,
but section 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).
Remove following paragraph from section 5.1.4. (Sam Hartman)
KINK implementations MUST make use of keyed Kerberos errors when the
appropriate service key is available as specified in [KRBREVS]. In
particular, clock skew errors MUST be integrity protected. For
unauthenticated Kerberos errors, the receiver MAY choose to act on
them, but SHOULD take precautions against make-work kinds of attacks.
Replace the above paragraph with the following: (kamada)
KINK implementations MUST make use of
a KINK Cksum field when returning KINK_KRB_ERROR and the appropriate
service key is available.
Drop reference to krb-error checksum from section 7.1. (Sam Hartman)
defined in the following sections. The checksum in the KRB-ERROR
message is not used, since the KINK header already contains a check-
sum field.
#18 [**] Kerberos error type limitations (section 5.1.4)
Why should a sender send only those errors? I'm mostly asking
for an explanation to be given to me or to be added to the document
rather than liberalization of the requirement. (Sam Hartman)
Related thread: Message-Id: <***@kame.net>
#19 [**] Cross-realm and U2U (section 5.1.5)
(not yet analyzed)
Please Consider how this works in the cross-realm case.
I.E. make sure you end up with the right ticket on the right side. I
believe this text assumes that you need a ticket in a realm close to
the client; I think that for things to work you actually need a realm
close to the server. Work through the message flows and make sure the
KDC doing the decryption actually has the necessary keys and then
adjust the document if necessary so the right KDC is used.
The document needs to clearly indicate what error code is used in the
case when the responder cannot get a ticket because some cross-realm
key is missing. In general we want it to be possible for an initiator
to try several identities until the initiator finds the right one that
has a shared key. (Sam Hartman)
#20 [**] KINK_ENCRYPT format (section 5.1.8)
(solution proposed)
The format of the encrypted part of KINK_ENCRYPT (section 5.1.8) is
vague. I think of using the output of raw encryption algorithms
(i.e. E(confounder | plaintext | pad)) or using EncryptedData.
treat "encryption with
integrity protection" output as a whole, don't peek under the covers to
find a "checksum" part you can throw away (Ken Raeburn)
drop references to the initialization vector (Ken Raeburn)
Please use the output of the kcrypto encrypt
operation directly. Of most importance is to make sure that all
kcrypto enctypes will work even if it is not possible to decompose the
kcrypto checksum from the encrypted data. This probably means that in
some cases you will have double checksums.
You also need to deal with making sure you can determine the length of
the plaintext. (Sam Hartman)
Related thread: Message-Id: <***@kame.net>
Proposed solution:
Use the output of the kcrypto encryption.
#21 [*] Next Payload in KINK_ENCRYPT (section 5.1.8)
(solution proposed)
Text should probably indacte that next payload must be none.
Proposed solution:
The section 5.1 describes it,
however it would be better to describe explicitly so.
reader does not has trouble even if the text is described repeatedly.
(Message-Id: <***@kame.net>)
#22 [*] Kerberos PFS (section 6.8)
(solution proposed)
Sec 6.8: "Kerberos in general does not provide PFS so it is somewhat
questionable whether a system which is heavily relying on Kerberos
benefits from PFS." First, that sounds like it might be Security
Considerations material. Second, I don't follow; explain please?
(Ken Raeburn)
Related thread: Message-Id: <***@kame.net>
- (Current) Kerberos doesn't provide PFS.
- KINK optionally provides PFS.
- KINK PFS has benefits but is not mandatory because of the
computational cost.
so editorial fix (or even removing this sentence) would be
enough.
#23 [*] KE interoperability (section 6.8)
What happens if a peer that implements the KE payloads communicates
with a peer that does not. Specify the behavior in sufficient detail
to guarantee interoperability. (Sam Hartman)
Releated thread: Message-Id: <***@kame.net>
#24 [*] MUST/SHOULD in clock skew (section 7.1)
The time difference MUST be computed and SHOULD be stored
and used? Why the different requirement levels? (And is this sort of
thing in the domain of KINK or Kerberos?) (Ken Raeburn)
Related thread: Message-ID: <***@miyazawa.org>
#25 [**] prf (section 8)
Section 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.
Use a prf
from kcrypto, don't assume the checksum operations are deterministic
hash functions (Ken Raeburn)
Section 6.1 (the description of hash algorithm):
This checksum may not be deterministic and is probably not
appropriate for use in setting up a key. A PRF is provided, although
depending on how the hash is used the PRF may or may not be a suitable
replacement. There has been significant discussion within krb-wg on
when the PRF is appropriate and when it is not. This discussion
centered around key determination in pkinit. (Sam Hartman)
Message-ID: <20050210161443XN%***@nanohz.org>
#26 [*] Key derivation (section 8)
The key derivation seems inconsistent with the crypto framework
document. (Sam Hartman)
I don't understand what this section says well enough to determine
whether it works with kcrypto. (Sam Hartman)
#27 [*](2401bis) SPD Considerations (section 10.1)
This should not go in the security considartions section. It is
really more about IPsec architectural considerations than security
considerations.
This text needs to take into account 2401bis. In particular it needs
to be properly split between SPD considerations and PAD
considerations. (Sam Hartman)
Related thread: Message-ID: <***@miyazawa.org>
#28 [*] Key usage
Usage of kink should specify the key usage numbers for kerberos
encryption. (Sam Hartman)
You can assign the numbers out of the space reserved for applications
if principals used for kink will not be used for other purposes. If
principals used for kink will be used for other purposes it is
probably desirable to talk to Tom Yu and get a key usage number added
to 1510ter. You'll also want to add the same key usage number to Kink
to avoid a normative reference to 1510ter.
(Sam Hartman, Message-ID: <***@cz.mit.edu>)
#29 [*](2401bis) Rekeying (section 4.4.1)
section 4.4.1:
Please make sure this discussion is aligned with 2401bis. I think it
may change small details but they seem to have adopted much of the
same strategy kink uses. The area wher I believe they speak to this
issue is when you should rekey (timers etc). (Sam Hartman)
#30 [*](2401bis) IKEv2
Should we adopt IKEv2?
If we should...
- 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.
#31 [*] behavior on KINK_ERROR
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.
when does the responder generate these errors?
#32 [-] I-D nits
(waiting revised i-d)
Review the I-D nits and RFC authors docs. I spotted a lot of
mechanical things (number of lines per page; avoid hyphenation; use
ragged right margin; need two spaces after sentence-ending period; fix
page numbers in table of contents; add section numbers to TOC) most of
which I think are specified in one of those documents.
(Ken Raeburn)
the document needs to meet all the ID nits when it is
submitted. (Sam Hartman)
#33 [-] IANA considerations (section 11)
I think the correct terminology is "port
number", not "port", and they're "assigned", not "created". This
section says no new registries are required in the first paragraph, and
the third one specifies that IANA must create one (but without the
associated procedural data that is required nowadays). Are the KINK
payload types and ISAKMP payload types actually ever used in the same
field? If not, I don't think they need to come out of the same
registry. (Ken Raeburn)
Needs work. You may want to stop by tthe IANA office hours and ask
them for advice. They are generally quite good at working with
authors to figure out how things need to be specified.
(Sam Hartman)
#38 [-] Terminology
(waiting revised i-d)
Section 2 and 10.1.
Kerberos is now using the term user-user rather than user-to-user.
(Sam Hartman)
Section 2.
Principals are not either client or service principals;
they can and often do fill both roles. (Sam Hartman)
#40 [-] Wording
(waiting revised i-d)
Section 2, last paragraph. "Between" is generally non-directional,
but in this case, a direction seems to be intended to be inferred; try
"from...to" instead. (Ken Raeburn)
#41 [-] Wording in section 3, Protocol Overview
Section 3, English usage/grammar problems with the first two paragraphs.
(Sam Hartman)
Section 3.
which allows a final acknowledgment message when the respondent needs
a full three-way handshake. This is only needed when the optimistic
keying route is not taken, though it is expected that that will not
be the norm. KINK also provides rekeying and dead peer detection as
What is expected not to be the norm? Please reword.
(Sam Hartman)
#42 [-] Wording
(waiting revised i-d)
Section 4.3, discussing attributes, mixes singular and plural
indications. The word "lone" appears to be popular with the author,
too. :-) (Ken Raeburn)
#43 [-] Wording
(waiting revised i-d)
Sec 8: "By optional, it is meant..." is badly worded. (Ken Raeburn)
#35 [-] References
(solution proposed)
The reference to [PKCROSS] is unnecessary, and only happens once, in
the introduction. I'd suggest dropping it. That's one less
unpublished I-D in the references section. (Ken Raeburn)
[KRBREVS] is referenced but not listed in the references section.
(Ken Raeburn)
Sec 5.1.7, next to last paragraph on page 21, is "IKE" (the
protocol) fuzzy about use of different SAs, or is it "[IKE]" (the
document)? (Ken Raeburn)
Section 1:
Remove the reference to pkcross or cite something outside the IETF.
It's an expired ID without and active editor. (Sam Hartman)
Section 1:
Add an informative reference to IKE. (Sam Hartman)
Section 2:
Cite a reference for DER. (Sam Hartman)
Section 5: DOI
Cite a specific registry please. IANA registries are typically
named, and a URL reference would probably be appropriate.
#36 [-] Typos
(waiting revised i-d)
4.4.2. Dead Peer Detection
In the fourth paragraph, "loose" is to be "lose".
5.1 KINK Payloads
In the first item, the length of the Next Payload should be
one octet instead of two.
5.1.1. KINK Padding Rules
In the second item, "other other" is to be "other".
5.1.1. KINK Padding Rules
The first item in the list should end with a period like
the others. (Ken Raeburn)
5.1.5. KINK_TGT_REQ Payload
In the third item, "krbtgt/REALM/@REALM" is to be "krbtgt/***@REALM".
5.1.6. KINK_TGT_REP Payload
In the caption of Figure 13, "KINK_TGT_REQ" is to be "KINK_TGT_REP".
7.3. CREATE
"IPspec" is to be "IPsec".
7.5. STATUS
In the last paragraph, "REPLY KINK Header" should be in one line.
In the last paragraph, "[KRB_ERROR]" is to be "[KINK_ERROR]".
overall:
"'s" is used in some places where I'd use "s" for a plural form.
--
KAMADA Ken'ichi <***@nanohz.org>
KAMADA Ken'ichi <***@nanohz.org>