home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / 95jul / skip-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  7KB  |  246 lines
  1.  
  2. Simple Key Management for IP BOF (SKIP)
  3.  
  4. Reported by Hemma Prafullchandra/Sun Microsystems
  5.  
  6. The SKIP BOF met once at the 33rd IETF on Wednesday, 19 July.  The
  7. meeting was chaired by Martin Patterson.
  8.  
  9.  
  10. Agenda
  11.  
  12.    o Introduction
  13.    o SKIP in AH/ESP
  14.    o ETHZ SKIP implementation
  15.    o ELVIS+ SKIP implementation
  16.    o End-System SKIP implementation
  17.    o General discussion
  18.  
  19.  
  20. SKIP in AH/ESP -- Tom Markson
  21.  
  22. How is the Kp algorithm related to the IPSEC security transforms
  23. algorithm?
  24.  
  25.      Kp algorithm is specified using eight bits, so one can assign a
  26.      number for every transform defined by IPSEC.
  27.  
  28.  
  29. What if it requires more than eight bits?  Would Sun/author be willing
  30. to change the specification to allow it to inter-work with ESP?
  31.  
  32.      Yes, as our goal is to allow SKIP to inter-work with ESP.
  33.  
  34.  
  35. What is the lifetime of Kij?
  36.  
  37.      The lifetime of Kij is dependent on the lifetime of the
  38.      Diffie-Hellman keys of the communicating parties.  The lifetime of
  39.      Kijn is implementation dependent, meaning whenever n is changed,
  40.      Kijn will change.  n is never zero.
  41.  
  42.  
  43. Comment:  For interoperability, how n changes also needs to be defined
  44. and not only how the initial value is established.
  45.  
  46. Why not use ephemeral half keys instead of Kijn?
  47.  
  48.      (This question could not be answered to Hilarie Orman's
  49.      satisfaction.  Ashar will have to address this one.)  Hilarie
  50.      commented that there are other more elegant solutions.
  51.  
  52.  
  53. The SKIP header appears in every ESP packet.  Are there any plans to
  54. integrate SKIP further into ESP?
  55.  
  56.      There was no clear consensus.
  57.  
  58.  
  59. What is the overhead per packet considering there is a SKIP header in
  60. every packet?
  61.  
  62.      Martin referred to performance numbers on SKIP; mentioned path MTU
  63.      discovery.  The point was made that crypto performance is often CPU
  64.      bound.  (Cheryl Madson reported that, per Steve Deering, path MTU
  65.      discovery and multicast is not intended to work for IPv4.)  A
  66.      request was made for some performance figures on unencrypted data
  67.      with SKIP headers to evaluate the SKIP header overhead per packet
  68.      issue.  Some figures were also requested on cpu/network throughput.
  69.      Jeff Schiller suggested using compressed headers even though state
  70.      would have to be maintained.
  71.  
  72.  
  73. What are we doing about certificate distribution?
  74.  
  75.      There is quite a bit of work in progress in this area, but no
  76.      specifications as this time.  We have a limited protocol
  77.      implemented to do bilateral certificate exchange, we are also
  78.      working on both chained and cross-certification models of the
  79.      X.509/PEM world and the PGP web-of-trust.  We would like to work
  80.      within IPSEC on this.
  81.  
  82.  
  83. How many bits of the Diffie-Hellman keys are used to derive the shared
  84. secret?  Now that we are also discussing the key distribution problem,
  85. why was SKIP not presented at the IPSEC Working Group session during the
  86. key management session?
  87.  
  88.      SKIP assumes that the communicating parties have already
  89.      established certified Diffie-Hellman public keys for the
  90.      corresponding party/parties.  Now, we are working on solving the
  91.      problem of certificate distribution; we have nothing to present
  92.      yet.
  93.  
  94.  
  95.  
  96. ETHZ SKIP Implementation -- Germano Caronni
  97.  
  98.    o Based on first draft plus modifications
  99.    o IPSP protocol 79
  100.    o Unicast only
  101.    o Transport and encapsulated mode
  102.    o Des, idea and "rc4"
  103.    o Keyed MD5
  104.    o Manual keying
  105.    o Solaris 2.4, NeXTSTEP, NetBSD
  106.    o Not interoperable with the other implementations
  107.  
  108.  
  109. FTP over IP with DES+MD5 (ss10 -> ss20) => approximately 300kB/sec).
  110. This work will be released in the public domain around the 15th of
  111. August.
  112.  
  113. Why SKIP and not photuris?
  114.  
  115.      In February of 1995, when my work was started, the photuris
  116.      specification was not concrete.  SKIP is much more simple,
  117.      basically context free.  SKIP works with gateways, and has concept
  118.      for small multicast groups.
  119.  
  120.  
  121. Still missing:
  122.  
  123.    o Multicast
  124.  
  125.    o Key management (key distribution for bilateral key exchange on its
  126.      way)
  127.  
  128.    o No ASN.1, X.509 -- next
  129.  
  130.  
  131. Differences from the specification:
  132.  
  133.  
  134.    o Defined padding of Kp if required
  135.  
  136.    o For transport mode, used reserved byte after next-p-field to
  137.      transmit number of pad bytes
  138.  
  139.    o Authentication over next-p-field, reserved bytes, sequence number,
  140.      data
  141.  
  142.  
  143. Which level of OS was this implemented to?
  144.  
  145.      For Solaris, to binary (no source available).
  146.      For NeXTSTEP, as a binary patch.
  147.      For NetBSD, catch interrupts.
  148.  
  149.  
  150.  
  151. ELVIS+ -- Nickolai Tzarev
  152.  
  153. Two realizations:
  154.  
  155.    o Solaris 2.4
  156.  
  157.       -  Unicast
  158.       -  Simple command line interface
  159.       -  Simple graphical interface
  160.       -  MD5
  161.       -  Final release in October
  162.  
  163.      Futures:  support for multicast and key distribution
  164.  
  165.    o DOS/Windows
  166.  
  167.       -  NDISv2 compliance driver
  168.       -  NDIS v3 next
  169.       -  Final release in November
  170.  
  171.      Futures:  windows for workgroups and windows95
  172.  
  173.  
  174. Cryptography in Russia is banned, how is this going to effect your work?
  175.  
  176.      Encryption/decryption is banned but if used for privacy of personal
  177.      information then is it okay.  Also, the president has signed the
  178.      decree, the parliament has not.
  179.  
  180.  
  181.  
  182. ES-SKIP -- Tom Markson
  183.  
  184. Loadable kernel module?
  185.  
  186.      Yes, but tried to limit the dependencies on the kernel.
  187.  
  188.  
  189. Does it always have to run below the IP layer?
  190.  
  191.      Yes.
  192.  
  193.  
  194. The draft is not sufficient to implement SKIP, the FAQs are also
  195. required.  Are you planning to integrate the changes into the draft?
  196.  
  197.      Yes, a revision of the draft will be made
  198.  
  199.  
  200. What are the node-ids?
  201.  
  202.      Martin gave an explanation.
  203.  
  204.  
  205. There are other groups of algorithms that can be used, is SKIP flexible
  206. enough to support other algorithms, e.g., elliptic curves?
  207.  
  208.      Martin said yes, though Diffie-Hellman is the implicit default.
  209.  
  210.  
  211. How are the values that the Diffie-Hellman modulus used negotiated?  If
  212. you have a 512 bit modulus and a 1024 bit modulus, will they
  213. interoperate?
  214.  
  215.      SKIP does not negotiate this.  It is done out-of-band.  512-bit DH
  216.      keys will not interoperate with 1024-bit DH keys.
  217.  
  218.      For interoperability, a set of 512-bit and 1024-bit DH parameters
  219.      should be published as part of the draft.  Generate a set of these
  220.      parameters that impeachable in the IETF forum.
  221.  
  222.      Internet standards need to be specified in a manner that
  223.      independent implementations can interoperate.  Photuris negotiates
  224.      almost everything, so that if independent implementations existed
  225.      they are very likely to interoperate.  Skip should be able to
  226.      negotiate which Kij and Kp algorithms are supported by the remote
  227.      party.
  228.  
  229.  
  230. Should the FAQs be folded or incorporated into the SKIP draft?
  231.  
  232.      Jeff did not think this is necessary.  They can be specified as
  233.      separate drafts, but all the information needs to be provided, and
  234.      there needs to consensus on the drafts.
  235.  
  236.  
  237. What is the relation with IPSEC?
  238.  
  239.      Jeff decided to take a straw-poll and asked how many people would
  240.      be happy with SKIP moving into the standards track as an Proposed
  241.      Standard?  80/consensus to move SKIP into the standards track.
  242.      Ashar needs to discuss with Jeff S., Paul L. and Ran A. how to
  243.      proceed; clearly some changes will be required to the
  244.      Internet-Draft.
  245.  
  246.