The INSC Security Infrastructure

1
The INSCSecurity Infrastructure

• Canadian National Demonstration
• November 2003
• Dr. S. Zeber
• Defence RD Canada Ottawa

2
Outline

• INSC Network and Security Architecture
• INSC Key Management Infrastructure (KMI)
• Elements
• Observations and Conclusions
• INSC Directory Infrastructure
• Elements
• Observations and Conclusions

3
INSC Network Architecture
4
INSC Security Architecture
BLACK
NETWORK

• Coalition LANs are interconnected by a an
  unsecure (black) network.

5
INSC Security Architecture
BLACK
NETWORK

• End systems within different coalition LANs
  communicate securely through an IPsec tunnel.

6
Scope of INSC Security
Network Layer security only, no Application Layer
Security
7
Security Management Requirements

• Security policy
• Key management for IPsec cryptographic keys used
  for authentication
• IPsec device administration

8
Security Policy Framework

• SP Framework identifies issues to be addressed
  by security policy
• Classification of domains
• Algorithms
• Key management
• Device identification
• Routing issues
• Mechanisms and layer placement
• IPsec profiles

9
Security Policy

• Basic SP document does little more than reflect
  agreements already made
• One coalition
• Two coalition security domains (black red)
  separated by IPsec
• All CLANs are in the same coalition domain and at
  the same level of security classification
• Application Layer security not addressed
• All INSC information is unclassified
• Only IPsec used to provide security services

10
Key Management

• IPsec keys must be issued and managed in a secure
  and trusted manner
• Initial testing with manual distribution of
  pre-shared secrets (symmetric authentication
  keys)
• Final testing and demonstration using X.509
  device authentication

11
Key Management Requirements

• Security policy (subset of INSC Security Policy)
• Mechanisms and procedures that are
• Secure
• Trusted
• Scalable

12
Manual Key Management

• Small communities
• Static configurations
• Limited geographic distribution
• Secure
• Trusted
• Does not scale well

13
Electronic Key Management

• All sizes of communities
• Dynamic configurations
• Wide geographic distribution
• Secure ?
• Trusted ?
• Scalable

14
Elements of an Electronic Key Management
Infrastructure (KMI)
Electronic Key Management gt Public Key
Infrastructure (PKI)

• Security Policy
• Certification Authority (CA)
• One or more Registration Authorities (RAs)
• Directory
• Client software
• Operating Procedures

15
The INSC KMI Security Policy

• No formal KM security policy
• Pragmatic approach adopt operational policy as
  required
• Trust model accept all certificates signed by an
  INSC CA
• Certificate Profiles CA, device profiles defined
  for interoperability
• No Certificate Policy, Certification Practices
  Statement goal was technology demo

16
The INSC KMI Certification Authority

• No COTS products enabled for IPv6
• Certification Authority (CA) services using
  OpenSSL (off-line)
• CA administrator executed scripts to
• Revoke certificates
• Update CRLs
• Sign certificates
• RA services, interactions with IPsec devices,
  directory, via manual procedures

17
The INSC KMI The LDAP Directory

• No COTS products enabled for IPv6
• OpenLDAP open source software (IPv6, PKI schema)
• 3 nations (CA, DE, US) operated black domain
  (JCWAN) OpenLDAP servers
• DE hosted nations not operating an LDAP server
• Fully meshed replication all servers hold
  complete directory information database

18
The INSC KMI Key Generation

• Authentication key pair, certificate request
  generated locally on the IPsec device (script)
• Private key never leaves the device
• Certificate request ? CA for signing
• CA signs certificate (script)
• Certificate ? directory
• Directory update (script)
• Directory replication

19
The INSC KMI Key Revocation

• CA administrator generates CRL (script)
• CRL ? directory
• Directory update (script)
• Directory replication (push mechanism)

20
The INSC KMI Life Cycle Management

• Device certificates issued for duration of
  project
• No automatic detection of certificate expiry
• No automatic certificate renewal
• No automatic CRL update
• ONLY MANUAL PROCEDURES

21
The INSC KMI IPsec Device Procedures

• IPsec device interaction with KMI via manual
  operator procedures
• No client software or API to request/receive CA
  services
• No software or API to interact with the directory
• Private keys, certificates, CRLs stored locally
• Automatic CRL checking controlled by
  configuration parameter strictcrlpolicyyesno
• INSC default strictcrlpolicyno

22
The INSC KMI Observations - 1

• IPsec/IPv6 implementations largely available
• Different IPsec implementations interoperable
• IPsec devices can use X.509 authentication but
  full integration with KMI is incomplete
• no dynamic retrieval of certificates, CRLs
• lack of standard API for KMI services

23
The INSC KMI Observations - 2

• Security policy and procedures should be defined
  before deployment
• Suitable trust model for coalition operations
  needed
• Impact of tactical requirements on electronic key
  management not addressed
• Evaluation and accreditation not addressed (out
  of scope)

24
The INSC Security Infrastructure Future
Challenges

• Full integration of IPsec/IPv6 implementations
  with electronic key management
• Commercial PKI, directory support for IPv6
• Integration of IPsec in a tactical environment
• Security policy
• Evaluation and accreditation

25
The INSC Security Infrastructure Conclusions

• INSC has demonstrated that IPsec with electronic
  KMI is a viable concept to provide secure
  communications in a coalition environment
• Required components exist but the glue is still
  evolving
• INSC provides a good basis for developing an
  appropriate security policy

26
Thank You

• Questions ?