Re: Last Call: 'Kerberized Internet Negotiation of Keys (KINK)' to Proposed Standard (fwd)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Comments:

 - Rekeying

"
3.6.  Rekeying Security Associations

   KINK requires the initiator of an SA to be responsible for rekeying
   the SA.  ...
"

   First, "requires" isn't proper RFC2119 terminology, and proper
   RFC2119 terminology in this regard is missing in that section.  This
   would be fine, except that...

   ...second, since KINK allows for user-to-user Kerberos V exchanges I
   see no reason that responders couldn't, if they wanted to, act as
   initiators, so there's a question, I think, as to whether responders
   are simply not allowed to do that or merely expected to not do that.
   Or did I miss something else?

   Third, even if responders typically could not act as initiators (say,
   for implementation-specific issues), one might still want some
   notification that an SA has expired and traffic needs it to be
   rekeyed.

   Looking at the minutes from IETF62 I see that there was concern about
   having servers do the u2u dance, but when re-keying the server knows
   that it's had an SA with a particular peer and so I think the DoS
   concern goes away.


 - Section 5.3 limits the IDs that can be used with KINK to
   address/subnet/address range IDs.  I think this is too limited, it
   seems likely to make KINK very difficult to use.

   I'd rather that a new ID type be defined that corresponds to Kerberos
   V principal names and/or that ID_FQDN and ID_RFC822_ADDR be allowed
   and a simple algorithm be recommended for matching principals and
   such IDs.

   In any case, much too little is said about IDs, and while what is
   said may be appropriate for a doc defining a KE protocol, unless a
   profile doc is to follow it that specifies such details...  how is
   one to use this KE?  Local/distributed configuration of
   principal<->IDs seems hard to deal with and prone to usability and/or
   interop problems, if not even to security problems (e.g., using DNS,
   not DNSSEC to map host principals to IP addresses to match to
   asserted IDs).

   Perhaps there should be a new principal name type hint for IP address
   based names.  That would push some complexity from implementation to
   host administration, while creating a separate problem (how to
   determine the realm name of a given address), but it seems possibly
   worthwhile.


 - Section 4.2.4.  How does cross-realm user-to-user work?

   Also, this doesn't make sense:

   "
                                 ...  When the requested principal is
   "principal@REALM", ...
   "

   Isn't "principal@REALM" pretty much the only form that the requested
   principal name can take?  Or are there other forms?  Where are those
   described?


 - Section 4.2.4.  How are the values of PrincName constructed?  Are
   they DER encodings of

      SEQUENCE { pname PrincipalName, realm, RealmName}?

   Or are they an "unparsed" representation of principal names following
   rules similar to those listed in RFC4121?

   This is very simply dealt with by saying that the contents of
   PrincName is given by section 2.1.3 of RFC1964, but without the
   GSS-API exported name token header.


 - Key derivation.  IKEv2 has different orders for the concatenation of
   the prf input data than KINK does.  You might want to double check
   with a cryptographer that KINK is doing the right thing here
   (particularly in light of the NIST KDF work).


 - Sub-session key generation.

   Section 3.2.1 says that "... KINK takes advantage of the fact that
   the KDC provides a reliable source of randomness which is used in key
   derivation."  But there's no prescribed mechanism by which Kerberos V
   clients are to include KDC-provided entropy into the sub-session key
   generation, nor is there any text saying that clients MAY/SHOULD/MUST
   do this in some, presumably, implementation dependent manner.

   RFC4120 does not, I think, rescue KINK here either, for it only says
   that "[if] the client selects a sub-session key, care must be taken
   to ensure the randomness of the selected sub-session key."

   I think it's better that KINK say that clients which do not have
   local, reliable sources of entropy SHOULD make use of KDC-provided
   entropy (in the form of ticket session keys and/or KDC-REP enc part
   nonces).


Thanks,

Nico
-- 

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]