Embed Size (px)
Citation preview
Outline
• IPSEC 관련 IETF WGs
• IPSEC WG
• IPSRA WG
• IPSP WG
IPSEC 관련 IETF WGs
• IPSEC WG– 1993 년 발족– IP security protocols and algorithms 표준화
• IPSRA WG– 2000.3 월 1st WG meeting– Remote access issue
• IPSP WG– 2000.3 월 1st WG meeting– Policy issue
IPSEC WG
WG Goals
• 네트워크 계층에서– 보안 프로토콜과– 암호 알고리즘 표준을 개발하여– cryptographic security service 제공 :
• Authentication• Integrity• Confidentiality• Access Control
• 응용계층에서 – 네트워크 보안 프로토콜 및 키 관리 지원 프로토콜
IPSEC Protocols
• 네트워크 계층 보안 프로토콜– AH (Authentication Header)– ESP (Encapsulating Security Payload)
• 응용계층 키 관리 프로토콜– IKE (Internet Key Exchange)
AH protocol
• Authentication 알고리즘 이용• Integrity, Data Origin Authentication 서비스 제공
Next Header (8) Payload Length(8) Reserved (16)
SPI (Security Parameters Index) (32)
Sequence Number (32)
Authentication Data (32* n)
IP header AH header TCP, ….
ESP protocol• Encryption 과 Authentication 알고리즘 이용• Integrity, Data Origin Authentication 및 Confidentiality 서비스
제공
Pad Length (8)Padding (0 - 255 Byte)
SPI (Security Parameters Index) (32)
Sequence Number (32)
Payload Data
Next Header (8)
Authentication Data (32* n)
Encry
ptio
nA
uth
entica
tion
IP header ESP header TCP, … Payload ESP Trailer ESP Auth.
Security Association
• Simplex connection between two end-points • Affords security services to the traffic carried by it
AH or
ESP
SA
알고
리즘
AH or
ESP
SA
알고
리즘
Host or Security Gateway Host or Security Gateway
Security Association (cont.)• 트래픽이 양방향이면 , 두개의 SA 필요• Flexible granularity
– 두 SG 간 모든 트래픽에 하나의 Encrypted Tunnel 을 이용 . 또는 , 두 SG 를 경유하는 각 Host 쌍 트래픽 마다 하나씩 여러 Encrypted Tunnel 을 이용
• Two modes– Transport mode SA: 호스트 간에만 적용– Tunnel mode SA: IP tunnel 에 적용
• SA Combination– 트래픽 스트림이 원하는 보안 서비스가 하나의 SA 로는 충족될 수
없을 때 , 두 개이상의 SA 를 결합– 4 가지 기본 결합 방식지원을 의무화
IKE Protocol
• SA and Key Management Protocol– SA 협상 , 생성 , 관리– Key 생성 , 분배 , 갱신
• A hybrid protocol of – ISAKMP : framework, message format, phases– Oakley : key exchange modes– SKEME : public key encryption
Phases of IKE Protocol• Phase I
– Establishment of secure and authenticated communication channel (IKE SA) and authenticated keys
– 4 Authentication methods• Preshared keys• Digital signature• Public key encryption• Revised public key encryption
– Main and aggressive modes
• Phase II– Establishment of IPSEC SA– Quick mode
Main Mode with Signatures
Initiator Responder
HDR, SAHDR, SA
HDR, KE, NiHDR, KE, Nr
HDR*, IDii, [CERT,] SIG-I HDR*, IDir, [CERT,]
SIG-RHDR: Header SA: Security Association KE: Key Exchange
N: Nonce CERT: Certificate SIG: Signature
ID: Identity i: Initiator r: Responder
Aggressive Mode with Signatures
Initiator Responder
HDR, SA, KE, Ni, IDiiHDR, SA, KE, Nr, IDir,
[CERT,] SIG-R HDR, [CERT,] SIG-I
HDR: Header SA: Security Association KE: Key Exchange
N: Nonce CERT: Certificate SIG: Signature
ID: Identity i: Initiator r: Responder
Quick Mode in Phase II
Initiator Responder
HDR*, HASH(1), SA, Ni
[, KE] [, IDci, IDcr]HDR*, HASH(2), SA, Nr
[, KE] [, IDci, IDcr] HDR*, HASH(3) HDR: Header SA: Security Association KE: Key Exchange
N: Nonce ID: Identity
i: Initiator r: Responder
IPSEC and NAT
• Traditional NAT (Network Address Translation)– Home network, SOHO network, etc.
• private addresses vs. globally unique addresses
– Basic NAT :
• one group of IP addresses --> another
– NAPT (Network Address Port Translation) :
• many network addresses/ ports --> single net. Addr/
ports
NAT operation - example
Stub router w/NAT Stub router w/NAT
Regional router
Stub A Stub B
WAN
s = 198.76.29.7
d = 198.76.28.4
LAN
10.33.96.5
s = 10.33.96.5
d = 198.76.28.4
LAN
10.81.13.22
s = 198.76.29.7
d = 10.81.13.22
s = 198.76.29.7
d = 198.76.28.4
WAN
NAPT operation - example
Stub router w/NAPT
Service Provider router
Stub A
WAN
s = 138.76.28.4, sport = 1024
d = 138.76.29.7, dport = 23
LAN
10.0.0.10
s = 10.0.0.10, sport=3017
d = 138.76.29.7, dport = 23
10.0.0.2
s = 138.76.29.7, sport = 23
d = 138.76.28.4, dport = 1024
10.0.0.1
s = 138.76.29.7, sport = 23
d = 10.0.0.10, dport = 3017
Incompatibilities between NAT and IPSEC
• between IPSEC AH and NAT
• between checksums and NAT
• between IKE address identifiers and NAT
• between fixed IKE destination ports and NAPT
• between overlapping SPD entries and NAT
• between IPSEC SPI selection and NAT
• between embedded IP addresses and NAT
Alternative Proposals
• UDP encapsulation– IKE and IPSEC packets are encapsulated in
UDP prior to being sent
• RSIP (Realm Specific IP)– addresses issues of IPSEC SPI demultiplexing
and SPD overlap
• IKE and checksum processing changes
IPSRA WG
Background
• Typical remote access in recent past– dial-up users via PSTN to network access server– PPP-based protocol – access control, authorization, and accounting functions
• RADIUS, TACACS, etc.
• Growing internet access via ISP • Advent of IPSEC• Remote access in future
– IPsec-based
Problems to be solved• User authentication requires human interaction• IPSEC IKE supports authentication methods based on
public- key technology• Public key infrastructure for authentication of individual
human users will take longer time to be deployed• Legacy authentication systems will continue to exist for
a while– OTP, username/password, H/W authentication token, etc
• And remote host configuration and security access control issues must be solved
WG Goals
• To define requirements and architecture– as an informational RFC
• To define user authentication mechanism– running IKE using legacy authentication mechanisms– standard track
• To define remote host configuration mechanism– standard track
• To define access control mechanism– security policy configuration– standard track
Past Meetings
• 1st BOF• 2nd BOF
– Washington, 1999.11
• 1st WG meeting– 47th IETF, Adelaide, Australia, 2000.3
• 2nd WG meeting– 48th IETF, Pittsburgh, USA, 2000.8
• Next WG meeting– San Diego, next week
Drafts
• No RFC• 3 WG drafts• Requirements draft (1)• Authentication drafts (2)
• Configuration draft (IPSEC WG draft)
• Some other drafts
Requirement draft
• Currently, 02 version (2000.11)• Understanding requirements in a number of differing remote
scenarios– Some shared and some unique requirements
• Requirement categories– Endpoint Authentication– Remote host configuration– Security Policy configuration– Auditing– Intermediary Traversal
Reference picture
Remote Access Client (IRAC)
Security Gateway (SGW/ IRAS)
Target network
Internet
Endpoint Authentication
• Refers to verification of the identities of the communication partners – e.g., IRAC and IRAS
• Machine-level authentication• User-level authentication• Combined User/ Machine authentication
• Remote access authentication– typically asymmetric– good deal of variation in authentication requirements
for differing scenarios
Remote Host Configuration
• Refers to network-related device configuration of the client system
• Parameters– IP address, subnet mask, broadcast address, host name,
domain name servers, default routers, MTU, default TTL, etc.
• Virtual address– virtual presence on the corporate network via an IPsec
tunnel
Security Policy Configuration
• Refers to IPsec policy configuration of both the IRAC and IRAS
• For examples,– block the internet access to IRAC from outside world– For IRAS, particular user’s access could be controlled
via policies based upon the particular address (or the address from a specific pool)
Auditing
• Refers to the generation and collection of connection status information
• Some accounting information– connection start time– connection end time– incoming octets– outgoing octets
• Maintains security and integrity of the connected network
Intermediary Traversal
• Refers to the ability to pass secured traffic across intermediaries such as NAPT and firewalls
Scenarios
• Telecommuters• Corporate to remote extranet• Extranet laptop to home corporate net• Extranet desktop to home corporate net• Remote dialup laptop (Road warrior) access• Public system to corporate network
Telecommuters(Dialup/DSL/Cable modem)
IRAC
Corporate network
InternetModem ISP SGW
• Dialup/DSL/Cable modem telecommuters using their own home systems to access corporate resources
Corporate to Remote Extranet
Corporate B
Internet SGW/FW
• Extranet users using their corporate desktop systems to access the remote company network of a business partner
SGW/FW
My Corporate A
User
Extranet Laptop to Home Corporate Net
Corporate B
Internet SGW/FW
• Extranet users using their own laptop within another company’s network to access their home corporate network
SGW/FW
My Corporate A
Pop
FTP
Corp-A laptop
Extranet Desktop to Home Corporate Net
Corporate B
Internet SGW/FW
• Extranet users using a business partner’s system (on that partner’s network) to access their home corporate network
SGW/FW
My Corporate A
Pop
FTP
Corp-A desktop
Remote Dialup Laptop (Road Warrior) Acces
• Road warriors using their own laptop systems to access corporate resources via an arbitrary ISP dialup connection
• Virtually indistinguishable from the telecommuter scenario• Typically dialup is short-lived
Public System to Corporate Network
• Remote users using a borrowed system (e.g., an airport kiosk) to access corporate resources
Scenario Commonalities• User authentication is required in almost all cases• Machine authentication for IRAC is generally only useful
when combined with user authentication. Combined user and machine authentication is useful in some scenarios
• Machine authentication for IRAS is required in all scenarios
• Device configuration mechanism is required in most cases• Dynamic IRAC policy configuration is useful in several
scenarios• Most Scenarios require auditing• An intermediary traversal mechanism may be required in
any of the scenarios
Authentication drafts
• Two proposals– Pre-IKE Credential Provisioning Protocol
• PIC draft
– Client Certificate and Key Retrieval for IKE• getcert draft
PIC draft
• One of approaches of integrating legacy authentication mechanisms into IKE
• WG draft• Currently 01 version (2000.9)
– Switched from XAuth to EAP for legacy authentication
• Use simplified ISAKMP/ IKE • Use EAP (Extensible Authentication Protocol,
RFC 2284) • No modification to IKE
PIC Architecture
Client/User
Authentication Server (AS)
Legacy Authentication Server (LAS)
Security Gateway (SGW)
Optional Link
PIC Protocol• Three main stages in PIC protocol (Btw Client and AS)
– establish one-way trust relationship. A secure channel from the client to the AS is created (Server authenticated)
– Legacy authentication is performed over this channel. Use EAP tunneled within ISKMP (User authenticated)
– The AS sends the client a (typically short-term) credential which can be used in subsequent IKE exchanges
• The credential can be thought as– a certificate, – a private key generated or stored by the AS and
accompanied by a corresponding certificate, or – symmetric secret key
Getcert draft• The architecture is similar to PIC’s
– integrate legacy authentication into IKE– use the separated AS
• The differences is in the details:– use TLS and HTTP rather than EAP, ISAKMP/IKE
• Client-side certificate generation option was selected by straw poll, among 4 proposals
• approved as a WG draft in 2000.11• Currently 00 version
Configuration (DHCP) draft• Virtual presence is useful
– using virtual IP address and then tunneling
• DHCP meets requirements of a host with IPSEC tunnel mode interface
• No modification to DHCP is required• draft is stable (currently 08, 현재 WG last call 진행중 )
Virtual host
SGW/ DHCP relay
Target network
Internet
DHCP server
Remote host virtual presence
Externally visible host
Configuration Steps
• Establish IKE SA between IRAC and IRAS• Establish DHCP SA between IRAC and IRAS• Exchange DHCP messages between IRAC and
DHCP server– using IRAS as a DHCP relay
• Establish IPSEC SA and start to communicate
Topic of next week
• Requirement– report update
• PIC and getcert– no agreement yet
• DHCP– near closure
IPSP WG
Backgrounds• Rapid growth of the need to control access to
network resources(BW, routers, hosts,…)
• The scope of IPSEC IKE limits the protocol to the authenticated exchange of keying material and associated policy information between the end-points of a security association
• However, along the path of a communication, there may be administrative entities ...
WG Goals
• To specify information model and data model for supporting IP security policies
• To develop an policy specification language• To provides guidelines for the provisioning of
IPSEC policies using existing policy distribution protocols– profiles for LDAP, COPS, SNMP and FTP
• To develop a policy exchange and negotiation protocol– discovering policy servers, distributing and negotiating
policy, and resolving policy conflicts
Past Meetings
• BOF– 1999.3
• 1st WG meeting– 47th IETF, Adelaide, Australia, 2000.3
• 2nd WG meeting– 48th IETF, Pittsburgh, USA, 2000.8
Drafts
• No RFC and 7 Internet drafts
• Policy Specification Language draft• Model draft• SPP draft• Architecture draft• Requirement draft• PIB draft• Roadmap draft
Simple Scenario
• Host A wishes to communicate with Host B, using a strong encryption
• Host A needs to determine– what its local policy (w.r.t. the comm. with B) is– what B’s policy (w.r.t. the same comm.) is– what SGs if any are in between A and B– what their policies (w.r.t. that comm.) is
Host A Host BSG1 SG2
Simple Scenario (cont.)• Depending on the individual policies involved ,
Host A may establish any combination of these SAs:– SA between Host A and Host B– SA between Host A and SG1– SA between Host A and SG2 – SA between SG1 and SG2– SA between SG1 and Host B– SA between SG2 and Host B
IPSP Architecture• Use of SPP protocol for SG discovery and policy
distribution
• Use of trust management to resolve policies
• Use of language to exchange policies
• Most of the burden of discovering and processing policy is placed on the initiator.– Such as policy resolution operation
• IPsec policy is defined in terms of local policy and signed policy statements from trusted entities
Security Policy Protocol
• Protocol for discovering, accessing and processing the security policy information
Host A Host BSG1 SG2
Policy Server A
Policy Server B
Q1/R1 Q2/R2
Q2/R2
Q2/R2 Q3/R3
SPP Message• Message = header + payload
• 6 message types– Query, Reply, Policy, Policy Ack, Transfer, KeepAlive
• 3 Payload types– Query: SG, Comsec, Certificate– Record: SG, Comsec, SA, Certificate, Policy
server, Transfer– Signature: RSA, DSA
• 메시지는 전자서명으로 인증
Summary
• IPSEC 관련 IETF WG 작업 내용 요약– IPSEC WG– IPSRA WG– IPSP WG
• Remote access 는 IPSEC 구축의 중요 부분
• 자동적이고 효율적인 IPSEC Policy management 는 망 운영에 매우 중요
![Modul komparasi pengantar aplikom [ksl uty]](https://img.pdfslide.tips/doc/110x75/54790825b379595e2b8b464c/modul-komparasi-pengantar-aplikom-ksl-uty.jpg)
