Open Interfaces for e-Government

The Austrian Citizen Card

Access Control

Document information

Table of contents

1. General information
   1. Naming conventions
   2. Keywords
2. Classification of access
   1. Authentication classes
   2. Certification conditions
   3. Classification of commands
3. Access Control
   1. Rules
   2. Chains
   3. Default settings for a local Citizen Card Environment
   4. Default settings for a server-based Citizen Card Environment
4. Security and threat analysis
5. References
6. History

1 General information

This document describes how the functions of the Citizen Card Environment can be protected against unauthorised access:

• Control functions during access by calling TCP and TLS bindings
• Control functions during access by calling HTTP and HTTPS bindings
• Control functions during access by command cascading via HTTP and HTTPS bindings

1.1 Naming conventions

For better readability, this document dispenses with non-gender-specific formulations. However, the formulations expressly relate to both sexes.

The following name space prefixes are used in this specification to identify the name spaces of XML elements:

1.2 Keywords

This document uses the following keywords to categorise requirements: must, must not, required, should, should not, recommended, may, and optional. The interpretation of these keywords is set down in [Keywords].

2 Classification of access

2.1 Authentication classes

In terms of authentication, access to a Citizen Card command can be categorised in one of the following four classes: anonym, pseudoanonym, certified and certifiedGovAgency. In order for commands to be classified in this way, the following questions must be answered:

Can the origin of the command request be identified?

Parameters from the binding protocols, such as the source IP address, the Referer HTTP header, the DataURL parameter of the HTTP binding, or information from the client or server certificates used are also used to answer this question.

Can the destination of the command response be identified?

Parameters from the binding protocols, such as the source IP address, the DataURL parameter of the HTTP binding, or information from the client or server certificates used are also used to answer this question.

The four authentication classes can be characterised along the following simplified lines:

anonym

The Citizen Card Environment contains neither information about the origin of the command request nor about the destination of the command response.

pseudoanonym

Although the Citizen Card Environment contains information about the origin of the command request and/or about the destination of the command response, this information is based on unsecured parameters of the bindings.

certified

The Citizen Card Environment contains secure (certificate-based) information about the origin of the command request and/or about the destination of the command response.

certifiedGovAgency

The Citizen Card Environment contains secure (certificate-based) information about the origin of the command request and/or the destination of the command response. This information indicates that the origin or destination is a public authority or a service provider of the public authority, i.e. the domain name for which the certificate is issued matches the *.gv.at pattern or the certificate contains either the certificate extension administrative property or service provider property [VerwEig].

The following graphic contains the decision-making tree for assigning access to a Citizen Card Environment command in one of the four authentication classes. For the sake of clarity, no further distinction is made in the graphic between certified and certifiedGovAgency.

Firstly, a distinction is to be made according to the origin of the command request. A command request can be received from one of the four bindings TCP, TLS, HTTP and HTTPS or from the DataURL server (the server that is identified with the DataURL parameter of the HTTP binding and which can transmit other command requests to the Citizen Card Environment as part of command cascading).

If a command request originates in the TCP binding, access is classified as pseudoanonym and the source IP address of the TCP connection is labelled as the identification URL.

If a command request originates in the TLS binding, the next step is to check whether the requesting party has identified himself in the TLS connection to the Citizen Card Environment using a client certificate. If so, access is classified as certified, otherwise (as with the TCP binding) it is classified as pseudoanonym. In both cases the source IP address of the TLS connection is recorded as the identifying URL.

If a command request originates in the HTTP binding, the next step is to check whether the execution of the command requires protection, or just the command response (cf. section 2.3). If even the execution of the command requires protection, access should be classified as anonym because in this case, the origin of the command request determines how access is classified. Although the IP address of the command request is known, in most cases it must be assumed that the command request comes from the citizen's browser via the HTTP binding, so that the browser acts as a kind of proxy and conceals the actual origin of the command request. The source IP address of the HTTP connection is recorded as the identifying URL. If, by contrast, the command response requires protection, then the destination of the command response determines how access is classified. Thus, the next step is to check whether the DataURL parameter of this binding is used. If not, there is no information available about the destination of the command response; access is classified as anonym, and the source IP address of the HTTP connection is recorded as the identifying URL. If so, then the protocol of the DataURL parameter is to be analysed in a final step. If the parameter is http, access is classified as pseudoanonym; if, on the other hand, the parameter is https, access should be classified as certified because the information about the destination of the command response is secured by means of the server's certificate behind the DataURL. In both cases DataURL is recorded as the identifying URL.

If the command request reaches the Citizen Card Environment via the HTTPS binding, the next step is to check whether the requesting party has identified himself in the TLS connection beneath using a client certificate. If not, then the same further checks are to be used as in the HTTP binding, beginning with the check of whether the command execution or command response requires protection. If, by contrast, the client certificate was used, the HTTP header Referer has to be evaluated to determine the actual origin of the command request. If this header is in place, access is to be classified as pseudoanonym and the value of the header is recorded as the identifying URL. If the header is missing, access is to be classified as certified and the source IP address of the HTTPS connection is recorded as the identifying URL.

If the command request is routed via command cascading of the HTTP or HTTPS bindings from the DataURL server to the Citizen Card Environment, then, in a subsequent step, the protocol of the URL previously used by the Citizen Card Environment to contact the DataURL server is to be analysed. If the protocol is https, access is classified as certified, because the origin of the command request is then assured via the certificate of the DataURL server. DataURL is recorded as the identifying URL. If, on the other hand the protocol is http, the next step is to check whether the execution of the command requires protection or just the command response (cf. section 2.3). If even the execution of the command requires protection, access should be classified as pseudoanonym because in this case the origin of the command request determines how access is classified. In this case, too, DataURL is recorded as the identifying URL. Otherwise, the remaining checks take place as in the case of the HTTP binding, starting with the check of whether the DataURL parameter of the binding is used.

2.2 Certification conditions

If a DataURL with https protocol is used, the TLS and HTTPS bindings and the connection of the Citizen Card Environment to the DataURL server are based on the TLS protocol, which uses X.509 certificates [X509] to authenticate client and server.

In all three cases, the certificate used is only of relevance for assigning access to an authentication class if it has been issued by a certification service provider that has been established as trustworthy by the Citizen Card Environment.

2.3 Classification of commands

The following table lists the commands of the Security Layer interface and shows whether this execution of the command or the command response requires protection (compare this with the decision-making tree for classifying access in section 2.1).

3 Access control

It is a matter for implementers to decide which rules they implement with which degree of detail, based on the classification presented. However, the rules presented below must be protected.

3.1 Rules

Rules describe a link between input data and a resulting action or user interaction. Rules are organized in chains and processed in sequence. The first rule that applies is executed. This simple prioritisation of rules is sufficient for the purposes of access control.

3.1.1 Input data

Authentication class

The authentication class that must be met as a minimum criterion if a rule is to apply. Appropriate values are as follows: anonym, pseudoanonym, certified, certifiedGovAgency (cf. section 2.1).

Identification term

This input date must match the identifying URL (cf. section 2.1) of the authentication class (origin of the command request or destination of the command response). Possible values are domain names, IP addresses and URLs. A domain name or IP address must match the server part of the identifying URL, while a URL must match the entire identifying URL. Wildcards can also be used here:

• * matches any value;
• For domain names, a single specification of a wildcard * for one or more parts of the domain is allowed at the start of the pattern (e.g. *.gv.at or *.cio.gv.at, but not *io.gv.at);
• For IP addresses, a single specification of a wildcard * for one or more bytes of the IP address is allowed at the end of the pattern (e.g. 193.170.* or 193.170.251.*, but not 193.170.25*);
• For URLs, a single specification of a wildcard is allowed at the end of the URL (e.g. https://finanzonline.bmf.gv.at/arbeitnehmerveranlagung/*).

Command name

The local name of the command request of the Security Layer interface (e.g. InfoboxReadRequest). Part of the name is permitted with a subsequent wildcard '*' (e.g. Infobox* for all info box commands), or, alternatively a wildcard '*' may be used for all commands.

Command parameter

Depending on the command from the Security Layer interface, one or more parameters should be specified. In the case of info box commands, the InfoboxIdentifier parameter specifies the name of the info box in question. In the case of commands that access private keys, the KeyboxIdentifier parameter specifies the name of the key box used. When the IdenitityLink and Mandates info boxes are read out, the PersonIdentifier parameter indicates whether the sourcePINs (source identification numbers) for natural persons contained there would be transmitted without change (base), or would be replaced by the corresponding, derived sector-specific personal identifiers (derived). A single wildcard '*' may be used for the InfoboxIdentifier, KeyboxIdentifier and Identifier parameters.

3.1.2 Actions

Valid actions for rules are allow, deny and name of another chain. Allow means that the function call is permitted and is to be executed. Deny means that the function call is not permitted and is not to be executed. The name of another chain means that the processing of rules is to continue with the first rule in the chain specified.

In the case of the actions allow and deny, the type of interaction must also be defined via the user interface.

3.1.3 User interaction

The type of interaction indicates how the user is to be involved in command processing. This means that only the minimum required interaction is defined in the context of the rules. Higher grade interactions may be necessary, depending on the function to be completed. There are four interaction types: none, info, confirm, confirmWithSecret. none means that the function to be executed does not need to be confirmed by the citizen; info means that the citizen must be notified of the action to be executed via the user interface; confirm means that the citizen must confirm permission to execute via the user interface; in the case of confirmWithSecret, the citizen must give permission for execution by entering a password via the user interface.

3.2 Chains

At least two chains must exist: Identification und Command. Processing always begins with the Identification chain. The division makes it possible first to pinpoint the command request and the destination of the command response, after which further limits can be set on a command basis.

3.3 Default settings for a local Citizen Card Environment

When a local Citizen Card Environment is delivered to the citizen, its rules must be configured so that they comply with the following standard settings. The Citizen Card Environment should allow the citizen to change the standard settings according to his personal wishes.

3.3.1 Chain Identification

3.3.2 Chain Command

3.4 Default settings for a server-based Citizen Card Environment

When a local Citizen Card Environment is used by the citizen for the first time, its rules must be configured so that they comply with the following standard settings. The Citizen Card Environment should allow the citizen to change the standard settings according to his personal wishes.

3.4.1 Chain Identification

3.4.2 Chain Command

See section 3.3.2.

4 Security and threat analysis

4.1 Control requirement of the commands for creating signatures

The decision that only the result of commands for creating signatures, but not the action itself, requires protection was taken on pragmatic grounds. Thus, in principle, it is possible for commands for creating signatures to be issued from an unknown source and transferred to a known destination. However, because a potential attacker would need the signature result for an effective attack, this classification seems justified.

4.2 Cross-site scripting attacks

A cross-site scripting (XSS) attack (cf. [XSS-FAQ]) allows an individual who is attacking the Citizen Card Environment to use the HTTPS binding with client authentication to show a false origin for the command request:

The attacker deceives the citizen into executing a manipulated link to a page that is classified as trustworthy in the rules of the Citizen Card Environment (e.g. the homepage of a public authority). This link contains JavaScript elements as parameters that are to execute an HTTPS post to the Citizen Card Environment. If the authority's page really is susceptible to an XSS attack, then these JavaScript elements are located on the page that the citizen receives from the actual trustworthy page in response when the link is followed, and are executed after the page is loaded in the browser. The Citizen Card Environment now receives a command request via the HTTPS binding. In line with the decision-making tree from section 2.1 the Citizen Card Environment checks the HTTP header Referer if the citizen's browser has identified itself with a client certificate. This header refers to the page classified as trustworthy, which is why access is classified as pseudoanonym and the trustworthy page is falsely recorded as the identifying URL (even though the command to the Citizen Card Environment actually comes from the JavaScript smuggled in by the attacker).

It is not least for this reason that the standard settings for access control in sections 3.3 and 3.4 have been chosen so that the citizen must confirm all sensitive commands.

5 References

Keywords

Bradner, S.: RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. IETF Request For Comment, March 1997. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc2119.txt.

RFC2396

Berners-Lee, T., Fielding, R. and Masinter, L.: RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. IETF Request For Comment, August 1998. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc2046.txt.

VerwEig

Hollosi, Arno: X.509 Zertifikatserweiterungen für die Verwaltung [X.509 Certificate Extensions For Administration]. Convention for E-Government in Austria drafted by the Federal Staff Unit for ICT Strategy, Technology and Standards. Public Draft. Version 1.0.3, 21 February 2005. Downloaded from the World Wide Web on 1 March 2005 under http://www.cio.gv.at/it-infrastructure/pki/X509ext-20030218.pdf.

X509

Polk, W., Ford, W., Solo, D.: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. IETF Request For Comment, April 2002. Downloaded from the World Wide Web on 14 May 2004 under http://www.ietf.org/rfc/rfc3280.txt.

XSS-FAQ

Cgisecurity.com: The Cross Site Scripting FAQ. Downloaded from the World Wide Web on 14 May 2004 under http://www.cgisecurity.com/xss-faq.html.

6 History