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

[Jeffrey Hutzelman]

The KINK protocol (Kerberized IPsec) is now in its second IETF-wide Last
Call (the last was in 2002).  Participants in this WG are encouraged to
review the document and send in their comments.

In addition, we have received a request to allocate two key usage numbers
for KINK, in accordance with the requirements of RFC4120 section 9.  Derek
Atkins, chair of KINK, has forwarded to me the following description of
what the numbers will be used for, taken from the KINK document:

> 8.  Key Usage Numbers for Kerberos Key Derivation
>
>    Kerberos encrypt/decrypt functions and get_mic/verify_mic functions
>    require "key usage numbers".  They are used to generate specific keys
>    for cryptographic operations so that different keys are used for
>    different purposes/objects.  KINK uses two usage numbers listed
>    below.
>
>       Purpose                           Usage number
>       -------                           ------------
>       KINK_ENCRYPT (for encryption)     XXX -- TBA by rfc1510ter
>       Cksum (for checksum)              XXX -- TBA by rfc1510ter

If there are any comments or objections to assigning numbers for these key
usages, please raise them on this list sometime in the next two weeks.  If
there are none by the time the IETF Last Call on KINK expires on Dec 12,
2005, I will ask Tom to select numbers and update the registry.

-- Jeff



---------- Forwarded Message ----------
Date: Monday, November 28, 2005 01:42:59 PM -0500
From: The IESG <[hidden email]>
To: IETF-Announce <[hidden email]>
Subject: Last Call: 'Kerberized Internet Negotiation of Keys (KINK)' to
Proposed Standard

The IESG has received a request from the Kerberized Internet Negotiation of
Keys WG to consider the following document:

- 'Kerberized Internet Negotiation of Keys (KINK) '
   <draft-ietf-kink-kink-10.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[hidden email] or [hidden email] mailing lists by 2005-12-12.

This draft was before the IETF in December of 2002 requesting last
call comments. The protocol has changed to address IESG comments and
because of evolution of Kerberos and IPsec in the following years.
This second last call requests comments on the changes introduced in
the protocol since 2002. Even given this long delaythere is still
active interest in the work and in implementations of Kink.

We would like to thank the Kink working group for their perseverance and
apologize for the length of the delay.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-kink-kink-10.txt


_______________________________________________
IETF-Announce mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf-announce


---------- End Forwarded Message ----------

[Nicolas Williams]

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

[Sam Hartman-5]

>>>>> "Nicolas" == Nicolas Williams <[hidden email]> writes:


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

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

Nico, these are phase 2 IDs.  I.E. they describe the SA, not the
parties involved.

I'm afraid you are living in an IKEV2 world where terminology makes
sense.

[Chaskiel Grundman-3]

--On Tuesday, November 29, 2005 12:41:38 -0600 Nicolas Williams
<[hidden email]> wrote:

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

kink actually proscribes the use of sub-session keys:

4 KINK Message Format[....]
  o  Cksum (variable) -- Kerberos keyed checksum over the entire
      message excluding the Cksum field itself.[...] The key used
      MUST be the session key in the ticket.

7 ISAKMP Key Derivation [....]

o  SKEYID_d is the session key in the Kerberos service ticket from
      the AP-REQ.  Note that subkeys are not used in KINK and MUST be
      ignored if received.

This issue has been discussed in the past (multiple times even), and
bringing it up again will probably not result in anything other than wasted
time.


I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is
used, only that it
"is encrypted using the encryption algorithm specified by the etype of the
session key"

[Nicolas Williams]

On Tue, Nov 29, 2005 at 03:57:40PM -0500, Chaskiel M Grundman wrote:

> --On Tuesday, November 29, 2005 12:41:38 -0600 Nicolas Williams
> <[hidden email]> wrote:
>
> > - Sub-session key generation.
> > [...]
> kink actually proscribes the use of sub-session keys:
>
> 4 KINK Message Format[....]
>  o  Cksum (variable) -- Kerberos keyed checksum over the entire
>      message excluding the Cksum field itself.[...] The key used
>      MUST be the session key in the ticket.
>
> 7 ISAKMP Key Derivation [....]
>
> o  SKEYID_d is the session key in the Kerberos service ticket from
>      the AP-REQ.  Note that subkeys are not used in KINK and MUST be
>      ignored if received.
>
> This issue has been discussed in the past (multiple times even), and
> bringing it up again will probably not result in anything other than wasted
> time.

*nod*

> I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is
> used, only that it
> "is encrypted using the encryption algorithm specified by the etype of the
> session key"

Hmmm, mumble, mumble, reflection attacks, mumble, mumble.

Shouldn't KINK derive separate keys for each direction for the "cksum"
and KINK_ENCRYPT payload fields?  Or is there inherent protection from
reflection attacks in the actual message flow?

[Nicolas Williams]

On Tue, Nov 29, 2005 at 03:40:19PM -0500, Sam Hartman wrote:
> Nico, these are phase 2 IDs.  I.E. they describe the SA, not the
> parties involved.
>
> I'm afraid you are living in an IKEV2 world where terminology makes
> sense.

Ah, sorry.

Ok, so I will assume that authorization is out of scope for KINK.

Nico
--

[Chaskiel Grundman-3]

> 4.2.3.  KINK_KRB_ERROR Payload [...]
>
>   KINK implementations MUST make use of a KINK Cksum field when
>   returning KINK_KRB_ERROR and the appropriate service key is
>   available.  In particular, clock skew errors MUST be integrity
>   protected.

The kerberos API, such as it is, does not guarantee that the application
will have access to the ticket session key if KRB5KRB_AP_ERR_SKEW is
returned from krb5_rd_req. neither mit krb5 nor heimdal return the
decrypted ticket if krb5_rd_req fails. (current releases of heimdal do not
check for clock skew in krb5_rd_req! This will be corrected in a future
release) It does not appear that either implementation updates the keyblock
stored in the auth_context until after all authenticator checks are
complete, so that copy of the key is not available to the application
either.

While implementation concerns like this are not usually critical, in this
case, I think they should be considered, since it is far more likely that
this part of the spec will be ignored than the kerberos implementations be
extended to make it possible for kink implementations to conform to it.

I do not recommend just removing the integrity protection requirement from
skew errors. if integrity for skew errors was not required, an attacker
might be able to coerce an initiator into producing an AP_REQ that is
invalid now, but could be successfully replayed at a later time.

[Nicolas Williams]

On Tue, Nov 29, 2005 at 06:01:15PM -0500, Chaskiel M Grundman wrote:

> >4.2.3.  KINK_KRB_ERROR Payload [...]
> >
> >  KINK implementations MUST make use of a KINK Cksum field when
> >  returning KINK_KRB_ERROR and the appropriate service key is
> >  available.  In particular, clock skew errors MUST be integrity
> >  protected.
>
> The kerberos API, such as it is, does not guarantee that the application
> will have access to the ticket session key if KRB5KRB_AP_ERR_SKEW is
> returned from krb5_rd_req. neither mit krb5 nor heimdal return the
> decrypted ticket if krb5_rd_req fails. (current releases of heimdal do not
> check for clock skew in krb5_rd_req! This will be corrected in a future
> release) It does not appear that either implementation updates the keyblock
> stored in the auth_context until after all authenticator checks are
> complete, so that copy of the key is not available to the application
> either.

There is no standard krb5 API...

> While implementation concerns like this are not usually critical, in this
> case, I think they should be considered, since it is far more likely that
> this part of the spec will be ignored than the kerberos implementations be
> extended to make it possible for kink implementations to conform to it.

...but I tend to agree.

Ultimately some error notifications simply cannot be integrity
protected, so initiators must be prepared to receive such notifications
and deal with them, either by giving up early or retrying with a
timeout.  Attempting to do better than Kerberos V itself does for error
messages seems likely to create API problems.

The value of protecting skew error messages is this: clients can work
around server-side skew when otherwise they could not.

Such a feature too would require API work: krb5_rd_rep*() would need a
way to output skew between the client and server, and krb5_mk_req*()
would need a skew input (that would have to be used very, very
carefully).

Is it wise for Kerberos V applications to be doing this sort of thing?

And should Kerberos V clients ever correct for skew other than that
between the client and the KDC?

Why can't the servers do their own KDC exchanges to discover server-side
skew?  (Why, for u2u they'd be engaging in such KDC exchanges anyways...)

I'm convinced, I think.  This feature should be removed.

Nico
--

[KAMADA Ken'ichi]

At Tue, 29 Nov 2005 15:39:04 -0600,
Nicolas Williams <[hidden email]> wrote:

>
> > I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is
> > used, only that it
> > "is encrypted using the encryption algorithm specified by the etype of the
> > session key"
>
> Hmmm, mumble, mumble, reflection attacks, mumble, mumble.
>
> Shouldn't KINK derive separate keys for each direction for the "cksum"
> and KINK_ENCRYPT payload fields?  Or is there inherent protection from
> reflection attacks in the actual message flow?

The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP) with the
Cksum field.
I thought it is enough to prevent reflection.  Isn't it?

--
KAMADA Ken'ichi <[hidden email]>

[KAMADA Ken'ichi]

At Tue, 29 Nov 2005 17:31:37 -0600,
Nicolas Williams <[hidden email]> wrote:

>
> > While implementation concerns like this are not usually critical, in this
> > case, I think they should be considered, since it is far more likely that
> > this part of the spec will be ignored than the kerberos implementations be
> > extended to make it possible for kink implementations to conform to it.
>
> ...but I tend to agree.
>
> Ultimately some error notifications simply cannot be integrity
> protected, so initiators must be prepared to receive such notifications
> and deal with them, either by giving up early or retrying with a
> timeout.  Attempting to do better than Kerberos V itself does for error
> messages seems likely to create API problems.
>
> The value of protecting skew error messages is this: clients can work
> around server-side skew when otherwise they could not.
>
> Such a feature too would require API work: krb5_rd_rep*() would need a
> way to output skew between the client and server, and krb5_mk_req*()
> would need a skew input (that would have to be used very, very
> carefully).
>
> Is it wise for Kerberos V applications to be doing this sort of thing?

When I was implementing this part of the spec using MIT krb5 and
Heimdal (when I was not yet involved with editing the draft), it was
much of a bother, though not impossible with accessing the library
internals.  The code is included in
ftp://ftp.kame.net/pub/racoon2/racoon2-20051102a.tgz, but is very
dirty, over-familiar with the library, and fragile with library
upgrades.

On the other hand, rfc1510ter will have checksummed KRB-ERROR.
Doesn't that mean we need API work anyway when rfc1510ter is
standardized, in order to extract key on the failure of krb5_rd_req()?

--
KAMADA Ken'ichi <[hidden email]>

[Nicolas Williams]

On Tue, Nov 29, 2005 at 03:39:04PM -0600, Nicolas Williams wrote:

> On Tue, Nov 29, 2005 at 03:57:40PM -0500, Chaskiel M Grundman wrote:
> > I did notice that section 4.2.7 KINK_ENCRYPT does not specify what key is
> > used, only that it
> > "is encrypted using the encryption algorithm specified by the etype of the
> > session key"
>
> Hmmm, mumble, mumble, reflection attacks, mumble, mumble.
>
> Shouldn't KINK derive separate keys for each direction for the "cksum"
> and KINK_ENCRYPT payload fields?  Or is there inherent protection from
> reflection attacks in the actual message flow?

Well, I also note stuff like: "[The XID] is not used for replay
protection because that functionality is provided by Kerberos."

But KINK isn't using KRB-SAFE or KRB-PRIV, it's using raw KCRYPTO!

So the only place that KINK gets replay protection for free from
Kerberos V is in the AP exchange.  So, how exactly does KINK get "replay
protection of key management messages," a goal stated in the first
paragraph of the introduction?  Did I miss something?


Another problem is that there seems to be no way of tying a particular
KINK message, making use of a Kerberos V key, to a given AP exchange/
Ticket.  This might be fine for a KE that follows the IKEv1/RFC2401
model, but it seems to me that it isn't fine in an IKEv2/RFC2401bis
world.



Nico
--

[Sam Hartman-5]

>>>>> "KAMADA" == KAMADA Ken'ichi <[hidden email]> writes:


    KAMADA> The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP)
    KAMADA> with the Cksum field.  I thought it is enough to prevent
    KAMADA> reflection.  Isn't it?

I believe so.

[Nicolas Williams]

On Wed, Nov 30, 2005 at 11:07:35AM -0600, Nicolas Williams wrote:
> So the only place that KINK gets replay protection for free from
> Kerberos V is in the AP exchange.  So, how exactly does KINK get "replay
> protection of key management messages," a goal stated in the first
> paragraph of the introduction?  Did I miss something?

Yes, I missed something: every KINK message has an AP-REQ or AP-REP (or
KRB-ERROR).

The KINK "checksum" field and KINK_ENCRYPT payload use keys derived from
the session key of the Ticket, which would normally mean that Ticket
reuse implies key reuse which brings replay protection into question.
But the presence of an AP-REQ or AP-REP in the KINK message that is part
of the checksum input means that key reuse is not enough to lead to
replays, and the presence of timestamps in the Authenticator and AP-REP
enc part means that the inputs to the checksum cannot be replayed unless
time goes backwards, and the requirement that the AP-REP timestamps
match the AP-REQ timestamps provides replay protection to the client.

This also answers my question about reflection attacks.

Is this analysis correct?

Nico
--

[Nicolas Williams]

On Wed, Nov 30, 2005 at 12:24:13PM -0500, Sam Hartman wrote:
> >>>>> "KAMADA" == KAMADA Ken'ichi <[hidden email]> writes:
>
>
>     KAMADA> The KINK_ENCRYPT payload is tied with AP-REQ (or AP-REP)
>     KAMADA> with the Cksum field.  I thought it is enough to prevent
>     KAMADA> reflection.  Isn't it?
>
> I believe so.

Yes, I had not noticed that all KINK messages have an AP-REQ, AP-REP or
KRB-ERROR.

Nico
--

[Michael Thomas-2]

Nicolas Williams wrote:

> On Wed, Nov 30, 2005 at 11:07:35AM -0600, Nicolas Williams wrote:
>
>>So the only place that KINK gets replay protection for free from
>>Kerberos V is in the AP exchange.  So, how exactly does KINK get "replay
>>protection of key management messages," a goal stated in the first
>>paragraph of the introduction?  Did I miss something?
>
>
> Yes, I missed something: every KINK message has an AP-REQ or AP-REP (or
> KRB-ERROR).
>
> The KINK "checksum" field and KINK_ENCRYPT payload use keys derived from
> the session key of the Ticket, which would normally mean that Ticket
> reuse implies key reuse which brings replay protection into question.
> But the presence of an AP-REQ or AP-REP in the KINK message that is part
> of the checksum input means that key reuse is not enough to lead to
> replays, and the presence of timestamps in the Authenticator and AP-REP
> enc part means that the inputs to the checksum cannot be replayed unless
> time goes backwards, and the requirement that the AP-REP timestamps
> match the AP-REQ timestamps provides replay protection to the client.
>
> This also answers my question about reflection attacks.
>
> Is this analysis correct?

That's pretty much how I remember it.

                Mike

[KAMADA Ken'ichi]

Thank you for your review.

At Tue, 29 Nov 2005 12:41:38 -0600,
Nicolas Williams <[hidden email]> 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 <[hidden email]>

[Nicolas Williams]

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 <[hidden email]> 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
--

[Nicolas Williams]

On Thu, Dec 01, 2005 at 01:14:31PM +0900, KAMADA Ken'ichi wrote:

> At Tue, 29 Nov 2005 12:41:38 -0600,
> Nicolas Williams <[hidden email]> wrote:
> >  - 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.)

Right, I was confused -- Sam explained how I got confused.

It would be nice if KINK supported IKEv2-style traffic selectors, but I
assume that's out of scope here.

Nico
--