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

["KAMADA Ken'ichi" <kamada@xxxxxxxxxx>]

Thank you for your review.

At Tue, 29 Nov 2005 12:41:38 -0600,
Nicolas Williams <Nicolas.Williams@xxxxxxx> wrote:
> 
>  - 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?

A responder can become an initiator (with U2U if necessary) and it's
possible to rekey from the responder, but it is not expected in my
opinion.

KINK could disallow the responder to rekey, but still, the responder
can make new SAs (pretending independent of rekeying) and delete old
ones, and it cannot be distinguished from rekeying from the initiator.
So I don't think "disallowing" and "expecting-not-to-do" have much
difference in this case.

>    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.

KINK is based on IKE(v1) and negotiates SA lifetime (see the first
paragraph of section 3.2 of kink-10), so the initiator should notice
SA expiration and rekey it.



>  - 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.

Section 5.3 says that IDs in KINK identify traffic to be protected
(like TSs in IKEv2).  Peer's identifiers are pricnipal names provided
in AP exchange.  (Note that AP_REQ and AP_REP are always exchanged
when negotiating SAs.)



>  - 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?

That paragraph is poorly worded, sorry.  The string "principal" and
"REALM" in the quoted sentence correspond to the same strings in that
sentence.  So, what I wanted to say was:
  - The returned TGT MUST be a non-inter-realm TGT of the requested
    realm, and
  - The cname/crealm of the TGT MUST match the requested principal.

I'd propose to change the paragraph with this one:

   o  PrincName -- The name of the principal which the initiator want to
      communicate with.  It is assumed that the initiator knows the
      responder's principal name (including the realm name) in the same
      way as the non-User-to-User case.  The returned TGT MUST NOT be an
      inter-realm TGT and it's cname and crealm MUST match the requested
      principal name, so that the initiator can rendezvous with the
      responder at the responder's realm.

For comparison, here is the old one:

   o  PrincName -- The name of the principal which the initiator want to
      communicate with.  It is assumed that the initiator knows the
      responder's principal name (including the realm name) in the same
      way as the non-User-to-User case.  When the requested principal is
      "principal@REALM", the responder MUST return a ticket whose server
      and client principals are "krbtgt/REALM@REALM" and
      "principal@REALM" respectively, so that the initiator can obtain a
      User-to-User service ticket at the KDC of the responder's realm.



>  - 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.

I don't have noticed it wasn't defined.  Thank you for pointing it
out.  I assumed "unparsed" representation, so your deal sounds good
to me.


-- 
KAMADA Ken'ichi <kamada@xxxxxxxxxx>