kink-09

[Ken Raeburn <raeburn@xxxxxxx>]

Sorry this is so late, I've had some non-work disruptions going on  
lately.

Name canonicalization:

Section 4.2.1 says that the principal name that SHOULD be used for  
the service is kink/fqdn@REALM, with fqdn "obtained from some name  
services".  (It also says, "but see the Security Considerations  
section"; that section does touch on the binding between principal  
names and SA selectors, but it's not at all clear that that's what  
this is referring to.)

An insecure name service must not be consulted in determining the  
FQDN; otherwise, a spoofed DNS (or whatever) reply could tell the  
client, "that's an alias for server-1.black-hats.con", and the client  
would happily authenticate to that server.

In the Kerberos working group, there's a draft in the works to  
address this problem, draft-ietf-krb-wg-kerberos-referrals-06.txt.   
However, there may be some less than wonderful interactions.  For  
example, you make a request for a service name which may be an alias,  
and (if it's an alias in the realm of the KDC you're talking to, and  
if you requested canonicalization) you get back a ticket either for  
the correct service principal name, or (if the canonical name is not  
in the same realm as the alias) for a remote-realm TGS.  But the  
current draft is a bit fuzzy in the user-to-user case.

   The AP-REQ MUST request mutual authentication.  The principal name
   that the KINK service SHOULD use is "kink/fqdn@REALM", where "kink"
   is for the KINK IPsec service, "fqdn" is the fully qualified domain
   name of the service host, and "REALM" is the Kerberos realm of the
   service.  A principal name is case sensitive, and "fqdn" part  
MUST be
   lower case as described in [KERBEROS].  This document does not
   specify how to generate the principal name; complete principal names
   are stored in local policy, hostnames are obtained from some name
   services, etc; but see the Security Considerations section.

We've been considering some cases where aliases are entered in one  
realm, pointing to a principal in another realm, when there is no  
overlap between the administration of the two realms.  The type of  
example I keep bringing up is a DNS CNAME record added for  
convenience at one site, e.g., "gftp" in the local domain points to  
ftp.gnu.org, but requires less typing.  If you want to make Kerberos- 
authenticated connections to that host, either you need to  
canonicalize the hostname through secure DNS, which we can't just  
assume will happen, or the KDC needs to be able to tell the client  
the real realm and principal name to authenticate to.  A key point in  
this example is that the software on ftp.gnu.org has *no knowledge*  
of the other name assigned by some random site.

So there may be cases where kink/fqdn is not the real principal name  
used by the service.  What if kink/foo.dom.ain@REALM is an alias for  
host/FOO$@REALM, or a little trickier, host/FOO$@REALM2?


Non-PKINIT cases:

Can we describe a use case or two that doesn't involve PKINIT but  
does do user-to-user authentication?  They don't need to go into the  
document, but if we want to support them, we should make sure they  
don't have some ramifications we haven't allowed for.

I've come up with some possibilities:

1) User walks up to a public workstation (hardware reasonably  
protected, software completely hackable) and boots it off a CD  
(bypassing the workstation's possibly-hacked software) which contains  
a NetBSD Live! (or Knoppix or whatever) image, including Kerberos and  
IPsec software.  No secret key data here, but CA info and server  
names for the {company, university, secret government organization}  
are included in this customized version.  The user types in  
"nikita@xxxxxxxxxxxx" and a password, Kerberos tickets are acquired,  
and an IPsec session is established to the user's file/mail/ldap/ 
whatever server.

2) Some kind of multiuser variant of case #1, with different SAs for  
different users on the same client host, simultaneously.  Gets into  
some of the channel binding stuff Nico Williams has been working on.   
Probably not something we need to dig into much, as long as KINK  
allows for multiple SAs.

3) Imagine two instances of case #2 (or #1), where users on the two  
systems want to communicate peer-to-peer, not via some central  
server.  Now neither one has a kink/foo principal available.  In this  
case, I think it's okay to assume that at least one of the users will  
have to type in the name of the other, or at least be prompted to  
select "accept".  (Section 4.2.4 supports this.)  Probably on both  
sides.

4) Case #3, but to make it worse, put name canonicalization in the  
picture, and the two users have exchanged NT-ENTERPRISE principal  
names alice@xxxxxx and bob@xxxxxx, rather than  
Alice_Jones@xxxxxxxxxxxx and Robert_Smith@WORLD-DOMINATION-STRATEGIC- 
PLANNING.MS.COM, because the short names are what they log in with,  
use for email, etc.  Can they establish an IPsec session between  
them, securely?  Actually, this probably belongs on the krb-wg list;  
I'll bring it up there.


I *think* the upshot of these is:
 - SHOULD for using "kink/fqdn" may be too strong.  It's the name  
that should be started with (but canonicalization may change it) in  
the normal host-to-host case.  When users are involved (or maybe  
services acting as users or clients), the users' principals would be  
the logical choice.
 - While canonicalization hasn't been published yet, the KINK draft  
should allow for it.  In particular, when asking for a TGT for a  
particular principal, after we've tried non-u2u authentication and  
gotten referral data back and then been told that we have to do u2u,  
the canonical name is the one we should be asking for.  I haven't  
figured out good wording yet that allows for canonicalization without  
mentioning it explicitly, but I don't think we want to wait for  
referrals to get published first.


Relatively minor stuff:

- Introduction:

      Therefore, public key
    operations (if any) are limited and are amortized over the lifetime
    of the initial authentication operation to the KDC.  For example, a
    client may use a single public key exchange with the KDC to
    efficiently establish multiple SAs with many other servers in the
    realm of the KDC.

  I would argue that the "initial authentication operation to the  
KDC" is the AS exchange which typically lasts less than a second.   
The public key ops are amortized over the life of the acquired  
credentials.

     The reason is that since
   the keys are stored in the KDC, the number of principal keys is O(n)
   rather than O(n*m), where "n" is the number of clients and "m" is  
the
   number of servers.

  It would be O(n+m) instead of O(n); I'm not an expert on the IPsec  
world, but I wouldn't be so quick to assert that n always dwarfs m.

      Kerberos, like any internet protocol, does have
    its own security considerations.  You can find them discussed in
    [KERBEROS].

  That's security-considerations material, not introductory  
material.  In fact, I think the security considerations section  
already talks about it.

- Section 2:  "KINK directly reuses Quick Mode payloads defined in  
the section 5.5 of [IKE], with some minor changes and omissions."   
Drop "the".

- Section 3.6: One case that might be worth mentioning is when the  
user's tickets are going to expire at the end of the "hard lifetime  
by time" of the SA.  In that case, unless there's some other reason  
(lifetime by byte count?), there's no purpose in attempting to rekey,  
because the new SA will have the same expiration time.  (This sort of  
applies also in renewable-TGT or PKINIT or keytab cases when the KDC  
isn't available to issue a new TGT, but that could be seen as  
starting the rekey process and then failing.)  In some environments,  
it may make sense to prompt the user to re-enter their password, but  
until the new tickets are actually acquired (or the byte count gets  
high enough), it makes no sense to continue.

- Sections 4.2.1, 4.2.2: The descriptions of EPOCH use the phrase  
"across different restarts".  Different from what?  I think "across  
restarts" is better.

- Section 11:  "The KINK's use of Kerberos presents a couple of  
considerations."  Drop "the".

- Pages should end with a formfeed (control-L), not a caret and an  
"L".  RFC Editor can fix that up, but if there's need for a -10 and  
it's not too hard (perhaps with post-processing), it'd be nice to fix  
it.