Subject: 49th IETF KINK WG minutes

From: Jonathan Trostle <[email-masked]>
Date: Tue, 19 Dec 2000 20:58:05 -0800

I have enclosed the KINK WG meeting minutes. Please send any comments 
in the next two days.

Thanks,
Jonathan

KINK WG Meeting Minutes (49th IETF at San Diego, CA, Tuesday, Dec. 12)

Reported by Lisa Dussealt and Jonathan Trostle

INTRODUCTION

The first meeting of the KINK WG took place on December 12th, Tuesday 
1-2PM at the 49th IETF. Derek Atkins and Jonathan Trostle opened the
meeting with the following list of agenda items:

KINK Agenda:
KINK Requirements Draft - Mike Thomas
KINK Key Management Draft - Mike Thomas
Server Initiated Authentication - Sasha Medvinsky
Artificial Phase 1 SA Key Management Draft - Tero Kivinen

The immediate goals of the WG are to move the requirements draft into 
WG last call in January, and to proceed with standardization of a key
management specification.

KINK REQUIREMENTS
-----------------------------------

The WG chairs plan to put the requirements draft into WG last call in 
January.

The current requirements draft specifies that both symmetric key and
public key (pkinit) clients must be supported; it was suggested that initial
authentication is outside the scope of the draft. Initial authentication is 
mentioned in the draft since pkinit clients will not generally have a symmetric 
key in the Kerberos database, and the draft needs to accomodate such
clients acting as servers (by using user-user authentication). The latter
is a required scenario for packetcable security.

There was some discussion on the list of whether the protocol must be 
capable of rekeying, but this seems to be outside of the scope of the work.  
Currently this is in the requirements document. Paul Hoffman stated that he would discuss it on the list. Derek stated that although it's a good goal to have, it's not a hard requirement.

The question was raised whether there ought to be a requirement to work with IPSP. Marcus Leech stated that it should be the other way around: IPSP 
ought to work with the policies. KINK is an effector of these policies.

Paul Hoffman mentioned that there was also interest in using other 
authentication protocols to fake a phase 1 SA in the same manner that
Tero Kivinen's draft uses Kerberos to create the artificial phase 1 SA.
For now, a general mechanism to allow other authentication mechanisms
to be plugged in is out of scope. 

An audience member asked whether there ought to be motivation in the draft 
as well as requirements. In particular, more details on why RFC 2409 (IKE)
is not adequate to solve the set of scenarios being targetted by the WG are
desired. Derek and Mike Thomas indicated that additional concrete motivational suggestions would be welcome. Mike also suggested that the design documents explain the reasoning behind their choices. 

Scott Fluhrer asked about requirements for peer discovery; Jonathan 
Trostle replied that if you don't know who your peer is then there would
be issues with respect to who you are authenticating. Mike stated that the 
issue appeared to be orthogonal. 

KINK KEY MANAGEMENT DRAFT
----------------------------------------------------

Michael Thomas led this discussion. The goals of the draft are to use Kerberos (AP_REQ and AP_REP) messages to establish an IPSEC SA using two messages (or three messages in some cases). The protocol uses a command, reply, and ack messages exchange:

Initiator -------------> Responder
              CMD

Initiator <------------ Responder
              REPLY

Initiator -------------> Responder
              ACK

Several message types are defined (create, delete, etc.) and these messages
use a sequence of ISAKMP defined payloads (currently these payloads are 
defined by value in the draft). For example, the ISAKMP SA, proposal, and 
transform payloads are used in the create message to create a new SA.

The draft also defines new messages to be used to obtain a peer's Kerberos 
ticket granting ticket (TGT) and to send a TGT to the peer, so that user-user
authentication can be used. Using user-user authentication handles the case
where the client is a pkinit client and does not have a long term key in the
Kerberos database. 

Key derivation for the IPSEC SA is defined in the draft. The key derivation can
be accomplished in the two message exchange if the responder is willing
to not contribute to the keys for its outbound SA. If not, the responder sets
the ack bit in the reply and the initiator will use the responder nonce as
additional input into its inbound SA keys. Both initiator and responder 
nonces are used as input into the initiator's outbound SA keys. 

Mike Thomas sent some mail to the list regarding what is needed in order to rekey a security association.  Jesse Walker's contention was that the text in the draft was not explicit enough, so Mike took some of his input from his last mail, and the current text is the result.

Mike stated that we need to create a new SA that describes the new SA, 
basically for the same flow, and set up some rules for which SA to use at which times.  Mike solicits comments on the WG list.

Mike wants to clarify whether the initiator or responder can kill off whatever 
SA they like.  

Mike would like more examination of the key derivation material in the draft. 
He indicated that more work is needed on the error messages too. Mike
looked at Freeswan/Pluto and hopes to have an implementation by the next
IETF (March 2001).

SERVER INITIATED AUTHENTICATION
----------------------------------------------------------

Sasha led the discussion here. Sasha's main concern is in a packetcable
scenario where there are many clients communicating with a single server.
There is a standby server that takes over when the first server fails. With
the existing KINK draft user to user approach, the server must request the
client's TGT and then obtain a service ticket targetted at the client. Sasha
would like to send a new message, the wakeup message, from the server
to the client to indicate to the client that it should obtain a service ticket
for the server and then authenticate to the server. Thus some of the work is
shifted from the server to the client thus improving scalability and performance
of the server in this failover scenario. 

One concern that was expressed regarding Sasha's approach is that 3rd party denial of service attacks would be easy to launch and potentially difficult to track. In particular, a malicious peer could send wakeups (which are unauthenticated) to a large number of clients in order to bring down a given server(s) and also temporarily remove a KDC from service. Additionally, data would not flow earlier on the IPSEC SA. Alternative solutions include the sharing the ticket cache between the two servers, and pre-establishment of IPSEC SA's between the clients and the backup server.

Sasha also raised some concerns regarding authorization data in tickets when using user-user authentication. Matt Hur and others disagreed with this line of reasoning, saying that the KDC could just as easily bind policy and authorization data for either the client or the server into the ticket. 

Additionally, some denial of service attacks might be mitigated if the client has an access control list which would prevent some wake up requests from being acted upon. Access control lists would not be applicable in all environments, and would only partially mitigate denial of service attacks in environments where they could be used. 

There was a desire to resolve this issue at the WG meeting rather than move the discussion to the WG list, but since roughly 10 people had read the draft, it was decided to move the discussion to the list and obtain consensus there.

ARTIFICIAL KERBEROS IKE SA DRAFT
-----------------------------------------------------------

Tero Kivinen presented his draft for KINK key management: 
draft-ietf-kink-ike-over-kkmp-00.txt.  The draft uses a newly defined 
Kerberos payload to exchange the AP_REQ and AP_REP messages.
At that point, the two peers share the Kerberos session key which is used
to create the following shared state (corresponding to a successful phase
1 exchange): cookies, SKEYID for key material, and IV.

Everything that is in IKE phase 2 can be supported: new group mode, quick 
mode, etc.

Tero claimed that his draft is quite simple to implement.  Tero has implemented IKE, and he stated that his new draft would take one day to implement.

Tero also stated that any new features or improvements to phase 2 IKE could
also be reflected in his work since it builds upon IKE. Tero noted that he
needed to add the capability for Kerberos user-user messages. The Kerberos
payload message in his draft could be used to transport KRB_TGT_REQ and
KRB_TGT_REPLY messages, in order to support user to user messages.

An audience member questioned the possibility of replays. Tero stated that
if the SA is already valid, then they see there is duplicate SA numbers
so they drop the packet immediately.  When it doesn't see any traffic coming 
through, it doesn't do any expensive calculation. Derek pointed out that
the Kerberos authenticator contains a timestamp to prevent replays.

Another audience member also asked whether the Kerberos session key
was big enough; the response was that the key is typed so it will be the
right size for whatever crypto algorithm is being used.