home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / ipsec / ipsec-minutes-95jul.txt < prev    next >
Text File  |  1995-10-18  |  10KB  |  234 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Antonio Fernandez/Bellcore and Mark Schertler/NSA
  6.  
  7. Minutes of the IP Security Protocol Working Group (IPSEC)
  8.  
  9. The IPSEC Working Group met during the 33rd IETF on Wednesday, 19 July.
  10. Paul Lambert chaired the meeting which was broadcast on the MBone.  The
  11. meeting covered the status of the IP ESP and AH documents, a
  12. presentation and discussion about the Internet Key Management Protocol
  13. (IKMP) and a presentation of DNS Security Extensions (DNSSEC) to provide
  14. long-term keys on the Internet.
  15.  
  16. Martin Patterson announced a SKIP BOF. Several implementations of SKIP
  17. have been developed and alignment of SKIP with ESP and AH is being
  18. discussed.  The main purpose of the BOF is to get the people
  19. implementing versions of SKIP together.
  20.  
  21.  
  22.  
  23. IPSEC Document Status
  24.  
  25.  
  26. The following IPSEC Specifications have been advanced to Proposed
  27. Standard:
  28.  
  29.  
  30.    o Security Architecture for the Internet Protocol
  31.      <draft-ietf-ipsec-arch-02.txt>
  32.  
  33.    o IP Authentication Header <draft-ietf-ipsec-auth-02.txt>
  34.  
  35.    o IP Encapsulating Security Payload (ESP)
  36.      <draft-ietf-ipsec-esp-01.txt>
  37.  
  38.    o IP Authentication using Keyed MD5 <draft-ietf-ipsec-ah-md5-03.txt>
  39.  
  40.    o The ESP DES-CBC Transform <draft-ietf-ipsec-esp-des-cbc-04.txt>
  41.  
  42.  
  43. The IP Authentication using Keyed MD5 specification before it is
  44. forwarded to the RFC Editor will be edited to reflect Hugo Krawczyk's
  45. comments concerning having the prepended key padded with a one (1) and
  46. some number of zeros (0) to a length of 512 bits.
  47.  
  48. Jeff Schiller, Security Area Director, will provide the official
  49. response to the comments received during the Last Call period.
  50.  
  51. Several implementations of ESP and AH are being developed and an
  52. implementor's mailing list has been started.  Contact Perry Metzger
  53. (perry@imsi.com) if you are an implementor and would like to be on the
  54. mailing list.
  55.  
  56.  
  57. Internet Key Management Protocol (IKMP)
  58.  
  59.  
  60. Currently IPSEC is considering two Internet Key Management Protocol
  61. (IKMP) Proposals:
  62.  
  63.  
  64.    o Photuris <draft-ipsec-photuris-02.txt>
  65.    o Internet Security Association Key Management Protocol (ISAKMP)
  66.      <draft-nsa-isakmp-01.txt>
  67.  
  68.  
  69. Paul Lambert reviewed the IKMP goals and requirements.  The IKMP
  70. mechanism must support the selection of security transforms and creation
  71. of session keys for ESP and AH. Algorithm, mechanism, and key exchange
  72. independence to provide migration for the future is also a requirement.
  73. IKMP should be general enough to be used by protocols developed in other
  74. working groups.
  75.  
  76. Photuris
  77.  
  78. The Photuris editors, Phil Karn and Bill Simpson, were unable to attend
  79. the IETF meeting.  In their absence an open discussion of Photuris was
  80. held.  Issues raised concerning the Photuris specification included the
  81. need to clarify the relationship between the security association
  82. definitions in Photuris and in the Security Architecture for IP
  83. specification.  Another clarification required is how the SIGN exchange
  84. should be encrypted.  The question of how Photuris would be used by a
  85. router acting on behalf of an end system was also raised.
  86.  
  87. Internet Security Association and Key Management Protocol (ISAKMP)
  88.  
  89. Mark Schertler, NSA Information Systems Security Organization (ISSO),
  90. presented the Internet Security Association and Key Management Protocol
  91. (ISAKMP).
  92.  
  93. ISAKMP is a flexible key management architecture that provides a common
  94. mechanism for security attribute negotiation, strong authentication, and
  95. session key establishment.  ISAKMP is key exchange, authentication
  96. mechanism, and cryptographic algorithm independent.  ISAKMP by providing
  97. a common security association (SA) establishment mechanism can be used
  98. by other protocols developed by the IETF that require SAs.  This
  99. architecture follows the Security Architecture for IP, ESP and AH
  100. specifications lead.  As was done in the IP Authentication using Keyed
  101. MD5 ESP DES-CBC specifications, a base KMP transform including a session
  102. key generation algorithm, authentication mechanism, and encryption
  103. algorithm must be specified.  The Photuris session key generation
  104. algorithm is a good candidate for the base KMP transform.  This is a
  105. possible way to utilize both proposals---ISAKMP as the Internet Key
  106. Management Protocol and Photuris as the base IKMP transform.
  107.  
  108. The features of ISAKMP include:
  109.  
  110.  
  111.    o A fixed field header that contains no security attributes making
  112.      header parsing consistent and migration to new security attributes
  113.      easier
  114.  
  115.    o Replay prevention using a time variant cookie
  116.  
  117.    o Initialization exchange to indicate base KMP transform or select
  118.      other KMP transforms to protect SA and session key establishment
  119.  
  120.    o Strong authentication mechanism required
  121.  
  122.    o Support for multiple certificate authorities
  123.  
  124.    o Transport protocol independence
  125.  
  126.  
  127. Following its header, ISAKMP separates security information into
  128. discrete payloads based on the security information's function.  The key
  129. exchange payload has a Key Exchange Identifier (KEI) which indicates the
  130. key exchange algorithm used.  KEIs must be specified in a separate RFC
  131. and/or registered with IANA. The RFC would define the keying information
  132. and payload format to be exchanged with the protocol.
  133.  
  134. The authentication payload identifies the Certificate Authority that
  135. issued the certificate.  This is also an IANA issued identifier.  The
  136. Authentication Type field indicates the type of authentication data
  137. (e.g., Certificate format).  Finally the payload contains the
  138. authentication data that is used to authenticate the peer entity.
  139.  
  140. The Security Association (SA) payload contains the security attributes
  141. being offered (request) or accepted (response) for the security
  142. association.  Security attributes can be bundled together into a set
  143. (e.g., encryption - DES, hash - MD5, signature - RSA, etc.)  or each
  144. attribute can be followed by a list of the acceptable options (e.g.,
  145. encryption - DES, IDEA, 3DES). Either format has a field which indicates
  146. which security service the security attributes support (e.g., ESP, AH,
  147. or OSPF authentication).  The SA payload supports the SA parameters
  148. defined in the Security Architecture for IP and allows for migration to
  149. SA parameters defined for future security services and mechanisms.
  150.  
  151. ISAKMP defines protocol exchanges to establish Security Associations
  152. (SAs) and create session keys, modify SAs, delete SAs and transmit
  153. notifications (error messages and front-end synchronization).
  154.  
  155. A concern was raised that the ISAKMP proposal has too much flexibility,
  156. too many combinations will make it impossible to understand all the
  157. security implications.  Therefore, only a minimum of flexibility is
  158. required.  Responses from the floor stated that we can not have only one
  159. solution (key exchange algorithm).  Another statement was that we must
  160. choose one key exchange everyone implements for interoperability, but we
  161. must allow an open migration path and not tie ourselves down to a
  162. specific algorithm.  The ISAKMP editors stated that ISAKMP is a protocol
  163. that supports many key management architectures, the Photuris key
  164. exchange is an example of a key exchange that fits into the ISAKMP
  165. protocol and can be defined as the must implement for Internet
  166. interoperability.
  167.  
  168. Development of an ISAKMP prototype has begun and the developers are open
  169. to all suggestions.  Initially the prototype will negotiate and place
  170. two types of security associations.  The first an Internet SA utilizes
  171. either RSA with PGP certificates or RSA with RSA certificates for its
  172. authentication mechanism, the Diffie-Van Oorschot-Wiener STS (Photuris)
  173. for session key creation, DES-CBC for encryption, and MD5 for hashing.
  174. The second SA utilize algorithms form the Fortezza Card which are DSA
  175. with Fortezza certificates for authentication, Key Exchange Algorithm
  176. (KEA) for session key creation, Skipjack for encryption and Secure Hash
  177. Algorithm (SHA) for hashing.  The developers welcome anyone who would
  178. like to develop additional security associations to contact them.
  179.  
  180. The prototype is on SunOS 4.1.3, using gcc 2.6.x and running on UDP for
  181. the transport protocol.  The schedule is to complete the prototype by
  182. 17 November and post the source code on the NSA Web Site
  183. (http://www.nsa.gov:8080/).  The developer's future plans are to
  184. prototype an Internet security solution using ISAKMP, ESP, and AH. A
  185. model of ISAKMP has been developed using the Foresight modeling tool.
  186. This model will be used to perform vulnerability testing prior to
  187. prototype completion.
  188.  
  189.  
  190.  
  191. DNS Security Extensions (DNSSEC)
  192.  
  193.  
  194. Donald Eastlake presented work being done on DNS Security Extensions
  195. (DNSSEC) and its relationship to IPSEC work.  IKMP will create session
  196. (short-term) keys, but there is also a requirement for long-term keys.
  197. There are several sources for long-term keys, and one is the DNSSEC.
  198. DNSSEC includes provisions for associating long-term keys with users and
  199. hosts and also explicit provisions for indicating the protocols
  200. associated with the long-term keys.  The public (long-term) keys can be
  201. signed (e.g., certified) and stored in the DNS. Thus the long-term keys
  202. are available on-line.  DNSSEC supports a variety of key types requests.
  203. DNS is widely deployed in the Internet and having the entities being
  204. named linked to the domain names is a natural in the global Internet.
  205.  
  206. Public alpha code will be made available soon (in the next few days) by
  207. Trusted Information Systems (TIS).
  208.  
  209. The Internet-Draft which incorporates implementation experience thus far
  210. is available at:
  211.  
  212. ftp://ds.internic.net/internet-drafts/draft-ietf-dnssec-secext-04.txt
  213.  
  214.  
  215.  
  216. Future Work Items
  217.  
  218. Paul Lambert concluded the meeting by presenting a list of possible
  219. future work items that the IPSEC Working Group should consider.
  220.  
  221.  
  222.    o Management of security (ESP, AH, etc.)
  223.    o Access control
  224.    o Additional Security Transforms
  225.    o Additional Security Exchanges
  226.    o Multicast Key Management
  227.    o 3rd part security (router like)
  228.    o Naming
  229.    o Cryptographic issues
  230.    o MD5 security issues
  231.    o True anonymity
  232.    o Application issues
  233.  
  234.