[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SKIP BOF minutes



Here are the minutes from the SKIP BOF, held at the Stockholm
IETF meeting.

SKIP BOF  (July, 19th 1995; 3:30 pm)
====================================

Working Group Session: Simple Key Management for IP

Chairperson: Martin Patterson (martinp@france.sun.com)

Minutes reported by Hemma Prafullchandra  (hemma@incog.com).

Agenda:
3:30 Intro and reason for the BOF - Martin Patterson (chair)
3:35 SKIP in AH/ESP
4:05 Presentation of ETHZ SKIP implementation
4:30 Presentation of ELVIS+ SKIP implementation
4:55 Presentation of End-System SKIP implementation
5:20 Q&A and general discussion

SKIP in AH/ESP Tom Markson
--------------------------

Q1: 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. 

Q2: 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.

Q3: 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.

Q4: Why not use ephimereal half keys instead of Kijn ?
    (Hilarie Orman -- we could not answer this to Hilarie's satisfaction.
     Ashar will have to address this one.)
    Comment from Hilarie: there are other more elegant solutions ...

Q5: The skip header appears in every ESP packet, any plans to integrate
skip further into ESP ?

   No clear consensus.

   What is the overhead per packet considering there is a skip hdr in
every packet ??

Martin --> refered performance numbers on skip... mention of path mtu discovery.
Point was made that crypto performance is often CPU bound.

(note: Cheryl Madson informed me that path mtu discovery and multicast
is not intended to work for ipv4 as per Steve Deering)

A request was made for some performance figures on unencrypted data but with
 skip hdrs to evaluate the skip hdr overhead per packet issue. Also, some
figures on cpu/network throughput.

A suggestion was made to make use of compressed headers even though
state would have to be maintained. (from Jeff Schiller)

Q6: what are we doing about certificate distribution ?

There is quite a bit of work in progress in this area, 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.

Q7: How many bits of the Diffie-Hellman keys are used to derive the shared secret ?

Q8: Now that we are also discussing the key distribution problem why was
skip not presented at the ipsec wg 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 !


Germano Caronni (skip@tik.ethz.ch) on ETHZ SKIP implementation
--------------------------------------------------------------

- based on first draft + modifications
- ipsp protocol 79
- unicast only
- transport and encapsulated mode
- des, idea and "rc4"
- keyed MD5
- manual keying
- solaris 2.4, NeXTstep, NetBSD
- not interoperable with the other implementations

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


Q: why skip and not photuris ?
  In Feb '95, when my work was started the photuris spec. was not concrete.
SKIP much more simple, basically context free. SKIP works with gateways,
and has concept for small multicast groups.

Still missing:
- multicast
- key management (key distribution for bilateral key exchange on its way)
- no ASN.1, X.509 -- next

Differences from spec:
- defined padding of Kp if required
- for transport mode, used reserved byte after next-p-field to transmit
number of pad bytes
- authentication over next-p-field, reserved bytes, sequence number, data


Q1: 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:
a) Solaris 2.4
    - unicast
    - simple command line interface
    - simple graphical interface
    - MD5
    - final release in October

  Futures: support for multicast and key distribution

b) DOS/Windows
  - NDISv2 compliance driver
  - NDIS v3 next
  - final release in November

  Futures: windows for workgroups and windows95


Q1: cryptography is 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)
---------------------

Slides from Tom.

Q1: Loadable kernel module ?
yes, but tried to limit the dependencies on the kernel.

Q2: does it always have to below ip layer ?
yes

Q3: the draft is not sufficient to implement SKIP, the faq's are also
required. Are you planning to interate the changes into the draft ?
yes, a revision of the draft will be made

Q4: what are the node-ids ?
Martin -> explanation.

Q5: Other groups of algorithms that can be used, is skip flexible enough
to support other algorithms, e.g. elliptic curves ?
Martin -> yes, though Diffie-Hellman is the implicit default.

Q6: How do negotiate what values of the Diffie-Hellman modulus was used
? 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 bits and 1024 bits DH params 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.

Q7: should the faq's be folded incorporated into th skip draft ?
Jeff S. -> not necessarily, they can be specified as separate drafts,
but all the information needs to be provided, and there needs to
concensus on the drafts.

Q8: what is the relation with ipsec ? 
At this point Jeff decided to take a straw-poll.
Q: How many people would be happy with skip moving into the standards
track as an elective standard ?
80% of the attendees raised their hands, 

Jeff -> I think there is
concensus here to move SKIP into the stds track. Ashar needs to discuss with
Jeff S., Paul L. and Ran A. the process by which to proceed further;
clearly some changes will be required to the internet-draft.


SKIP BOF  ROSTER (July, 19th 1995; 3:30 pm)
===========================================

Martin Patterson			martinp@france.sun.com (Chair)
Hemma Prafullchandra			hemma@incog.com
Joseph Reveane				jreveane@france.sun.com
Denis Pinkas				D.pinkas@frcl.bull.fr
Uwe Ellermann				Ellermann@cert.dfn.de
Ward Bathrick				Ward@mls.hac.com
Eric Fleischman				Ericf@atc.hvery.com
Math Aarnro				Mea@funet.fi
Dragan Greboviom			Dragan@bnr.ca
Antonin Fernandez			Afa@bellcore.com
Eric Rescorla				Ekr@eit.com
Jeff Schiller				Jis@mit.edu
Richard Graveman			Rfg@ctt.bellcore.com
Tatu Ylonen				Ylo@cs.hut.fi
Charlie Kaufman				Charlie_Kaufman@iris.com
Germano Caronni				Caronni@tik.ethz.ch
Nick Tzarev				Nick@elvis.ru
Roman Sagalaev				kanat@elvis.ru
Don Stephenson				Dons@eng.sun.com
Masayaki Abe				Abe@isl.ntt.jp
Marc Hasson				Marc@mentat.com
Hiroshi Tachibaa			Tachi@iij.ad.jp
Hilarie Orman				Ho@cs.arizona.edu
Sven Tafvelin				Tafvelin@ce.chalmers.se
David Johnson				Dbj@cs.cmu.edu
Dan Frommer				Dan@radguard.co il
Brett Chappell				Bchappe@relay.nsmc.navy.mil
Bill Medlin				Billmd@cap.hp.com
Cyrus Chow				Cyrus.Chow@arc.nasa.gov
Peter Yee				Yee@Spyrus.com
Sean Kennedy				Liam@bbnplanet.com
Mark Hollinger				Myth@ucx.lkg.dec.com
Mark Scherther				Mjs@tycho.ncsc.mil
David Carrel				Carrel@cisco.com
Leonid Yegoshin				Egoshin@ihep.su
Marcus Leech				Mleech@bnr.ca
Matti Huvila				Matti.Huvila@abo.fi
Randy Catoe				Randy@mci.net
Bob Gilligan				Gilligan@Eng.sun.com
Johan Sandfeldt				Johan.Sandfeldt@it.ki.se
Carl Smith				Cs@Eng.sun.com
Hans Davidson				Hans.Davidson@it.ki.se
Nevil Brownlee				N.Brownlee@auckland.ac.nz
Gunnar Lindberg				Lindberg@cs.chalmers.se
Fumio Teraoka				Tera@csl.sony.co.jp
Joaquim Macedo				Macedo@umunho.pt
Don Bonaddio				Donbon@it.hq.nasa.gov
Cheryl Madson				Cmadson@baynetworks.com
Chris Shenton				Cshenton@wirehead.hq.nasa.gov
Paul Lambert				Paul_Lambert@email.mot.com
Joseph Ferracin				Joseph.Ferracin@ed.nce.sita.int
Juha-Pekka Ahopello			Juha-Pekka.Ahopello@ntc.nokia.com
Urs Eppenberger				Eppenberger@switch.ch
Osman Ismael				Osman@france.sun.com
Bo Kullmar				Bo.Kullmar@riksbank.se
Henry Sihnreich				Hsinreich@mcimail.com
William R. Soley			Soley@eng.sun.com
Alon Cohen				Alon@vocaltec.com
Ute Bormam				Ute@informatikuni-bremen.de
M. Hampton				M.Hampton@ic.ac.uk
Peter Ford				Pford@mci.net
Tom Markson				Markson@incog.com