IP Security Working Group
Twenty-Ninth IETF
March 31, 1994

Co-chair: Paul Lambert
Motorola
602-441-3646
Paul_Lambert@email.mot.com

Co-chair: Jim Zmuda
Spyrus

IP Security (IPSEC) Agenda

• 9:30 - Introductions - review and approve agenda
• 9:40 - Review of charter and schedule
• 9:50 - Liaisons
• 10:00 - Brief review of existing implementations
• 10:05 - Presentation and discussion on joint IPSP proposal
• 10:20 - Review and discussion of IPSP issues and recommendations
• 10:30 - Key management - discussion of related activities
• 11:15 - IP key management - What is it?
• 11:40 - Summary of key management recommendations
• 11:50 - Summary - next meeting, review action items, update schedule
• 12:00 - Adjourn

IP Security Protocol Environment

IPSP in Reference Model

Applicable Standards

• IEEE Standard for Interoperable LAN Security (SILS) Secure Data Exchange - IEEE 802.10B and Key Management - IEEE 802.10C
• ISO SC6 and SC21
  ISO-IEC DIS 11577 Network Layer Security Protocol
• ANSI X3T5.7 Generic Upper Layer Security
• IETF - Common Authentication Technologies
• IETF - Privacy Enhanced Mail
• X.509 - Security for the Directory Service
• X.411 Security for Electronic Messaging
• ANSI X9 Wholesale and Retail Key Management Standards
• NIST Digital Signature Standard (DSS)
• RSA Signature Specifications
• ANSI X3S3.3 (Network Layer Security Protocol - NLSP)
• CCITT T1.P1 (Universal Personal Communications)
• And others

Standards for Lower Layer Security

IP Security Protocol

• Many specifications for "network layer security" (SP3-N, SP3-A, SP3-I, SP3-D, SP3-C, NLSP, I-NLSP, swIPe, and others)
• Many implementations of various flavors of IP layer security (ANS, AT&T, DEC, Hughes, Morningstar, Motorola, Semaphore, UUNET, and others)
• No interoperation between implementations
• No IPSP Internet-Draft (yet...)

IPSP Proposal (Lambert, Zmuda and Others)

• Simple cryptographic encapsulation protocol
• Support algorithm independence by "bundling" cryptographic processing and field formats into a "security transformation"
• Defer:
  • Fragmentation
  • Sequence integrity without recovery
• Include worked examples of "security transformations" for:
  • Confidentiality, integrity, and authentication
    (initial recommendation DES-CBC-MD5)
  • Confidentiality only
    (initial recommendation DES-CBC)
  • Integrity and authentication
    (initial recommendation MD5-keyed)

IPSP Protocol Processing

• Determine the appropriate security association
• Prepend the protocol and length fields
• Perform cryptographic transformation
• Prepend SAID

• Determine if SA required
• Use source and destination address and SAID to select SA
• Perform transformation indicated in SA info
• Pass data to next protocol indicated by IPSP "next protocol" field

IPSP Generic Format

IPSP Format With DES-CBC-MD5

IPSP Action Items

• Publish IPSP Internet-Draft
• Coordinate interoperable pilot
  • Manual key management
  • Single "security transformation"
    (DES-CBC-MD5?)
• Solicit IPSP review and writing
  • MD5 based integrity only
  • Fragmentation
  • Security transformation with sequence integrity
  • Other optional security transformations (public key based?)

IP Key Management

• A protocol and cryptographic techniques
• Application layer protocol for IPSP
• Independent of IPSP
• Initially supporting public key techniques (not patent issues!)
• Later adding key distribution center (e.g., Kerberos) and/or manual

Key Management

• SDNS KMP - missing some things like algorithms
• IEEE 802.10C - draft form, still very rough, based on GULS
• ISO GULS - generic envelopes, very complex, no specific algorithms or option negotiation
• PEM - not real-time, but does address certificates
• PGP
• X.509 - IPSEC will likely use X.509 certificate formats
• X9.17 - private keys, now working on public keys
• SAMP - second generation SDNS KMP, may be posted to net soon
• SAEP - embedded in NLSP, network layer protocol
• Kerberos - private keys centrally managed
• CATS-GSSAPI - IPSP KMP might be able to use their interface to pass information to IPSP; also an outstanding question of whether IPSP will meet their needs from a user perspective

Peer-to-Peer Exchanges

• Authentication mechanism/algorithm negotiation - we will support multiple algorithms
• Peer-entity authentication - often built into the key exchange
• Key establishment - obtain or create a key for use by IPSP
• Security association negotiation
• Termination of SA

Security Management

• Certificate distribution - peer-to-peer or via a third party (PEM, PGP, DNS)
• CRL list - possibly support through SNMP
• Centralized key distribution - used for shared key/multicast
• Access control attributes

Key Management Issues

• Device name and address implications for directories and certificates
• Authorization list/delegation - what hosts is an IPSP router permitted
• How are IPSP access lists for routers distributed and maintained?
• Can a SA change, or is a change accomplished by terminating an old SA and establishing a new one??
• Shared keys - used for multicast or (possibly) multiple IPSP routers serving a site