Simple Key Management for IP BOF (SKIP)

Reported by Hemma Prafullchandra/Sun Microsystems

The SKIP BOF met once at the 33rd IETF on Wednesday, 19 July.  The
meeting was chaired by Martin Patterson.


Agenda

   o Introduction
   o SKIP in AH/ESP
   o ETHZ SKIP implementation
   o ELVIS+ SKIP implementation
   o End-System SKIP implementation
   o General discussion


SKIP in AH/ESP -- Tom Markson

How is the Kp algorithm related to the IPSEC security transforms
algorithm?

     Kp algorithm is specified using eight bits, so one can assign a
     number for every transform defined by IPSEC.


What if it requires more than eight bits?  Would Sun/author be willing
to change the specification to allow it to inter-work with ESP?

     Yes, as our goal is to allow SKIP to inter-work with ESP.


What is the lifetime of Kij?

     The lifetime of Kij is dependent on the lifetime of the
     Diffie-Hellman keys of the communicating parties.  The lifetime of
     Kijn is implementation dependent, meaning whenever n is changed,
     Kijn will change.  n is never zero.


Comment:  For interoperability, how n changes also needs to be defined
and not only how the initial value is established.

Why not use ephemeral half keys instead of Kijn?

     (This question could not be answered to Hilarie Orman's
     satisfaction.  Ashar will have to address this one.)  Hilarie
     commented that there are other more elegant solutions.


The SKIP header appears in every ESP packet.  Are there any plans to
integrate SKIP further into ESP?

     There was no clear consensus.


What is the overhead per packet considering there is a SKIP header in
every packet?

     Martin referred to performance numbers on SKIP; mentioned path MTU
     discovery.  The point was made that crypto performance is often CPU
     bound.  (Cheryl Madson reported that, per Steve Deering, path MTU
     discovery and multicast is not intended to work for IPv4.)  A
     request was made for some performance figures on unencrypted data
     with SKIP headers to evaluate the SKIP header overhead per packet
     issue.  Some figures were also requested on cpu/network throughput.
     Jeff Schiller suggested using compressed headers even though state
     would have to be maintained.


What are we doing about certificate distribution?

     There is quite a bit of work in progress in this area, but no
     specifications as this time.  We have a limited protocol
     implemented to do bilateral certificate exchange, we are also
     working on both chained and cross-certification models of the
     X.509/PEM world and the PGP web-of-trust.  We would like to work
     within IPSEC on this.


How many bits of the Diffie-Hellman keys are used to derive the shared
secret?  Now that we are also discussing the key distribution problem,
why was SKIP not presented at the IPSEC Working Group session during the
key management session?

     SKIP assumes that the communicating parties have already
     established certified Diffie-Hellman public keys for the
     corresponding party/parties.  Now, we are working on solving the
     problem of certificate distribution; we have nothing to present
     yet.



ETHZ SKIP Implementation -- Germano Caronni

   o Based on first draft plus modifications
   o IPSP protocol 79
   o Unicast only
   o Transport and encapsulated mode
   o Des, idea and "rc4"
   o Keyed MD5
   o Manual keying
   o Solaris 2.4, NeXTSTEP, NetBSD
   o Not interoperable with the other implementations


FTP over IP with DES+MD5 (ss10 -> ss20) => approximately 300kB/sec).
This work will be released in the public domain around the 15th of
August.

Why SKIP and not photuris?

     In February of 1995, when my work was started, the photuris
     specification was not concrete.  SKIP is much more simple,
     basically context free.  SKIP works with gateways, and has concept
     for small multicast groups.


Still missing:

   o Multicast

   o Key management (key distribution for bilateral key exchange on its
     way)

   o No ASN.1, X.509 -- next


Differences from the specification:


   o Defined padding of Kp if required

   o For transport mode, used reserved byte after next-p-field to
     transmit number of pad bytes

   o Authentication over next-p-field, reserved bytes, sequence number,
     data


Which level of OS was this implemented to?

     For Solaris, to binary (no source available).
     For NeXTSTEP, as a binary patch.
     For NetBSD, catch interrupts.



ELVIS+ -- Nickolai Tzarev

Two realizations:

   o Solaris 2.4

      -  Unicast
      -  Simple command line interface
      -  Simple graphical interface
      -  MD5
      -  Final release in October

     Futures:  support for multicast and key distribution

   o DOS/Windows

      -  NDISv2 compliance driver
      -  NDIS v3 next
      -  Final release in November

     Futures:  windows for workgroups and windows95


Cryptography in Russia is banned, how is this going to effect your work?

     Encryption/decryption is banned but if used for privacy of personal
     information then is it okay.  Also, the president has signed the
     decree, the parliament has not.



ES-SKIP -- Tom Markson

Loadable kernel module?

     Yes, but tried to limit the dependencies on the kernel.


Does it always have to run below the IP layer?

     Yes.


The draft is not sufficient to implement SKIP, the FAQs are also
required.  Are you planning to integrate the changes into the draft?

     Yes, a revision of the draft will be made


What are the node-ids?

     Martin gave an explanation.


There are other groups of algorithms that can be used, is SKIP flexible
enough to support other algorithms, e.g., elliptic curves?

     Martin said yes, though Diffie-Hellman is the implicit default.


How are the values that the Diffie-Hellman modulus used negotiated?  If
you have a 512 bit modulus and a 1024 bit modulus, will they
interoperate?

     SKIP does not negotiate this.  It is done out-of-band.  512-bit DH
     keys will not interoperate with 1024-bit DH keys.

     For interoperability, a set of 512-bit and 1024-bit DH parameters
     should be published as part of the draft.  Generate a set of these
     parameters that impeachable in the IETF forum.

     Internet standards need to be specified in a manner that
     independent implementations can interoperate.  Photuris negotiates
     almost everything, so that if independent implementations existed
     they are very likely to interoperate.  Skip should be able to
     negotiate which Kij and Kp algorithms are supported by the remote
     party.


Should the FAQs be folded or incorporated into the SKIP draft?

     Jeff did not think this is necessary.  They can be specified as
     separate drafts, but all the information needs to be provided, and
     there needs to consensus on the drafts.


What is the relation with IPSEC?

     Jeff decided to take a straw-poll and asked how many people would
     be happy with SKIP moving into the standards track as an Proposed
     Standard?  80/consensus to move SKIP into the standards track.
     Ashar needs to discuss with Jeff S., Paul L. and Ran A. how to
     proceed; clearly some changes will be required to the
     Internet-Draft.