From owner-ietf-kink@mail.vpnc.org Mon Nov 20 10:38:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13110 for ; Mon, 20 Nov 2000 10:38:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA15753 for ietf-kink-bks; Mon, 20 Nov 2000 07:29:50 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA15742 for ; Mon, 20 Nov 2000 07:29:49 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id KAA28359; Mon, 20 Nov 2000 10:30:25 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <97DEDE66B3DCD11199D200805FA71BE202FD4887@ntas0027.gi.com> From: Derek Atkins Date: 20 Nov 2000 10:30:24 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Tue, 14 Nov 2000 15:15:12 -0500" Message-ID: Lines: 19 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Medvinsky, Sasha (SD-EX)" writes: > Also, the client should really have an Access Control List of the servers it > wants to talk to and would not normally respond to a request from a server > it doesn't know about. Even if a client did respond to any such server - > the KDC has only a limited number of them in its database. This doesn't make sense in the KINK framework. KINK is meant as a peer-to-peer protocol. You cannot expect a KINK Peer to necessarily know what other peers to expect to talk to it. I think you are applying PacketCable architecture requirements to KINK, in a way that those requirements do not apply. -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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 14:01:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24431 for ; Mon, 20 Nov 2000 14:01:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA04900 for ietf-kink-bks; Mon, 20 Nov 2000 10:56:15 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04895 for ; Mon, 20 Nov 2000 10:56:12 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWRE8LVTPEEZS0H2@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 10:56:18 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 10:55:10 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 13:58:29 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Derek Atkins'" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48AC@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek, KINK is a peer-to-peer protocol, but Kerberos is not. A client-server architecture is more commonly used with Kerberos than the user-to-user case. I would say Kerberos looses some of its advantages when it is used in the user-to-user mode. There is nothing special about the PacketCable architecture, except that it assumes a client-server architecture and I don't think that we should exclude it from KINK. Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@MIT.EDU] > Sent: Monday, November 20, 2000 7:30 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > "Medvinsky, Sasha (SD-EX)" writes: > > > Also, the client should really have an Access Control List > of the servers it > > wants to talk to and would not normally respond to a > request from a server > > it doesn't know about. Even if a client did respond to any > such server - > > the KDC has only a limited number of them in its database. > > This doesn't make sense in the KINK framework. KINK is meant as a > peer-to-peer protocol. You cannot expect a KINK Peer to necessarily > know what other peers to expect to talk to it. I think you are > applying PacketCable architecture requirements to KINK, in a way that > those requirements do not apply. > > -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 N1NWH > warlord@MIT.EDU PGP key available > From owner-ietf-kink@mail.vpnc.org Mon Nov 20 14:12:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26635 for ; Mon, 20 Nov 2000 14:12:49 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05178 for ietf-kink-bks; Mon, 20 Nov 2000 11:05:48 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05174 for ; Mon, 20 Nov 2000 11:05:46 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA06373; Mon, 20 Nov 2000 12:06:25 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id OAA23833; Mon, 20 Nov 2000 14:06:25 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKJ5ha235660; Mon, 20 Nov 2000 14:05:43 -0500 (EST) Message-Id: <200011201905.eAKJ5ha235660@thunk.east.sun.com> From: Bill Sommerfeld To: "Medvinsky, Sasha (SD-EX)" cc: "'Derek Atkins'" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 13:58:29 EST." <97DEDE66B3DCD11199D200805FA71BE202FD48AC@ntas0027.gi.com> Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 14:05:43 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > KINK is a peer-to-peer protocol, yes > but Kerberos is not. kerberos is a 3-party protocol involving a KDC and two principals. All principals in possession of their long term key can trivially do peer-to-peer authentication. the user-to-user extension in kerberos v5 also lets "clients" which only have a TGT do peer-to-peer authentication without posession of the long-term key. - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 14:20:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28264 for ; Mon, 20 Nov 2000 14:20:12 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05361 for ietf-kink-bks; Mon, 20 Nov 2000 11:10:15 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05357 for ; Mon, 20 Nov 2000 11:10:14 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA28576; Mon, 20 Nov 2000 14:10:53 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <97DEDE66B3DCD11199D200805FA71BE202FD48AC@ntas0027.gi.com> From: Derek Atkins Date: 20 Nov 2000 14:10:52 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Mon, 20 Nov 2000 13:58:29 -0500" Message-ID: Lines: 37 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Medvinsky, Sasha (SD-EX)" writes: > Derek, > > KINK is a peer-to-peer protocol, but Kerberos is not. A client-server > architecture is more commonly used with Kerberos than the user-to-user case. > I would say Kerberos looses some of its advantages when it is used in the > user-to-user mode. > > There is nothing special about the PacketCable architecture, except that it > assumes a client-server architecture and I don't think that we should > exclude it from KINK. > > Sasha. The special case of PacketCable is that servers may need to initiate IPSec with clients, but you don't want to have the server store keys. So, you want to be able to securely "handoff" the authentication to the clients, via a wakeup or other mechanism. What this amounts to is the application server telling the application client something like "I want to authenticate to you, so initiate an authentication to me". This is particularly a problem with PKINIT entities, as you cannot obtain an AP_REQ for a PKINIT ID. I believe that the latter problem is one that KINK will have to solve (most likely by using user-2-user, initiated by either party). However, I do believe that the former is out-of-scope for KINK. I don't think KINK should try to worry about forcing the initiator of sessions. -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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 14:22:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28743 for ; Mon, 20 Nov 2000 14:22:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05349 for ietf-kink-bks; Mon, 20 Nov 2000 11:10:09 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05345 for ; Mon, 20 Nov 2000 11:10:08 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWREPUBEIWEZRYXM@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 11:10:16 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 11:09:03 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 14:12:24 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'sommerfeld@east.sun.com'" Cc: "'Derek Atkins'" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48B0@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: All I was saying is that although you can do peer-to-peer authentication with Kerberos, you shouldn't require it for an architecture where you don't have a peer-to-peer relationship. Sasha. > -----Original Message----- > From: Bill Sommerfeld [mailto:sommerfeld@east.sun.com] > Sent: Monday, November 20, 2000 11:06 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Derek Atkins'; 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > KINK is a peer-to-peer protocol, > > yes > > > but Kerberos is not. > > kerberos is a 3-party protocol involving a KDC and two principals. > > All principals in possession of their long term key can trivially do > peer-to-peer authentication. the user-to-user extension in kerberos > v5 also lets "clients" which only have a TGT do peer-to-peer > authentication without posession of the long-term key. > > - Bill > From owner-ietf-kink@mail.vpnc.org Mon Nov 20 14:23:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28833 for ; Mon, 20 Nov 2000 14:23:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05470 for ietf-kink-bks; Mon, 20 Nov 2000 11:14:32 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05466 for ; Mon, 20 Nov 2000 11:14:30 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWREV9SW9GEZS3R0@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 11:14:43 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 11:13:26 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 14:16:47 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Derek Atkins'" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48B1@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: What makes this "hand-off of authentication to clients" out of scope for KINK? Sasha. > -----Original Message----- > From: Derek Atkins [mailto:warlord@mit.edu] > Sent: Monday, November 20, 2000 11:11 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > "Medvinsky, Sasha (SD-EX)" writes: > > > Derek, > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > client-server > > architecture is more commonly used with Kerberos than the > user-to-user case. > > I would say Kerberos looses some of its advantages when it > is used in the > > user-to-user mode. > > > > There is nothing special about the PacketCable > architecture, except that it > > assumes a client-server architecture and I don't think that > we should > > exclude it from KINK. > > > > Sasha. > > The special case of PacketCable is that servers may need to initiate > IPSec with clients, but you don't want to have the server store keys. > So, you want to be able to securely "handoff" the authentication to > the clients, via a wakeup or other mechanism. What this amounts to is > the application server telling the application client something like > "I want to authenticate to you, so initiate an authentication to me". > This is particularly a problem with PKINIT entities, as you cannot > obtain an AP_REQ for a PKINIT ID. > > I believe that the latter problem is one that KINK will have to solve > (most likely by using user-2-user, initiated by either party). > However, I do believe that the former is out-of-scope for KINK. I > don't think KINK should try to worry about forcing the initiator of > sessions. > > -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 N1NWH > warlord@MIT.EDU PGP key available > From owner-ietf-kink@mail.vpnc.org Mon Nov 20 14:40:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01890 for ; Mon, 20 Nov 2000 14:40:55 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA06707 for ietf-kink-bks; Mon, 20 Nov 2000 11:33:21 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06703 for ; Mon, 20 Nov 2000 11:33:20 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA28591; Mon, 20 Nov 2000 14:34:02 -0500 To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <97DEDE66B3DCD11199D200805FA71BE202FD48B1@ntas0027.gi.com> From: Derek Atkins Date: 20 Nov 2000 14:34:02 -0500 In-Reply-To: "Medvinsky, Sasha's message of "Mon, 20 Nov 2000 14:16:47 -0500" Message-ID: Lines: 95 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I consider it out of scope because it adds uncesseary complexity to the general KINK protocol. It is complexity that perhaps PacketCable needs (or, more likely, wants), but it is not complexity that makes sense, IMHO, for a general-purpose IPSec key management protocol. It either forces us to add options to the protcol (thereby adding complexity), or it forces us to always handoff authentication and design a secure way to doing so (also adding complextity). The problem is that there is no way to always know a priori whether a peer is a PKINIT peer (where PKINIT peer is one that only has a TGT to work with, which implies normal users as well as PKINIT-based hosts) or a normal peer. In order to reduce complexity in KINK we have to optimize for either PKINIT or non-PKINIT peers. I believe that non-PKINIT peers are the "normal" case (namely, hosts with krb5 keytabs). Based upon this assumption (we should probably discuss whether this assumption has merits), we should optimize the protocol for non-PKINIT. This implies that we should try normal Kerberos, and if we cannot obtain an AP_REQ, then we try U2U. It means an extra round-trip to the KDC in the case of a PKINIT peer the first time we try to authenticate. We can always cache U2U tickets. Alternately, if we optimize for PKINIT peers, we should just use U2U at all times. However, in neither case do we try to offload authentication from one entity to the other. The initiator is always the initiator, the responder is always the responder. Never are we trying to have the initiator tell the responder to initiate authentication. -derek "Medvinsky, Sasha (SD-EX)" writes: > What makes this "hand-off of authentication to clients" out of scope for > KINK? > > Sasha. > > > -----Original Message----- > > From: Derek Atkins [mailto:warlord@mit.edu] > > Sent: Monday, November 20, 2000 11:11 AM > > To: Medvinsky, Sasha (SD-EX) > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > Derek, > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > client-server > > > architecture is more commonly used with Kerberos than the > > user-to-user case. > > > I would say Kerberos looses some of its advantages when it > > is used in the > > > user-to-user mode. > > > > > > There is nothing special about the PacketCable > > architecture, except that it > > > assumes a client-server architecture and I don't think that > > we should > > > exclude it from KINK. > > > > > > Sasha. > > > > The special case of PacketCable is that servers may need to initiate > > IPSec with clients, but you don't want to have the server store keys. > > So, you want to be able to securely "handoff" the authentication to > > the clients, via a wakeup or other mechanism. What this amounts to is > > the application server telling the application client something like > > "I want to authenticate to you, so initiate an authentication to me". > > This is particularly a problem with PKINIT entities, as you cannot > > obtain an AP_REQ for a PKINIT ID. > > > > I believe that the latter problem is one that KINK will have to solve > > (most likely by using user-2-user, initiated by either party). > > However, I do believe that the former is out-of-scope for KINK. I > > don't think KINK should try to worry about forcing the initiator of > > sessions. > > > > -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 N1NWH > > warlord@MIT.EDU PGP key available > > -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 15:03:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06028 for ; Mon, 20 Nov 2000 15:03:25 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA08292 for ietf-kink-bks; Mon, 20 Nov 2000 11:54:59 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA08288 for ; Mon, 20 Nov 2000 11:54:58 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id LAA17904; Mon, 20 Nov 2000 11:55:07 -0800 (PST) Date: Mon, 20 Nov 2000 11:55:06 -0800 (PST) From: Jan Vilhuber To: Derek Atkins cc: "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As Michael pointed out a few weeks ago, if we assume some sort of enrollment protocol, that creates a shared secret between pkinit clients and KDC, then the pkinit case becomes the general case, i.e. anyone can initiate to a pkinit client, after the pkinit client has 'enrolled' with a KDC (and you wouldn't even need u-u). Rather than add complexity to KINK, I would prefer we put together an enrollment proposal, either within THIS group, or propose it in the kerberos WG. jan On 20 Nov 2000, Derek Atkins wrote: > I consider it out of scope because it adds uncesseary complexity to > the general KINK protocol. It is complexity that perhaps PacketCable > needs (or, more likely, wants), but it is not complexity that makes > sense, IMHO, for a general-purpose IPSec key management protocol. It > either forces us to add options to the protcol (thereby adding > complexity), or it forces us to always handoff authentication and > design a secure way to doing so (also adding complextity). > > The problem is that there is no way to always know a priori whether a > peer is a PKINIT peer (where PKINIT peer is one that only has a TGT to > work with, which implies normal users as well as PKINIT-based hosts) > or a normal peer. In order to reduce complexity in KINK we have to > optimize for either PKINIT or non-PKINIT peers. I believe that > non-PKINIT peers are the "normal" case (namely, hosts with krb5 > keytabs). > > Based upon this assumption (we should probably discuss whether this > assumption has merits), we should optimize the protocol for > non-PKINIT. This implies that we should try normal Kerberos, and if > we cannot obtain an AP_REQ, then we try U2U. It means an extra > round-trip to the KDC in the case of a PKINIT peer the first time we > try to authenticate. We can always cache U2U tickets. Alternately, > if we optimize for PKINIT peers, we should just use U2U at all times. > > However, in neither case do we try to offload authentication from one > entity to the other. The initiator is always the initiator, the > responder is always the responder. Never are we trying to have the > initiator tell the responder to initiate authentication. > > -derek > > "Medvinsky, Sasha (SD-EX)" writes: > > > What makes this "hand-off of authentication to clients" out of scope for > > KINK? > > > > Sasha. > > > > > -----Original Message----- > > > From: Derek Atkins [mailto:warlord@mit.edu] > > > Sent: Monday, November 20, 2000 11:11 AM > > > To: Medvinsky, Sasha (SD-EX) > > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > Derek, > > > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > > client-server > > > > architecture is more commonly used with Kerberos than the > > > user-to-user case. > > > > I would say Kerberos looses some of its advantages when it > > > is used in the > > > > user-to-user mode. > > > > > > > > There is nothing special about the PacketCable > > > architecture, except that it > > > > assumes a client-server architecture and I don't think that > > > we should > > > > exclude it from KINK. > > > > > > > > Sasha. > > > > > > The special case of PacketCable is that servers may need to initiate > > > IPSec with clients, but you don't want to have the server store keys. > > > So, you want to be able to securely "handoff" the authentication to > > > the clients, via a wakeup or other mechanism. What this amounts to is > > > the application server telling the application client something like > > > "I want to authenticate to you, so initiate an authentication to me". > > > This is particularly a problem with PKINIT entities, as you cannot > > > obtain an AP_REQ for a PKINIT ID. > > > > > > I believe that the latter problem is one that KINK will have to solve > > > (most likely by using user-2-user, initiated by either party). > > > However, I do believe that the former is out-of-scope for KINK. I > > > don't think KINK should try to worry about forcing the initiator of > > > sessions. > > > > > > -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 N1NWH > > > warlord@MIT.EDU PGP key available > > > > > -- > 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 N1NWH > warlord@MIT.EDU PGP key available > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 15:58:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15954 for ; Mon, 20 Nov 2000 15:58:08 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA10327 for ietf-kink-bks; Mon, 20 Nov 2000 12:45:40 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA10316 for ; Mon, 20 Nov 2000 12:45:35 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWRI2MW2N6EZS7UO@GI.COM> for ietf-kink@vpnc.org; Mon, 20 Nov 2000 12:46:03 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 20 Nov 2000 12:44:52 -0500 Content-return: allowed Date: Mon, 20 Nov 2000 15:48:09 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Jan Vilhuber'" , Derek Atkins Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48B4@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As I replied to Mike's email, this client enrollment would eliminate some of the disadvantages of the user-to-user mode (e.g. adding user policy/authorization into the tickets), but would still require a server to obtain/maintain tickets for its clients. I also listed benefits of not having to do that. Sasha. > -----Original Message----- > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > Sent: Monday, November 20, 2000 11:55 AM > To: Derek Atkins > Cc: Medvinsky, Sasha (SD-EX); 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > As Michael pointed out a few weeks ago, if we assume some > sort of enrollment > protocol, that creates a shared secret between pkinit clients > and KDC, then > the pkinit case becomes the general case, i.e. anyone can > initiate to a > pkinit client, after the pkinit client has 'enrolled' with a > KDC (and you > wouldn't even need u-u). > > Rather than add complexity to KINK, I would prefer we put together an > enrollment proposal, either within THIS group, or propose it > in the kerberos > WG. > > jan > > > > > On 20 Nov 2000, Derek Atkins wrote: > > > I consider it out of scope because it adds uncesseary complexity to > > the general KINK protocol. It is complexity that perhaps > PacketCable > > needs (or, more likely, wants), but it is not complexity that makes > > sense, IMHO, for a general-purpose IPSec key management > protocol. It > > either forces us to add options to the protcol (thereby adding > > complexity), or it forces us to always handoff authentication and > > design a secure way to doing so (also adding complextity). > > > > The problem is that there is no way to always know a priori > whether a > > peer is a PKINIT peer (where PKINIT peer is one that only > has a TGT to > > work with, which implies normal users as well as PKINIT-based hosts) > > or a normal peer. In order to reduce complexity in KINK we have to > > optimize for either PKINIT or non-PKINIT peers. I believe that > > non-PKINIT peers are the "normal" case (namely, hosts with krb5 > > keytabs). > > > > Based upon this assumption (we should probably discuss whether this > > assumption has merits), we should optimize the protocol for > > non-PKINIT. This implies that we should try normal Kerberos, and if > > we cannot obtain an AP_REQ, then we try U2U. It means an extra > > round-trip to the KDC in the case of a PKINIT peer the first time we > > try to authenticate. We can always cache U2U tickets. Alternately, > > if we optimize for PKINIT peers, we should just use U2U at > all times. > > > > However, in neither case do we try to offload > authentication from one > > entity to the other. The initiator is always the initiator, the > > responder is always the responder. Never are we trying to have the > > initiator tell the responder to initiate authentication. > > > > -derek > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > What makes this "hand-off of authentication to clients" > out of scope for > > > KINK? > > > > > > Sasha. > > > > > > > -----Original Message----- > > > > From: Derek Atkins [mailto:warlord@mit.edu] > > > > Sent: Monday, November 20, 2000 11:11 AM > > > > To: Medvinsky, Sasha (SD-EX) > > > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > > > Derek, > > > > > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > > > client-server > > > > > architecture is more commonly used with Kerberos than the > > > > user-to-user case. > > > > > I would say Kerberos looses some of its advantages when it > > > > is used in the > > > > > user-to-user mode. > > > > > > > > > > There is nothing special about the PacketCable > > > > architecture, except that it > > > > > assumes a client-server architecture and I don't think that > > > > we should > > > > > exclude it from KINK. > > > > > > > > > > Sasha. > > > > > > > > The special case of PacketCable is that servers may > need to initiate > > > > IPSec with clients, but you don't want to have the > server store keys. > > > > So, you want to be able to securely "handoff" the > authentication to > > > > the clients, via a wakeup or other mechanism. What > this amounts to is > > > > the application server telling the application client > something like > > > > "I want to authenticate to you, so initiate an > authentication to me". > > > > This is particularly a problem with PKINIT entities, as > you cannot > > > > obtain an AP_REQ for a PKINIT ID. > > > > > > > > I believe that the latter problem is one that KINK will > have to solve > > > > (most likely by using user-2-user, initiated by either party). > > > > However, I do believe that the former is out-of-scope > for KINK. I > > > > don't think KINK should try to worry about forcing the > initiator of > > > > sessions. > > > > > > > > -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 N1NWH > > > > warlord@MIT.EDU PGP key available > > > > > > > > -- > > 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 N1NWH > > warlord@MIT.EDU PGP key available > > > > -- > Jan Vilhuber > vilhuber@cisco.com > Cisco Systems, San Jose > (408) 527-0847 > From owner-ietf-kink@mail.vpnc.org Mon Nov 20 16:30:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20438 for ; Mon, 20 Nov 2000 16:30:23 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id NAA11922 for ietf-kink-bks; Mon, 20 Nov 2000 13:17:40 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA11918 for ; Mon, 20 Nov 2000 13:17:39 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA22711; Mon, 20 Nov 2000 13:17:20 -0800 (PST) Date: Mon, 20 Nov 2000 13:17:20 -0800 (PST) From: Jan Vilhuber To: "Medvinsky, Sasha (SD-EX)" cc: Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD48B4@ntas0027.gi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Medvinsky, Sasha (SD-EX) wrote: > As I replied to Mike's email, this client enrollment would eliminate some of > the disadvantages of the user-to-user mode (e.g. adding user > policy/authorization into the tickets), but would still require a server to > obtain/maintain tickets for its clients. Which gets back to the fact that KINK is for peer-to-peer, so any server is a client and any client is a server. So they all need to be principals in the KDC, so we need to enroll them. Unless you want to do u-u, I guess, which complicates things. I'd prefer to have them enrolled. jan > I also listed benefits of not > having to do that. > > Sasha. > > > > -----Original Message----- > > From: Jan Vilhuber [mailto:vilhuber@cisco.com] > > Sent: Monday, November 20, 2000 11:55 AM > > To: Derek Atkins > > Cc: Medvinsky, Sasha (SD-EX); 'Michael Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > As Michael pointed out a few weeks ago, if we assume some > > sort of enrollment > > protocol, that creates a shared secret between pkinit clients > > and KDC, then > > the pkinit case becomes the general case, i.e. anyone can > > initiate to a > > pkinit client, after the pkinit client has 'enrolled' with a > > KDC (and you > > wouldn't even need u-u). > > > > Rather than add complexity to KINK, I would prefer we put together an > > enrollment proposal, either within THIS group, or propose it > > in the kerberos > > WG. > > > > jan > > > > > > > > > > On 20 Nov 2000, Derek Atkins wrote: > > > > > I consider it out of scope because it adds uncesseary complexity to > > > the general KINK protocol. It is complexity that perhaps > > PacketCable > > > needs (or, more likely, wants), but it is not complexity that makes > > > sense, IMHO, for a general-purpose IPSec key management > > protocol. It > > > either forces us to add options to the protcol (thereby adding > > > complexity), or it forces us to always handoff authentication and > > > design a secure way to doing so (also adding complextity). > > > > > > The problem is that there is no way to always know a priori > > whether a > > > peer is a PKINIT peer (where PKINIT peer is one that only > > has a TGT to > > > work with, which implies normal users as well as PKINIT-based hosts) > > > or a normal peer. In order to reduce complexity in KINK we have to > > > optimize for either PKINIT or non-PKINIT peers. I believe that > > > non-PKINIT peers are the "normal" case (namely, hosts with krb5 > > > keytabs). > > > > > > Based upon this assumption (we should probably discuss whether this > > > assumption has merits), we should optimize the protocol for > > > non-PKINIT. This implies that we should try normal Kerberos, and if > > > we cannot obtain an AP_REQ, then we try U2U. It means an extra > > > round-trip to the KDC in the case of a PKINIT peer the first time we > > > try to authenticate. We can always cache U2U tickets. Alternately, > > > if we optimize for PKINIT peers, we should just use U2U at > > all times. > > > > > > However, in neither case do we try to offload > > authentication from one > > > entity to the other. The initiator is always the initiator, the > > > responder is always the responder. Never are we trying to have the > > > initiator tell the responder to initiate authentication. > > > > > > -derek > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > What makes this "hand-off of authentication to clients" > > out of scope for > > > > KINK? > > > > > > > > Sasha. > > > > > > > > > -----Original Message----- > > > > > From: Derek Atkins [mailto:warlord@mit.edu] > > > > > Sent: Monday, November 20, 2000 11:11 AM > > > > > To: Medvinsky, Sasha (SD-EX) > > > > > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > > > > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > > > > > > > > "Medvinsky, Sasha (SD-EX)" writes: > > > > > > > > > > > Derek, > > > > > > > > > > > > KINK is a peer-to-peer protocol, but Kerberos is not. A > > > > > client-server > > > > > > architecture is more commonly used with Kerberos than the > > > > > user-to-user case. > > > > > > I would say Kerberos looses some of its advantages when it > > > > > is used in the > > > > > > user-to-user mode. > > > > > > > > > > > > There is nothing special about the PacketCable > > > > > architecture, except that it > > > > > > assumes a client-server architecture and I don't think that > > > > > we should > > > > > > exclude it from KINK. > > > > > > > > > > > > Sasha. > > > > > > > > > > The special case of PacketCable is that servers may > > need to initiate > > > > > IPSec with clients, but you don't want to have the > > server store keys. > > > > > So, you want to be able to securely "handoff" the > > authentication to > > > > > the clients, via a wakeup or other mechanism. What > > this amounts to is > > > > > the application server telling the application client > > something like > > > > > "I want to authenticate to you, so initiate an > > authentication to me". > > > > > This is particularly a problem with PKINIT entities, as > > you cannot > > > > > obtain an AP_REQ for a PKINIT ID. > > > > > > > > > > I believe that the latter problem is one that KINK will > > have to solve > > > > > (most likely by using user-2-user, initiated by either party). > > > > > However, I do believe that the former is out-of-scope > > for KINK. I > > > > > don't think KINK should try to worry about forcing the > > initiator of > > > > > sessions. > > > > > > > > > > -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 N1NWH > > > > > warlord@MIT.EDU PGP key available > > > > > > > > > > > -- > > > 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 N1NWH > > > warlord@MIT.EDU PGP key available > > > > > > > -- > > Jan Vilhuber > > vilhuber@cisco.com > > Cisco Systems, San Jose > > (408) 527-0847 > > > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 16:35:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21297 for ; Mon, 20 Nov 2000 16:35:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12264 for ietf-kink-bks; Mon, 20 Nov 2000 13:25:25 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12260 for ; Mon, 20 Nov 2000 13:25:23 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA04997; Mon, 20 Nov 2000 13:26:02 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA25239; Mon, 20 Nov 2000 16:25:57 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKLPGa236169; Mon, 20 Nov 2000 16:25:16 -0500 (EST) Message-Id: <200011202125.eAKLPGa236169@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 13:17:20 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 16:25:15 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Unless you want to do u-u, I guess, which complicates things. I'd prefer to > have them enrolled. depends on how you measure complexity. i suspect a new enrollment protocol would be more complex than just using u-u. - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 16:39:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22372 for ; Mon, 20 Nov 2000 16:39:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12435 for ietf-kink-bks; Mon, 20 Nov 2000 13:31:37 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12431 for ; Mon, 20 Nov 2000 13:31:36 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA23427; Mon, 20 Nov 2000 13:31:15 -0800 (PST) Date: Mon, 20 Nov 2000 13:31:15 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202125.eAKLPGa236169@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > Unless you want to do u-u, I guess, which complicates things. I'd prefer to > > have them enrolled. > > depends on how you measure complexity. Agreed. I measure it in terms of added complexity WITHIN the same protocol. A new enrollment protocol may be somewhat complex, but this complexity is orthogonal to KINK, thus making KINK easier to analyze for security. Adding more exchanges for corner-cases certainly doesn't help people analyze it for weaknesses. > i suspect a new enrollment > protocol would be more complex than just using u-u. > But it may be usefull to other people as well. Two semi-complex protocols are better than one hyper-complex one. In my opinion, anyway. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 16:51:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25190 for ; Mon, 20 Nov 2000 16:51:16 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12660 for ietf-kink-bks; Mon, 20 Nov 2000 13:38:52 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12654 for ; Mon, 20 Nov 2000 13:38:51 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA13770; Mon, 20 Nov 2000 13:39:27 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id QAA28812; Mon, 20 Nov 2000 16:39:24 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKLcha236255; Mon, 20 Nov 2000 16:38:43 -0500 (EST) Message-Id: <200011202138.eAKLcha236255@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: Bill Sommerfeld , "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 13:31:15 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 16:38:42 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Agreed. I measure it in terms of added complexity WITHIN the same protocol. A > new enrollment protocol may be somewhat complex, but this complexity is > orthogonal to KINK, thus making KINK easier to analyze for security. Adding > more exchanges for corner-cases certainly doesn't help people analyze it for > weaknesses. true. i've suggested on numerous occasions that KINK should avoid this problem by always using user-to-user. - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 16:52:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25419 for ; Mon, 20 Nov 2000 16:52:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA12902 for ietf-kink-bks; Mon, 20 Nov 2000 13:46:52 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA12897 for ; Mon, 20 Nov 2000 13:46:50 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id NAA24233; Mon, 20 Nov 2000 13:46:30 -0800 (PST) Date: Mon, 20 Nov 2000 13:46:29 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202138.eAKLcha236255@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > Agreed. I measure it in terms of added complexity WITHIN the same protocol. A > > new enrollment protocol may be somewhat complex, but this complexity is > > orthogonal to KINK, thus making KINK easier to analyze for security. Adding > > more exchanges for corner-cases certainly doesn't help people analyze it for > > weaknesses. > > true. i've suggested on numerous occasions that KINK should avoid > this problem by always using user-to-user. > I guess that's one way. The other is to never use u-u, and force everyone to be a principal in the KDC. Not being 100% kerberos-expert, this appeals to me more, especially in light of the fact that a pkinit-enrollment may be usefull in other protocols/occasions (I'm guessing). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 17:36:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01608 for ; Mon, 20 Nov 2000 17:36:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14131 for ietf-kink-bks; Mon, 20 Nov 2000 14:30:30 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14127 for ; Mon, 20 Nov 2000 14:30:28 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id RAA28827; Mon, 20 Nov 2000 17:31:13 -0500 To: Jan Vilhuber Cc: Bill Sommerfeld , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: From: Derek Atkins Date: 20 Nov 2000 17:31:13 -0500 In-Reply-To: Jan Vilhuber's message of "Mon, 20 Nov 2000 13:46:29 -0800 (PST)" Message-ID: Lines: 30 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jan Vilhuber writes: > I guess that's one way. The other is to never use u-u, and force everyone to > be a principal in the KDC. Not being 100% kerberos-expert, this appeals to me > more, especially in light of the fact that a pkinit-enrollment may be usefull > in other protocols/occasions (I'm guessing). The problem is that this wont work for, a user being the responder. A user would be enrolled in the KDC, but they have a password, not a keytab. So, the system would only have a TGT credential to work with (although a foreign system would still be able to get a "valid" service-key response from the KDC). Perhaps we just don't care; or perhaps "users" can only be IPSec initiators. -derek > jan > -- > Jan Vilhuber vilhuber@cisco.com > Cisco Systems, San Jose (408) 527-0847 -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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 17:44:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02662 for ; Mon, 20 Nov 2000 17:44:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14300 for ietf-kink-bks; Mon, 20 Nov 2000 14:37:17 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14295 for ; Mon, 20 Nov 2000 14:37:15 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA09636; Mon, 20 Nov 2000 15:37:50 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id RAA23184; Mon, 20 Nov 2000 17:37:49 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKMb7a236351; Mon, 20 Nov 2000 17:37:07 -0500 (EST) Message-Id: <200011202237.eAKMb7a236351@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: Jan Vilhuber , Bill Sommerfeld , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 17:31:13 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 17:37:07 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Perhaps we just don't care; or perhaps "users" can only be IPSec > initiators. That won't work in the general case since many possible uses of ipsec require peer-to-peer keying. (or, rather, require either end to be able to initiate rekeying). - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:03:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05134 for ; Mon, 20 Nov 2000 18:03:24 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA14864 for ietf-kink-bks; Mon, 20 Nov 2000 14:56:27 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA14859 for ; Mon, 20 Nov 2000 14:56:25 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id RAA28842; Mon, 20 Nov 2000 17:57:06 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202237.eAKMb7a236351@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 17:57:06 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 17:37:07 -0500" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld writes: > > Perhaps we just don't care; or perhaps "users" can only be IPSec > > initiators. > > That won't work in the general case since many possible uses of ipsec > require peer-to-peer keying. (or, rather, require either end to be > able to initiate rekeying). It works for road-warrior VPNs :) In other cases, you probably aren't authenticating users to users, or hosts to users, but rather hosts to hosts. So I don't think it matters there, either. The only case I can truly think of where you might want to have the user authenticate one end is for a road-warrior VPN solution, and in that case, no, the server WONT be initiating anything :) > - Bill -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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:06:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05565 for ; Mon, 20 Nov 2000 18:06:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA14981 for ietf-kink-bks; Mon, 20 Nov 2000 15:00:55 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA14977 for ; Mon, 20 Nov 2000 15:00:53 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA26707; Mon, 20 Nov 2000 16:01:35 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA27969; Mon, 20 Nov 2000 18:01:33 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKN0pa236400; Mon, 20 Nov 2000 18:00:51 -0500 (EST) Message-Id: <200011202300.eAKN0pa236400@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 17:57:06 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:00:51 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It works for road-warrior VPNs :) that's nice. > In other cases, you probably aren't authenticating users to users, or > hosts to users, but rather hosts to hosts. This is an unwarranted assumption, and the ipsec implementation i'm working on doesn't make that assumption. > So I don't think it matters there, either. I think it does. - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:09:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA05920 for ; Mon, 20 Nov 2000 18:09:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15048 for ietf-kink-bks; Mon, 20 Nov 2000 15:03:24 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15040 for ; Mon, 20 Nov 2000 15:03:22 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id SAA28852; Mon, 20 Nov 2000 18:04:08 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202300.eAKN0pa236400@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 18:04:08 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 18:00:51 -0500" Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Well, clearly we disagree. :) We'll see what the group at large thinks. -derek Bill Sommerfeld writes: > > It works for road-warrior VPNs :) > > that's nice. > > > In other cases, you probably aren't authenticating users to users, or > > hosts to users, but rather hosts to hosts. > > This is an unwarranted assumption, and the ipsec implementation i'm > working on doesn't make that assumption. > > > So I don't think it matters there, either. > > I think it does. > > - Bill -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:20:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA07309 for ; Mon, 20 Nov 2000 18:20:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15170 for ietf-kink-bks; Mon, 20 Nov 2000 15:07:45 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15164 for ; Mon, 20 Nov 2000 15:07:44 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA28340; Mon, 20 Nov 2000 15:07:54 -0800 (PST) Date: Mon, 20 Nov 2000 15:07:53 -0800 (PST) From: Jan Vilhuber To: Derek Atkins cc: sommerfeld@east.sun.com, "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 20 Nov 2000, Derek Atkins wrote: > Bill Sommerfeld writes: > > > > Perhaps we just don't care; or perhaps "users" can only be IPSec > > > initiators. > > > > That won't work in the general case since many possible uses of ipsec > > require peer-to-peer keying. (or, rather, require either end to be > > able to initiate rekeying). > > It works for road-warrior VPNs :) > > In other cases, you probably aren't authenticating users to users, or > hosts to users, but rather hosts to hosts. So I don't think it > matters there, either. The only case I can truly think of where you > might want to have the user authenticate one end is for a road-warrior > VPN solution, and in that case, no, the server WONT be initiating > anything :) > It might also be worthwhile to do what IKE failed to do, which is to spell out re-keying behaviour. If we spell out that the original initiator needs to be the one to reinitiate a re-key, then problems won't arise. That's not to say that initiation can not be in both directions, but if someone will be a responder, that host/user MUST be a principal in the KDC. That covers your road-warrior example, as those users may NOT need to be principals, assuming they will always initiate and will always initiate a re-key. Whether the semantics I propose above are the correct ones, or not, I think this should be in the draft somewhere to avoid ambuguities in rekeying which we now have to deal with in IKE (See Jenkins draft). jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:27:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08181 for ; Mon, 20 Nov 2000 18:27:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15483 for ietf-kink-bks; Mon, 20 Nov 2000 15:22:32 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15478 for ; Mon, 20 Nov 2000 15:22:30 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10761; Mon, 20 Nov 2000 16:23:13 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA01759; Mon, 20 Nov 2000 18:23:12 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKNMUa236427; Mon, 20 Nov 2000 18:22:30 -0500 (EST) Message-Id: <200011202322.eAKNMUa236427@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: Derek Atkins , sommerfeld@east.sun.com, "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 15:07:53 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:22:29 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It might also be worthwhile to do what IKE failed to do, which is to spell > out re-keying behaviour. If we spell out that the original initiator needs to > be the one to reinitiate a re-key, then problems won't arise. How can that possibly work in a non-VPN, non-connection-oriented scenario? Does the initiator *always* recreate an expiring SA, just in case the peer might want to send something in the future? Do you engage in some sort of layering violation, peeking into TCP to see if there are still open connections or tracking connection state in the IP layer? Or do you not care about long-lived connections, and let them drop if the initiator doesn't have the session up? I'm not happy with any of these alternatives.. the responder must be able to turn around and reinitiate back to the initiator.. - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:38:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09565 for ; Mon, 20 Nov 2000 18:38:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15643 for ietf-kink-bks; Mon, 20 Nov 2000 15:32:38 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15639 for ; Mon, 20 Nov 2000 15:32:36 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id SAA28879; Mon, 20 Nov 2000 18:33:21 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202322.eAKNMUa236427@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 18:33:20 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 18:22:29 -0500" Message-ID: Lines: 40 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld writes: > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? If you're using user-authentication, then yes, you should keep it up, as long as your TGT is valid. Once the TGT expires, you can let the connection drop. The user has to reauthenticate themselves to the system anyways; alternatively they can re-initialize IPSec by hand at the same time that they get new tickets. > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? If your user TGT expires, you HAVE to let them drop anyways. Unless you're expecting to have a UI violation where the kernel will asynchronously pop up some UI function to ask the user for username/password in order to obtain a TGT when it's expired? So, in the user-auth case, no, I don't care about long-lived connections. They can't exist without user intervention. > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. And I think limiting this particular case to host-host authentication is a reasonable protocol limitation. > - Bill -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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:41:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09981 for ; Mon, 20 Nov 2000 18:41:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15699 for ietf-kink-bks; Mon, 20 Nov 2000 15:36:33 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15695 for ; Mon, 20 Nov 2000 15:36:32 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA29634; Mon, 20 Nov 2000 15:36:45 -0800 (PST) Date: Mon, 20 Nov 2000 15:36:45 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202322.eAKNMUa236427@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > It might also be worthwhile to do what IKE failed to do, which is to spell > > out re-keying behaviour. If we spell out that the original initiator needs to > > be the one to reinitiate a re-key, then problems won't arise. > > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? > I didn't say it was perfect. ;) > Do you engage in some sort of layering violation, peeking into TCP to > see if there are still open connections or tracking connection state > in the IP layer? > No. We do none of that. We don't even do what I described above. It's just an idea. If it doesn't pan out, it doesn't pan out. > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? > If the initiator is a road-warrior, whose dynamic-IP connection went down as well (due to timeout or whatever), then it might not matter. Your objection is valid, though. jan > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. > > - Bill > -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:45:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10480 for ; Mon, 20 Nov 2000 18:45:11 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15690 for ietf-kink-bks; Mon, 20 Nov 2000 15:36:27 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15686 for ; Mon, 20 Nov 2000 15:36:26 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA20399; Mon, 20 Nov 2000 16:37:06 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA04253; Mon, 20 Nov 2000 18:37:04 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKNaMa236461; Mon, 20 Nov 2000 18:36:22 -0500 (EST) Message-Id: <200011202336.eAKNaMa236461@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 18:33:20 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:36:22 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > How can that possibly work in a non-VPN, non-connection-oriented > > scenario? Does the initiator *always* recreate an expiring SA, just > > in case the peer might want to send something in the future? > > If you're using user-authentication, then yes, you should keep it up, > as long as your TGT is valid. Why? In many cases, we might have nothing further to send to the peer.. > If your user TGT expires, you HAVE to let them drop anyways. Unless > you're expecting to have a UI violation where the kernel will > asynchronously pop up some UI function to ask the user for > username/password in order to obtain a TGT when it's expired? BTW, that would be the key management daemon, not the kernel.. - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 18:56:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11898 for ; Mon, 20 Nov 2000 18:56:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA15877 for ietf-kink-bks; Mon, 20 Nov 2000 15:50:13 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA15873 for ; Mon, 20 Nov 2000 15:50:12 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id SAA28896; Mon, 20 Nov 2000 18:50:57 -0500 To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202336.eAKNaMa236461@thunk.east.sun.com> From: Derek Atkins Date: 20 Nov 2000 18:50:56 -0500 In-Reply-To: Bill Sommerfeld's message of "Mon, 20 Nov 2000 18:36:22 -0500" Message-ID: Lines: 22 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bill Sommerfeld writes: > > If your user TGT expires, you HAVE to let them drop anyways. Unless > > you're expecting to have a UI violation where the kernel will > > asynchronously pop up some UI function to ask the user for > > username/password in order to obtain a TGT when it's expired? > > BTW, that would be the key management daemon, not the kernel.. It's still a system daemon, not a user app. So, how do you get the user's credentials there anyways? And how do you report to the user when those tickets expire? > - Bill -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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 20 19:01:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12625 for ; Mon, 20 Nov 2000 19:01:45 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16010 for ietf-kink-bks; Mon, 20 Nov 2000 15:57:44 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16005 for ; Mon, 20 Nov 2000 15:57:43 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id PAA00493; Mon, 20 Nov 2000 15:57:55 -0800 (PST) Date: Mon, 20 Nov 2000 15:57:55 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202336.eAKNaMa236461@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > > How can that possibly work in a non-VPN, non-connection-oriented > > > scenario? Does the initiator *always* recreate an expiring SA, just > > > in case the peer might want to send something in the future? > > > > If you're using user-authentication, then yes, you should keep it up, > > as long as your TGT is valid. > > Why? In many cases, we might have nothing further to send to the peer.. > So you an idle-timer. Host-to-host probably doesn't want this, but vpn probably will. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 19:04:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13000 for ; Mon, 20 Nov 2000 19:04:34 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA16034 for ietf-kink-bks; Mon, 20 Nov 2000 15:59:12 -0800 (PST) Received: from lukla.Sun.COM (lukla.Sun.COM [192.18.98.31]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA16030 for ; Mon, 20 Nov 2000 15:59:10 -0800 (PST) Received: from eastmail1.East.Sun.COM ([129.148.1.240]) by lukla.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06024; Mon, 20 Nov 2000 16:59:53 -0700 (MST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id SAA07837; Mon, 20 Nov 2000 18:59:52 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAKNx9a236511; Mon, 20 Nov 2000 18:59:09 -0500 (EST) Message-Id: <200011202359.eAKNx9a236511@thunk.east.sun.com> From: Bill Sommerfeld To: Jan Vilhuber cc: Bill Sommerfeld , Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "Mon, 20 Nov 2000 15:57:55 PST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 18:59:09 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So you an idle-timer. Host-to-host probably doesn't want this, but vpn > probably will. That only detects that we wanted to send something recently, not that the peer might want to send us something in the future... - Bill From owner-ietf-kink@mail.vpnc.org Mon Nov 20 19:10:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13847 for ; Mon, 20 Nov 2000 19:10:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16115 for ietf-kink-bks; Mon, 20 Nov 2000 16:04:23 -0800 (PST) Received: from cisco.com (flipper.cisco.com [171.69.25.141]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16111 for ; Mon, 20 Nov 2000 16:04:21 -0800 (PST) Received: from localhost (ssh-sj1.cisco.com [171.68.225.134]) by cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/8.8.8) with ESMTP id QAA00764; Mon, 20 Nov 2000 16:04:00 -0800 (PST) Date: Mon, 20 Nov 2000 16:04:00 -0800 (PST) From: Jan Vilhuber To: Bill Sommerfeld cc: Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202359.eAKNx9a236511@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 20 Nov 2000, Bill Sommerfeld wrote: > > So you an idle-timer. Host-to-host probably doesn't want this, but vpn > > probably will. > > That only detects that we wanted to send something recently, not that > the peer might want to send us something in the future... > As I said: In a dial-up/vpn scenario that doesn't matter. If you have something to send, and the link has gone away (or the SA's have died, which amounts to the same thing), you're out of luck anyway. jan -- Jan Vilhuber vilhuber@cisco.com Cisco Systems, San Jose (408) 527-0847 From owner-ietf-kink@mail.vpnc.org Mon Nov 20 19:16:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14682 for ; Mon, 20 Nov 2000 19:16:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA16198 for ietf-kink-bks; Mon, 20 Nov 2000 16:10:52 -0800 (PST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA16194 for ; Mon, 20 Nov 2000 16:10:51 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA27773; Mon, 20 Nov 2000 16:11:33 -0800 (PST) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail2.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id TAA27375; Mon, 20 Nov 2000 19:11:32 -0500 (EST) Received: from thunk (localhost [127.0.0.1]) by thunk.east.sun.com (8.11.1+Sun/8.10.2) with ESMTP id eAL0Aoa236559; Mon, 20 Nov 2000 19:10:50 -0500 (EST) Message-Id: <200011210010.eAL0Aoa236559@thunk.east.sun.com> From: Bill Sommerfeld To: Derek Atkins cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-reply-to: Your message of "20 Nov 2000 18:50:56 EST." Reply-to: sommerfeld@east.sun.com Date: Mon, 20 Nov 2000 19:10:49 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > It's still a system daemon, not a user app. So, how do you get the > user's credentials there anyways? I can think of a number of ways, one of which is a per-user authentication proxy which is connected to the key management daemon at login time, which can run with a UI. - Bill From owner-ietf-kink@mail.vpnc.org Tue Nov 21 06:16:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03291 for ; Tue, 21 Nov 2000 06:16:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26842 for ietf-kink-bks; Tue, 21 Nov 2000 02:56:25 -0800 (PST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26836 for ; Tue, 21 Nov 2000 02:56:24 -0800 (PST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00795; Tue, 21 Nov 2000 05:57:11 -0500 (EST) Message-Id: <200011211057.FAA00795@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-kink@vpnc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-kink-ike-over-kkmp-00.txt Date: Tue, 21 Nov 2000 05:57:10 -0500 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart 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 : Running IKE Phase 2 over Artificial Kerberos IKE SA Author(s) : T. Kivinen Filename : draft-ietf-kink-ike-over-kkmp-00.txt Pages : 6 Date : 20-Nov-00 This document defines how to create artificial IKE SA using kerberos [RFC-1510]. It defines how to calculate SKEYID, cookies and IV needed by the IKE SA from the Kerberos session key. After the artificial IKE SA is created, it can be used to run normal IKE [RFC-2409] phase 2 negotia- tions. Those negotiations include quick Mode (creating IPsec SA), new group mode, delete notifications, and error notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-kink-ike-over-kkmp-00.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-ike-over-kkmp-00.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: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-kink-ike-over-kkmp-00.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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001120151452.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-kink-ike-over-kkmp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-kink-ike-over-kkmp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001120151452.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-kink@mail.vpnc.org Tue Nov 21 10:50:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25674 for ; Tue, 21 Nov 2000 10:49:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA19873 for ietf-kink-bks; Tue, 21 Nov 2000 07:37:12 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA19868 for ; Tue, 21 Nov 2000 07:37:10 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA24031; Tue, 21 Nov 2000 07:37:26 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07553; Tue, 21 Nov 2000 07:37:26 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.38582.343689.600494@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 07:37:26 -0800 (PST) To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202125.eAKLPGa236169@thunk.east.sun.com> References: <200011202125.eAKLPGa236169@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > > Unless you want to do u-u, I guess, which complicates things. I'd prefer to > > have them enrolled. > > depends on how you measure complexity. i suspect a new enrollment > protocol would be more complex than just using u-u. We're a little bit afield of KINK here, but... I've been thinking that the enrollment _protocol_ doesn't need to be complicated at all: it could just be a normal PKINIT Kerberos AS-REQ, perhaps with a flag that tells the KDC to enroll the principal with the session key that it puts into the TGT. Perhaps it can even be done without an explicit flag. That would have the nice property that you'd also get symmetric key refresh basically for free, though it does force the KDC to deal with previous and next keys instead of just one key. That said, I think that the harder problem is going to come down to all of the implications of distributed database propogation on the KDC's. That, of course, is an application problem though. Mike From owner-ietf-kink@mail.vpnc.org Tue Nov 21 10:51:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26175 for ; Tue, 21 Nov 2000 10:51:50 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA20011 for ietf-kink-bks; Tue, 21 Nov 2000 07:39:57 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA20005 for ; Tue, 21 Nov 2000 07:39:56 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA24083; Tue, 21 Nov 2000 07:40:10 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07556; Tue, 21 Nov 2000 07:40:10 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.38746.494551.568022@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 07:40:10 -0800 (PST) To: sommerfeld@east.sun.com Cc: Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , Derek Atkins , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202138.eAKLcha236255@thunk.east.sun.com> References: <200011202138.eAKLcha236255@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > > Agreed. I measure it in terms of added complexity WITHIN the same protocol. A > > new enrollment protocol may be somewhat complex, but this complexity is > > orthogonal to KINK, thus making KINK easier to analyze for security. Adding > > more exchanges for corner-cases certainly doesn't help people analyze it for > > weaknesses. > > true. i've suggested on numerous occasions that KINK should avoid > this problem by always using user-to-user. User-User pretty much forces the normal create SA case to be a two round trip affair. One of the goals here is to reduce keying latency, and cutting out round trips is an obvious means to that goal. Mike From owner-ietf-kink@mail.vpnc.org Tue Nov 21 11:07:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29776 for ; Tue, 21 Nov 2000 11:07:22 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA23388 for ietf-kink-bks; Tue, 21 Nov 2000 07:55:01 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA23384 for ; Tue, 21 Nov 2000 07:55:00 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA24316; Tue, 21 Nov 2000 07:55:14 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA07559; Tue, 21 Nov 2000 07:55:13 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.39649.745697.39680@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 07:55:13 -0800 (PST) To: sommerfeld@east.sun.com Cc: Jan Vilhuber , Derek Atkins , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: <200011202322.eAKNMUa236427@thunk.east.sun.com> References: <200011202322.eAKNMUa236427@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I guess I don't quite grok the dilemma here. Initiator and responder only matter when setting up/tearing down the SA. Though perhaps not optimal, there shouldn't be a problem having two SA's with the same flow spec between two hosts -- they just needs to chose one. Assuming that either party can tear down an existing SA (which now that I think about it may not work in the current draft), you have the situation where either side can manage the SA's any way they see fit. What am I missing? Mike Bill Sommerfeld writes: > > It might also be worthwhile to do what IKE failed to do, which is to spell > > out re-keying behaviour. If we spell out that the original initiator needs to > > be the one to reinitiate a re-key, then problems won't arise. > > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? > > Do you engage in some sort of layering violation, peeking into TCP to > see if there are still open connections or tracking connection state > in the IP layer? > > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? > > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. > > - Bill > From owner-ietf-kink@mail.vpnc.org Tue Nov 21 11:12:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01123 for ; Tue, 21 Nov 2000 11:12:53 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24183 for ietf-kink-bks; Tue, 21 Nov 2000 08:03:49 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24178 for ; Tue, 21 Nov 2000 08:03:47 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA24455; Tue, 21 Nov 2000 08:04:05 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07562; Tue, 21 Nov 2000 08:04:05 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.40180.929436.605303@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 08:04:04 -0800 (PST) To: Derek Atkins Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: References: <200011202322.eAKNMUa236427@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Derek Atkins writes: > If you're using user-authentication, then yes, you should keep it up, > as long as your TGT is valid. Once the TGT expires, you can let the > connection drop. I don't think I agree. The current draft has a lifetime of the SA which may be shorter than the length of the service ticket. This is probably useful if your sessions are plentiful, random and short lived. Using a short lifetime mitigates the need to explicitly delete SA's. > If your user TGT expires, you HAVE to let them drop anyways. Unless > you're expecting to have a UI violation where the kernel will > asynchronously pop up some UI function to ask the user for > username/password in order to obtain a TGT when it's expired? What's wrong with this? That's all that getty is, in some sense. > So, in the user-auth case, no, I don't care about long-lived > connections. They can't exist without user intervention. Is a smart card "user auth"? > > I'm not happy with any of these alternatives.. the responder must be > > able to turn around and reinitiate back to the initiator.. > > And I think limiting this particular case to host-host authentication > is a reasonable protocol limitation. Well, _I_ don't think we should be so limited, but fortunately, this looks like an implementation issue, not a protocol issue. Mike From owner-ietf-kink@mail.vpnc.org Tue Nov 21 11:19:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02615 for ; Tue, 21 Nov 2000 11:19:33 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24660 for ietf-kink-bks; Tue, 21 Nov 2000 08:10:16 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24642 for ; Tue, 21 Nov 2000 08:10:02 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA24531; Tue, 21 Nov 2000 08:10:19 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07565; Tue, 21 Nov 2000 08:10:18 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.40554.533913.28856@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 08:10:18 -0800 (PST) To: Derek Atkins Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: References: <200011202336.eAKNaMa236461@thunk.east.sun.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Derek Atkins writes: > Bill Sommerfeld writes: > > > > If your user TGT expires, you HAVE to let them drop anyways. Unless > > > you're expecting to have a UI violation where the kernel will > > > asynchronously pop up some UI function to ask the user for > > > username/password in order to obtain a TGT when it's expired? > > > > BTW, that would be the key management daemon, not the kernel.. > > It's still a system daemon, not a user app. So, how do you get the > user's credentials there anyways? And how do you report to the user > when those tickets expire? C'mon, Derik. Netscrape manages to figure out how to prompt the user for credentials... this doesn't seem like rocket science. The important interface is the kernel/user boundary; once it's outside of the kernel, it's not very difficult to imagine an event driven this or that that could handle this quite cleanly. Mike From owner-ietf-kink@mail.vpnc.org Tue Nov 21 11:26:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04130 for ; Tue, 21 Nov 2000 11:26:14 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24737 for ietf-kink-bks; Tue, 21 Nov 2000 08:11:18 -0800 (PST) Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24732 for ; Tue, 21 Nov 2000 08:11:16 -0800 (PST) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id QAA10260; Tue, 21 Nov 2000 16:12:02 GMT Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Tue, 21 Nov 2000 16:12:01 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 21 Nov 2000 08:12:00 -0800 Message-ID: <10C8636AE359D4119118009027AE9987031A8FD5@FMSMSX34> From: "Walker, Jesse" To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK Date: Tue, 21 Nov 2000 08:11:58 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, How, when, and if they choose one is precisely the issue. This was something left unspecified in the interaction between IKE and IPsec, and as a result vendors implemented conformant but non-interoperable solutions to this problem. -- Jesse -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, November 21, 2000 7:55 AM To: sommerfeld@east.sun.com Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael Thomas'; 'ietf-kink@vpnc.org' Subject: Re: alternative to user-to-user Kerberos in KINK I guess I don't quite grok the dilemma here. Initiator and responder only matter when setting up/tearing down the SA. Though perhaps not optimal, there shouldn't be a problem having two SA's with the same flow spec between two hosts -- they just needs to chose one. Assuming that either party can tear down an existing SA (which now that I think about it may not work in the current draft), you have the situation where either side can manage the SA's any way they see fit. What am I missing? Mike Bill Sommerfeld writes: > > It might also be worthwhile to do what IKE failed to do, which is to spell > > out re-keying behaviour. If we spell out that the original initiator needs to > > be the one to reinitiate a re-key, then problems won't arise. > > How can that possibly work in a non-VPN, non-connection-oriented > scenario? Does the initiator *always* recreate an expiring SA, just > in case the peer might want to send something in the future? > > Do you engage in some sort of layering violation, peeking into TCP to > see if there are still open connections or tracking connection state > in the IP layer? > > Or do you not care about long-lived connections, and let them drop if > the initiator doesn't have the session up? > > I'm not happy with any of these alternatives.. the responder must be > able to turn around and reinitiate back to the initiator.. > > - Bill > From owner-ietf-kink@mail.vpnc.org Tue Nov 21 11:43:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08028 for ; Tue, 21 Nov 2000 11:42:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25199 for ietf-kink-bks; Tue, 21 Nov 2000 08:25:17 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25195 for ; Tue, 21 Nov 2000 08:25:16 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id IAA24914; Tue, 21 Nov 2000 08:25:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA07574; Tue, 21 Nov 2000 08:25:32 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.41468.325527.359049@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 08:25:32 -0800 (PST) To: "Walker, Jesse" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <10C8636AE359D4119118009027AE9987031A8FD5@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8FD5@FMSMSX34> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jesse, Correct me if I'm wrong, but this sure looks like it's out of the scope of the keying protocol per se. It seems like it would be better to have a BCP or something with base IPsec which defines what the expected behavior ought to be when you have two SA's with the same flow spec. Mike Walker, Jesse writes: > Mike, > > How, when, and if they choose one is precisely the issue. This was something > left unspecified in the interaction between IKE and IPsec, and as a result > vendors implemented conformant but non-interoperable solutions to this > problem. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 7:55 AM > To: sommerfeld@east.sun.com > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > I guess I don't quite grok the dilemma here. Initiator and > responder only matter when setting up/tearing down the > SA. Though perhaps not optimal, there shouldn't be a > problem having two SA's with the same flow spec between > two hosts -- they just needs to chose one. Assuming > that either party can tear down an existing SA (which > now that I think about it may not work in the current > draft), you have the situation where either side can > manage the SA's any way they see fit. > > What am I missing? > > Mike > > Bill Sommerfeld writes: > > > It might also be worthwhile to do what IKE failed to do, which is to > spell > > > out re-keying behaviour. If we spell out that the original initiator > needs to > > > be the one to reinitiate a re-key, then problems won't arise. > > > > How can that possibly work in a non-VPN, non-connection-oriented > > scenario? Does the initiator *always* recreate an expiring SA, just > > in case the peer might want to send something in the future? > > > > Do you engage in some sort of layering violation, peeking into TCP to > > see if there are still open connections or tracking connection state > > in the IP layer? > > > > Or do you not care about long-lived connections, and let them drop if > > the initiator doesn't have the session up? > > > > I'm not happy with any of these alternatives.. the responder must be > > able to turn around and reinitiate back to the initiator.. > > > > - Bill > > > > From owner-ietf-kink@mail.vpnc.org Tue Nov 21 12:29:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16710 for ; Tue, 21 Nov 2000 12:29:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29188 for ietf-kink-bks; Tue, 21 Nov 2000 09:21:00 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29179 for ; Tue, 21 Nov 2000 09:20:58 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id MAA29606; Tue, 21 Nov 2000 12:21:45 -0500 To: Michael Thomas Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK References: <200011202336.eAKNaMa236461@thunk.east.sun.com> <14874.40554.533913.28856@thomasm-u1.cisco.com> From: Derek Atkins Date: 21 Nov 2000 12:21:44 -0500 In-Reply-To: Michael Thomas's message of "Tue, 21 Nov 2000 08:10:18 -0800 (PST)" Message-ID: Lines: 29 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Michael Thomas writes: > C'mon, Derik. Netscrape manages to figure out how to prompt > the user for credentials... this doesn't seem like rocket > science. The important interface is the kernel/user boundary; > once it's outside of the kernel, it's not very difficult > to imagine an event driven this or that that could handle this > quite cleanly. Netscrape is a single application. I haven't seen it interact with IPSec. I'm not saying that we can't register a user-agent with the key management daemon to ask for user input. IKE-XAuth certainly requires something like that. I'm just pointing out implementation issues. There's more than just kernel/user boundary, there's also a daemon(background-process)/UI boundary. No, it's not insurmountable. But I also don't think a protocol like this should necessarily mandate a particular UI requirement. > Mike -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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Tue Nov 21 12:41:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19269 for ; Tue, 21 Nov 2000 12:41:10 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA29611 for ietf-kink-bks; Tue, 21 Nov 2000 09:26:04 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA29605 for ; Tue, 21 Nov 2000 09:26:03 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA26472; Tue, 21 Nov 2000 09:26:16 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA07593; Tue, 21 Nov 2000 09:26:15 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.45111.798172.241271@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 09:26:15 -0800 (PST) To: Derek Atkins Cc: Michael Thomas , sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'ietf-kink@vpnc.org'" Subject: Re: alternative to user-to-user Kerberos in KINK In-Reply-To: References: <200011202336.eAKNaMa236461@thunk.east.sun.com> <14874.40554.533913.28856@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Derek Atkins writes: > There's more than just kernel/user boundary, there's also a > daemon(background-process)/UI boundary. No, it's not insurmountable. > But I also don't think a protocol like this should necessarily mandate > a particular UI requirement. Well, I don't either but the good news is that nobody's mandating anything on that count. Everybody is entitled to their own way of getting KINK key(s). Mike From owner-ietf-kink@mail.vpnc.org Tue Nov 21 13:17:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27846 for ; Tue, 21 Nov 2000 13:17:37 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02017 for ietf-kink-bks; Tue, 21 Nov 2000 10:05:32 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02013 for ; Tue, 21 Nov 2000 10:05:31 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA27572; Tue, 21 Nov 2000 10:05:16 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA07606; Tue, 21 Nov 2000 10:05:16 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14874.47452.245075.146852@thomasm-u1.cisco.com> Date: Tue, 21 Nov 2000 10:05:16 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'sommerfeld@east.sun.com'" , "'Derek Atkins'" , "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD48B0@ntas0027.gi.com> References: <97DEDE66B3DCD11199D200805FA71BE202FD48B0@ntas0027.gi.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Medvinsky, Sasha (SD-EX) writes: > All I was saying is that although you can do peer-to-peer authentication > with Kerberos, you shouldn't require it for an architecture where you don't > have a peer-to-peer relationship. I think client/server and peer-peer is somewhat misleading. Colloquially, client/server means that clients initiate transactions, not servers. Peer to peer means that no such distinction is drawn. I don't think that Kerberos, per se, has much to say on that front because "client" machines can host services and "server" machines can act as clients, so it appears to _mostly_ be a distinction without a difference. There are only two things that I know of which requires me to qualify myself above: 1) clients may authenticate using PKINIT which leads to the U-U/enrollment debate 2) it may be a worthwhile optimization to allow machines which subtend large numbers of users (let's not call them clients, because that's misleading) to have the abilty to require the high fanout devices to get and maintain tickets, thus avoiding duplication of effort and storage. #1 seems like we may be headed toward consensus that Matt's idea of enrollment may be a reasonable idea to pursue for PKinit. U-U should also be a fallback. The dispute seems mostly over #2. I still feel really uneasy about the inherent DoS attacks. I'm also not convinced that the real-life use of KINK cannot avoid this dilemma for the most part. Given the downside, I think that waiting to see real implementation experience would be a more prudent course of action. Mike From owner-ietf-kink@mail.vpnc.org Wed Nov 22 10:38:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12940 for ; Wed, 22 Nov 2000 10:38:45 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id HAA09054 for ietf-kink-bks; Wed, 22 Nov 2000 07:30:49 -0800 (PST) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA09044 for ; Wed, 22 Nov 2000 07:30:47 -0800 (PST) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id HAA17884; Wed, 22 Nov 2000 07:31:42 -0800 (PST) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 22 Nov 2000 15:31:42 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 07:31:41 -0800 Message-ID: <10C8636AE359D4119118009027AE9987031A8FEB@FMSMSX34> From: "Walker, Jesse" To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK Date: Wed, 22 Nov 2000 07:31:32 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, I think sidestepping the issue is a fundamental strategic mistake that will render KINK far less relevant than it could otherwise be. Rightly or wrongly, my belief is that one of the justifications for KINK's existence is a number of interoperability issues could never be resolved for IKE. In particular, this issue was never fully addressed for the IKE/IPsec interaction (it is usually referred to as the rekey issue). My recollection is that by the time Tim Jenkins finally published a reasonable way to resolve the problem, vendors had already implemented 8 conformant but non-interoperable algorithms for accomplishing the coordination, and it thereby became infeasible to get any consensus on how to move forward, since no one was willing to give up their own approach. With KINK there is a clean slate, and if the issue is addressed up front, there is a far, far better chance for genuine interoperability. It is not hard to specify an algorithm--the implementation history of the IKE/IPsec interaction gives us at least 8 to choose from! All the spec should do is specify one and decree once and for all that that's how to do it when using KINK. -- Jesse -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Tuesday, November 21, 2000 8:26 AM To: Walker, Jesse Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' Subject: RE: alternative to user-to-user Kerberos in KINK Jesse, Correct me if I'm wrong, but this sure looks like it's out of the scope of the keying protocol per se. It seems like it would be better to have a BCP or something with base IPsec which defines what the expected behavior ought to be when you have two SA's with the same flow spec. Mike Walker, Jesse writes: > Mike, > > How, when, and if they choose one is precisely the issue. This was something > left unspecified in the interaction between IKE and IPsec, and as a result > vendors implemented conformant but non-interoperable solutions to this > problem. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 7:55 AM > To: sommerfeld@east.sun.com > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > I guess I don't quite grok the dilemma here. Initiator and > responder only matter when setting up/tearing down the > SA. Though perhaps not optimal, there shouldn't be a > problem having two SA's with the same flow spec between > two hosts -- they just needs to chose one. Assuming > that either party can tear down an existing SA (which > now that I think about it may not work in the current > draft), you have the situation where either side can > manage the SA's any way they see fit. > > What am I missing? > > Mike > > Bill Sommerfeld writes: > > > It might also be worthwhile to do what IKE failed to do, which is to > spell > > > out re-keying behaviour. If we spell out that the original initiator > needs to > > > be the one to reinitiate a re-key, then problems won't arise. > > > > How can that possibly work in a non-VPN, non-connection-oriented > > scenario? Does the initiator *always* recreate an expiring SA, just > > in case the peer might want to send something in the future? > > > > Do you engage in some sort of layering violation, peeking into TCP to > > see if there are still open connections or tracking connection state > > in the IP layer? > > > > Or do you not care about long-lived connections, and let them drop if > > the initiator doesn't have the session up? > > > > I'm not happy with any of these alternatives.. the responder must be > > able to turn around and reinitiate back to the initiator.. > > > > - Bill > > > > From owner-ietf-kink@mail.vpnc.org Wed Nov 22 12:37:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03854 for ; Wed, 22 Nov 2000 12:37:37 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA20064 for ietf-kink-bks; Wed, 22 Nov 2000 09:21:27 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA20057 for ; Wed, 22 Nov 2000 09:21:26 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA12499; Wed, 22 Nov 2000 09:21:51 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA08031; Wed, 22 Nov 2000 09:21:51 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14876.174.903678.329297@thomasm-u1.cisco.com> Date: Wed, 22 Nov 2000 09:21:50 -0800 (PST) To: "Walker, Jesse" Cc: "'Michael Thomas'" , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <10C8636AE359D4119118009027AE9987031A8FEB@FMSMSX34> References: <10C8636AE359D4119118009027AE9987031A8FEB@FMSMSX34> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit OK, I'm obviously not up to speed on the rekeying wars and I don't remember the details of the jenkins draft. I'm also not sure what, in particular, was the hole that so many people drove through. Showing my ignorance, if it's only a matter in KINK of also describing how the selectors are processed when you have two identical ones, could we just say that you choose the newest one to send on? Does this actually even matter? Thus to rekey, the _rekeying_ initiator would CREATE a new SA on SPI Y, and DELETE the old SPI on X. During the transition, there are a few conditions: 0) The CREATE has not been sent; both initiator and responder MUST process on the old SPI (ie, it's the normal steady state of the previous SA). 1) The CREATE REPLY has not arrived; the initiator MUST consider only the old SPI for sending and receiving traffic. 2) The DELETE has not arrived; the responder MUST choose the new SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. The initiator MUST send on the new SPI, but accept data on both SPI's. The following two are optional; the initiator MAY allow the old SPI to time out: 3) The DELETE REPLY has not arrived; same as (2) for the responder. For the initiator, it MUST accept traffic on either SPI, but only send on the new SPI. 4) The DELETE REPLY is received; same as (0). Am I out in left field here? Mike Walker, Jesse writes: > Mike, > > I think sidestepping the issue is a fundamental strategic mistake that will > render KINK far less relevant than it could otherwise be. > > Rightly or wrongly, my belief is that one of the justifications for KINK's > existence is a number of interoperability issues could never be resolved for > IKE. In particular, this issue was never fully addressed for the IKE/IPsec > interaction (it is usually referred to as the rekey issue). My recollection > is that by the time Tim Jenkins finally published a reasonable way to > resolve the problem, vendors had already implemented 8 conformant but > non-interoperable algorithms for accomplishing the coordination, and it > thereby became infeasible to get any consensus on how to move forward, since > no one was willing to give up their own approach. > > With KINK there is a clean slate, and if the issue is addressed up front, > there is a far, far better chance for genuine interoperability. It is not > hard to specify an algorithm--the implementation history of the IKE/IPsec > interaction gives us at least 8 to choose from! All the spec should do is > specify one and decree once and for all that that's how to do it when using > KINK. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 8:26 AM > To: Walker, Jesse > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > Jesse, > > Correct me if I'm wrong, but this sure looks like > it's out of the scope of the keying protocol per > se. It seems like it would be better to have a BCP > or something with base IPsec which defines what > the expected behavior ought to be when you have > two SA's with the same flow spec. > > Mike > > Walker, Jesse writes: > > Mike, > > > > How, when, and if they choose one is precisely the issue. This was > something > > left unspecified in the interaction between IKE and IPsec, and as a > result > > vendors implemented conformant but non-interoperable solutions to this > > problem. > > > > -- Jesse > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:55 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > I guess I don't quite grok the dilemma here. Initiator and > > responder only matter when setting up/tearing down the > > SA. Though perhaps not optimal, there shouldn't be a > > problem having two SA's with the same flow spec between > > two hosts -- they just needs to chose one. Assuming > > that either party can tear down an existing SA (which > > now that I think about it may not work in the current > > draft), you have the situation where either side can > > manage the SA's any way they see fit. > > > > What am I missing? > > > > Mike > > > > Bill Sommerfeld writes: > > > > It might also be worthwhile to do what IKE failed to do, which is to > > spell > > > > out re-keying behaviour. If we spell out that the original initiator > > needs to > > > > be the one to reinitiate a re-key, then problems won't arise. > > > > > > How can that possibly work in a non-VPN, non-connection-oriented > > > scenario? Does the initiator *always* recreate an expiring SA, just > > > in case the peer might want to send something in the future? > > > > > > Do you engage in some sort of layering violation, peeking into TCP to > > > see if there are still open connections or tracking connection state > > > in the IP layer? > > > > > > Or do you not care about long-lived connections, and let them drop if > > > the initiator doesn't have the session up? > > > > > > I'm not happy with any of these alternatives.. the responder must be > > > able to turn around and reinitiate back to the initiator.. > > > > > > - Bill > > > > > > > > > From owner-ietf-kink@mail.vpnc.org Wed Nov 22 20:43:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19441 for ; Wed, 22 Nov 2000 20:43:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA09393 for ietf-kink-bks; Wed, 22 Nov 2000 17:28:49 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09387 for ; Wed, 22 Nov 2000 17:28:47 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWUKJD3RDOEZTHTS@GI.COM> for ietf-kink@vpnc.org; Wed, 22 Nov 2000 17:29:08 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:27:59 -0500 Content-return: allowed Date: Wed, 22 Nov 2000 20:31:06 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" , sommerfeld@east.sun.com Cc: Jan Vilhuber , Derek Atkins , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48D0@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, I don't think there is a need for an new enrollment protocol - it has been defined already. An authenticated PKINIT client would get a service ticket for an "Change Password Service" and then set its symmetric service key with an existing protocol in http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.tx t. Despite the title of the draft, it allows updates to service keys as well as client passwords. Although the draft was originally intended for updates to an existing key, there is no reason why it couldn't create a new key as well. Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 7:37 AM > To: sommerfeld@east.sun.com > Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael > Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > Bill Sommerfeld writes: > > > Unless you want to do u-u, I guess, which complicates > things. I'd prefer to > > > have them enrolled. > > > > depends on how you measure complexity. i suspect a new enrollment > > protocol would be more complex than just using u-u. > > We're a little bit afield of KINK here, but... > > I've been thinking that the enrollment _protocol_ > doesn't need to be complicated at all: it could > just be a normal PKINIT Kerberos AS-REQ, perhaps > with a flag that tells the KDC to enroll the > principal with the session key that it puts into > the TGT. Perhaps it can even be done without an > explicit flag. That would have the nice property > that you'd also get symmetric key refresh basically > for free, though it does force the KDC to deal with > previous and next keys instead of just one key. > > That said, I think that the harder problem is > going to come down to all of the implications of > distributed database propogation on the KDC's. > That, of course, is an application problem though. > > Mike > From owner-ietf-kink@mail.vpnc.org Wed Nov 22 20:53:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21842 for ; Wed, 22 Nov 2000 20:53:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA09771 for ietf-kink-bks; Wed, 22 Nov 2000 17:45:13 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA09767 for ; Wed, 22 Nov 2000 17:45:12 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JWUL3T5K36EZTB7E@GI.COM> for ietf-kink@vpnc.org; Wed, 22 Nov 2000 17:45:38 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 22 Nov 2000 17:44:28 -0500 Content-return: allowed Date: Wed, 22 Nov 2000 20:47:35 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" , Derek Atkins Cc: sommerfeld@east.sun.com, Jan Vilhuber , "Medvinsky, Sasha (SD-EX)" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48D2@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree with Mike. With Kerberos upgraded to 3-DES or AES, tickets could safely last for weeks - which improves system scalability, you don't have to contact the KDC as often. Tickets may also be used for some purpose other than IPSec. The lifetime of SAs should not be tied to the ticket lifetime (although they can't exceed it). > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 8:04 AM > To: Derek Atkins > Cc: sommerfeld@east.sun.com; Jan Vilhuber; Medvinsky, Sasha (SD-EX); > 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: Re: alternative to user-to-user Kerberos in KINK > > > Derek Atkins writes: > > If you're using user-authentication, then yes, you should > keep it up, > > as long as your TGT is valid. Once the TGT expires, you > can let the > > connection drop. > > I don't think I agree. The current draft has a lifetime of > the SA which may be shorter than the length of the service > ticket. This is probably useful if your sessions are > plentiful, random and short lived. Using a short lifetime > mitigates the need to explicitly delete SA's. From owner-ietf-kink@mail.vpnc.org Mon Nov 27 14:09:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02093 for ; Mon, 27 Nov 2000 14:09:01 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id KAA21156 for ietf-kink-bks; Mon, 27 Nov 2000 10:43:30 -0800 (PST) Received: from thalia.fm.intel.com (thalia.fm.intel.com [132.233.247.11]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21149 for ; Mon, 27 Nov 2000 10:43:28 -0800 (PST) Received: from SMTP (fmsmsxvs04-1.fm.intel.com [132.233.42.204]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.33 2000/11/21 19:27:27 smothers Exp $) with SMTP id SAA04206; Mon, 27 Nov 2000 18:46:02 GMT Received: from fmsmsx26.fm.intel.com ([132.233.48.26]) by 132.233.48.204 (Norton AntiVirus for Internet Email Gateways 1.0) ; Mon, 27 Nov 2000 18:44:37 0000 (GMT) Received: by fmsmsx26.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 10:44:36 -0800 Message-ID: <10C8636AE359D4119118009027AE9987031A8FFE@FMSMSX34> From: "Walker, Jesse" To: "'Michael Thomas'" Cc: "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK Date: Mon, 27 Nov 2000 10:44:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, You have proposed a very good start. Here are some comments. a. The document needs to specify a way to identify who is indeed the rekeying initiator in cases of a tie. (IPXWAN totally orders IPX addresses and then arbitrarily decrees the larger of the two wins; perhaps we employ something similar.) b. If KINK rekeying works like IKE rekeying, in that each peer has to contribute nonces and the like as entropy for computing the new SA keys, it is not evident that (2) below is correct. This is because the responder does not know that the initiator can compute the correct SA keys for the new SA until after it knows the peer has received its CREATE REPLY; it will be sending traffic into a black hole if the CREATE REPLY is lost. The responder should indeed receive on both old and new SA as (2) suggests, but perhaps it may be better to continue sending on the old send SA until the DELETE from the initiator arrives. Then if its CREATE REPLY never arrives, communication can at least continue until the SA key expires. (In a two-phase commit protocol, you don't commit until phase 2.) c. If you buy (b) above, then the initiator needs a retry timer for its CREATE (to try to ellicit a CREATE REPLY), and the responder needs a retry timer for CREATE REPLY (to ellicit a DELETE). I think (3) is correct or almost correct in the case it actually receives a CREATE REPLY: the initiator sends on the new SA, but receives on both the old and the new. It knows the responder knows the keys for the new SAs, because it received the CREATE REPLY. But it can't do away with the old SA until it receives the DELETE REPLY from the responder (or key expiry), because it doesn't know that the responder has comitted to use the new SAs. I do not think this is optional behavior; I think it is mandatory to make interoperability a possibility. d. What seems optional is the responder could send a DELETE REPLY and delete its old SAs if it receives traffic from the initiator on the new SA; this says conclusively that the peer received its CREATE REPLAY, because it is protecting its traffic under the new SPIs and keys associated with the new SA. Likewise, the initiator can finally delete its old SAs if it receives traffic on the new SA. This is conclusive evidence that the responder has received either its DELETE REPLY or noticed that the new SA is in use. This optional provision will allow progress if the DELETE/DELETE REPLY messages are all lost but the IPsec datagrams can still get through. It is optional because retries of the CREATE REPLY and DELETE messages should eventually cause convergence if the peers are still reachable to each other. e. We don't have any behavior for when an expected reply never arrives. Presumably we want to continue using the old SAs until their keys expire, but this is counter to the decisions discussed above about when to start sending on the new SA. So maybe there isn't a retry limit on DELETEs? Or maybe the reasoning of when to begin sending on the new SA is wrong? -- Jesse -----Original Message----- From: Michael Thomas [mailto:mat@cisco.com] Sent: Wednesday, November 22, 2000 9:22 AM To: Walker, Jesse Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' Subject: RE: alternative to user-to-user Kerberos in KINK OK, I'm obviously not up to speed on the rekeying wars and I don't remember the details of the jenkins draft. I'm also not sure what, in particular, was the hole that so many people drove through. Showing my ignorance, if it's only a matter in KINK of also describing how the selectors are processed when you have two identical ones, could we just say that you choose the newest one to send on? Does this actually even matter? Thus to rekey, the _rekeying_ initiator would CREATE a new SA on SPI Y, and DELETE the old SPI on X. During the transition, there are a few conditions: 0) The CREATE has not been sent; both initiator and responder MUST process on the old SPI (ie, it's the normal steady state of the previous SA). 1) The CREATE REPLY has not arrived; the initiator MUST consider only the old SPI for sending and receiving traffic. 2) The DELETE has not arrived; the responder MUST choose the new SPI if there are two flow specs which are identical for outgoing traffic and MUST accept incoming traffic on the old SPI. The initiator MUST send on the new SPI, but accept data on both SPI's. The following two are optional; the initiator MAY allow the old SPI to time out: 3) The DELETE REPLY has not arrived; same as (2) for the responder. For the initiator, it MUST accept traffic on either SPI, but only send on the new SPI. 4) The DELETE REPLY is received; same as (0). Am I out in left field here? Mike Walker, Jesse writes: > Mike, > > I think sidestepping the issue is a fundamental strategic mistake that will > render KINK far less relevant than it could otherwise be. > > Rightly or wrongly, my belief is that one of the justifications for KINK's > existence is a number of interoperability issues could never be resolved for > IKE. In particular, this issue was never fully addressed for the IKE/IPsec > interaction (it is usually referred to as the rekey issue). My recollection > is that by the time Tim Jenkins finally published a reasonable way to > resolve the problem, vendors had already implemented 8 conformant but > non-interoperable algorithms for accomplishing the coordination, and it > thereby became infeasible to get any consensus on how to move forward, since > no one was willing to give up their own approach. > > With KINK there is a clean slate, and if the issue is addressed up front, > there is a far, far better chance for genuine interoperability. It is not > hard to specify an algorithm--the implementation history of the IKE/IPsec > interaction gives us at least 8 to choose from! All the spec should do is > specify one and decree once and for all that that's how to do it when using > KINK. > > -- Jesse > > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 8:26 AM > To: Walker, Jesse > Cc: 'Michael Thomas'; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > Jesse, > > Correct me if I'm wrong, but this sure looks like > it's out of the scope of the keying protocol per > se. It seems like it would be better to have a BCP > or something with base IPsec which defines what > the expected behavior ought to be when you have > two SA's with the same flow spec. > > Mike > > Walker, Jesse writes: > > Mike, > > > > How, when, and if they choose one is precisely the issue. This was > something > > left unspecified in the interaction between IKE and IPsec, and as a > result > > vendors implemented conformant but non-interoperable solutions to this > > problem. > > > > -- Jesse > > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:55 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Derek Atkins; Medvinsky, Sasha (SD-EX); 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > > > I guess I don't quite grok the dilemma here. Initiator and > > responder only matter when setting up/tearing down the > > SA. Though perhaps not optimal, there shouldn't be a > > problem having two SA's with the same flow spec between > > two hosts -- they just needs to chose one. Assuming > > that either party can tear down an existing SA (which > > now that I think about it may not work in the current > > draft), you have the situation where either side can > > manage the SA's any way they see fit. > > > > What am I missing? > > > > Mike > > > > Bill Sommerfeld writes: > > > > It might also be worthwhile to do what IKE failed to do, which is to > > spell > > > > out re-keying behaviour. If we spell out that the original initiator > > needs to > > > > be the one to reinitiate a re-key, then problems won't arise. > > > > > > How can that possibly work in a non-VPN, non-connection-oriented > > > scenario? Does the initiator *always* recreate an expiring SA, just > > > in case the peer might want to send something in the future? > > > > > > Do you engage in some sort of layering violation, peeking into TCP to > > > see if there are still open connections or tracking connection state > > > in the IP layer? > > > > > > Or do you not care about long-lived connections, and let them drop if > > > the initiator doesn't have the session up? > > > > > > I'm not happy with any of these alternatives.. the responder must be > > > able to turn around and reinitiate back to the initiator.. > > > > > > - Bill > > > > > > > > > From owner-ietf-kink@mail.vpnc.org Mon Nov 27 15:40:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29557 for ; Mon, 27 Nov 2000 15:40:52 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA29032 for ietf-kink-bks; Mon, 27 Nov 2000 12:25:22 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA29027 for ; Mon, 27 Nov 2000 12:25:20 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id PAA08163; Mon, 27 Nov 2000 15:26:31 -0500 To: ietf-kink@vpnc.org Subject: KINK Draft Agenda From: Derek Atkins Date: 27 Nov 2000 15:26:31 -0500 Message-ID: Lines: 39 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here is the draft agenda for the KINK WG meeting in San Diego, with times for everyone who has asked to speak. Let me know if there should be any changes. -derek Kerberized Internet Nogotiation of Keys Working Group (KINK) Chairs: Derek Atkins John Trostle San Diego Meeting Time: Tuesday 1300-1400 Draft Agenda Who When Derek Atkins - Telcordia Agenda Bashing :00-:03 Mike Thomas - Cisco KINK Requirements :05-:20 Mike Thoman - Cisco KINK Draft Protocol :20-:33 Sasha Medvinsky - Motorola server-initiated key management :35-:45 with PKINIT clients Tero Kivinen - SSH IKE-Over-KKMP :48-:59 -- 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 N1NWH warlord@MIT.EDU PGP key available From owner-ietf-kink@mail.vpnc.org Mon Nov 27 17:40:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05299 for ; Mon, 27 Nov 2000 17:40:40 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA05434 for ietf-kink-bks; Mon, 27 Nov 2000 14:28:09 -0800 (PST) Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA05427 for ; Mon, 27 Nov 2000 14:28:08 -0800 (PST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id OAA21586; Mon, 27 Nov 2000 14:28:57 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id OAA09465; Mon, 27 Nov 2000 14:28:57 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14882.57385.532385.969881@thomasm-u1.cisco.com> Date: Mon, 27 Nov 2000 14:28:57 -0800 (PST) To: "Medvinsky, Sasha (SD-EX)" Cc: "'Michael Thomas'" , sommerfeld@east.sun.com, Jan Vilhuber , Derek Atkins , "'ietf-kink@vpnc.org'" Subject: RE: alternative to user-to-user Kerberos in KINK In-Reply-To: <97DEDE66B3DCD11199D200805FA71BE202FD48D0@ntas0027.gi.com> References: <97DEDE66B3DCD11199D200805FA71BE202FD48D0@ntas0027.gi.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm all for begging, borrowing or stealing. I only scanned the draft over quickly -- is there a way for the KDC to specify the password? That seems like it would give the best password source since by definition the KDC's RNG better be good. Mike Medvinsky, Sasha (SD-EX) writes: > Mike, > > I don't think there is a need for an new enrollment protocol - it has been > defined already. An authenticated PKINIT client would get a service ticket > for an "Change Password Service" and then set its symmetric service key with > an existing protocol in > http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.tx > t. > > Despite the title of the draft, it allows updates to service keys as well as > client passwords. Although the draft was originally intended for updates to > an existing key, there is no reason why it couldn't create a new key as > well. > > Sasha. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:37 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > Bill Sommerfeld writes: > > > > Unless you want to do u-u, I guess, which complicates > > things. I'd prefer to > > > > have them enrolled. > > > > > > depends on how you measure complexity. i suspect a new enrollment > > > protocol would be more complex than just using u-u. > > > > We're a little bit afield of KINK here, but... > > > > I've been thinking that the enrollment _protocol_ > > doesn't need to be complicated at all: it could > > just be a normal PKINIT Kerberos AS-REQ, perhaps > > with a flag that tells the KDC to enroll the > > principal with the session key that it puts into > > the TGT. Perhaps it can even be done without an > > explicit flag. That would have the nice property > > that you'd also get symmetric key refresh basically > > for free, though it does force the KDC to deal with > > previous and next keys instead of just one key. > > > > That said, I think that the harder problem is > > going to come down to all of the implications of > > distributed database propogation on the KDC's. > > That, of course, is an application problem though. > > > > Mike > > > From owner-ietf-kink@mail.vpnc.org Mon Nov 27 18:10:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13506 for ; Mon, 27 Nov 2000 18:10:03 -0500 (EST) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA06457 for ietf-kink-bks; Mon, 27 Nov 2000 14:57:16 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA06453 for ; Mon, 27 Nov 2000 14:57:15 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JX1EPJCBB6EZV4DD@GI.COM> for ietf-kink@vpnc.org; Mon, 27 Nov 2000 14:57:57 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 27 Nov 2000 14:56:39 -0500 Content-return: allowed Date: Mon, 27 Nov 2000 18:00:05 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" Cc: sommerfeld@east.sun.com, Jan Vilhuber , Derek Atkins , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48E0@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In that draft, it is always the client that specifies the new key or password. You can always recommend that the client uses the session key as a seed into its pseudo-random number generator. Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Monday, November 27, 2000 2:29 PM > To: Medvinsky, Sasha (SD-EX) > Cc: 'Michael Thomas'; sommerfeld@east.sun.com; Jan Vilhuber; Derek > Atkins; 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > > I'm all for begging, borrowing or stealing. I only > scanned the draft over quickly -- is there a way > for the KDC to specify the password? That seems > like it would give the best password source since > by definition the KDC's RNG better be good. > > Mike > > Medvinsky, Sasha (SD-EX) writes: > > Mike, > > > > I don't think there is a need for an new enrollment > protocol - it has been > > defined already. An authenticated PKINIT client would get > a service ticket > > for an "Change Password Service" and then set its > symmetric service key with > > an existing protocol in > > http://www.ietf.org/internet-drafts/draft-ietf-cat-kerberos-set-passwd-03.tx > t. > > Despite the title of the draft, it allows updates to service keys as well as > client passwords. Although the draft was originally intended for updates to > an existing key, there is no reason why it couldn't create a new key as > well. > > Sasha. > > > -----Original Message----- > > From: Michael Thomas [mailto:mat@cisco.com] > > Sent: Tuesday, November 21, 2000 7:37 AM > > To: sommerfeld@east.sun.com > > Cc: Jan Vilhuber; Medvinsky, Sasha (SD-EX); Derek Atkins; 'Michael > > Thomas'; 'ietf-kink@vpnc.org' > > Subject: Re: alternative to user-to-user Kerberos in KINK > > > > > > Bill Sommerfeld writes: > > > > Unless you want to do u-u, I guess, which complicates > > things. I'd prefer to > > > > have them enrolled. > > > > > > depends on how you measure complexity. i suspect a new enrollment > > > protocol would be more complex than just using u-u. > > > > We're a little bit afield of KINK here, but... > > > > I've been thinking that the enrollment _protocol_ > > doesn't need to be complicated at all: it could > > just be a normal PKINIT Kerberos AS-REQ, perhaps > > with a flag that tells the KDC to enroll the > > principal with the session key that it puts into > > the TGT. Perhaps it can even be done without an > > explicit flag. That would have the nice property > > that you'd also get symmetric key refresh basically > > for free, though it does force the KDC to deal with > > previous and next keys instead of just one key. > > > > That said, I think that the harder problem is > > going to come down to all of the implications of > > distributed database propogation on the KDC's. > > That, of course, is an application problem though. > > > > Mike > > > From owner-ietf-kink@mail.vpnc.org Tue Nov 28 21:07:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA12510 for ; Tue, 28 Nov 2000 21:07:07 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA20810 for ietf-kink-bks; Tue, 28 Nov 2000 17:46:30 -0800 (PST) Received: from ariel.gi.com (ariel.gi.com [168.84.84.10]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA20806 for ; Tue, 28 Nov 2000 17:46:29 -0800 (PST) Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #46260) with ESMTP id <01JX2YX3IGBIEZVTMV@GI.COM> for ietf-kink@vpnc.org; Tue, 28 Nov 2000 17:47:25 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 17:46:11 -0500 Content-return: allowed Date: Tue, 28 Nov 2000 20:49:39 -0500 From: "Medvinsky, Sasha (SD-EX)" Subject: RE: alternative to user-to-user Kerberos in KINK To: "'Michael Thomas'" Cc: "'sommerfeld@east.sun.com'" , "'Derek Atkins'" , "'ietf-kink@vpnc.org'" Message-id: <97DEDE66B3DCD11199D200805FA71BE202FD48FE@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain; charset="iso-8859-1" Sender: owner-ietf-kink@mail.vpnc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Mike, The DoS attacks do not apply in the case where clients have a list of servers that they are talking to, where by client and server I mean Kerberos client and application server. In other words, a client will reject a WakeUp if the server name is not in its ACL. This works fine in PacketCable and so if it is not generally useful in KINK, we would leave it as a PacketCable-specific extension that addresses issue #2 you have listed below. Or maybe it could be a separate draft under KINK called something like "client-server profile and extensions to KINK". Sasha. > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Tuesday, November 21, 2000 10:05 AM > To: Medvinsky, Sasha (SD-EX) > Cc: 'sommerfeld@east.sun.com'; 'Derek Atkins'; 'Michael Thomas'; > 'ietf-kink@vpnc.org' > Subject: RE: alternative to user-to-user Kerberos in KINK > > > Medvinsky, Sasha (SD-EX) writes: > > All I was saying is that although you can do peer-to-peer > authentication > > with Kerberos, you shouldn't require it for an > architecture where you don't > > have a peer-to-peer relationship. > > I think client/server and peer-peer is somewhat > misleading. Colloquially, client/server means that > clients initiate transactions, not servers. Peer > to peer means that no such distinction is drawn. > > I don't think that Kerberos, per se, has much to > say on that front because "client" machines can > host services and "server" machines can act as > clients, so it appears to _mostly_ be a distinction > without a difference. > > There are only two things that I know of which > requires me to qualify myself above: > > 1) clients may authenticate using PKINIT which > leads to the U-U/enrollment debate > 2) it may be a worthwhile optimization to allow > machines which subtend large numbers of users > (let's not call them clients, because that's > misleading) to have the abilty to require > the high fanout devices to get and maintain > tickets, thus avoiding duplication of effort > and storage. > > #1 seems like we may be headed toward consensus > that Matt's idea of enrollment may be a reasonable > idea to pursue for PKinit. U-U should also be a > fallback. The dispute seems mostly > over #2. I still feel really uneasy about the > inherent DoS attacks. I'm also not convinced that > the real-life use of KINK cannot avoid this dilemma > for the most part. > > Given the downside, I think that waiting to see > real implementation experience would be a more > prudent course of action. > > Mike >