Section 1 of 5 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5

Archive-name: kerberos-faq/general
Posting-Frequency: monthly
URL: http://www.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html
Copyright: (c) 2000 United States Government as represented by the
        Secretary of the Navy. All rights reserved.

Table of Contents:

   * 0. Introduction

   * 1. General information about Kerberos
        o 1.1. What is Kerberos?
        o 1.2. Where does the name "Kerberos" come from?
        o 1.3. Hey! I remember my Greek mythology, and I thought the dog
          that guarded the entrance was called Cerberus! What gives?
        o 1.4. Where can I find out more information about Kerberos?
        o 1.5. What is the latest version of Kerberos available from MIT?
        o 1.6. Are there any other free version of Kerberos available?
        o 1.7. What are the differences between Kerberos Version 4 and
          Version 5?
        o 1.8. What are the differences between AFS Kerberos and "normal"
          Kerberos?
        o 1.9. What is the format of principals?
        o 1.10. How are realms named? Do they really have to be uppercase?
        o 1.11. What is ASN.1?
        o 1.12. I see the acronyms TGT and TGS used a lot. What do they
          mean?
        o 1.13. What is the export status of Kerberos?
        o 1.14. What is a "Kerberos client", "Kerberos server", and
          "application server"?
        o 1.15. I use software package , and it claims it supports
          Kerberos. What does that mean?
        o 1.16. What is cross-realm authentication?
        o 1.17. Are there security risks involved in cross-realm
          authentication?
        o 1.18. Are there any known weaknesses in Kerberos?
        o 1.19. What is preauthentication?
        o 1.20. Why do I need to synchronize my system clocks to run
          Kerberos?
        o 1.21. What computer vendors support Kerberos?
        o 1.22. Can I use Kerberos 4 clients with Kerberos 5? How about the
          reverse?
        o 1.23. What is a "key salt"? "kvno"?
        o 1.24. Does Kerberos support multi-homed machines?
        o 1.25. What is "user to user" authentication?
        o 1.26. What are forwardable tickets?
        o 1.27. What are renewable tickets?
        o 1.28. What are postdatable tickets?
        o 1.29. What are the advantages/disadvantages of Kerberos vs. SSL?
        o 1.30. What are proxiable tickets?
   * 2. Administration questions
        o 2.1. Okay, I'm the administrator of a site, and I'd like to run
          Kerberos. What do I need to do?
        o 2.2. What sort of resources do I need to dedicate to a KDC?
        o 2.3. What programs/files need to go on each application server?
        o 2.4. What programs/files need to go on each client?
        o 2.5. There's a lot of stuff in the krb5.conf and kdc.conf files.
          What does it all mean, and what do I really need?
        o 2.6. How do I change the master key?
        o 2.7. How do I set up slave servers?
        o 2.8. What do I need to do to make V4 clients work with my V5 KDC?
        o 2.9. I just added a host key to a machine with ktadd, and the kvno
          got incremented! What just happened?
        o 2.10. How do I run kadmin from a shell script unattended?
        o 2.11. I can't use kadmin to talk to the admin server of another
          realm. What am I doing wrong?
        o 2.12. We run AFS at our site currently. Is there a way we can run
          Kerberos along with AFS?
        o 2.13. Employee  just left the company, and he had root on our
          KDC. What should I do?
        o 2.14. How should I configure my DNS for Kerberos?
        o 2.15. What do I need to do to setup cross-realm authentication?
        o 2.16. Can I configure the admin server to reject bad passwords?
        o 2.17. Is there a hook I can use to do further password checking?
        o 2.18. How come the "Last xxx" fields in the Kerberos database
          don't seem to get updated?
        o 2.19. What does krb524d do? Do I need to run it?
        o 2.20. What is v5passwdd? Do I need to run it?
        o 2.21. How do a rename a principal?
        o 2.22. What is the difference between the "-a valid" and the "-a
          user" flags for telnetd?
        o 2.23. I already have a standard Unix password database for my user
          population. Can I convert this to a Kerberos password database?
        o 2.24. Can I have multiple realms on a single KDC?
        o 2.25. What is the kadm5.acl file?
   * 3. User and application questions
        o 3.1. What happens when my tickets expire?
        o 3.2. How do I run a cron job with Kerberos authentication?
        o 3.3. How do I use renewable tickets?
        o 3.4. What is the .k5login file, and how do I use it?
        o 3.5. I've hear Microsoft will support Kerberos in Windows 2000. Is
          that true?
        o 3.6. How can I be authenticated as two different principals at the
          same time?
        o 3.7. How come Kerberos rlogin works to a machine, but when I use
          Kerberos telnet I'm still asked for a password?
        o 3.8. How do I use Kerberos telnet/rlogin to connect to a system as
          a userid other than my current one?
        o 3.9. Is there any way to do Kerberos authentication across the
          WWW?
        o 3.10. Is there a way to use Kerberos to authenticate my X windows
          connections? I tried compiling the Kerberos support in X, but it
          didn't work.
        o 3.11. I need to use Kerberos through a firewall. What does my
          firewall administrator need to do?
   * 4. Error messages and other problems.
        o 4.1. "No such file or directory"
        o 4.2. "Decrypt integrity check failed"
        o 4.3. "Cannot find/read stored master key"
        o 4.4. "Incorrect net address"
        o 4.5. "Initial Ticket response appears to be Version 4 error"
        o 4.6. "Message stream modified"
        o 4.7. "Illegal cross-realm ticket"
        o 4.8. "Couldn't authenticate to server: Bad sendauth version was
          sent"
        o 4.9. When I try using Kerberos ftp, it doesn't work, but it says,
          "No error".
        o 4.10. When I telnet from a Linux machine to a Solaris machine with
          Kerberos and hit Ctrl-C, the connection hangs.
   * 5. Programming with Kerberos.
        o 5.1. How do I start programming with Kerberos?
        o 5.2. What is GSSAPI?
        o 5.3. What is SASL?
        o 5.4. Is there a reference for the Kerberos API?

------------------------------------------------------------

Subject: 0. Introduction

Welcome to the Kerberos FAQ! The intent of this document is to answer many
of the recurring questions that appear on the kerberos@mit.edu mailing list,
as well as the comp.protocols.kerberos newsgroup. It is also intended to
serve as a repository of information for people who want to know more about
the Kerberos authentication system.

In general, this FAQ deals with the freely available MIT releases of
Kerberos. If a question deals specifically with another implementation of
Kerberos, then it will be explicitly mentioned.

Questions and comments should be directed to the FAQ maintainer, Ken
Hornstein, .

------------------------------------------------------------

Subject: 1. General information about Kerberos

------------------------------------------------------------

Subject: 1.1 What is Kerberos?

From 

     Kerberos is a network authentication protocol. It is designed to
     provide strong authentication for client/server applications by
     using secret-key cryptography. A free implementation of this
     protocol is available from the Massachusetts Institute of
     Technology. Kerberos is available in many commercial products as
     well.

     The Internet is an insecure place. Many of the protocols used in
     the Internet do not provide any security. Tools to "sniff"
     passwords off of the network are in common use by systems
     crackers. Thus, applications which send an unencrypted password
     over the network are extremely vulnerable. Worse yet, other
     client/server applications rely on the client program to be
     "honest" about the identity of the user who is using it. Other
     applications rely on the client to restrict its activities to
     those which it is allowed to do, with no other enforcement by the
     server.

     Some sites attempt to use firewalls to solve their network
     security problems. Unfortunately, firewalls assume that "the bad
     guys" are on the outside, which is often a very bad assumption.
     Most of the really damaging incidents of computer crime are
     carried out by insiders. Firewalls also have a significant
     disadvantage in that they restrict how your users can use the
     Internet. (After all, firewalls are simply a less extreme example
     of the dictum that there is nothing more secure then a computer
     which is not connected to the network --- and powered off!) In
     many places, these restrictions are simply unrealistic and
     unacceptable.

     Kerberos was created by MIT as a solution to these network
     security problems. The Kerberos protocol uses strong cryptography
     so that a client can prove its identity to a server (and vice
     versa) across an insecure network connection. After a client and
     server have used Kerberos to prove their identity, they can also
     encrypt all of their communications to assure privacy and data
     integrity as they go about their business.

     Kerberos is freely available from MIT, under a copyright
     permission notice very similar to the one used for the BSD
     operating and X11 Windowing system. MIT provides Kerberos in
     source form, so that anyone who wishes to use it may look over the
     code for themselves and assure themselves that the code is
     trustworthy. In addition, for those who prefer to rely on a
     professional supported product, Kerberos is available as a product
     from many different vendors.

     In summary, Kerberos is a solution to your network security
     problems. It provides the tools of authentication and strong
     cryptography over the network to help you secure your information
     systems across your entire enterprise. We hope you find Kerberos
     as useful as it has been to us. At MIT, Kerberos has been
     invaluable to our Information/Technology architecture.

------------------------------------------------------------

Subject: 1.2. Where does the name "Kerberos" come from?

The name Kerberos comes from Greek mythology; it is the three-headed dog
that guarded the entrance to Hades.

------------------------------------------------------------

Subject: 1.3. Hey! I remember my Greek mythology, and I thought the dog that
	guarded the entrance was called Cerberus! What gives?

I personally wonder about this myself. I have seen references in "The
Devil's Dictionary" that claim it is Kerberos, but when I checked this
myself I only found the "Cerberus" variant.

I never actually heard of the "Kerberos" spelling/pronunciation until I got
involved with Kerberos myself.

From: Tom Yu 

     "Cerberus" is the Latin spelling of the Greek "Kerberos", and
     according to the OED is pronounced like "serberus", but that is
     quite at odds with the Greek, as the initial consonant is a "k".
     MIT Project Athena chose to use the Greek spelling and
     pronunciation.

From: Jan Sacharuk 

     Tom Yu is correct, Cerberus is the Latin spelling. However, the
     fact that the OED says that the 'c' is pronounced as an 's' is an
     English affectation. In Latin, the letter 'c' is always hard. So
     Cerberus is pronounced 'Ker-ber-ous'. The letter 'u' is also
     slightly different, making it somewhere in between 'oos' and
     'ous'.

From: Michael A. Covington 

     "Kerberos" is the original Greek name. In Latin, the letter K is
     not normally used, and in Roman times, C always represented the K
     sound. Also, "-os" is a Greek suffix (nominative masculine
     singular) whose nearest equivalent in Latin is the suffix "-us"
     (very familiar in Latin names). That's why the name goes into
     Latin as Cerberus.

     (See, a Ph.D. in linguistics is good for something! :)

------------------------------------------------------------

Subject: 1.4. Where can I find out more information about Kerberos?

If you're new to Kerberos, I would suggest you read:

   * Bill Bryant, "Designing an Authentication System: A Dialogue in Four
     Scenes."
     

     A cute explanation of Kerberos protocol, in plain English. Technobabble
     is kept to a minimum.

   * Jeffrey I. Schiller, "Secure Distributed Computing", Scientific
     American, November 1994, pp 72-76.

     An excellent overview that covers all of the important details of the
     Kerberos protocol. It also explains how it's used at MIT as a "real
     world" example. This article could be useful in persuading manager
     droids that Kerberos is a good thing.

   * J. G. Steiner, B. Clifford Neuman, and J.I. Schiller, "Kerberos: An
     Authentication Service for Open Network Systems".
     

     The original paper describing Kerberos. A good general overview. It
     describes the encryption notation used by many other Kerberos papers,
     so it is definitely worth reading if you want to read other Kerberos
     papers.

   * Brian Tung, "The Moron's Guide to Kerberos"
     

     Despite the title, goes into a fair amount of detail. I would suggest
     reading this after you have read one or more of the higher-level
     papers.

The MIT Kerberos web page  has many links
pointing to Kerberos resources.

One of the best tutorials for Kerberos is Jim Rowe's, "How To Kerberize Your
Site", which is available at:

   * 

There is an RFC for Kerberos 5: RFC 1510, which is available at:



But it is a rather difficult read unless you already know a lot about how
Kerberos works.

------------------------------------------------------------

Subject: 1.5. What is the latest version of Kerberos available from MIT?

The latest version of Kerberos 4 from MIT is patchlevel 10. You can get it
by reading  and
following the directions in that file.

Kerberos 4 is officially considered "dead" by MIT; all current development
is concentrated on Kerberos 5.

The latest version of Kerberos 5 is 1.2.1. You can get it from the following
location:

http
     Go to the Kerberos web page , select
     the link marked, "Release 1.2", and from there, select "Retrieving".

Note that only U.S. & Canadian citizens can legally download Kerberos from
MIT. However, Kerberos 5 is available for ftp from:


I have no idea if it is legal for non-US residents to download Kerberos from
this ftp site.

------------------------------------------------------------

Subject: 1.6. Are there any other free version of Kerberos available?

Cygnus Solutions has announced the release of KerbNet 1.2. This is based on
the MIT 1.0pl1 release, but with a number of enhancements. You can find out
more information about KerbNet at .

The Center for Parallel Computers at the Royal Institute of Technology in
Stockholm, Sweden have a version of eBones (Bones with crypto calls added
back in). This is a version of Kerberos 4 that is exportable to other
countries (assuming that your country allows you to import cryptographic
software). It is available at

.

A web page for KTH krb4 is available at:

   * 

There is also work at the Center for Parallel Computers to create a freely
available version of Kerberos 5 called Heimdal. Mailing lists to discuss
Heimdal are are available at:

   *  - low-volume announcement only, moderated
   *  - high-volume discussion

Send email to  to subscribe to either one of these
mailing lists.

A web page for heimdal is also available at:



As of this writing, the latest release is 0.03a.

------------------------------------------------------------

Subject: 1.7. What are the differences between Kerberos Version 4 and
	Version 5?

The paper "The Evolution of the Kerberos Authentication System" is a very
good description of the limitations of Kerberos 4 and what changes were made
in Kerberos 5. This paper is available from
.

However, here is a quick list of the more important changes:

   * The key salt algorithm has been changed to use the entire principal
     name.
   * The network protocol has been completely redone and now uses ASN.1
     encoding everywhere.
   * There is now support for forwardable, renewable, and postdatable
     tickets.
   * Kerberos tickets can now contain multiple IP addresses and addresses
     for different types of networking protocols.
   * A generic crypto interface module is now used, so other encryption
     algorithms beside DES can be used.
   * There is now support for replay caches, so authenticators are not
     vulnerable to replay.
   * There is support for transitive cross-realm authentication.

------------------------------------------------------------

Subject: 1.8. What are the differences between AFS Kerberos and "normal"
	Kerberos?

The Kerberos used in AFS (formerly known as the Andrew File System) was
developed from the Kerberos 4 papers, but before the protocol was
formalized.

As a result, AFS Kerberos uses the RX protocol for all communication between
the clients and database servers (which function as KDCs in Kerberos
termology)

The standard AFS clients that perform authentication discard the TGT after
they acquire an AFS service ticket. This means that you can't get tickets
for other services using your AFS token.

It is possible to use regular Kerberos instead of AFS Kerberos. For more
information, see Question 2.12.

------------------------------------------------------------

Subject: 1.9. What is the format of principals?

In Kerberos 4, a principal was divided into three parts:

  1. The principal name
  2. An optional instance
  3. The Kerberos realm

Kerberos 4 principals are written in the following format:

name.instance@realm

Kerberos 5 principals are written in a slightly different format:

component/component/component@realm

The terms "name" and "instance" are still used for the first and the second
components respectively.

Note that in both Kerberos 4 and Kerberos 5, the way that principals are
encoded into strings have nothing to do with the way they are stored
internally in Kerberos.

There is an established convention as to how principals are named.
Generally, you will encounter three different types of principals.

  1. A principal without an instance. This is used for users, with the
     username being used as the principal name. Some examples:

     kenh@CMF.NRL.NAVY.MIL
     tytso@ATHENA.MIT.EDU

  2. A principal with a hostname for an instance. This is used to
     distinguish between the same service on different machines. Some
     examples:

     host/foo.bar.org@BAR.ORG
     ftp/blah.bar.org@BAR.ORG

  3. A principal with a unique instance that is not a hostname. For these
     principals the instance has other significance.

     krbtgt/BAR.ORG@BAR.ORG
     krbtgt/FOO.ORG@BAR.ORG

While the specification for Kerberos 5 allows more than two components, in
practice this is not used.

The two most important differences between Kerberos 4 principals and
Kerberos 5 principals are:

  1. The instance separator in Kerberos 4 is a period (.) where in Kerberos
     5 the instance separator is a forward slash (/).
  2. In principals where the hostname is used as the instance, the "short"
     hostname (without a domain name) is used as the instance for Kerberos
     4. In Kerberos 5, the fully qualified domain name is used as the
     instance.

------------------------------------------------------------

Subject: 1.10. How are realms named? Do they really have to be uppercase?

In theory, the realm name is arbitrary. You can call your realm whatever you
want.

However, in practice a Kerberos realm is named by uppercasing the DNS domain
name associated with the hosts in the to-be named realm. In other words, if
your hosts are all in the foo.org domain, you might call your Kerberos realm
FOO.ORG.

If you wish to have more than one Kerberos realm associated with the same
DNS domain name, the convention is to create realms that are in the same
hierarchy of your DNS domain name. For example, if you wish to have two
Kerberos realms in the DNS domain foo.org for Human Resources and Sales, you
might create the Kerberos realms HR.FOO.ORG and SALES.FOO.ORG.

The convention to use uppercase for realms names arose out of the desire to
easily distinguish between DNS domain names (which are actually
case-insensitive) and Kerberos realms. The Kerberos realm name is case
sensitive (the realm foo.org is different than the realm FOO.ORG). You are
not required to have an uppercase Kerberos realm, but I would strongly
advise it.

It is worth noting that the recent revisions to the Kerberos standard have
specified that uppercase realm names are preferred and lowercase realm names
have been depreciated.

------------------------------------------------------------

Subject: 1.11. What is ASN.1?

ASN.1 is short for Abstract Syntax Notation One. It is a notation for
describing abstract types and values. Using ASN.1, one can describe the
format of complex objects by putting together more simpler types.

However, ASN.1 does not specify how these objects are encoded into strings
of ones and zeros. For that, you must use a set of encoding rules. The two
most common encoding rules are the Basic Encoding Rules (BER) and the
Distinguished Encoding Rules (DER). The only difference between BER and DER
is that there are multiple ways to encode objects in the BER, but the DER is
a subset of the BER such that there is only one possible way to encode each
object.

Kerberos 5 uses ASN.1 and the DER to encode and decode all of the Kerberos
protocol messages. Unless you are planning on adding to the Kerberos
protocol itself, you don't really need to worry about ASN.1 at all.

If you wish to learn more about ASN.1, I would suggest reading:

   * Burton S. Kaliski Jr., "A Layman's Guide to a Subset of ASN.1, BER, and
     DER"
     
   * Brian Tung, "ASN.1: Wherefore Art Thou?"
     

------------------------------------------------------------

Subject: 1.12. I see the acronyms TGT and TGS used a lot. What do they mean?

TGT is the acronym for a "Ticket Granting Ticket".

TGS is the acronym for the "Ticket Granting Service".

While it may seen that the two acronyms are used interchangeably, they refer
to two very different things. The Ticket Granting Ticket is a Kerberos
ticket for the Ticket Granting Service. Both play a special role in
Kerberos.

When a user first authenticates to Kerberos, he talks to the Authentication
Service on the KDC to get a Ticket Granting Ticket. This ticket is encrypted
with the user's password.

When the user wants to talk to a Kerberized service, he uses the Ticket
Granting Ticket to talk to the Ticket Granting Service (which also runs on
the KDC). The Ticket Granting Service verifies the user's identity using the
Ticket Granting Ticket and issues a ticket for the desired service.

The reason the Ticket Granting Ticket exists is so a user doesn't have to
enter in their password every time they wish to connect to a Kerberized
service or keep a copy of their password around. If the Ticket Granting
Ticket is compromised, an attacker can only masquerade as a user until the
ticket expires.

The documentation in Question 1.4 explains all of this in further detail.

------------------------------------------------------------

Subject: 1.13. What is the export status of Kerberos?

This is a topic of much discussion, and it appears that there is no clear
answer. Your best bet is to contact a lawyer for a definitive answer. But if
you're willing to listen to "educated guesses", read on.

The recent US Government relaxation of export controls has caused much
discussion on this topic. The current belief is that under the new
regulations, Kerberos source code can be exported everywhere, except for the
so-called "T7" countries (countries that are defined by the US State
Department as being terrorist countries).

The definitive source for the exact regulations is the Bureau of Export
Administration, and their web site is at:


Specifically, if you look at the Encryption License Exemption Chart,


you can see that under "Unrestricted, encryption source code (open source
code)" that the only restriction is to not knowingly export to T7 countries.

The official response from MIT with respect to the export status of Kerberos
5 is that they have contacted their legal staff, and they have not yet given
them an answer.

However, Question 1.5 does list a non-US ftp site for Kerberos 5. The
legality of downloading Kerberos from this site is unknown.

------------------------------------------------------------

Subject: 1.14. What is a "Kerberos client", "Kerberos server", and
	"application server"?

In Kerberos, all authentication takes place between clients and servers. So
in Kerberos termology, a "Kerberos client" is any entity that gets a service
ticket for a Kerberos service. A client is typically a user, but any
principal can be a client (unless for some reason the administrator has
explicitly forbidden this principal to be a client).

The term "Kerberos server" generally refers to the Key Distribution Center,
or the KDC for short. The KDC implements the Authentication Service (AS) and
the Ticket Granting Service (TGS). The KDC has a copy of every password
associated with every principal. For this reason, it is absolutely vital
that the KDC be as secure as possible.

Most KDC implementations store the principals in a database, so you may hear
the term "Kerberos database" applied to the KDC.

For reliability purposes, it is possible to have backup KDCs. These are
referred to as slave servers. The slaves all synchronize their databases
from the master KDC.

In most Kerberos implementations there is also an administration server
which allows remote manipulation of the Kerberos database. This
administration server usually runs on the KDC.

The term "application server" generally refers to Kerberized programs that
clients communicate with using Kerberos tickets for authentication. For
example, the Kerberos telnet daemon (telnetd) is an example of an
application server.

------------------------------------------------------------

Subject: 1.15. I use software package , and it claims it supports
	Kerberos. What does that mean?

Unfortunately, "supporting Kerberos" can mean a number of things.

The most basic level of Kerberos support is verifying a plaintext password
against the Kerberos database. Depending on the application, this may or may
not be secure. For example, since the Unix xlock application is designed to
verify passwords and (hopefully) is only run from on your local workstation,
verifying passwords against a Kerberos database is perfectly adequate.
However, if you have a POP server that verifies the PASS command by checking
the password against a Kerberos database, that is NOT secure, because the
password will travel over the network in the clear.

There are different levels of password verification, however. Unless a
program that does plaintext password verification uses the acquired TGT to
get a service ticket for a locally trusted service (that is, with the key in
a keytab on local disk), then an attacker can spoof the client with a TGT
encrypted in a known password.

The next level of Kerberos support is a "true" Kerberized application that
uses Kerberos tickets to verify identity and/or encrypt data. This is the
way that Kerberos was designed to function, and it provides the highest
level of security that Kerberos has to offer. Unfortunately, relatively few
applications support Kerberos to this degree.

If you use an application that claims to support Kerberos, you should find
out exactly what this means and determine if that is appropriate for your
environment. If you use Kerberos primarily as a single-signon system, then
having a POP server that verifies plaintext passwords against a Kerberos
database may be acceptable to you.

All of the Unix replacement commands that come with the MIT Kerberos
distributions (telnet, ftp, rlogin, rsh, etc), are "true" Kerberized
applications.

------------------------------------------------------------

Subject: 1.16. What is cross-realm authentication?

Any Kerberos principal can authenticate to other principals within the same
Kerberos realm. However, it is also possible to configure a Kerberos realm
so principals in one realm can authenticate to principals in another realm.
This is called cross-realm authentication.

The way this is implemented is the KDCs in the two realms share a special
cross-realm secret, and this secret is used to prove the identity of
principals when crossing the boundary between realms.

Kerberos 5 supports an additional variant of this called transitive
cross-realm authentication. In traditional cross-realm authentication, each
pair of realms that wish to authenticate need to share a cross-realm secret.
This means in a group of N realms, 2 * ((N - 1) ** 2) secrets will need to
be exchanged in order to cover all possible cross-realm authentication
paths.

In transitive cross-realm authentication you can define a path of realms
connected via cross-realm secrets and use this path to "hop" between realms
until you get credentials in the desired realm.

Information on configuring cross-realm authentication can be found in the
answer to Question 2.15

------------------------------------------------------------

Subject: 1.17. Are there security risks involved in cross-realm
	authentication?

When you set up a cross-realm secret, you are in essence trusting the remote
KDC to only issue cross-realm tickets for the correct users. If you do not
trust the foreign KDC then all principals from the foreign realm are

Section 1 of 5 - Prev - Next
All sections - 1 - 2 - 3 - 4 - 5

© allanswers.org | Terms of use