Subject: I-D ACTION:draft-ietf-kink-reqmt-03.txt

From: [email-masked]
Date: Wed, 02 May 2001 07:37:18 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Kerberized Internet Negotiation of Keys Working Group of the IETF.

	Title		: Requirements for Kerberized Internet Negotiation of 
                          Keys
	Author(s)	: M. Thomas
	Filename	: draft-ietf-kink-reqmt-03.txt
	Pages		: 5
	Date		: 01-May-01
	
The KINK working group is chartered to create a standards track
protocol to facilitate centralized key management for IPsec security
associations as defined in RFC 2401, as an alternative to IKE (RFC
2409).  Participating systems will use the Kerberos architecture as
defined in RFC 1510 (and its successors) for key management. The goal
of the working group is to produce a streamlined, fast, easily
managed, and cryptographically sound protocol without requiring
public key.
The working group will not require changes to either IPsec (RFC
2401), or Kerberos (RFC 1510).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-kink-reqmt-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-kink-reqmt-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-kink-reqmt-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Rohit Aradhya <[email-masked]>
Date: Wed, 02 May 2001 18:30:28 +0530

Hi,
    I have following observations regarding this draft.. 'really appriciate  any clearifications

In the requirements sections of the draft.

1.  Most of the requirements specified here are met by the  Packet cable specification
(PKT-SP-SEC-I01-991201) document,  is this draft has some special requirements which are currently not
supported by Packet Cable Spec mentioned above.
2.  In third hyphen of the requirements section.. if i am interpreting it correctly.. does this mean
to say..  It should be possible to start SA negotiation from either  hosts participating.  OR  just
send a wakeup from one host and always the AP_REQ starts from another machine.
3.  Can anybody clearify what is User-to-User mode and its significance.?
4.  The requirement for Multiple realms -- It should be a requirement mostly for KDC?

-B.Regards
   Rohit

[email-masked] wrote:

>   ------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[email-masked]>

--
--------------------------------------------------------
 [x] General Business Information
 [ ] Motorola Internal Use only
 [ ] Motorola Confidential Proprietary
--------------------------------------------------------
--------------------------------------------------------
Rohit Aradhya, Motorola Banglore, India
Ph- (080)5598615  X-4005

---

From: Derek Atkins <[email-masked]>
Date: 08 May 2001 13:49:04 -0400

Rohit Aradhya <[email-masked]> writes:

> 1.  Most of the requirements specified here are met by the Packet
> cable specification (PKT-SP-SEC-I01-991201) document, is this draft
> has some special requirements which are currently not supported by
> Packet Cable Spec mentioned above.

Considering that KINK is somewhat derived from PacketCable, it isn't
surprising that the requirements appear to mostly be met by the
PacketCable specification.  However, I'm not convinced that
PacketCable meets ALL the requirements of KINK.

> 2.  In third hyphen of the requirements section.. if i am
> interpreting it correctly.. does this mean to say..  It should be
> possible to start SA negotiation from either hosts participating.
> OR just send a wakeup from one host and always the AP_REQ starts
> from another machine.

It means that the complete KINK protocol must allow either
participating host to initiate an SA negotiation.  HOW that is met is
a matter for the actual protocol and is out-of-scope for the
requirements themselves.  This may involve a handoff, or it may
involve a direct authentication, or it may involve a request for a TGT
to perform U-2-U.

> 3.  Can anybody clearify what is User-to-User mode and its significance.?

Read RFC 1510.  User-to-user allows a "responder" (i.e. a "server") to
have just a TGT and not a kerberos keytab.  In other words, it allows
a Kerberos "client" (an entity with just a TGT) to act as a service
provider.

> requirement mostly for KDC?

Not necessarily.  This is an issue in terms of naming at the KINK
protocol level.  You cannot just push it off to the KDCs.  Otherwise a
protocol may just assume that all entities are in the same Kerberos
Realm, and that would be bad.

>    Rohit

-derek

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