Subject: My comments on the KINK Requirements

From: Derek Atkins <[email-masked]>
Date: 04 Jan 2001 13:40:57 -0500

Mike (and everyone),

Here are my comments on the requirements draft.  I've put my comments
inline with your draft pieces (and I've cut out areas where I have no
comments).

-derek

Requirements

   KINK must meet the following requirements at a minimum:

-    The protocol must use Kerberos to create session keys in a secure
     fashion

A side effect of this is that the protocol must use the Kerberos
session key as part of the generation of IPSec keys.

-    The protocol must be able to start up SA's regardless of any
     client/server disposition in the keying protocol

In other words, either IPSec peer can be the initiator or responder,
regardless of whether it's a Kerberos 'client' (TGT-only) or Kerberos
'server' (has a keytab).

-    Kerberos makes a distinction between clients and servers; IPsec
     does not. The protocol must allow for IPsec security associations
     to be initiated by both servers and clients, thus preserving
     IPsec's peer to peer nature.

Isn't this the same thing, just said differently?

-    The protocol must be able to initially authenticate using either
     secret key, or public key authentication.

-    The protocol must accommodate any combination of public and secret
     key peers

I'm not convinced we need to reference public/secret key.  We just use
what Kerberos provides.  So, I think these two requirements can
probably be rewritten to say:

  - The protocol must allow an initiator or a responder (or both) to
    authenticate with just a TGT (using Kerberos User-to-User).

[snip]

-    The protocol must be capable of rekeying without the assistance of
     the KDC if the session ticket is still valid

Using the phrase "Kerberos session ticket" is probably clearer.

The following sections do not belong in the requirements draft:

---------begin

Deliverables

     The working group's responsibilities are as follows:

-    Complete a protocol which meets the requirements outlined above

-    Keep all KINK working group documents moving along publication /
     standardization track.
   The list of the working group's current work items is as follows:

-    Define the base Kerberized Internet Negotiation of Keys protocol.

Goals and Milestones

Sep 2000      Consensus on requirements document

Dec 2000      Review drafts at Dec IETF

Jan 2001      Consensus on base draft protocol

Mar 2001      WG Last call on draft

Mar 2001-Jun 2001
              Interoperability Bakeoffs

Aug 2001      Interoperability results, decision to recycle or move for-
              ward

Administrativa

Chair(s):

  Derek Atkins <[email-masked]>

Document Editor:

  TBD

Internet Area Director(s):

  Jeffrey Schiller <[email-masked]>
  Marcus Leech <[email-masked]>

Internet Area Advisor:

TBD

Mailing Lists:

  General Discussion: [email-masked]
  To Subscribe: [email-masked]
  In Body: in body: subscribe ietf-kink
  Archive: ftp://

---------end

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Matthew Hur <[email-masked]>
Date: Thu, 18 Jan 2001 14:42:04 -0800

>     authenticate with just a TGT (using Kerberos User-to-User).

I'm not sure that this is very clear either.  How about:
  - The protocol must support Kerberos User-to-User mode for cases in which 
a principal does not have an entry in the Kerberos principal database (i.e. 
uses PKINIT).

---

From: Derek Atkins <[email-masked]>
Date: 19 Jan 2001 10:25:39 -0500

> a principal does not have an entry in the Kerberos principal database (i.e. 

Unfortunately this ignores the case where the principal DOES have an
entry in the KDC but doesn't have a keytab (i.e. a Kerberos User).
I was trying to cover both cases.  Perhaps:

  - The protocol must support Kerberos User-to-User mode for cases in
    which the initiator cannot obtain an AP_REQ for the responder
    (i.e. the responder is a PKINIT client) or the responder cannot
    decrypt and AP_REQ from the initiator (i.e. the ressponder doesn't
    have a Kerberos Keytab, just a TGT).

-derek

---

From: Michael Thomas <[email-masked]>
Date: Tue, 23 Jan 2001 16:51:21 -0800 (PST)

So, I'm trying to collect the conclusion of this thread to
finalize the requirements draft. I'd like to get this done
soon. 

I'll respond to each of these, and hopefully we can wrap
this up.

 > session key as part of the generation of IPSec keys.

Correct. Do you think we need to be explicit about the generation
part?

 > regardless of whether it's a Kerberos 'client' (TGT-only) or Kerberos

Correct.

 > Isn't this the same thing, just said differently?

Yeah, probably. Which version do you like better? :-)

 >     authenticate with just a TGT (using Kerberos User-to-User).

This is what lead to your discussion with Matt. I'm cool
with your final wording if Matt is.

 > Using the phrase "Kerberos session ticket" is probably clearer.

Ok.

 > The following sections do not belong in the requirements draft:

Right. Will nuke.

---

From: Derek Atkins <[email-masked]>
Date: 26 Jan 2001 15:04:43 -0500

> finalize the requirements draft. I'd like to get this done

Sounds like a plan :)

> Correct. Do you think we need to be explicit about the generation

Yes.  Jeff has asked (in the past) to make this an explicit
requirement.  So, we should be as explicit as we can.

>  > regardless of whether it's a Kerberos 'client' (TGT-only) or Kerberos

Ok, we should be more explicit (again, extra verbiage explaining what
you mean is "ok" -- we're not going for short bullet-point items :)

> Yeah, probably. Which version do you like better? :-)

Honestly, I don't think I have a preference.  Feel free to combine
them, however -- we should probably only have one requirement to a
customer.

> with your final wording if Matt is.

Ok.  Matt?

>  > The following sections do not belong in the requirements draft:

Wonderful.  I look forward to seeing another draft.

-derek

---

From: Michael Thomas <[email-masked]>
Date: Mon, 29 Jan 2001 10:01:42 -0800 (PST)

Great. I'll get the new draft out asap.

	    Mike
Matthew Hur writes:
 > At 03:04 PM 1/26/2001 -0500, Derek Atkins wrote:
 > OK by me.

---

From: Matthew Hur <[email-masked]>
Date: Mon, 29 Jan 2001 09:56:53 -0800

OK by me.