Impact of authorization to response times in Open Network Environment

Last update: 27.11.1998

Markus Peuhkuri
Helsinki University of Technology
puhuri@iki.fi

Abstract

Authorization generally requires some message exchange between parties. Number of messages may affect usability of services as message propagation delay is limited by speed of light and cannot be improved. In this study various protocols are studied and usability is compared considering variance of round trip times.

We found out that there are quite much differences in number of messages needed to authenticate the other party depending on protocol and implementation. Also one must take account possible directory lookups. In some protocols no extra messages are needed in best case, while even more than ten messages are needed on some other protocols.

1. Introduction

1.1 The Earth as fixed sized object

1.2 Authentication in network environment

1.3 Delays and usability

2. The Open Network Environment infrastructure

2.1 Connection setup

3. Protocols

3.1. Authentication

3.1.1. Passwords

One-time passwords

3.1.2. Public-key cryptography

3.1.3. Zero-knowledge proofs

3.1.4. Signatures

3.2. Key exchange

3.2.1. Public-key based key exchange

3.3. Key distribution

3.3.1. Domain Name System

3.3.2. X.509

3.4. Authentication and key exchange

3.4.1. Distributed Authentication Security Service (DASS)

4. Case studies

4.1. Secure Sockets Layer

4.2. IP Security protocol

4.3. Secure Shell

4.4. Kerberos

5. Comparison of protocols

5.1. Comparison by examples

6. Conclusions

References

A. Authentication time in different scenarios without TCP connection setup

B. Authentication time in different scenarios including TCP connection setup

Many protocols are designed for use in local area networks (LAN) where typically end-to-end delays are at most some milliseconds. If these protocols are extended to use in networks with delays of more than two magnitudes, some serious performance problems may arise.

In this study, the basic characteristics of the Internet are presented, some most well-known authentication protocols are studied from temporal usability point of view and finally some important existing implementations are outlined and compared. No in-depth security analysis of protocols are made. The message size is supposed to be negligible as compared with available bandwidth.

1.1 The Earth as fixed sized object

As the transmission speeds increase, the Long Fat Pipes-phenomenon comes more and more common. In those networks with large delay-bandwidth product, the transmit time of a data block is minimal compared to the propagation time. If man someday populates the space, propagation delay will have even more dominating effects.

1.2 Authentication in network environment

There are cases when there is no need to authenticate the communicating party. In those cases one only needs to assure oneself about integrity of data received. This can be done after transfer and does not increase the actual transfer time. There may be, however, some delay caused by database or directory lookup for example to verify signature.

1.3 Delays and usability

We can divide communication actions into four classes:

1. Pre-task communication is needed before work can start; this can include loading applications etc. Computer-skilled people are in many cases used to wait and do not expect application to start immediately. People without computing background expect system to be available immediately, however.
2. In-task communication is mandatory to happen before task can continue. A typical example is to submit some information and to get response back.
3. Background communication happens parallel to work flow. Exact time it happens and time is takes is not important. Mail program checking periodically for new mail is in this class.
4. After-task communication is needed to save state and to gracefully end communication. This can be invisible to user but in cases where user power-offs terminal, it causes delays for user.

Because the ONE uses Internet Protocol as network protocol, components and servers may be located in any part of Internet. If full on-demand component model is adopted, more connections and more authentications are needed as compared to the traditional systems where applications are static.

2.1 Connection setup

Both the connection setup and closing are based on three-way handshake. In the connection setup, the calling party sends header-only TCP segment with sequence number set and SYN flag on. The called party responds this by acknowledging the sequence number and sets it's own initial sequence number; both ACK and SYN flags are on. After this segment is received by the calling party, it acknowledges the called party's sequence number and connection is established.

The most of client-server applications begin by client issuing command. This can be in the same segment with the initial acknowledge, but most implementations send it in another segment because of commonly used application programming interface (BSD Sockets) [3]. This does not increase delay, only one extra TCP/IP header is transmitted.

The data is then exchanged. It is controlled by the end system capacity (how complicate operations one must perform), number of dialogs, and actual bulk data transfer which is then limited by network bandwidth and delay. To illustrate these phases of communication, normal hypertext transfer protocol (HTTP) version 1.0 connection is presented on Figure 1.

Figure 1. Phases in HTTP/1.0. communication [4].

A new connection is created for each element that is transfered. As each web page has several components, many connections are made. Some web browsers establish parallel connections to speed up the transfer. A newer version of HTTP protocol, 1.1, can transfer many components over one TCP connection [5]. This makes page retrieval faster when existing connection can be utilized.

3. Protocols

This system does not need any complicate hardware, but is has several drawbacks. The most serious ones are:

• Password is badly chosen.
• Password is too short or from too limited alphabet.
• System is vulnerable for eavesdropping.

The other way is to have a lists, either on paper or on electronic device, of passwords which are then sequently used. The values are generated so that it is very hard to calculate next one from (possibly all) previous values. For example, the S/Key system calculates values x_i starting from initial value R: x₁=f(R), x₂=f(f(R)), ..., x_n=f(x_n-1). The f() is chosen so that f^-1 is very difficult. First the x_n is used, then x_n-1. [6, p. 53]

The problem with password systems is that they only authenticate the other party, who has no possibilities to find out whether he is communicating with the right party or with some man-in-middle.

3.1.2. Public-key cryptography

The advantage of the public-key cryptography is that the public key is really public: no harm is done if it is published. Public keys can be stored to some public directories. This reliefs key management. The only thing that must be taken care is integrity of public keys, which is usually managed with certification (signing of keys) by certification authority (CA). [6, p. 31]

The basic public-key authentication is following:

1. Client selects some random number(s) R_ci, computes A₁ = f(K^priv, R_c1, R_c2, ...) and sends the result A₁ to the server.
2. The server sends different random number R_s.
3. The client computes A₂ = g(K^priv, R_c1, R_c2, ..., R_s) and sends the result A₂ to the server.
4. The host verifies, with using clients public key K^pub, that A₁ and A₂ are such that the client would have computed those only if he knows private key K^priv.

There are three messages to be sent, two from client to server and one from server to client. In case of mutual authentication there are total four messages if messages to other directions are combined.

3.1.3. Zero-knowledge proofs

1. Client transforms his knowledge to some new (random) related hard problem and solves this hard one by using his knowledge. He commits the solution using bit-commitment scheme and sends the new problem and commitment to the server.
2. The server asks the client either to
   1. [A] prove that the problems are related (isomorphic)
   2. [B] open the committed solution and prove that it is the solution.
3. Client complies.

Of course, it would be useful to send all problems and commitments in one message and answers (A or B) in another, in which case client needs to send only 2 messages and server needs to send only one message. However, the theory here is not so established that this can be proven to be still zero-knowledge in generic case. [6, p. 106]

The zero-knowledge proof can be made also non-interactively. In this case only one message from client to server is needed. This utilizes one-way hash functions and committing answers based on (unpredictable) output of that hash function. The number of proofs needed is larger (64 or more), however, to avoid brute-force search over commitments. This can be used in signatures or in signature-based authentication.

The zero-knowledge proof of identity has some problems. The most serious one is that while one [A] thinks he is proving his identity to some other party [B], this other party [B] can simultaneously prove to third party [C] that he is [A].

3.1.4. Signatures

The client may verify true origin of data if it is signed. A digital signature is a digest calculated from signed document (typically one-way hash function) which is then signed (encrypted with private key). The client verifies the digest signature (decrypts with claimed origin's public key) and compares it to digest value, calculated from message received.

To verify the signature the client must retrieve data originator's public key but during actual data transfer, no extra steps because of verification are needed. The signature can also be used by the server to verify data the client sent.

3.2. Key exchange

The key exchange can be divided into two phases: retrieving public keys (key distribution) and exchanging keys for session. The first phase must only be once for key lifetime (if the end system can store data secretly) but the other takes place with communication.

3.2.1. Public-key based key exchange

It is also possible for client to launch communication immediately as encrypted message can be piggy-backed onto key exchange message. In this case no overhead messages are needed. The signatures are needed to avoid man-in-middle attacks. [6, p. 51]

3.3. Key distribution

In proposed system [8] there can be three types of keys:

Zone keys

are used to authenticate records for each zone. The private part of this key is most critical for system integrity so it is recommended that this key is not kept in any of on-line systems and is used only periodically to sign records.

Host keys

are keys for the end systems.

User keys

or account keys are for users or other entities at the end systems.

There are several certification authorities (CA) who sign keys for entities. The CAs form a tree-like structure: each CA has several forward certificates for other CAs signed by it and reverse certificate signed by other CA. This makes it possible to find certification path between the different CAs. The basic assumption is that each entity knows its own key and public key of that CA who has signed entity's public key.

To verify some signature one must find a chain of certificates from CA it knows to CA who has signed the signature. One reasonable assumption is that the CA tree does not have more than five levels (usually less):

1. Top-level CA (root: key self-signed)
2. Country top-level CA
3. Certification agency CA (maybe some CA-service company)
4. Organization CA
5. Sub-organization CA

Before one can use certificate, it must be verified not to be revoked. It can be revoked, for example, because the private key has been compromised. There will be periodical revocation notice lists, where one can check if the key is still valid. The update interval of the list is a compromise between certificate security and overhead.

The directory servers and clients can cache certificates so that the most frequently used certificates (top, country, most certification agencies, and most popular service providers) can be found quickly. This greatly reduces time needed for key retrieval. The worst situation is that one must find all certificates from the remote server.

There will be several CA trees, by different root server. To verify a certificate issued by CA in other administrative domain (different CA tree) a cross-certificate is needed: this is a certificate issued by one CA in one domain to the other CA in the other domain. Currently, the CA hierarchy is very flat: each root CA issues certificates directly to organizations.

Figure 2. The hierarchy of CAs.

3.4. Authentication and key exchange

3.4.1. Distributed Authentication Security Service (DASS)

The client sends a message with name of server to public key server. It responds with public key with servers address signed by key server. The client verifies the signature, generates random keys (both session key and public/private key pair), constructs a message with time stamp and sends it to server. The server asks (possibly different) key server for client's public key. The server verifies a signature, decrypts session key and sends a new time stamp for client to complete mutual authentication. [6, p 62]

Figure 3. DASS key exchange.

As can be seen from Figure 3, total of six messages are needed: one pair between client and server, another two pairs to key servers. This gives total time T_tot = T^rtt_c,ks + T^rtt_c,s + T^rtt_s,ks.

4. Case studies

After the TCP connection is established, the client sends a client hello message to which server responds with a server hello message. The hello messages do establish connection attributes which include the protocol version, a session identifier, the cipher suite used, and the compression method in addition to a random values for both the server and the client.

After the hello messages are exchanged, the server will send its certificate and optionally server key exchange. When the server has been authenticated, it may request certificate from the client, if appropriate cipher suite is used. After receiving all of client hello the server instructs client to start using encryption and also finishes the initial handshake. The application transfer can now take place (Figure 4).

Figure 4. SSL connection establishment.

When the client and the server decide to resume a previous session or duplicate an existing session, only the hello messages are exchanged. If the server does not find a matching session identifier, it acts as the connection is a new one. The advantage of resuming previous session is the saved amount of processing on end stations (which may have considerable effect on server performance). The client sends in both cases two messages and the server sends either two or one messages. In first case it takes two times round trip time to complete, on later one only one round trip time before the client can send data.

4.2. IP Security protocol

The authentication is a transport-protocol independent, so within same SA, there may be data from the different protocols. The authentication data is calculated with some message digest algorithm (like MD5). The authentication is done either by prepending the data to be authenticated with shared secret (keyed digest) or by signing the digest with asymmetric digital signature algorithm.

To avoid replay attacks, the 32-bit sequence number is not allowed to wrap around: one must establish new SA and generate new keys. This happens once in 2³² packets: if 1460 byte TCP segments are transfered, one can transfer 5.7 TB of data in one SA. The keys used can be either host based or user based with a different security levels. The IP SEC framework does not specify how keys are distributed, but states few possible candidates. Among those are Domain Name System (DNS) Security Extensions [8] [9] which will provide signed entity keys in the DNS thus utilizing existing infrastructure. The Public Key Infrastructure (PKIX) is a X.509 adaptation to the Internet infrastructure. Also it is possible to have an informal PGP-style web-of-trust. [20]

The key exchange used in IP SEC is the Internet Key Exchange (IKE), which is partly based on The Internet Security Association and Key Management Protocol (ISAKMP). The IKE protocol is used to to negotiate security associations and keying material between the entities. It can be used in two modes: normal mode, which requires four messages and aggressive mode, where only three messages are needed (Figure 5).

Figure 5. Internet Key Exchange in aggressive mode.

4.3. Secure Shell

After reliable byte stream (typically TCP) is established between the client and the server, the host authentication is done with transport layer functions. Both ends send version identification string which also serves as an input for key exchange. With this message, both of the ends learn the version other end is using.

The key exchange begins with both of the ends sending a key exchange initialization packet, where each entity lists algorithms for key exchange, keys, encryption, MAC, and a compression supported by it. Also supported languages are listed. There may be a different set of algorithms for the both directions. For each category the best algorithm supported by the both ends is selected.

Currently, there is only one key exchange method defined: Diffie-Hellman [6, p. 513]. The client sends e = g^x mod p, where x is random number, g and p are defined by the protocol. The server responds with message which has it's public key, f = g^y mod p (y random), and signature of already exchanged data (including e). The client verifies that the key is really the host key using database and then verifies the signature. The secure communication is established. [22]

If the user wants to authenticate, it sends a service request for an user authentication. After receiving positive response from the server the client sends authentication request with method it chooses. If the server does not accept authentication, the client may try some other authentication method. There is not any specified order; the client may choose to try first the one that is most easy for human user. If the server rejects authentication, it will supply a list of authentication methods it accepts.

There are several authentication methods which may be used alone or combined. [23]

• User public key authentication with signature.
• Password authentication.
• Host based authentication: the host supplies it's public key and if the server trusts this system, it will accept the requesting user.

Figure 6. SSH key exchange and authentication.

When user logs in a system, the system connects to Kerberos server where it retrieves a session key to be used between the user and the ticket granting service (TGS). This is encrypted with key based on user's password so end system can decrypt this if the user supplies the right password. After this is done, the user password is erased from memory to avoid compromise. The ticket for TGS (Ticket granting ticket: TGT) is also valuable, but only for limited life time. After ticket lifetime expires, it is useless.

When user wants to connect to some service, to which he does not already have ticket, he generates authenticator used between him and the server, connects to TGS and gets ticket for that specified service. The user can now connect with encrypted channel to the server. After the ticket expires, the user must retrieve a new one for service from TGS and if TGT has been expired, a new TGT from Kerberos server. If this happens the user must supply his password again.

Figure 7. The Kerberos messages.

When a user logs in, one message to Kerberos server and back is needed. When user starts to use some service, a message exchange to TGS is needed but after that the communication to server may take place immediately. The problem with Kerberos is scalability, the Kerberos server must know secret keys for each of the users and each of TGSs. This may cause some trust problems if the keys are used between several organizations.

5. Comparison of protocols

Number of messages in key distribution protocols is presented in Table 2, there are both DNS and X.509. Choosing the key distribution mechanism is very important as it is mainly the factor that dictates how many users there can be in system.

Table 1. Number of messages needed to authenticate communicating party.

Authentication system	client->server messages	server->client messages	Directory lookups
Simple passwords, One-time passwords	2	(2 prompts)
Challenge-response	2	1
Public key (client only)	2	1	c:0, s:1
Public key (mutual)	2	2	c:1, s:1
Public key (with key exchange)	0	0	c:1, s:1
Zero-knowledge proof	> 10	> 10	c:1, s:1
Data authentication with signatures	0	0	1
DASS	1	1	c:1, s:1
SSL	2	2	c:1, s:1
IP SEC	2	1	c:1, s:1
Secure Shell	4	4	c:1, s:1
Kerberos	0	0	c<>Kerberos: 1+1, c<>TGS: 1+1

Table 2. Number of messages to retrieve public key.

System	Number of lookups	Notes
DNS	0 - 6	Assumes maximum depth of 4 hierarchy levels (+ user)
X.509	1 - 8	Assumes maximum depth of CA tree to be 5. May be larger, if certificates are in different CA tree. Note that locating directory servers may need some more queries

5.1. Comparison by examples

To mount the protocols described above to the real world, following the protocols are compared in 30 different scenarios. We suppose that the client is located next to Helsinki-Vantaa airport and the server is on one of five locations (exact location is a airport). We select end-to-end delay based on measurements in [25] (current typical values) and absolute minimum by assuming that there is a direct fiber link along great circle route (Table 3).

For each case, we also have three different cases to retrieve public key: none (key is stored locally), X.509 with 2 local (delay 1 or 18 ms) and 2 remote (delay same as to the server) and DNS with one remote query. The assumed directory structure in X.509 is that two of certificats needed are found from local directory server (possibly local top-level and root certificates) and two other are found from direcotry next to the server. For DNS it is assumed that the extra lookup is only needed to retrieve user key; other keys and certificates are found in other queries.

The results from calculations are presented in Appendix A and B. In the latter the TCP connection setup is included and represents total connection setup. We must further include time for possible query-response action.

In calculating the values all end-system processing is assumed to take place immediately. If the prosess involves some public-key operations they usualu take a long time. While increase in computing power will shorten those time, also key lengts must increase which may or may not zero out the advantage gained in processor technology. This depends on how factoring large number developes.

From those results we can see that with delays found in the present Internet are so long that 0.1 second time is exceeded in nearly all cases. The times are still worse when a key lookup is included. Even in theoretical optimum case the times exceed for longer distances..

The user authentication can be done in many different ways. Some systems such as passwords are weak while other mechanism provide strong authentication as long as one can keep a secret (typically a private key or a key phrase). The number of messages is different in different systems; also some systems need to do some directory lookups to retrieve keys.

Usability factors cannot be ignored when designing authentication system as good usability is one of key points to adoption of security system and maintaining them as secure. There are several protocols than can be used: most of them require at least one or two round trip times. However, the differences between implementations are not too big, but may have some impact.

The Kerberos system and data authentication with signatures have the benefit that they do not require any extra messages between server and client. The IPSEC has the benefit of establishing security associations between hosts: one can then communicate with different servers, both the ones based TCP and the ones based on UDP.

The transport layer protocols, SSL and SSH, can support several TCP connections by one authentication. The zero-knowledge proofs are a interesting technique, but they may require ten or more messages.

The DNS with security extensions looks quite promising for public key distribution, as in many cases no extra messages are needed to retrieve public key. Furthermore it is based on existing infrastructure. The X.509 based distribution is a good choice, if the process involves directory lookup in any case as it may be the case with email.

For more exact analysis, we should take account:

• Prosessing time needed at end system (public-key arithmetic, random key generation, chippering) should be estimated. Number of connections in maybe-typical example. This would take account additional connections to certain host as on some systems the second connection would have less overhead.
• Locality of services used: how much of use is local and are remote connections atypical.
• Directory structure to retrieve keys and certificates.

[1]

Nielsen, J., "Usability Engineering", AP Professional, 1993.

[2]

Netscape Communications developer web site <URL:http://developer1.netscape.com:80/tech/index.html.

[3]

McKusick, M., Bostic, K., Karels, M., Quaterman, J., "The Design and Implementation of the 4.4BSD Operating System", Addison-Wesley Publishing Company, Inc., 1996.

[4]

Berners-Lee, T., Fielding, R., Frystyck, H., "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, IETF, 1996.

[5]

Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Berners-Lee, T., "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, IETF, 1997.

[6]

Schneider, B., "Applied Cryptography Second Edition : protocols, algorithms, and source code in C", John Wiley & Sons, Inc., 1996.

[7]

Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E., and Stewart, L. "An Extension to HTTP : Digest Access Authentication". RFC 2069, January 1997.

[8]

Eastlake, D., Kaufman, C., "Domain Name System Security Extensions", RFC 2065, IETF, January 1997.

[9]

Eastlake III, D., "Domain Name System Protocol Security Extensions", Internet-Draft: draft-ietf-dnssec-secext2-05.txt, Work in Progress, April 1998.

[10]

ITU-T Recommendation X.509 : Information Technology - Open Systems Interconnection - The Directory: Authentication Framework, Nov 1993.

[11]

Arsenault, A., Turner, S., "Internet X.509 Public Key Infrastructure : PKIX Roadmap", draft-ietf-pkix-roadmap-00.txt, Work in Progress, September 1998.

[12]

Housley, R., Hoffman, P., "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP," draft-ietf-pkix-opp-ftp-http-04.txt, Work in Progress, July 1998.

[13]

Reddy, S., "WEB based Certificate Access Protocol-- WebCAP/1.0," draft-ietf-pkix-webcap-00.txt, Work in Progress, April 1998.

[14]

Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C., "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP," draft-ietf-pkix-ocsp-07.txt, Work in Progress, September 1998.

[15]

Boeyen, S., Howes, T., Richard, P., "Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2," draft-ietf-pkix-ipki2opp-08.txt, Work in Progress, September 1998.

[16]

Dierks, T., Allen, C., "The TLS Protocol Version 1.0", draft-ietf-tls-protocol-05.txt, Work in Progress, November 1997.

[17]

Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, NRL, August 1995.

[18]

Atkinson, R., "IP Authentication Header", RFC 1826, NRL, August 1995.

[19]

Kent, S., Atkinson, R., "IP Authentication Header", Internet-Draft: draft-ietf-ipsec-auth-header-07.txt, Work in Progress, July 1998.

[20]

Maughan, D., Schertler, M., Schneider, M., Turner, J., "Internet Security Association and Key Management Protocol (ISAKMP)" draft-ietf-ipsec-isakmp-10.txt, Work in Progress, July 3, 1998.

[21]

Ylonen, T., Kivinen, T.,, Saarinen, M., Rinne, T., Lehtinen, S., "SSH Protocol Architecture" draft-ietf-secsh-architecture-02, Work in Progress, August 1998.

[22]

Ylonen, T., Kivinen, T.,, Saarinen, M., Rinne, T., Lehtinen, S., "SSH Transport Layer Protocol" draft-ietf-secsh-transport-04, Work in Progress, August 1998.

[23]

Ylonen, T., Kivinen, T.,, Saarinen, M., Rinne, T., Lehtinen, S., "SSH Authentication Protocol", draft-ietf-secsh-userauth-04, Work in Progress, August 1998.

[24]

Steiner, J., Neuman, C., Schiller, J.,. "Kerberos: An authen-tication service for open network systems". In USENIX Conference Proceedings, pages 191-202. USENIX, 1988.

[25]

Luoma, M., Peuhkuri, M., Yletyinen, T., "Quality of service for IP voice services - is it necessary?", In Proceedings of Spie Voice, Video and Data'98, Boston (MA) USA. November 1998. Also <URL:http://www.tct.hut.fi/tutkimus/mitta/paperit/vvd98mmt.pdf>

Normal text

Time less than 0.1 seconds: good usability

Emphasized text

Time more than 0.1 seconds and less than 1 second: adequate usability

Strong text

Time more than 1 second: bad usability

Table A.1. Authentication time with local key distribution (without TCP connection setup)

Protocol	Joensuu		Amsterdam		Boston		Beijing		Sydney
	cur.	min.	cur.	min.	cur.	min.	cur.	min.	cur.	min.
Challenge-response	36	2	112	15	230	63	5860	63	512	151
Public key (client only)	36	2	112	15	230	63	5860	63	512	151
Public key (mutual)	72	4	224	30	460	126	11720	126	1024	303
Public key (with key exchange)	0	0	0	0	0	0	0	0	0	0
Zero-knowledge proof	360	24	1120	152	2300	634	58600	632	5120	1518
Data authentication with signatures	0	0	0	0	0	0	0	0	0	0
DASS	36	2	112	15	230	63	5860	63	512	151
SSL	72	4	224	30	460	126	11720	126	1024	303
IP SEC	36	2	112	15	230	63	5860	63	512	151
Secure Shell	144	9	448	60	920	253	23440	252	2048	607
Kerberos	54	3	130	16	248	64	5878	64	530	152

Table A.2. Authentication time with DNS key distribution (without TCP connection setup)

Protocol	Joensuu		Amsterdam		Boston		Beijing		Sydney
	cur.	min.	cur.	min.	cur.	min.	cur.	min.	cur.	min.
Challenge-response	72	4	224	30	460	126	11720	126	1024	303
Public key (client only)	72	4	224	30	460	126	11720	126	1024	303
Public key (mutual)	108	7	336	45	690	190	17580	189	1536	455
Public key (with key exchange)	36	2	112	15	230	63	5860	63	512	151
Zero-knowledge proof	396	26	1232	167	2530	697	64460	695	5632	1669
Data authentication with signatures	36	2	112	15	230	63	5860	63	512	151
DASS	72	4	224	30	460	126	11720	126	1024	303
SSL	108	7	336	45	690	190	17580	189	1536	455
IP SEC	72	4	224	30	460	126	11720	126	1024	303
Secure Shell	180	12	560	76	1150	317	29300	316	2560	759
Kerberos	90	5	242	31	478	127	11738	127	1042	304

Table A.3. Authentication time with X.509 key distribution (without TCP connection setup)

Protocol	Joensuu		Amsterdam		Boston		Beijing		Sydney
	cur.	min.	cur.	min.	cur.	min.	cur.	min.	cur.	min.
Challenge-response	180	11	408	49	762	194	17652	193	1608	459
Public key (client only)	180	11	408	49	762	194	17652	193	1608	459
Public key (mutual)	216	13	520	64	992	257	23512	256	2120	611
Public key (with key exchange)	144	8	296	34	532	130	11792	130	1096	307
Zero-knowledge proof	504	32	1416	186	2832	764	70392	762	6216	1825
Data authentication with signatures	144	8	296	34	532	130	11792	130	1096	307
DASS	180	11	408	49	762	194	17652	193	1608	459
SSL	216	13	520	64	992	257	23512	256	2120	611
IP SEC	180	11	408	49	762	194	17652	193	1608	459
Secure Shell	288	18	744	95	1452	384	35232	383	3144	914
Kerberos	198	12	426	50	780	195	17670	194	1626	460

Normal text

Time less than 0.1 seconds: good usability

Emphasized text

Time more than 0.1 seconds and less than 1 second: adequate usability

Strong text

Time more than 1 second: bad usability

Table B.1. Authentication time with local key distribution (including TCP connection setup)

Protocol	Joensuu		Amsterdam		Boston		Beijing		Sydney
	cur.	min.	cur.	min.	cur.	min.	cur.	min.	cur.	min.
Challenge-response	72	4	224	30	460	126	11720	126	1024	303
Public key (client only)	72	4	224	30	460	126	11720	126	1024	303
Public key (mutual)	108	7	336	45	690	190	17580	189	1536	455
Public key (with key exchange)	36	2	112	15	230	63	5860	63	512	151
Zero-knowledge proof	396	26	1232	167	2530	697	64460	695	5632	1669
Data authentication with signatures	36	2	112	15	230	63	5860	63	512	151
DASS	72	4	224	30	460	126	11720	126	1024	303
SSL	108	7	336	45	690	190	17580	189	1536	455
IP SEC	72	4	224	30	460	126	11720	126	1024	303
Secure Shell	180	12	560	76	1150	317	29300	316	2560	759
Kerberos	90	5	242	31	478	127	11738	127	1042	304

Table B.2. Authentication time with DNS key distribution (including TCP connection setup)

Protocol	Joensuu		Amsterdam		Boston		Beijing		Sydney
	cur.	min.	cur.	min.	cur.	min.	cur.	min.	cur.	min.
Challenge-response	108	7	336	45	690	190	17580	189	1536	455
Public key (client only)	108	7	336	45	690	190	17580	189	1536	455
Public key (mutual)	144	9	448	60	920	253	23440	252	2048	607
Public key (with key exchange)	72	4	224	30	460	126	11720	126	1024	303
Zero-knowledge proof	432	28	1344	182	2760	760	70320	758	6144	1821
Data authentication with signatures	72	4	224	30	460	126	11720	126	1024	303
DASS	108	7	336	45	690	190	17580	189	1536	455
SSL	144	9	448	60	920	253	23440	252	2048	607
IP SEC	108	7	336	45	690	190	17580	189	1536	455
Secure Shell	216	14	672	91	1380	380	35160	379	3072	910
Kerberos	126	8	354	46	708	191	17598	190	1554	456

Table B.3. Authentication time with X.509 key distribution (including TCP connection setup)

Protocol	Joensuu		Amsterdam		Boston		Beijing		Sydney
	cur.	min.	cur.	min.	cur.	min.	cur.	min.	cur.	min.
Challenge-response	216	13	520	64	992	257	23512	256	2120	611
Public key (client only)	216	13	520	64	992	257	23512	256	2120	611
Public key (mutual)	252	16	632	80	1222	321	29372	320	2632	763
Public key (with key exchange)	180	11	408	49	762	194	17652	193	1608	459
Zero-knowledge proof	540	35	1528	201	3062	828	76252	825	6728	1977
Data authentication with signatures	180	11	408	49	762	194	17652	193	1608	459
DASS	216	13	520	64	992	257	23512	256	2120	611
SSL	252	16	632	80	1222	321	29372	320	2632	763
IP SEC	216	13	520	64	992	257	23512	256	2120	611
Secure Shell	324	20	856	110	1682	447	41092	446	3656	1066
Kerberos	234	14	538	65	1010	258	23530	257	2138	612