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

[Nicolas Williams <Nicolas.Williams@xxxxxxx>]

On Thu, Dec 01, 2005 at 01:14:31PM +0900, KAMADA Ken'ichi wrote:
> Thank you for your review.

And you for your reply.

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

Allow me to re-phrase: is the "requires" above intended to have the
force of "REQUIRED"?  If not, might it be better to replace it with
"expects"?

"KINK expects the initiator of an SA to be responsible for rekeying..."
would not have confused me... :)

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

Are initiators REQUIRED to rekey expired SAs, even when no outgoing
packets require them?  If not, how could the initiator know that there
are no packets on the server side in need of a rekeyed SA?

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

Right.

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

Yes, I like this.

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

Ok, so add text like this to your text above:

   PrincName values are octet string representations of a principal and
   realm name formatted just like the to the octet string used in the
   "NAME" component of GSS-API [RFC2743] exported name token for the
   Kerberos V GSS-API mechanism [RFC1964].  See RFC1964,
   section 2.1.3.

You'll have to add a normative reference to RFC1964.  And you'll have to
add an informative reference to RFC2743 (informative because the text in
RFC1964 is sufficient to implement figure out how to encode PrincName).

Nico
--