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