Subject: kink-09

From: Ken Raeburn <[email-masked]>
Date: Wed, 7 Sep 2005 15:08:29 -0400

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  
"[email-masked]" 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 [email-masked] and [email-masked], rather than  
[email-masked] 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.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Tue, 13 Sep 2005 14:56:45 +0900

Thank you very much for the review.

At Wed, 7 Sep 2005 15:08:29 -0400,
> would happily authenticate to that server.

Yes, "but see the Security Considerations section" is referring to
the first paragraph of the section.

- An insecure name service must not be consulted, without doubt.
- For name canonicalization (CNAME resolution), DNSSEC should be "secure".
- For IP address resolution (binding hostname and selector),
  DNSSEC may not always be enough.
  e.g., If somehost.good.example.com resolves to 10.0.0.1 and
	anotherhost.bad.example.com also resolves to 10.0.0.1,
	which do you believe?

> host/FOO$@REALM, or a little trickier, host/FOO$@REALM2?

You seems to have interpreted "obtained from some name services" as
"canonicalizing a name".  My intention was "getting an FQDN from an IP
address"; of course this isn't referring insecure DNS reverse
resolution.  There was no intention to forbid names that are not
beginning with "kink/".

# BTW, how other protocols define their naming convention?
# (e.g. "host/", "ftp/")

> services acting as users or clients), the users' principals would be  

To meet above comments, how about this for section 4.2.1:

   This document does not specify how to generate the principal name.
   That is, complete principal names may be stored in local policy,
   FQDNs may be converted to principal names, IP addresses may be
   converted to principal names by secure name services, etc; but see
   the first paragraph of the Security Considerations section.

   If the peer's principal name for the KINK service is generated from
   an FQDN, the principal name, which the initiator starts from, will
   be "kink/fqdn@REALM"; where "kink" is a literal string 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].

And the first paragraph of Security Consideration:

   The principal names are the identities of the KINK services, but
   the traffic protected by SAs are identified by DOI specific
   selectors (IP addresses, port numbers, etc).  This may lead to a
   breakaway of SA-protected data from authentication.  For example,
   if two different host claims that they have the same IP address, it
   may be impossible to predict which principal's key protect the
   data.  Thus, an implementation must take care for the binding
   between principal names and the SA selectors.

> referrals to get published first.

Does anyone have any idea on this?

Thanks,
-- 
KAMADA Ken'ichi <[email-masked]>

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 13 Sep 2005 04:09:44 -0400

>     anotherhost.bad.example.com also resolves to 10.0.0.1,

If you're doing host->address mapping, then DNSSEC for the domain  
you're querying should be fine.  If you're doing address->host  
mapping, then the mappings in {good,bad}.example.com don't matter,  
what matters is DNSSEC protection for 1.0.0.10.in-addr.arpa.

> resolution.  There was no intention to forbid names that are not

Sorry if I was reading this incorrectly.

> # BTW, how other protocols define their naming convention?

They do host/fqdn@REALM, but with referrals in place, it'll be okay  
if these names are just aliases.  None of the current protocols (that  
I'm aware of) for these service names do user-to-user, so there's no  
request for a TGT using a principal name that the KDC wouldn't get  
the chance to alter.

> To meet above comments, how about this for section 4.2.1:

That looks pretty good.

> Does anyone have any idea on this?

Not yet. :-(  It may be enough to use the text you suggested in 4.2.1  
as the way of initially generating the principal name, and have  
something in the referrals draft describe how changes to the name by  
the KDC should be handled in cases like this...

Ken

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Tue, 13 Sep 2005 19:14:00 +0900

At Tue, 13 Sep 2005 04:09:44 -0400,
> what matters is DNSSEC protection for 1.0.0.10.in-addr.arpa.

host->address was in my mind.
Suppose an environment where the granularity of SA or principal
is hosts.
Two users are on sharedhost.example.com, which has 10.0.0.9.
They wanted to be protected by KINK and typed somehost.good.example.com
and anotherhost.bad.example.com respectively.
And if, both hostnames were resolved to 10.0.0.1...

Then, what the KINK daemon on the sharedhost.example.com should do?
Which key should be used to protect the SAs between 10.0.0.9 and
10.0.0.1?

I don't think this is a KINK/Kerberos specific matter, though.

> Sorry if I was reading this incorrectly.

No, that was a problem of my writing, sorry.

---

From: Ken Raeburn <[email-masked]>
Date: Tue, 13 Sep 2005 14:02:41 -0400

> Which key should be used to protect the SAs between 10.0.0.9 and

Ah, I see.  Interesting...  I'm not sure what to do about this case.

> I don't think this is a KINK/Kerberos specific matter, though.

No, it isn't.  How would a non-Kerberos IPsec deployment deal with  
such a case?

Ken

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Wed, 14 Sep 2005 10:24:20 +0900

> high enough), it makes no sense to continue.

Do you assume that the SA lifetime is truncated to the ticket endtime?

Is the lifetime of application session limited to the service ticket
in usual Kerberized applications?
I.e., if I (kerberized-)telnet to a remote host with a service ticket,
what will happen when the ticket expires?  Is the telnet session
disconnected?
# I can't find something on this in RFC 4120 or RFC 2942.

Sidenote: at least when Key Exchange payloads are used,
a ticket and an SA will have independent lifetimes.

---

From: "KAMADA Ken'ichi" <[email-masked]>
Date: Wed, 14 Sep 2005 10:57:55 +0900

At Tue, 13 Sep 2005 14:02:41 -0400,
> No, it isn't.  How would a non-Kerberos IPsec deployment deal with  

In IKEv1 implementations for example, I believe they have the mapping
between phase1 IDs and selectors in their (local) configuration.
But I don't know how they manage about dynamic case, say road-worrier.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 23 Sep 2005 10:50:02 -0400

So have we come to consensus on how to handle these issues?
If there was a misunderstanding from the reading of the text,
then we should add some additional text to help ensure that
the same misunderstanding does not occur again.

We should rev the draft one last time with these clarifications
and then I'll pass the draft up to the IESG.

-derek

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Kazunori Miyazawa <[email-masked]>
Date: Fri, 30 Sep 2005 19:03:34 +0900

> a ticket and an SA will have independent lifetimes.

I think Mr. Raeburn might point that KINK should obtain new ticket before rekey
if the ticket is going to expire.

I accordingly thought we needed to change the 2nd paragraph in the section 3.6 to

    There are no special semantics for rekeying SAs in KINK.  That is, in
    order to rekey an existing SA, the initiator must CREATE a new SA
    followed by either deleting the old SA with the DELETE flow or
    letting it timeout (If the initiator needs a new service ticket
    it should obtain it in advance).  When identical flow selectors are
    available on different SAs, KINK implementations SHOULD choose the SA most
    recently created.  It should be noted that KINK avoids most of the
    problems of [IKE] rekeying by having a reliable delete mechanism.

But, I found in the section 3

    KINK uses Kerberos as the authentication mechanism, therefore a KINK
    host needs to get a service ticket for each peer before actual key
    negotiations.  This is basically a pure Kerberos exchange and the
    actual KDC traffic here is for illustrative purposes only.  In
    practice, when a principal obtains various tickets is a subject of
    Kerberos and local policy consideration.

I think when and how getting a servcice ticket is a local matter and
it does not cause interoperability issues so that we don't need the change.

-- 
Kazunori Miyazawa

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Sep 2005 08:21:49 -0700

What I'd appreciate here is some insight as to what other
Kerberized applications do, especially ones that have their
own session timers. If they all mimimize their lifetimes to
the extant of the kerberos ticket lifetime, then that pretty
much tells us we should too. If some are independant, then I
think it's probably a local policy decision of the receiver
assuming that the ISAKMP negotiation allows a longer proposed
lifetime to be shortened by the receiver. If that's the case,
then I don't think that the spec needs to recommend anything,
and if it does it should at most be a SHOULD.

		Mike

Kazunori Miyazawa wrote:
>>> (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.
>>
>>
>>

---

From: Ken Raeburn <[email-masked]>
Date: Fri, 30 Sep 2005 15:02:31 -0400

> Do you assume that the SA lifetime is truncated to the ticket endtime?

For some reason I was thinking it was, but now I see nothing in the  
draft to support that.

> # I can't find something on this in RFC 4120 or RFC 2942.

It depends on the application.  Sometimes the session dies  
immediately, sometimes the session is kept open indefinitely.

Sorry, I should've checked more closely....

Ken

---

From: Michael Thomas <[email-masked]>
Date: Fri, 30 Sep 2005 12:44:12 -0700

Ken Raeburn wrote:
> It depends on the application.  Sometimes the session dies  immediately, 
> sometimes the session is kept open indefinitely.
> 

Then so long as the IKE phase 2 negotiations have the
ability for the receiver to minimize the lifetime (which
I think it does), then I don't really think there's much
if anything that the spec needs to say about this.

		Mike