21
1 Network Layer Security Howie Weiss (NASA/JPL/Cobham Analytic Solutions) Berlin Germany May 2011

Network Layer Security Howie Weiss (NASA/JPL/ Cobham Analytic Solutions) Berlin Germany May 2011

  • Upload
    arella

  • View
    51

  • Download
    0

Embed Size (px)

DESCRIPTION

Network Layer Security Howie Weiss (NASA/JPL/ Cobham Analytic Solutions) Berlin Germany May 2011. Agenda. CCSDS Network Layer Security IPSec+IKE Profile for CCSDS What is included? What is excluded? How is it used?. What is Network Layer Security?. Space extensions to FTP. Other Apps. - PowerPoint PPT Presentation

Citation preview

Page 1: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

1

Network Layer SecurityHowie Weiss

(NASA/JPL/Cobham Analytic Solutions)

Berlin GermanyMay 2011

Page 2: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

2

Agenda

• CCSDS Network Layer Security– IPSec+IKE Profile for CCSDS

» What is included?» What is excluded?» How is it used?

Page 3: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

3

What is Network Layer Security?

SCPS-NP IP

Space Link Subnet: CCSDS Data Link

SCPS-SP

Other Apps

IPSec

UDPTCPSC

PS-F

PTCP

Options

FTPFTPFeaturesSpace extensions

to the Socket Interface

Common Network-Layer Interface

SCPS-TP “TCP Tranquility”options

Space-optimizedIP variant

Space-optimizedIPSec variant

Space extensions to FTP

IKE

Page 4: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

4

IPSec: one protocol, many options

• Tunnel mode vs. transport mode• Default cipher suite (encryption + auth + mode)

– Authenticated encryption?– Null encryption (authentication-only)?

» ESP w/null encrypt or AH?– What would be allowed?

• Anti-replay option• Keying and rekeying

– Pre-placed keys?– IKE auto rekey

» Automatic when keys expire – regardless of mission state?

» Rekey “now” button?

Page 5: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

5

Issues to be resolved`

• Transport or tunnel mode or both?• ESP-only? AH-only?• ESP + AH?• Authentication-only w/o encryption allowed? (null

encryption)• Authenticated Encryption or Encryption w/o auth

allowed?• Keying and rekeying questions

– Automated vs. manual» IKEv1 or IKEv2

– SA lifetimes• Policy Management• Define default cipher suite(s)• Compression

Page 6: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

6

Transport vs. Tunnel Mode

• Transport Mode:– Single IP header– End-to-End mode (writter-2-

reader)– Not generally used commercially

• Tunnel Mode:– Dual IP headers – entire IP packet

is encapsulated– Gateway-to-Gateway mode

» Allows IPSec to be outboard in security gateways

» E.g., commercial VPNs• Recommendation for CCSDS:

– Tunnel Mode

Page 7: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

7

IPSec is TWO Protocols

• AH: IP Authentication Header (RFC 4302)– connectionless integrity – data origin authentication.– optional replay protection– No confidentiality

• ESP: Encapsulating Security Payload (RFC 4303)– confidentiality, – data origin authentication, – connectionless integrity, – anti-replay protection (w/automated key management), – limited traffic flow confidentiality.

» Provides encryption-only service for confidentiality» Provides integrity-only service» Provides confidentiality + integrity service

Page 8: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

8

AH Packet Format

IPv4Header

20 bytes

AHHeader

24 bytes

IPv4Header

20 bytes

ICMPHeader

8 bytes

ICMPData

80 bytes

NextHeader=IPIP1 byte

Length(this header)

1 byte

Pad

2 bytes

AHSPI

4 bytes

AHSeq #

4 bytes

AHICV

12 bytes

AH (IP protocol 51) total length 152 bytes

AH Authenticated (108 bytes)

Page 9: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

9

ESP w/Null Encryption

ESPSPI

4 bytes

ESPSeq #

4 bytes

IPv4 Header

20 bytes

ICMP(8 bytes hdr + 80 bytes data)88 bytes

Padvaries per RFC 2406- in this example2 bytes

PadLen

1 byte

NextHdr

1 byte

AuthenticationDatavaries: 8, 12,or 16 byte

12 bytes

ESP Auth

IPv4Header

20 bytes

ESPNull Encrypted Payload

132 bytes

ESP (IP protocol 50) total length 152 bytes

ESP Header ESP Trailer

ESP Authenticated (132 bytes)

Page 10: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

10

ESP w/AES-GCM

IPv4Header

20 bytes

ESPAES128 Encrypted Payload

140 bytes

ESPSPI

4 bytes

ESPSeq #

4 bytes

ESPIV

8 bytes

IPv4Header

20 bytes

ICMP(8 bytes hdr + 80 bytes data)88 bytes

Padvaries per RFC 2406- in this example2 bytes

PadLen

1 byte

NextHdr

1 byte

AuthenticationData varies: 8, 12,or 16 bytes

12 bytes

ESP (IP protocol 50) total length 160 bytes

Encrypted (128 bytes)

ESP Authenticated (140 bytes)

ESP Header ESP AuthESP Trailer

Page 11: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

11

ESP w/AES-GCM + AH

AH Authenticated (148 bytes)

IPv4Header

20 bytes

AHHeader (ref AH format)

24 bytes

ESPAES128 Encrypted Payload

140 bytes

ESPSPI

4 bytes

ESPSeq #

4 bytes

ESPIV

8 bytes

IPv4Header

20 bytes

ICMP(8 bytes hdr + 80 bytes data)88 bytes

Padvaries per RFC 2406- in this example2 bytes

PadLen

1 byte

NextHdr

1 byte

Authentication Data varies: 8, 12, 16 bytes12 bytes

AH (IP protocol 51) total length 184 bytes

Encrypted (128 bytes)

ESP Authenticated (140 bytes)

ESP Header ESP AuthESP Trailer

Page 12: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

12

ESP and/or AH ?

• AH does not support confidentiality• ESP supports both confidentiality and integrity

– Supports null encryption• AH was designed because of export control issues

regarding encryption algorithms• AH and ESP can be nested but why?

– Too much overhead • Recommendation for CCSDS:

– ESP-only

Page 13: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

13

Security Services Allowed

• Authentication-only mode– CCSDS Recommendation: allow– Needed for commanding w/o need for confidentiality

• Authenticated Encryption mode– CCSDS Recommendation: allow (must)– Encryption w/o authentication is shown to be a

dangerous practice• Non-authenticated Encryption mode

– CCSDS Recommendation: unsafe, not recommended– Operational overhead and mission risk analysis may

have need for this but it should not be done without analysis

Page 14: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

14

Keying

• Conformant IPSec must support BOTH automated and manual keying– Automated keying: Internet Key Exchange– Manual keying: ad-hoc (each implementation

determines how)• Issues regarding automated keying:

– Rekey at “bad” time in the mission timeline» E.g., critical burn maneuver» E.g., critical upload/download

– Requires little human intervention• Issues regarding manual keying:

– “simple” but requires human resources – Physical distribution and protection required

Page 15: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

15

Internet Key Exchange (IKE)

• IKE v1 (RFC 2409)– Complicated, robust protocol– Commercially widely used

• IKE v2 (RFC 4306)– Simpler than IKEv2 (maybe safer…)– Commercially not widely used, yet.

• Requires on-board flight code– More flight code to certify

» But do it once and reuse, reuse, reuse

Page 16: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

16

IKE Operation

• IKE rekeys when thresholds are met, for example:– Number of bytes transmitted– Elapsed time

• For space, IKE Rekey-Upon-Command is needed– E.g., button-push to rekey– E.g., button-push to inhibit rekey

• For space, timers will have to be tweaked vs. commercial (terrestrial) implementations

• Recommendation for CCSDS:– IKEv2 w/rekey commanding “button” rekey

Page 17: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

17

Manual Keying

• Sometimes simple is enough….• Need ability to preload keys (e.g., 512 keys, 1024 keys)

onboard– Maybe have a key upload ability?

• Command to change keys• Preload and manage Security Associations (SA)

• Recommendation for CCSDS:– Require manual key w/management

110010110010011100110110

Page 18: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

18

Policy Management

• IPSec supports policies, e.g.: – Security services on a connection– Access controls for connection

• No standards for loading, updating, supporting IPSec policies– SNMP-based approaches:

» RFC 4807: IPSec Security Policy Database Configuration MIB» IPSec Security Policy IPSec Action MIB (IETF draft)» IPSec Security Policy IKE Action MIB (IETF draft)

– Microsoft IPSec Policy Agent Service– KeyNote, ipsecconf, proprietary, etc

• What do we want to do?

Page 19: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

19

Cipher Suite

• Follow CCSDS Algorithms document– 128-bit key size– AES – AES-GCM for authenticated encryption– AES-CMAC, AES-GMAC, HMAC for

authentication/integrity

Page 20: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

20

Compression

• Overhead vs. Bandwidth!– IPSec adds overhead– Everyone complains about not having enough

bandwidth• IP Payload Compression Protocol (IPComp) (RFC 3173)

– Commercially supported– Compresses IP datagrams BEFORE security

processing on outbound– Decompresses IP datagrams AFTER security

processing on inbound

• Recommendation for CCSDS:– Optional use of IPComp

Page 21: Network Layer Security Howie Weiss (NASA/JPL/ Cobham  Analytic Solutions) Berlin Germany May  2011

21

Summary

• IPSec: ESP-only• Null encryption allowed• Authenticated encryption

– Non-authenticated encryption unsafe• IKEv2 w/rekey button• Manual keying w/management• Policy management needed - ?• Cipher suites follow algorithms blue book• Compression (IPComp)