Re: Last Call: Kerberized Internet Negotiation of Keys (KINK) toProposed Standard

[Michael Thomas <mat@cisco.com>]

OKABE Nobuo writes:
 > Here are our comments.
 > 
 > =====================================================================
 > 7.3.  CREATE
 > Comment 1)
 > 
 >     If a respondent's CPU is too poor for DH (ex. 8-bit CPU),
 >     it has to reject a proposal that includes KE payload.
 >     What message should the responder back to the initiator?
 >     Is NO-PROPOSAL-CHOSEN right one?
 >     Anyway, more specific description seems to be needed.

   There is no specific KINK error for this. I'm not
   sure what it is that IKE does (if it's even clear there),
   but if IKE would send back a NO-PROPOSAL-CHOSEN, that
   seems appropriate. I'm not very convinced that this is
   going to do what you want though as the other side isn't
   going to be able to figure out what the problem was.

   Honestly, I sort of think this is outside of the
   domain of the protocol, as there are bid-down attacks
   which could result if it the protocol specified a
   means of signaling this. It would probably be better
   to come up with some out of band way to agree not
   to send KE payloads... though I'm open to hear 
   disagreement though.

 > Comment 2)
 > 
 >     There is no KE payload in a reply message.
 >     Is it typo?

   Yes.

 > Comment 3)
 > 
 >     # This comment is related the above (Comment 2).
 > 
 >     Does a two-way handshake keep going if KINK peers exchanges
 >     KE payloads (in request and in reply)?
 >     The optimistic approach will be broken if DH is happen
 >     after the initiator receives KE payload in a reply message.
 >     But I'm not sure if ACK is needed or not.


   KE payloads definitely breaks optimism, and thus ACK
   must be used.

 > Comment 4)
 > 
 >    The draft does not define "prf".
 >    In IKE's case, a phase 1 negotiates a hash algorithm
 >    that is used for prf. But KINK does not use IKE phase 1.
 >    # I guess that the hash algorithm specified in the Kerberos ticket
 >    # is used.

   You're correct. Your solution seems reasonable as
   this is the same tact used for the integrity checksum.
   I'll fix this.
 
 > Again, I apologize if my mail disturbs you.

   No, thank you.

	     Mike