Early Defense - Enabling Attribute-Based Authorization in Grid Firewalls
Motivation
User Authentication
In todayʼs distributed computing environments, like Grids and Clouds, authentication and authorization decisions take place in the middleware or on the resources themselves. Thus, in both cases decision is felled within the local network of the hosting organization. This is due to the following reasons:
TCP-AuthN uses the TCP three-way handshake to transport and verify user's authentication information. TCP-AuthN proceeds as follows:
1) Encrypted connections - firewalls can't interpret application level protocols
2) TCP segment with SYN set includes information where to find the users certificate (1 in Fig.1).
2) IP addresses are no longer sufficient to decide if a connection is allowed or not
3) The firewall receives the SYN segment, retrieves the certificate from the repository, verifies the authentication information and authorizes the connection (B in Fig. 1).
Certificate: Data: Version: 3 (0x2) Serial Number: 1887 (0x75f) Signature Algorithm: sha1WithRSAEncryption Issuer: C=DE, O=GermanGrid, CN=GridKa-CA Validity Certificate: Not Before: Mar 15 09:31:25 2006 GMT Not After : Apr 14 09:31:25 2007Data: GMT Version:CN=Jan 3 (0x2) Wiebelitz Certificate: Subject: O=GermanGrid, OU=UniHannover, Serial Number: 1887 (0x75f) Data: Subject Public Key Info: Version: 3Public (0x2) Key Algorithm: rsaEncryptionSignature Algorithm: sha1WithRSAEncryption Issuer: C=DE, O=GermanGrid, CN=GridKa-CA Serial Number: 1887 Key: (0x75f) RSA Public (1024 bit) Validity Signature Algorithm: sha1WithRSAEncryption Modulus (1024 bit): Issuer: C=DE, 00:b3:00:cf:51:5b:7e:96:57:76:37:da:ea:ae:50: O=GermanGrid, CN=GridKa-CANot Before: Mar 15 09:31:25 2006 GMT Not After : Apr 14 09:31:25 2007 GMT Validity da:56:5f:04:72:32:fa:0f:23:f1:d6:d1:58:f7:75: Not Before: b8:a8:da:05:d2:57:c6:07:c5:5c:a4:5a:45:0f:48: Mar 15 09:31:25 2006 GMT Subject: O=GermanGrid, OU=UniHannover, CN=Jan Wiebelitz Subject Public Key Info: Not After : Apr 14 09:31:25 2007 GMT db:8f:2e:38:dd:fb:de:6a:a9:09:3e:44:13:90:bf: Public Key Algorithm: rsaEncryption Subject: O=GermanGrid, OU=UniHannover, CN=Jan Wiebelitz 43:4c:da:28:b5:99:9d:64:f0:18:29:07:25:f7:43: RSA Public Key: (1024 bit) Subject Publicab:23:71:69:cc:5b:f6:e5:d0:e4:8a:53:bc:0a:30: Key Info: Modulus (1024 bit): Public Key Algorithm: rsaEncryption f0:9d:c9:6f:3d:e1:d9:87:4a:f8:6f:c2:ca:52:b8: 00:b3:00:cf:51:5b:7e:96:57:76:37:da:ea:ae:50: RSA Public 66:ac:fd:e7:a9:8e:62:7b:d9:d4:14:85:4b:12:fa: Key: (1024 bit) da:56:5f:04:72:32:fa:0f:23:f1:d6:d1:58:f7:75: Modulus (1024 bit): ec:d1:b1:e4:d0:98:5f:e5:b7 b8:a8:da:05:d2:57:c6:07:c5:5c:a4:5a:45:0f:48: 00:b3:00:cf:51:5b:7e:96:57:76:37:da:ea:ae:50: Exponent: 65537 (0x10001) db:8f:2e:38:dd:fb:de:6a:a9:09:3e:44:13:90:bf: da:56:5f:04:72:32:fa:0f:23:f1:d6:d1:58:f7:75: X509v3 extensions: 43:4c:da:28:b5:99:9d:64:f0:18:29:07:25:f7:43: b8:a8:da:05:d2:57:c6:07:c5:5c:a4:5a:45:0f:48: X509v3 Basic Constraints: critical ab:23:71:69:cc:5b:f6:e5:d0:e4:8a:53:bc:0a:30: db:8f:2e:38:dd:fb:de:6a:a9:09:3e:44:13:90:bf: CA:FALSE f0:9d:c9:6f:3d:e1:d9:87:4a:f8:6f:c2:ca:52:b8: 43:4c:da:28:b5:99:9d:64:f0:18:29:07:25:f7:43: X509v3 Key Usage: critical ab:23:71:69:cc:5b:f6:e5:d0:e4:8a:53:bc:0a:30: Digital Signature, Non Repudiation, Key66:ac:fd:e7:a9:8e:62:7b:d9:d4:14:85:4b:12:fa: Encipherment, Data Encipherment ec:d1:b1:e4:d0:98:5f:e5:b7 f0:9d:c9:6f:3d:e1:d9:87:4a:f8:6f:c2:ca:52:b8: X509v3 Subject Key Identifier: Exponent: 65537 (0x10001) 66:ac:fd:e7:a9:8e:62:7b:d9:d4:14:85:4b:12:fa: 02:7F:1E:BA:F7:FA:EA:D0:E5:D5:4C:B5:40:12:7F:34:A3:B1:89:94 ec:d1:b1:e4:d0:98:5f:e5:b7 X509v3 Authority Key Identifier: X509v3 extensions: X509v3 Basic Constraints: critical Exponent: 65537 (0x10001) keyid:C6:75:C9:28:AC:D1:0B:FC:3C:FF:B9:B5:1E:D3:5F:3B:80:62:12:34 CA:FALSE X509v3 extensions: DirName:/C=DE/O=GermanGrid/CN=GridKa-CA X509v3 Key Usage: critical X509v3 Basic Constraints: critical serial:00 Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment CA:FALSE X509v3 Subject Key Identifier: X509v3 Key Usage: critical 02:7F:1E:BA:F7:FA:EA:D0:E5:D5:4C:B5:40:12:7F:34:A3:B1:89:94 Digital Signature, Non Repudiation, Key Encipherment, Data X509v3 Authority Key Identifier: Encipherment keyid:C6:75:C9:28:AC:D1:0B:FC:3C:FF:B9:B5:1E:D3:5F:3B:80:62:12:34 X509v3 Subject Key Identifier: DirName:/C=DE/O=GermanGrid/CN=GridKa-CA 02:7F:1E:BA:F7:FA:EA:D0:E5:D5:4C:B5:40:12:7F:34:A3:B1:89:94 serial:00 X509v3 Authority Key Identifier: keyid:C6:75:C9:28:AC:D1:0B:FC:3C:FF:B9:B5:1E:D3:5F:3B: 80:62:12:34 DirName:/C=DE/O=GermanGrid/CN=GridKa-CA serial:00
store user's certificate
certificate repository
TCP-AuthN
A B request user's certificate
client
Authentication
1 SYN tcpauthn Link to the repository
firewall
C verify user's certificate
server
Authorization
firewall
1) The user stores his certificate or proxy certificate on a certificate repository (A in Fig. 1).
4) The server responds to the connection opening with a TCP segment where the SYN flag and the ACK flag are set. 5) The firewall includes a challenge that is encrypted with the user's public key in the second TCP segment (2 in Fig. 1). 6) Finally the client responds in the third segment of the TCP three-way handshake with the decrypted challenge, which enables the firewall to authorize the connection ultimately.
D calculate challenge
Policy Administration Point
2 SYN/ACK tcpauthn challenge Verification
E calculate response
3
XACML Policy
ACK tcpauthn response
Policy Information Point F verify response
XACML Attributes
Policy Decision Point Attribute Query
ACK application data
XACML Attributes
XACML request ACK application data
XACML Response TCP Connection
Figure 1: Extended TCP three-way handshake
Client
TCP Connection
Policy Enforcement Point
Resource
Figure 2: The Firewall as Policy Execution Point (PEP)
Idea To enhance network security of distributed infrastructures, like Grids and Clouds, and to push the initial authorization decision back to the boundary between the public and the protected network we developed TCP-AuthN for dynamic firewall operation. The approach employs the initial three TCP segments to transport authentication information, firewalls are enabled to use this information to judge about the connection establishment. These three TCP segments are originally used to synchronize protocol parameters between the client and the server during connection establishment. In our approach additional information transported in the payload of these TCP segments enables firewalls to authorize the connection establishment. The authorization decision bases on a proper authentication, for which we employ X.509 certificates and proxycertificates. This allows a fine-grained authorization, which is based on user attributes. Therefore the firewall decision about a connection is no more depending on basic information from the TCP/IP network and transport layer. To distinguish the authentication information used by TCP-AuthN from data of the application layer a new TCP option tcpauthn is necessary. This TCP option must be present in the TCP header if TCP-AuthN is applied.
Integration TCP-AuthN enables the integration of the firewall as a Policy Enforcement Point (PEP) in the site's overall authorization architecture (Figure 2). The firewall can express the user's connection initiation itself as a Service Request, which is sent to a Policy Decision Point (PDP). The request relies on information that is provided within this first TCP segment and includes the user's DN or his attributes from a proxy-certificate. Depending on the policies and the presented user attributes the Policy Decision Point comes to a fine-grained decision, which controls the connection establishment.
Further Information Jan Wiebelitz Distributed Computing Security Group Leibniz Universität Hannover Hannover, Germany
[email protected] http://www.dcsec.uni-hannover.de
