1 |
|
2 |
|
3 |
Internet-Draft A. Hutchison, M. Kaiserswerth, P. Trommler |
4 |
<draft-trommler-http-ext-groups-00.txt> IBM Zurich Research |
5 |
March 20, 1996 (Expires September 20, 1996) |
6 |
|
7 |
|
8 |
|
9 |
|
10 |
An Extension of the HTTP Authentication Scheme To Support Server Groups |
11 |
|
12 |
|
13 |
1. Status of this Memo |
14 |
|
15 |
This document is an Internet-Draft. Internet-Drafts are working |
16 |
documents of the Internet Engineering Task Force (IETF), its areas, |
17 |
and its working groups. Note that other groups may also distribute |
18 |
working documents as Internet-Drafts. |
19 |
|
20 |
Internet-Drafts are draft documents valid for a maximum of six months |
21 |
and may be updated, replaced, or obsoleted by other documents at |
22 |
any time. It is inappropriate to use Internet- Drafts as reference |
23 |
material or to cite them other than as ``work in progress.'' |
24 |
|
25 |
To learn the current status of any Internet-Draft, please check the |
26 |
``1id-abstracts.txt'' listing contained in the Internet- Drafts |
27 |
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), |
28 |
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or |
29 |
ftp.isi.edu (US West Coast). |
30 |
|
31 |
Distribution of this document is unlimited. Please send comments to |
32 |
the authors (see last page for e-mail addresses). |
33 |
|
34 |
|
35 |
2. Abstract |
36 |
|
37 |
This document motivates and describes an extension to HTTP which |
38 |
allows protection spaces to be extended across multiple servers |
39 |
residing in possibly different domains. These servers form groups |
40 |
that allow browsers to obtain authentication information from a user |
41 |
just once while accessing information on any one server cooperating |
42 |
in such a group. |
43 |
|
44 |
To achieve this behavior, the HTTP WWW-Authenticate header |
45 |
information must be extended. This approach is independent of the |
46 |
authentication scheme, but is most scalable in conjunction with a |
47 |
|
48 |
|
49 |
|
50 |
|
51 |
|
52 |
|
53 |
|
54 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page i] |
55 |
|
56 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
57 |
|
58 |
|
59 |
trusted third party authentication scheme, such as the proposed |
60 |
Mediated Digest Authentication. |
61 |
|
62 |
|
63 |
3. Acknowledgments |
64 |
|
65 |
Thanks to Guenther Karjoth and Markus Buehler who helped identify the |
66 |
need for this proposal. |
67 |
|
68 |
|
69 |
|
70 |
|
71 |
|
72 |
|
73 |
|
74 |
|
75 |
|
76 |
|
77 |
|
78 |
|
79 |
|
80 |
|
81 |
|
82 |
|
83 |
|
84 |
|
85 |
|
86 |
|
87 |
|
88 |
|
89 |
|
90 |
|
91 |
|
92 |
|
93 |
|
94 |
|
95 |
|
96 |
|
97 |
|
98 |
|
99 |
|
100 |
|
101 |
|
102 |
|
103 |
|
104 |
|
105 |
|
106 |
|
107 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page ii] |
108 |
|
109 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
110 |
|
111 |
|
112 |
|
113 |
|
114 |
Contents |
115 |
|
116 |
|
117 |
|
118 |
1. Status of this Memo i |
119 |
|
120 |
2. Abstract i |
121 |
|
122 |
3. Acknowledgments ii |
123 |
|
124 |
4. Introduction 1 |
125 |
|
126 |
5. HTTP Authentication and Protection Space Model 1 |
127 |
|
128 |
6. The Server Group Model And Assumptions 2 |
129 |
|
130 |
7. Secure Authentication To A Group Of WWW Servers 3 |
131 |
|
132 |
8. Group Names and HTTP Modification 3 |
133 |
8.1. WWW-Authenticate Response-Header . . . . . . . . . . . . 4 |
134 |
8.2. Authorization Request-Header . . . . . . . . . . . . . . 5 |
135 |
|
136 |
9. Example Usage 5 |
137 |
9.1. Basic Authentication . . . . . . . . . . . . . . . . . . 5 |
138 |
9.2. Digest Authentication . . . . . . . . . . . . . . . . . . 6 |
139 |
9.3. Mediated Digest Authentication . . . . . . . . . . . . . 6 |
140 |
|
141 |
10. Implementation Issues 7 |
142 |
10.1. Server . . . . . . . . . . . . . . . . . . . . . . . . . 7 |
143 |
10.2. User Agent . . . . . . . . . . . . . . . . . . . . . . . 7 |
144 |
|
145 |
11. Conclusion 8 |
146 |
|
147 |
12. Authors' Address 9 |
148 |
|
149 |
|
150 |
|
151 |
|
152 |
|
153 |
|
154 |
|
155 |
|
156 |
|
157 |
|
158 |
|
159 |
|
160 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page iii] |
161 |
|
162 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
163 |
|
164 |
|
165 |
4. Introduction |
166 |
|
167 |
In this paper we propose an addition to the HTTP authentication |
168 |
information which allows users to provide their authentication |
169 |
information once for an entire set of servers belonging to the |
170 |
same logical group. The concept is that even if servers reside in |
171 |
different Internet domains, this enhancement allows them to share |
172 |
information among authorized members in a seamless manner. |
173 |
|
174 |
Although the proposed extension is not restricted to any particular |
175 |
authentication technique, we base our work on the Mediated Digest |
176 |
Authentication [4] Internet-Draft proposal, whereby authentication |
177 |
information is protected and, in the context of cooperating servers, |
178 |
group management is facilitated. |
179 |
|
180 |
|
181 |
5. HTTP Authentication and Protection Space Model |
182 |
|
183 |
Authentication of HTTP V1.0 [1] uses a simple challenge-response |
184 |
mechanism, which works as follows: a server which requires |
185 |
clients to authenticate themselves replies to a client's HTTP |
186 |
method invocation with an Unauthorized (401) error code, and an |
187 |
authentication challenge that contains an indication of the required |
188 |
authentication method. The client may then resubmit its request, but |
189 |
must include authentication information with it to be allowed access |
190 |
to the server's resources. The authentication challenge is always |
191 |
tied to a server-defined protection space. |
192 |
|
193 |
The protection space is defined through a combination of the server's |
194 |
root Uniform Resource Locator (URL) and a server-specified realm. |
195 |
For all practical purposes, the root URL is the server's name in |
196 |
either DNS or dotted IP address notation. The realm is a name |
197 |
the server administrator chooses and can be used to partition the |
198 |
server's file system into different protection spaces. |
199 |
|
200 |
In a typical implementation, encountering an Unauthorized |
201 |
(401) response causes a client browser to prompt the user for |
202 |
authentication credentials before the request is resubmitted with |
203 |
this information. For future accesses to the same protection space, |
204 |
the browser may then cache the user credentials and automatically |
205 |
include them in its accesses without further prompting the user. |
206 |
|
207 |
HTTP V1.0 [1] specifies only a basic authentication mechanism (BA), |
208 |
where the browser includes the user identification and password as |
209 |
a base-64 encoded string in an authentication field in the request |
210 |
|
211 |
|
212 |
|
213 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 1] |
214 |
|
215 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
216 |
|
217 |
|
218 |
header. This scheme is described in the draft as "a non-secure |
219 |
method of filtering unauthorized access to resources on an HTTP |
220 |
server". As this authentication information travels in the clear |
221 |
over an essentially insecure network, it is susceptible to capture by |
222 |
an observer who could then masquerade as the original user. |
223 |
|
224 |
To address the security concerns of the basic HTTP authentication |
225 |
method, two proposals were made in 1995. Both ensure that the |
226 |
authentication information never travels in the clear. These schemes |
227 |
can also prevent replay of HTTP requests by requiring that part of |
228 |
the request information changes on subsequent accesses by a same |
229 |
user to a given server protection space. This is achieved via the |
230 |
inclusion of nonces. |
231 |
|
232 |
Digest Authentication (DA) [2] operates in a similar fashion |
233 |
to BA, but transfers the user-id and password from browser to |
234 |
server in a hashed form. A server provided nonce can be used |
235 |
to establish response freshness and detect replays. Mediated |
236 |
Digest Authentication (MDA) [4] is based on DA, but introduces |
237 |
trusted third-parties who act as mediators in proving identity and |
238 |
establishing a session key. Introduction of a client nonce enables |
239 |
the browser to distinguish the server reply as the valid response |
240 |
associated with its request. A server employing MDA supplies |
241 |
a list of trusted third-parties, with which the server shares a |
242 |
cryptographic key, to a requesting client. If the client is able |
243 |
to identify a third-party in this list with which it also shares a |
244 |
cryptographic key, then this party can be contacted to enable mutual |
245 |
authentication to occur. |
246 |
|
247 |
|
248 |
6. The Server Group Model And Assumptions |
249 |
|
250 |
In this proposal we define a group of servers as a set of physically |
251 |
distinct servers wishing to collaborate to provide information to a |
252 |
closed user group. This closed user group is trusted by each server. |
253 |
|
254 |
A server group can be recognized as existing amongst the involved |
255 |
servers where, from a security point of view, access to one 'group |
256 |
member' ensures access to other group members. In practical terms |
257 |
this means that a company or organization can distribute information |
258 |
over several (geographically- and/or domain-separated) servers to |
259 |
form a server group. |
260 |
|
261 |
In the case of BA or DA, this requires that the (same) user-id and |
262 |
password are stored at each server and kept consistent among these. |
263 |
|
264 |
|
265 |
|
266 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 2] |
267 |
|
268 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
269 |
|
270 |
|
271 |
For reasons of consistency and distribution, use of the MDA scheme, |
272 |
which employs trusted third party based authentication, is very |
273 |
attractive. By 'signing-on' to any one of these group servers, a |
274 |
user can access any other server of that server group without having |
275 |
to repeat the sign-on procedure. |
276 |
|
277 |
|
278 |
7. Secure Authentication To A Group Of WWW Servers |
279 |
|
280 |
To achieve the server group model described, single server |
281 |
authentication requires extension to allow seamless retrieval of |
282 |
documents from any server belonging to a group. Secure access to |
283 |
servers in the group is seamless in that user-id and password are |
284 |
explicitly supplied by the user only once (exploiting the normal |
285 |
caching of authentication information in the browser), for the first |
286 |
group server encountered. |
287 |
|
288 |
As described in section 5, HTTP authentication information is always |
289 |
relative to a server's protection space, which is based on the |
290 |
combination of the canonical root URL of that server and a server |
291 |
defined realm. As a root URL always gives the server's Internet |
292 |
address, the protection space is uniquely tied to that server |
293 |
and cannot be extended to other servers that are only known under |
294 |
different Internet addresses. |
295 |
|
296 |
To extend the HTTP protection space beyond a single WWW server, the |
297 |
definition of the protection space must be made relative to a unique |
298 |
group name rather than a (root) URL, and the browser must be notified |
299 |
that the protection space information pertains to a group of servers |
300 |
rather than a single server. In subsequent sections we describe how |
301 |
this can be achieved. |
302 |
|
303 |
|
304 |
8. Group Names and HTTP Modification |
305 |
|
306 |
We considered several different solutions for defining unique group |
307 |
names for the global WWW. X.500-like distinguished group names were |
308 |
one candidate, but we decided that (for the time being) the overhead |
309 |
associated with maintaining such a naming scheme would be excessive. |
310 |
We rather elected to use the DNS name of a distinguished server in |
311 |
the server group as a unique base for the group name. This server |
312 |
name combined with a freely chosen group name, and the realm of the |
313 |
original HTTP specification, then defines a protection space that can |
314 |
span multiple servers belonging to the same server group. |
315 |
|
316 |
|
317 |
|
318 |
|
319 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 3] |
320 |
|
321 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
322 |
|
323 |
|
324 |
The required modifications to HTTP are described in the next two |
325 |
subsections. |
326 |
|
327 |
|
328 |
8.1. WWW-Authenticate Response-Header |
329 |
|
330 |
The WWW-Authenticate response header is prescribed for Unauthorized |
331 |
(401) server response messages. The field value is defined |
332 |
as consisting of at least one challenge that indicates the |
333 |
authentication scheme(s) and parameters applicable to the |
334 |
Request-URI. |
335 |
|
336 |
The challenge-response authentication mechanism of HTTP is described |
337 |
in [1] as: |
338 |
|
339 |
auth-scheme = token |
340 |
|
341 |
auth-param = token "=" quoted-string |
342 |
|
343 |
where 'token' is a case-insensitive identification of the |
344 |
authentication scheme, or the attribute for which an associated value |
345 |
is given, respectively. |
346 |
|
347 |
The 401 (unauthorized) response is structured as follows: |
348 |
|
349 |
challenge = auth-scheme 1*SP realm *("," auth-param) |
350 |
|
351 |
|
352 |
realm = "realm" "=" realm-value |
353 |
realm-value = quoted-string |
354 |
|
355 |
|
356 |
The HTTP V1.0 draft limits the 'realm' to a specific server where |
357 |
'the realm value, in combination with the canonical root URL of |
358 |
the server being accessed, defines the protection space'. In this |
359 |
way a set of 'protection spaces' is achieved. It is explicitly |
360 |
stated, though, that a single protection space cannot extend outside |
361 |
the scope of its server unless the authentication scheme specifies |
362 |
otherwise. |
363 |
|
364 |
Our proposal is to add an optional 'servgrp' field which can be |
365 |
used independently of authentication scheme to achieve cross-server |
366 |
protection spaces when desired. This results in a challenge field |
367 |
consisting of: |
368 |
|
369 |
|
370 |
|
371 |
|
372 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 4] |
373 |
|
374 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
375 |
|
376 |
|
377 |
challenge = auth-scheme 1*SP realm *("," auth-param) ["," servgrp] |
378 |
|
379 |
servgrp = "servgrp" "=" servgrp-value |
380 |
|
381 |
servgrp-value = quoted-string |
382 |
|
383 |
The content of the servgrp-value should be made unique in accordance |
384 |
with the naming proposals in section 8 of this document. |
385 |
|
386 |
|
387 |
8.2. Authorization Request-Header |
388 |
|
389 |
The Authorization request-header field is included by a user agent |
390 |
wishing to authenticate itself with a server. The field value |
391 |
is described in [1] as consisting of credentials containing the |
392 |
authentication information of the user agent for the realm of the |
393 |
resource being requested. The specification of a realm by a server |
394 |
indicates that the same credentials should be valid for all other |
395 |
requests within the nominated protection space. |
396 |
|
397 |
|
398 |
9. Example Usage |
399 |
|
400 |
In this section we illustrate the usage of the servgrp field with the |
401 |
Basic[1], Digest[2] and Mediated[4] authentication schemes. |
402 |
|
403 |
We have arbitrarily chosen to use the server "hundshorn.zurich.ibm.com" |
404 |
as the unique group identifier, and illustrate three authentication |
405 |
schemes with a group: |
406 |
|
407 |
hundshorn.zurich.ibm.com:med_image_group |
408 |
|
409 |
|
410 |
9.1. Basic Authentication |
411 |
|
412 |
The following message shows the WWW-Authenticate header containing |
413 |
server group information: |
414 |
|
415 |
WWW-Authenticate: Basic realm="x-rays", |
416 |
servgrp="hundshorn.zurich.ibm.com:med_image_group" |
417 |
|
418 |
The browser constructs an unaltered BA Authorization response with |
419 |
base-64 encoded user-id and password: |
420 |
|
421 |
Authorization: Basic YWh1OmFodQ== |
422 |
|
423 |
|
424 |
|
425 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 5] |
426 |
|
427 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
428 |
|
429 |
|
430 |
9.2. Digest Authentication |
431 |
|
432 |
Extension of the digest authentication scheme results in a similar |
433 |
extension of the WWW-Authenticate header with the addition of the |
434 |
server group information: |
435 |
|
436 |
WWW-Authenticate: Digest realm="x-rays", nonce="824385109", |
437 |
opaque="ef609f5de336fc7f0e0f5e22da9c921c", |
438 |
servgrp="hundshorn.zurich.ibm.com:med_image_group" |
439 |
|
440 |
In this scheme the browser also returns an unaltered DA Authorization |
441 |
response. In this case the browser returns a digest of the user-id |
442 |
and password, so that an observer could not directly retrieve these |
443 |
fields as in the BA case: |
444 |
|
445 |
Authorization: Digest username="ahu", realm="x-rays", |
446 |
nonce="824385109", uri="digest/", |
447 |
response="b9686783c8e29f91417a557bd13f65b7", |
448 |
opaque="ef609f5de336fc7f0e0f5e22da9c921c" |
449 |
|
450 |
|
451 |
9.3. Mediated Digest Authentication |
452 |
|
453 |
Extension of the MDA scheme can also be seen to present additional |
454 |
server group information with the WWW-Authenticate header fields. |
455 |
The MDA proposal also adds Trusted-Party messages to the server's |
456 |
reply. A mutually trusted party is contacted by the browser |
457 |
to perform authentication. The information in the server-mac |
458 |
field is passed by the browser to the selected authentication |
459 |
server (trusted-party), and in this way the client is also able to |
460 |
authenticate the server. This is not possible in BA or DA: |
461 |
|
462 |
WWW-Authenticate: Mediated realm="x-rays", nonce="824384997", |
463 |
opaque="017a975b3e5972507e7e098dc23e2031", |
464 |
servgrp="hundshorn.zurich.ibm.com:med_image_group" |
465 |
|
466 |
Trusted-Party: uri="mdap://gletscherhorn.zurich.ibm.com:1995", |
467 |
server-name="hundshorn.zurich.ibm.com", |
468 |
server-mac="fb400c1e1dc023e49441cd5092fdd566" |
469 |
|
470 |
Trusted-Party: uri="mdap://galmihorn.zurich.ibm.com:1995", |
471 |
server-name="hundshorn.zurich.ibm.com", |
472 |
server-mac="e0dde363778ee29540b4410ab009daac" |
473 |
|
474 |
|
475 |
|
476 |
|
477 |
|
478 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 6] |
479 |
|
480 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
481 |
|
482 |
|
483 |
Trusted-Party: uri="mdap://hundshorn.zurich.ibm.com:1995", |
484 |
server-name="hundshorn.zurich.ibm.com", |
485 |
server-mac="0205a4ea82fa6b596025038326759298" |
486 |
|
487 |
After receiving a (positive) response from the contacted |
488 |
trusted-party, the browser returns Authorization and Session-key |
489 |
headers to the server: |
490 |
|
491 |
Authorization: Mediated username="ahu", realm="x-rays", |
492 |
nonce="824384997", |
493 |
uri="mediated/", response="12f1950f5ca91f4febb7c6c05d0ec284", |
494 |
opaque="017a975b3e5972507e7e098dc23e2031" |
495 |
|
496 |
Session-key: uri="mdap://hundshorn.zurich.ibm.com:1995", |
497 |
server-name="hundshorn.zurich.ibm.com", |
498 |
server-key="ce6b7e04611d687ebdae5bdb59514593", |
499 |
server-mac="0dcda62dc189d186302b81f97c275827" |
500 |
|
501 |
The Internet Draft on MDA [4] requires a WWW server to cache session |
502 |
keys established by the authentication server. In this way state is |
503 |
introduced into the server which is supposed to be stateless. We |
504 |
therefore decided to cache the session key data received from the |
505 |
authentication server in the user agent. The user agent then resends |
506 |
this information each time a particular server is accessed again. |
507 |
Alternatively the approach of [3] could be deployed by adding the |
508 |
session key to the State-Info header (in encrypted form). |
509 |
|
510 |
|
511 |
10. Implementation Issues |
512 |
|
513 |
In this section we briefly describe the issues which have to be |
514 |
addressed in supporting the HTTP Modification described in section 8. |
515 |
|
516 |
|
517 |
10.1. Server |
518 |
|
519 |
On the server side it is necessary to enhance the access control |
520 |
files with a directive for naming the server group to which documents |
521 |
belong. |
522 |
|
523 |
|
524 |
10.2. User Agent |
525 |
|
526 |
On the user agent side it is necessary to take the group organization |
527 |
into consideration when caching authentication information. The |
528 |
|
529 |
|
530 |
|
531 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 7] |
532 |
|
533 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
534 |
|
535 |
|
536 |
current organization which HTTP implies (via the uni-server 'realm') |
537 |
is that servers are divided into local protection spaces. In the |
538 |
proposed multi-server 'server group' protection space, cache lookup |
539 |
should first consider group membership before attempting realm |
540 |
matching. |
541 |
|
542 |
|
543 |
11. Conclusion |
544 |
|
545 |
This document has presented a mechanism by which the existing HTTP |
546 |
single-server protection space can be extennded to provide protection |
547 |
across multiple servers. The extension enables seamless cooperation |
548 |
amongst servers, and secure authentication if it is used with a |
549 |
method such as MDA. |
550 |
|
551 |
The nature of this proposal is such that the enhancements can be |
552 |
implemented to coexist with the authentication mechanism of HTTP |
553 |
V1.0, or the various proposed authentication enhancements. The |
554 |
proposal allows upward compatibility, in that non group-enabled |
555 |
browsers simply ignore the additional information. |
556 |
|
557 |
We also advocate incorporation of secure group enablement as a |
558 |
permanent feature in the revised version of HTTP, V1.1. |
559 |
|
560 |
An AIX patch for NCSA's httpd version 1.5a and Mosaic for XWindow |
561 |
version 2.7b2 is available via anonymous ftp from ftp.zurich.ibm.com |
562 |
in directory /pub/trp/server-groups. An implementation of the |
563 |
authentication server can also be found at this location. |
564 |
|
565 |
|
566 |
References |
567 |
|
568 |
[1] T. Berners-Lee and R. T. Fielding and H. Frystyk Nielsen |
569 |
HyperText Transfer Protocol (HTTP) Internet Draft, Work in |
570 |
Progress February 1996 |
571 |
|
572 |
[2] J. Hostetler and others A Proposed Extension to HTTP: Digest |
573 |
Access Authentication Internet Draft, Work in Progress December |
574 |
1995 |
575 |
|
576 |
[3] D. M. Kristol and L. Montulli Proposed HTTP State Management |
577 |
Mechanism Internet Draft, Work in Progress February 1996 |
578 |
|
579 |
[4] D. Raggett Mediated Digest Authentication Internet Draft, Work |
580 |
in Progress March 1995 (expired) |
581 |
|
582 |
|
583 |
|
584 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 8] |
585 |
|
586 |
Internet-Draft HTTP Secure Server Groups March 20, 1996 |
587 |
|
588 |
|
589 |
12. Authors' Address |
590 |
|
591 |
Andrew Hutchison, Matthias Kaiserswerth, Peter Trommler |
592 |
IBM Zurich Research Laboratory |
593 |
Saeumerstrasse 4 |
594 |
CH-8803, Rueschlikon |
595 |
Switzerland |
596 |
{ahu,kai,trp}@zurich.ibm.com |
597 |
|
598 |
Any correspondence should please be directed to trp@zurich.ibm.com. |
599 |
(Phone: +41 1 724 8373 Fax: +41 1 710 3608) |
600 |
|
601 |
|
602 |
|
603 |
|
604 |
|
605 |
|
606 |
|
607 |
|
608 |
|
609 |
|
610 |
|
611 |
|
612 |
|
613 |
|
614 |
|
615 |
|
616 |
|
617 |
|
618 |
|
619 |
|
620 |
|
621 |
|
622 |
|
623 |
|
624 |
|
625 |
|
626 |
|
627 |
|
628 |
|
629 |
|
630 |
|
631 |
|
632 |
|
633 |
|
634 |
|
635 |
|
636 |
|
637 |
Hutchison, Kaiserswerth, Trommler Expires September 20, 1996 [Page 9] |