726 lines
28 KiB
Plaintext
726 lines
28 KiB
Plaintext
|
|
|
|
Kerberos Working Group M. Swift
|
|
Internet Draft University of WA
|
|
Document: draft-ietf-krb-wg-kerberos-referrals-00.txt J. Brezak
|
|
Category: Standards Track Microsoft
|
|
J. Trostle
|
|
Cisco Systems
|
|
K. Raeburn
|
|
MIT
|
|
February 2001
|
|
|
|
|
|
Generating KDC Referrals to locate Kerberos realms
|
|
|
|
|
|
Status of this Memo
|
|
|
|
This document is an Internet-Draft and is in full conformance with
|
|
all provisions of Section 10 of RFC2026 [1].
|
|
|
|
Internet-Drafts are working documents of the Internet Engineering
|
|
Task Force (IETF), its areas, and its working groups. Note that
|
|
other groups may also distribute working documents as Internet-
|
|
Drafts. Internet-Drafts are draft documents valid for a maximum of
|
|
six months and may be updated, replaced, or obsoleted by other
|
|
documents at any time. It is inappropriate to use Internet- Drafts
|
|
as reference material or to cite them other than as "work in
|
|
progress."
|
|
|
|
The list of current Internet-Drafts can be accessed at
|
|
http://www.ietf.org/ietf/1id-abstracts.txt
|
|
The list of Internet-Draft Shadow Directories can be accessed at
|
|
http://www.ietf.org/shadow.html.
|
|
|
|
1. Abstract
|
|
|
|
The draft documents a new method for a Kerberos Key Distribution
|
|
Center (KDC) to respond to client requests for kerberos tickets when
|
|
the client does not have detailed configuration information on the
|
|
realms of users or services. The KDC will handle requests for
|
|
principals in other realms by returning either a referral error or a
|
|
cross-realm TGT to another realm on the referral path. The clients
|
|
will use this referral information to reach the realm of the target
|
|
principal and then receive the ticket.
|
|
|
|
2. Conventions used in this document
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
|
|
this document are to be interpreted as described in RFC-2119 [2].
|
|
|
|
3. Introduction
|
|
|
|
|
|
|
|
|
|
Swift Category - Standards Track 1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
Current implementations of the Kerberos AS and TGS protocols, as
|
|
defined in RFC 1510 [3], use principal names constructed from a
|
|
known user or service name and realm. A service name is typically
|
|
constructed from a name of the service and the DNS host name of the
|
|
computer that is providing the service. Many existing deployments of
|
|
Kerberos use a single Kerberos realm where all users and services
|
|
would be using the same realm. However in an environment where there
|
|
are multiple trusted Kerberos realms, the client needs to be able to
|
|
determine what realm a particular user or service is in before
|
|
making an AS or TGS request. Traditionally this requires client
|
|
configuration to make this possible.
|
|
|
|
When having to deal with multiple trusted realms, users are forced
|
|
to know what realm they are in before they can obtain a ticket
|
|
granting ticket (TGT) with an AS request. However, in many cases the
|
|
user would like to use a more familiar name that is not directly
|
|
related to the realm of their Kerberos principal name. A good
|
|
example of this is an RFC-822 style email name. This document
|
|
describes a mechanism that would allow a user to specify a user
|
|
principal name that is an alias for the user's Kerberos principal
|
|
name. In practice this would be the name that the user specifies to
|
|
obtain a TGT from a Kerberos KDC. The user principal name no longer
|
|
has a direct relationship with the Kerberos principal or realm. Thus
|
|
the administrator is able to move the user's principal to other
|
|
realms without the user having to know that it happened.
|
|
|
|
Once a user has a TGT, they would like to be able to access services
|
|
in any trusted Kerberos realm. To do this requires that the client
|
|
be able to determine what realm the target service's host is in
|
|
before making the TGS request. Current implementations of Kerberos
|
|
typically have a table that maps DNS host names to corresponding
|
|
Kerberos realms. In order for this to work on the client, each
|
|
application canonicalizes the host name of the service by doing a
|
|
DNS lookup followed by a reverse lookup using the returned IP
|
|
address. The returned primary host name is then used in the
|
|
construction of the principal name for the target service. In order
|
|
for the correct realm to be added for the target host, the mapping
|
|
table [domain_to_realm] is consulted for the realm corresponding to
|
|
the DNS host name. The corresponding realm is then used to complete
|
|
the target service principal name.
|
|
|
|
This traditional mechanism requires that each client have very
|
|
detailed configuration information about the hosts that are
|
|
providing services and their corresponding realms. Having client
|
|
side configuration information can be very costly from an
|
|
administration point of view - especially if there are many realms
|
|
and computers in the environment.
|
|
|
|
Current implementations of Kerberos also have difficulty with
|
|
services on hosts that can have multiple host names (multi-homed
|
|
hosts). Traditionally, each host name would need to have a distinct
|
|
principal and a corresponding key. An extreme example of this would
|
|
be a Web server with multiple host names for each domain that it is
|
|
|
|
Swift Category - Standards Track 2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
supporting. Principal aliases allow multi-homed hosts to have a
|
|
single Kerberos principal (with a single key) that can have
|
|
identities for each distinct host name. This mechanism allows the
|
|
Kerberos client to request a service ticket for the distinct
|
|
hostname and allows the KDC to return a ticket for the single
|
|
principal that the host is using. This canonical principal name
|
|
allows the host to only have to manage a single key for all of the
|
|
identities that it supports. In addition, the client only needs to
|
|
know the realm of the canonical service name, not all of the
|
|
identities.
|
|
|
|
This draft proposes a solution for these problems and simplifies
|
|
administration by minimizing the configuration information needed on
|
|
each computer using Kerberos. Specifically it describes a mechanism
|
|
to allow the KDC to handle Canonicalization of names, provide for
|
|
principal aliases for users and services and provide a mechanism for
|
|
the KDC to determine the trusted realm authentication path by being
|
|
able to generate referrals to other realms in order to locate
|
|
principals.
|
|
|
|
To rectify these problems, this draft introduces three new kinds of
|
|
KDC referrals:
|
|
|
|
1. AS ticket referrals, in which the client doesn't know which realm
|
|
contains a user account.
|
|
2. TGS ticket referrals, in which the client doesn't know which
|
|
realm contains a server account.
|
|
3. Cross realm shortcut referrals, in which the KDC chooses the next
|
|
path on a referral chain
|
|
|
|
4. Realm Organization Model
|
|
|
|
This draft assumes that the world of principals is arranged on
|
|
multiple levels: the realm, the enterprise, and the world. A KDC may
|
|
issue tickets for any principal in its realm or cross-realm tickets
|
|
for realms with which it has a direct trust relationship. The KDC
|
|
also has access to a trusted name service that can resolve any name
|
|
from within its enterprise into a realm. This trusted name service
|
|
removes the need to use an untrusted DNS lookup for name resolution.
|
|
|
|
For example, consider the following configuration, where lines
|
|
indicate trust relationships:
|
|
|
|
MS.COM
|
|
/ \
|
|
/ \
|
|
OFFICE.MS.COM NT.MS.COM
|
|
|
|
In this configuration, all users in the MS.COM enterprise could have
|
|
a principal name such as alice@MS.COM, with the same realm portion.
|
|
In addition, servers at MS.COM should be able to have DNS host names
|
|
from any DNS domain independent of what Kerberos realm their
|
|
principal resides in.
|
|
|
|
Swift Category - Standards Track 3
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
|
|
5. Principal Names
|
|
|
|
5.1 Service Principal Names
|
|
|
|
The standard Kerberos model in RFC 1510 [3] gives each Kerberos
|
|
principal a single name. However, if a service is reachable by
|
|
several addresses, it is useful for a principal to have multiple
|
|
names. Consider a service running on a multi-homed machine. Rather
|
|
than requiring a separate principal and password for each name it
|
|
exports, a single account with multiple names could be used.
|
|
|
|
Multiple names are also useful for services in that clients need not
|
|
perform DNS lookups to resolve a host name into a full DNS address.
|
|
Instead, the service may have a name for each of its supported host
|
|
names, including its IP address. Nonetheless, it is still convenient
|
|
for the service to not have to be aware of all these names. Thus a
|
|
new name may be added to DNS for a service by updating DNS and the
|
|
KDC database without having to notify the service. In addition, it
|
|
implies that these aliases are globally unique: they do not include
|
|
a specifier dictating what realm contains the principal. Thus, an
|
|
alias for a server is of the form "class/instance/name" and may be
|
|
transmitted as any name type.
|
|
|
|
5.2 Client Principal Names
|
|
|
|
Similarly, a client account may also have multiple principal names.
|
|
More useful, though, is a globally unique name that allows
|
|
unification of email and security principal names. For example, all
|
|
users at MS may have a client principal name of the form
|
|
"joe@MS.COM" even though the principals are contained in multiple
|
|
realms. This global name is again an alias for the true client
|
|
principal name, which is indicates what realm contains the
|
|
principal. Thus, accounts "alice" in the realm ntdev.MS.COM and
|
|
"bob" in office.MS.COM may logon as "alice@MS.COM" and "bob@MS.COM".
|
|
This requires a new client principal name type, as the AS-REQ
|
|
message only contains a single realm field, and the realm portion of
|
|
this name doesn't correspond to any Kerberos realm. Thus, the entire
|
|
name "alice@MS.COM" is transmitted in the client name field of the
|
|
AS-REQ message, with a name type of KRB-NT-ENTERPRISE-PRINCIPAL.
|
|
|
|
KRB-NT-ENTERPRISE-PRINCIPAL 10
|
|
|
|
5.3 Name Canonicalization
|
|
|
|
In order to support name aliases, the Kerberos client must
|
|
explicitly request the name-canonicalization KDC option (bit 15) in
|
|
the ticket flags for the TGS-REQ. This flag indicates to the KDC
|
|
that the client is prepared to receive a reply with a different
|
|
client or server principal name than the request. Thus, the
|
|
KDCOptions types is redefined as:
|
|
|
|
KDCOptions ::= BIT STRING {
|
|
|
|
Swift Category - Standards Track 4
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
reserved(0),
|
|
forwardable(1),
|
|
forwarded(2),
|
|
proxiable(3),
|
|
proxy(4),
|
|
allow-postdate(5),
|
|
postdated(6),
|
|
unused7(7),
|
|
renewable(8),
|
|
unused9(9),
|
|
unused10(10),
|
|
unused11(11),
|
|
name-canonicalize(15),
|
|
renewable-ok(27),
|
|
enc-tkt-in-skey(28),
|
|
renew(30),
|
|
validate(31)
|
|
}
|
|
|
|
6. Client Referrals
|
|
|
|
The simplest form of ticket referral is for a user requesting a
|
|
ticket using an AS-REQ. In this case, the client machine will send
|
|
the AS request to a convenient trusted realm, either the realm of
|
|
the client machine or the realm of the client name. In the case of
|
|
the name Alice@MS.COM, the client may optimistically choose to send
|
|
the request to MS.COM.
|
|
|
|
The client will send the string "alice@MS.COM" in the client
|
|
principal name field using the KRB-NT-ENTERPRISE-PRINCIPAL name type
|
|
with the crealm set to MS.COM. The KDC will try to lookup the name
|
|
in its local account database. If the account is present in the
|
|
crealm of the request, it MUST return a KDC reply structure with the
|
|
appropriate ticket. If the account is not present in the crealm
|
|
specified in the request and the name-canonicalize flag in the
|
|
KDCoptions is set, the KDC will try to lookup the entire name,
|
|
Alice@MS.COM, using a name service. If this lookup is unsuccessful,
|
|
it MUST return the error KDC_ERR_C_PRINCIPAL_UNKNOWN. If the lookup
|
|
is successful, it MUST return an error KDC_ERR_WRONG_REALM (0x44)
|
|
and in the error message the cname and crealm field MUST contain the
|
|
client name and the true realm of the client. If the KDC contains
|
|
the account locally, it MUST return a normal ticket. The client name
|
|
and realm portions of the ticket and KDC reply message MUST be the
|
|
client's true name in the realm, not the globally unique name.
|
|
|
|
If the client receives a KDC_ERR_WRONG_REALM error, it will issue a
|
|
new AS request with the same client principal name used to generate
|
|
the first referral to the realm specified by the crealm field of the
|
|
kerberos error message from the first request. This request MUST
|
|
produce a valid AS response with a ticket for the canonical user
|
|
name. The ticket MUST also include the ticket extension containing
|
|
the TE-REFERRAL-DATA with the referred-names set to the name from
|
|
|
|
|
|
Swift Category - Standards Track 5
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
the AS request. Any other error or referral will terminate the
|
|
request and result in a failed AS request.
|
|
|
|
7. Server Referrals
|
|
|
|
The server referral mechanism is a bit more complex than the client
|
|
referral mechanism. The primary problem is that the KDC must return
|
|
a referral ticket rather than an error message, so it will include
|
|
in the TGS response information about what realm contains the
|
|
service. This is done by returning information about the server name
|
|
in the pre-auth data field of the KDC reply.
|
|
|
|
If the KDC resolves the server principal name into a principal in
|
|
its realm, it may return a normal ticket. If the name-canonicalize
|
|
flag in the KDCoptions is not set, then the KDC MUST only look up
|
|
the name as a normal principal name. Otherwise, it MUST search all
|
|
aliases as well. The server principal name in both the ticket and
|
|
the KDC reply MUST be the true server principal name instead of one
|
|
of the aliases. This frees the application server from needing to
|
|
know about all its aliases.
|
|
|
|
If the name-canonicalize flag in the KDCoptions is set and the KDC
|
|
doesn't find the principal locally, the KDC can return a cross-realm
|
|
ticket granting ticket to the next hop on the trust path towards a
|
|
realm that may be able to resolve the principal name.
|
|
|
|
If the KDC can determine the service principal's realm, it can
|
|
return the server realm as ticket extension data. The ticket
|
|
extension MUST be encrypted using the session key from the ticket,
|
|
and the same etype as is used to protect the TGS reply body.
|
|
|
|
The data itself is an ASN.1 encoded structure containing the
|
|
server's realm, and if known, canonical principal name and alias
|
|
names. The first name in the sequence is the canonical principal
|
|
name.
|
|
|
|
TE-REFERRAL-INFO 20
|
|
|
|
TE-REFERRAL-DATA ::= SEQUENCE {
|
|
referred-server-realm[0] KERB-REALM
|
|
referred-names[1] SEQUENCE OF
|
|
PrincipalNames OPTIONAL
|
|
}
|
|
|
|
|
|
The client can use this information to request a chain of cross-
|
|
realm ticket granting tickets until it reaches the realm of the
|
|
server, and can then expect to receive a valid service ticket.
|
|
|
|
In order to facilitate cross-realm interoperability, a client SHOULD
|
|
NOT send short names in TGS requests to the KDC. A short name is
|
|
defined as a Kerberos name that includes a DNS name that is not
|
|
fully qualified. The client MAY use forward DNS lookups to obtain
|
|
|
|
Swift Category - Standards Track 6
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
the long name that corresponds to the user entered short name (the
|
|
short name will be a prefix of the corresponding long name).
|
|
|
|
The client may use the referred-names field to tell if it already
|
|
has a ticket to the server in its ticket cache.
|
|
|
|
The client can use this information to request a chain of cross-
|
|
realm ticket granting tickets until it reaches the realm of the
|
|
server, and can then expect to receive a valid service ticket.
|
|
However an implementation should limit the number of referrals that
|
|
it processes to avoid infinite referral loops. A suggested limit is
|
|
5 referrals before giving up.
|
|
|
|
8. Cross Realm Routing
|
|
|
|
The current Kerberos protocol requires the client to explicitly
|
|
request a cross-realm TGT for each pair of realms on a referral
|
|
chain. As a result, the client machines need to be aware of the
|
|
trust hierarchy and of any short-cut trusts (those that aren't
|
|
parent-child trusts). This requires more configurations on the
|
|
client. Instead, the client should be able to request a TGT to the
|
|
target realm from each realm on the route. The KDC will determine
|
|
the best path for the client and return a cross-realm TGT. The
|
|
client has to be aware that a request for a cross-realm TGT may
|
|
return a TGT for a realm different from the one requested.
|
|
|
|
9. Security Considerations
|
|
|
|
The original Kerberos specification stated that the server principal
|
|
name in the KDC reply was the same as the server name in the
|
|
request. These protocol changes break that assumption, so the client
|
|
may be vulnerable to a denial of service attack by an attacker that
|
|
replays replies from previous requests. It can verify that the
|
|
request was one of its own by checking the client-address field or
|
|
authtime field, though, so the damage is limited and detectable.
|
|
|
|
For the AS exchange case, it is important that the logon mechanism
|
|
not trust a name that has not been used to authenticate the user.
|
|
For example, the name that the user enters as part of a logon
|
|
exchange may not be the name that the user authenticates as, given
|
|
that the KDC_ERR_WRONG_REALM error may have been returned. The
|
|
relevant Kerberos naming information for logon (if any), is the
|
|
client name and client realm in the service ticket targeted at the
|
|
workstation that was obtained using the user's initial TGT.
|
|
|
|
How the client name and client realm is mapped into a local account
|
|
for logon is a local matter, but the client logon mechanism MUST use
|
|
additional information such as the client realm and/or authorization
|
|
attributes from the service ticket presented to the workstation by
|
|
the user, when mapping the logon credentials to a local account on
|
|
the workstation.
|
|
|
|
10. Discussion
|
|
|
|
Swift Category - Standards Track 7
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
|
|
This section contains issues and suggestions that need to be
|
|
incorporated into this draft. From Ken Raeburn [raeburn@mit.edu]:
|
|
|
|
1) No means to do name canonicalization if you're not
|
|
authenticating. Is it okay to require credentials in order to do
|
|
canonicalization? If so, how about this: Send a TGS_REQ for the
|
|
service name you have. If you get back a TGS_REP for a service,
|
|
great; pull out the name and throw out the credentials. If you
|
|
get back a TGS_REP for a TGT service, ask again in the specified
|
|
realm. If you get back a KRB_ERROR because policy prohibits you
|
|
from authenticating to that service, we can add to the
|
|
specification that the {realm,sname} in the KRB_ERROR must be the
|
|
canonical name, and the checksum must be used. As long as the
|
|
checksum is present, it's still a secure exchange with the KDC.
|
|
|
|
If we have to be able to do name canonicalization without any
|
|
sort of credentials, either client-side (tickets) or server-side
|
|
(tickets automatically acquired via service key), I think we just
|
|
lose. But maybe GSSAPI should be changed if that's the case.
|
|
|
|
2) Can't refer to another realm and specify a different service name
|
|
to give to that realm's KDC. The local KDC can tell you a
|
|
different service name or a different realm name, but not both.
|
|
This comes up in the "gnuftp.raeburn.org CNAME ftp.gnu.org" type
|
|
of case I've mentioned.
|
|
|
|
Except ... the KDC-REP structure includes padata and ticket
|
|
extensions fields that are extensible. We could add a required
|
|
value to one of them -- perhaps only in the case where you return
|
|
a TGT when not asked -- that contains signed information about
|
|
the principal name to ask for in the other realm. (It would have
|
|
to be required, otherwise a man-in-the-middle could make it go
|
|
away.) Signing would be done using the session key for the TGS.
|
|
|
|
3) Secure canonicalization of service name in AS_REQ. If the
|
|
response is an AS_REP, we need a way to tell that the altered
|
|
server name wasn't a result of a MITM attack on the AS_REQ
|
|
message. Again, the KDC-REP extensible fields could have a new
|
|
required value added when name canonicalization happens,
|
|
indicating what the original principal name (in the AS_REQ
|
|
message) was, and signed using the same key as protects the
|
|
AS_REP. If it doesn't match what the client requested, the
|
|
messages were altered in transit.
|
|
|
|
4) Client name needs referral to another realm, and server name
|
|
needs canonicalization of some sort. The above fixes wouldn't
|
|
work for this case, and I'm not even sure which KDC should be
|
|
doing the canonicalization anyways.
|
|
|
|
|
|
The other-principal-name datum would probably look something like:
|
|
|
|
|
|
Swift Category - Standards Track 8
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
PrincipalAndNonce ::= SEQUENCE {
|
|
name[0] PrincipalName,
|
|
nonce[1] INTEGER -- copied from KDC_REQ
|
|
}
|
|
SignedPrincipal ::= SEQUENCE {
|
|
name-and-nonce[0] PrincipalAndNonce,
|
|
cksum[1] Checksum
|
|
}
|
|
{PA,TE}-ORIGINAL-SERVER-PRINCIPAL ::= SignedPrincipal
|
|
{PA,TE}-REMOTE-SERVER-PRINCIPAL ::= SignedPrincipal
|
|
|
|
with the checksum computed over the encoding of the 'name-and-nonce'
|
|
field, and appropriate PA- or TE- numbers assigned. I don't have a
|
|
strong opinion on whether it'd be a pa-data or ticket extension;
|
|
conceptually it seems like an abuse of either, but, well, I think
|
|
I'd rather abuse them than leave the facility both in and
|
|
inadequate.
|
|
|
|
The nonce is needed because multiple exchanges may be made with the
|
|
same key, and these extension fields aren't packed in with the other
|
|
encrypted data in the same response, so a MITM could pick apart
|
|
multiple messages and mix-and-match components. (In a TGS_REQ
|
|
exchange, a subsession key would help, but it's not required.)
|
|
|
|
The extension field would be required to prevent a MITM from
|
|
discarding the field from a response; a flag bit in a protected part
|
|
of the message (probably in 'flags' in EncKDCRepPart) could also let
|
|
us know of a cases where the information can be omitted, namely,
|
|
when no name change is done. Perhaps the bit should be set to
|
|
indicate that a name change *was* done, and clear if it wasn't,
|
|
making the no-change case more directly compatible with RFC1510.
|
|
|
|
11. References
|
|
|
|
|
|
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
|
|
9, RFC 2026, October 1996.
|
|
|
|
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
|
Levels", BCP 14, RFC 2119, March 1997
|
|
|
|
3 Kohl, J., Neuman, C., "The Kerberos Network Authentication
|
|
Service (V5)", RFC 1510, September 1993
|
|
|
|
|
|
12. Author's Addresses
|
|
|
|
Michael Swift
|
|
University of Washington
|
|
Seattle, Washington
|
|
Email: mikesw@cs.washington.edu
|
|
|
|
John Brezak
|
|
|
|
Swift Category - Standards Track 9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
Microsoft
|
|
One Microsoft Way
|
|
Redmond, Washington
|
|
Email: jbrezak@Microsoft.com
|
|
|
|
Jonathan Trostle
|
|
Cisco Systems
|
|
170 W. Tasman Dr.
|
|
San Jose, CA 95134
|
|
Email: jtrostle@cisco.com
|
|
|
|
Kenneth Raeburn
|
|
Massachusetts Institute of Technology 77
|
|
Massachusetts Avenue
|
|
Cambridge, Massachusetts 02139
|
|
Email: raeburn@mit.edu
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Swift Category - Standards Track 10
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
KDC Referrals February 2001
|
|
|
|
|
|
Full Copyright Statement
|
|
|
|
Copyright (C) The Internet Society (1999). All Rights Reserved.
|
|
|
|
This document and translations of it may be copied and furnished to
|
|
others, and derivative works that comment on or otherwise explain it
|
|
or assist in its implementation may be prepared, copied, published
|
|
and distributed, in whole or in part, without restriction of any
|
|
kind, provided that the above copyright notice and this paragraph
|
|
are included on all such copies and derivative works. However, this
|
|
document itself may not be modified in any way, such as by removing
|
|
the copyright notice or references to the Internet Society or other
|
|
Internet organizations, except as needed for the purpose of
|
|
developing Internet standards in which case the procedures for
|
|
copyrights defined in the Internet Standards process must be
|
|
followed, or as required to translate it into languages other than
|
|
English.
|
|
|
|
The limited permissions granted above are perpetual and will not be
|
|
revoked by the Internet Society or its successors or assigns.
|
|
|
|
This document and the information contained herein is provided on an
|
|
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
|
|
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
|
|
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
|
|
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
|
|
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Swift Category - Standards Track 11
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|