PANA Working Group H. Tschofenig
Internet-Draft Siemens
Expires: January 10, 2005 V. Sankhla
University of Southern California
July 12, 2004
Bootstrapping Kerberos
draft-tschofenig-pana-bootstrap-kerberos-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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.
This Internet-Draft will expire on January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document proposes a mechanism to obtain a Kerberos Ticket
Granting Ticket based on a successful EAP authentication and key
agreement message exchange. The initial network access
authentication procedure based on EAP is ideal for this purpose.
This proposal allows Kerberos to be used within a local network
without relying on a global Kerberos infrastructure. It should allow
an incremental deployment of Kerberos and a wider distribution of
Kerberos into roaming environments.
Tschofenig & Sankhla Expires January 10, 2005 [Page 1]
Internet-Draft Bootstrapping Kerberos July 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Problem Statement . . . . . . . . . . . . . . . . . . . . . 5
4. Solution Approach . . . . . . . . . . . . . . . . . . . . . 6
5. What are the advantages? . . . . . . . . . . . . . . . . . . 11
6. What are the disadvanges? . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . 13
8. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1 Normative References . . . . . . . . . . . . . . . . . . . 17
10.2 Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . 20
Tschofenig & Sankhla Expires January 10, 2005 [Page 2]
Internet-Draft Bootstrapping Kerberos July 2004
1. Introduction
Kerberos (see [RFC1510] and
[I-D.ietf-krb-wg-kerberos-clarifications]) is a well-known security
protocol which provides authentication, authorization and key
distribution and is used to secure a number of protocols - a list too
large to mention here. It is widely deployed in enterprise networks
where cross-realm authentication is not required at all or only to a
certain extend (in a environment with a hierarchical organizational
structure). In mobility environments Kerberos is, unfortunately, not
widely deployed since AAA protocols (such as RADIUS and DIAMETER),
which have different cross-realm (or inter-domain) signaling message
exchanges, are heavily used. The security properties of AAA
protocols and Kerberos also differ. The EAP key management framework
is described in [I-D.ietf-eap-keying]. This proposal tries to
combine the two protocols: Kerberos is used within the local network
and the AAA protocol is used as part of the network access
authentication and for communication between the visited network and
the home network.
Tschofenig & Sankhla Expires January 10, 2005 [Page 3]
Internet-Draft Bootstrapping Kerberos July 2004
2. Terminology
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 [RFC2119].
Tschofenig & Sankhla Expires January 10, 2005 [Page 4]
Internet-Draft Bootstrapping Kerberos July 2004
3. Problem Statement
RADIUS [RFC2865] and DIAMETER [RFC3588] are used in an environment
where accounting and charging is an important functionality.
Kerberos was never designed to provide these features. Kerberos
provides cross-realm functionality in a way which is different to
EAP/AAA protocols. Even though the cross-realm authentication
approach used by Kerberos might provide better security properties
(such as denial of service protection) the EAP/AAA is gaining
importance.
By combining the functionality of AAA protocols (cross-realm/
inter-domain behavior, accounting functionality and the existing AAA
infrastructure) with the benefits of Kerberos (support by a number of
existing protocols, authorization capabilities, key distribution and
protection of messages) a number of advantages can be achieved.
Section 3.4.4 of [I-D.iab-research-funding] points to the importance
of providing solutions for inter-realm Kerberos deployments: 'The
need for scalable inter-domain user authentication is increasingly
acute as ad-hoc computing and mobile computing become more widely
deployed. Thus, work on scalable mechanisms for mobile, ad-hoc, and
non-hierarchical inter-domain authentication would be very helpful.'
Tschofenig & Sankhla Expires January 10, 2005 [Page 5]
Internet-Draft Bootstrapping Kerberos July 2004
4. Solution Approach
At its abstract level this proposal suggests to start with a regular
AAA communication which might inludes the usage of EAP
[I-D.ietf-eap-rfc2284bis]. EAP acts as a container for a number of
authentication and key agreement mechanisms. The AAA infrastructure
is used to route, to transport and to secure AAA messages and their
payloads. As a result of the network access authentication the user
is authenticated to its home AAA server (in the subscription based
scenario) and the AAA protocol is ready to exchange collected
accounting records. In addition to this exchange the visited network
(to which the user's device is attached) receives the gurantee
through the execution of the AAA protocol and the AAA infrastructure
(roaming agreements etc.) that the home network can be hold liable
for the payment for the consumed resources by the end user.
Subsequently to a successful authentication and authorization the AAA
protocol does not only transmit a session key to the AAA attendant
but also creates a Kerberos Ticket Granting Ticket (TGT). This TGT
is only valid for the local network and is sent to the end host. The
session key is only sent to the Authenticator and not to the end host
whereas the TGT has to be made available to the end host itself. A
protocol between the end host and the Authenticator is therefore
required to carry the TGT.
Using the obtained TGT the user is able to request further service
tickets using a standard Kerberos service ticket request. A user
might also request service tickets for various applications, to
secure infrastructure services (DHCP, SLP, DNS, etc.), to secure QoS
signaling protocols (see [RFC3182] for RSVP security based on
Kerberos) or might even request a service ticket to subsequently
execute KINK [I-D.ietf-kink-kink] for the purpose of establishing
IPsec security associations.
Figure 1 shows a typical message exchange executed when an end host
moves to a new network. First, in step (1) some sort of address
configuration procedure takes place. If the network access
authentication procedure is executed as part of the link layer
protocol as for example in IEEE 802.11 then address configuration is
executed after step (2). The network access procedure (2) might
require many roundtrips depending on the authentication and key
exchange protocol used. Finally, after a sucessful completion of the
protocol exchange a TGT is attached to the final message and send to
the end host in step (3). This requires an additional Radius/
Diameter attribute to carry the TGT from the local AAA server (if we
assume that it is created at the local AAA server), which is assumed
to be co-located with the Kerberos Authentication Server (labeled as
KDC in Figure 1). Co-locating these two entities is done mainly for
Tschofenig & Sankhla Expires January 10, 2005 [Page 6]
Internet-Draft Bootstrapping Kerberos July 2004
simplicity reasons since an additional protocol would be required for
commuication rather than an API call. The TGT must, additionally, be
sent from the AAA attendant to the end host. Subsequently Kerberos
service tickets can be requested using the standard Kerberos message
exchange (step (4)).
FOR DISCUSSION: Should we create
o a Ticket Granting Ticket which is sent to the end host or
o bootstrap a security association (and in particular a session key)
which is then used by the end host to request the Ticket Granting
Ticket.
The latter approach would not modify the inital TGT Kerberos
exchange. Further issues are discussed in Section 8.
EAP acts as a container for a number of authentication and key
exchange protocols. As such some observations have to be made
concerning the properties of the used mechanisms: Since the Ticket
Granting Ticket has to include the AAA distributed session key (key
field in the encrypted part of the ticket) this proposal requires an
EAP mechanism which provides session key distribution. This session
key is then used by the end host to create an Authenticator for a
subsequent service ticket requests.
Tschofenig & Sankhla Expires January 10, 2005 [Page 7]
Internet-Draft Bootstrapping Kerberos July 2004
+----+ +----------+ +------+ +----+
| | | AAA | |AAAL +| | |
|Host| | Attendant| | KDC | |AAAH|
+-+--+ +-----+----+ +--+---+ +-+--+
| | | |
+-----------------+ | | |
| Address | | | |
| Configuration | | | |
| Procedure (1) | | | |
+-----------------+ | | |
| | | |
+--+-------------------+----------------+----------------+--+
| | Network Access Authentication | |
| | and | |
| | Session key distribtion based on | |
| |<------------- successful authentication (2) ------>| |
| | | |
| | Ticket Granting Ticket | |
| | Delivery (3) | |
| |<-----------------------------------+ | |
| | | |
+--+-------------------+----------------+----------------+--+
| | | |
+-------------------+----------------+ |
| Standard Kerberos Service Ticket | |
| Request/Reply (TGS_REQ/TGS_REP) | (4) |
+-------------------+----------------+ |
| | | |
Figure 1: Message Flow
Figure 2 shows a Ticket Granting Ticket with the relevant fields.
The ticket consists of two parts - one unencrypted and an encrypted
part. The unencrypted part contains only information for the
recepient (in our case for the Ticket Granting Server) to be able to
recognize a ticket for which a key to decrypt the ticket is
available. In the described case these fields contain the ticket
version number, the realm name of the visited network and the
principal name of the Ticket Granting Server (TGS). The remaining
fields of the ticket are encrypted with the key known only to the TGS
and the Authentication Server (AS). Note that the AS is co-located
with the local AAA server in our scenario. The encrypted part of the
ticket contains information about the user's realm and its identity
which are obtained from the initial authentication procedure. The
flags field contains a flag which provides an indication of this
Kerberos bootstrapping procedure to differentiate it to a regular
AS_REQ/AS_REP exchange. The key field is important since it contains
the session key distributed during the initial authentication
Tschofenig & Sankhla Expires January 10, 2005 [Page 8]
Internet-Draft Bootstrapping Kerberos July 2004
procedure as described in Figure 1 in step (2). This session key is
subsequently only relevant for the TGS. For service authentication
between the end host and application servers and new service ticket
has to be requested from the TGS using a standard Kerberos TGS_REQ/
TGS_REP message exchange.
Note that a protocol is required to carry the EAP messages and the
TGT from the AAA attendant to the end host. Such a protocol is
required to exchange the necessary parameters. This document does
not mandate a particular protocol. However, PANA
[I-D.ietf-pana-pana] is suitable for this purpose since it is a
flexbile and extensible protocol and allows the secure exchange of
parameters between the end host and the network.
+-------------------------------------------------+
Unencrypted | Ticket Version Number |
part of | Realm that issued a ticket |
the ticket | Server's Principal Name (sname) |
+-------------------------------------------------+
| Flags |
| Key |
| Realm in which the client is registered (crealm)|
| Client's principal identifier (cname) |
Encrypted | Transited Realms |
part of | Time of initial authentication (authtime) |
the ticket | Starttime |
(with a key known | Endtime |
to the TGS) | Renew-till |
| Hostaddress(es) (caddr) |
| Authorization-data |
+-------------------------------------------------+
Figure 2: Ticket Granting Ticket Content
It is important to highlight that the proposal described in this
document makes an assumption which has to be satisified in order for
this bootstrapping mechanism to work:
The authentication and key exchange protocol shown in Figure 1 (step
2) assumes that a session key is distributed and after a successful
protocol execution established between the end host and the AAA
attendant. The session key distribution with the help of AAA also
allows the local AAA server to learn the session key. Since the
Ticket Granting Ticket requires a session key to be placed in the Key
field as shown in Figure 2. Hence authentication and key exchange
protocol which do not establish a session key between the end host
and the local network (AAA attendant/local AAA server) cannot be used
Tschofenig & Sankhla Expires January 10, 2005 [Page 9]
Internet-Draft Bootstrapping Kerberos July 2004
for bootstrapping a Kerberos Ticket Granting Ticket.
Additionally it should be noted that the proposed bootstrapping
protocol does not necessarily require the execution of a EAP
protocol. Protocols such as described in [I-D.perkins-aaav6], in
[I-D.mun-aaa-dbu-mobileipv6] and in [I-D.le-aaa-diameter-mobileipv6]
would also provide the desired functionality without relying on EAP
methods for authentication. Instead a custom authenthication and key
exchange protocol is defined. Even the protocols developed in the
SACRED working group would provide the necessary pre-requisity to
return a Ticket Granting Ticket and to use this proposal. To focus
on an increasingly common deployment environment we have focused on
EAP.
Tschofenig & Sankhla Expires January 10, 2005 [Page 10]
Internet-Draft Bootstrapping Kerberos July 2004
5. What are the advantages?
The authors think that this proposal has the following advantages:
o A large number of protocols support Kerberos as an authentication
and key distribution protocol. Enabling Kerberos to be used for
these environments would also enable these protocols to be secured
with Kerberos.
o Initial cross-realm/inter-domain authentication can be done using
an arbitrary protocol (in case of EAP).
o Kerberos relies on symmetric keys (ignoring PKINIT
[I-D.ietf-cat-kerberos-pk-init] and PKCROSS
[I-D.ietf-cat-kerberos-pk-cross]) for authentication and key
distribution. The usage of symmetric keys is highly efficient and
the risk of denial of service attacks often found in public key
based protocols is reduced.
o Kerberos tickets are designed to allow authorization information
to be added to the ticket itself. Authorization information can
be added by the KDC and allows services to base their access
control policies not only on the identity of the principal.
o When passwords are used with Kerberos (without PKINIT or other
mechanisms) then there might be a vulnerability to dictionary
attacks. Replacing the AS exchange with an EAP authentication
this vulnerability can be prevented. Note that this assumes that
the chosen EAP method is not vulnerable to dictionary attacks.
o Some EAP methods provide user identity confidentiality of the EAP
peer against either active or passive adversaries. If a Kerberos
Ticket Granting Ticket is created with the help of the EAP derived
key and the user identity is not copied to the Ticket Granting
Ticket then there is no indication for an eavesdropper about the
identity of a user. This approach therefore adds user identity
confidentiality to Kerberos.
Tschofenig & Sankhla Expires January 10, 2005 [Page 11]
Internet-Draft Bootstrapping Kerberos July 2004
6. What are the disadvanges?
Despite the advantages listed in the previous section there are some
disadvantages or constraints with the following proposal:
o A Kerberos implementation has to be supported by end hosts.
o Kerberos heavily relies on timestamps. If the clocks of the end
host and the various servers in the access network suffer from a
clock-drift then some procedure is required for clock-
synchronization. Such procedures are for example described
in[I-D.ietf-krb-wg-kerberos-clarifications]. It requires further
investigation whether a secure time distribution mechanism should
be included in this proposal.
Tschofenig & Sankhla Expires January 10, 2005 [Page 12]
Internet-Draft Bootstrapping Kerberos July 2004
7. Security Considerations
The security of the proposed mechanism relies on the selected EAP
mechanism, on Kerberos and on the AAA key distribution mechanism. A
security analysis of different EAP methods is outside the scope of
this document. It is assumed that the AAA key distribution
mechanism, the selected EAP method and Kerberos is secure.
Hence this section can only describe threats related to the proposed
distribution of the TGT.
Stealing of the TGT:
An adversary might eavesdrop on the wireless link between the end
host and the AAA attendant to learn the exchanged TGT. Without
confidentiality protection of the TGT an adversary might be able
to retrieve the TGT. Since the TGT is encrypted with the key of
the ticket granting server (TGS). It is assumed that this key has
sufficient length.This assures that an adversary is able to learn
the encrypted content of the ticket. Hence we can conclude that
an adversary might not be able to request further service tickets
only based on the knowledge of the ticket granting ticket. This
is inline with the basic principles of Kerberos.
Modification of the TGT:
An adversary might want to modify the content of the TGT. A TGS
would immediately detect such a modification because most parts of
the ticket are encrypted. The unencrypted parts only contain
information about the TGS and its realm and are useless for an
adversary.
Replay of the TGT:
An adverary (malicious end host) might want to reuse a TGT of a
previous message exchange. Since the TGT contains a lifetime
field it is not possible to use TGTs with an expired lifetime. In
order to request a service ticket the end host has to know the
session key to build an Authenticator.
Tschofenig & Sankhla Expires January 10, 2005 [Page 13]
Internet-Draft Bootstrapping Kerberos July 2004
8. Open Issues
This section lists some open issues which have been identified during
the work on this approach:
o Packet formats (e.g., AAA AVP, PANA AVPs, etc.) are missing.
o As an alternative to provide the end host (i.e., user) with a TGT
it would be possible to create a tentaive user account at the KDC.
This allows the end host to request a TGT and subsequently service
tickets. This approach would not require a TGT to be transferred
to the end host with the initial AAA exchange.
o In order to provide a service ticket to run KINK for achieving
secure network access an additional roundtrip is required.
Solutions are possible which allow the establishment of an IPsec
security association with a fewer number of roundtrips.
o Should it be possible to request more than a TGT (for example a
service ticket for secure network access) with the help of this
proposal?
o It might be helpful to have a flag inside the ticket to indicate
that the ticket presented to a server was not obtained by a
regular AS exchange but rather with this bootstapping mechanism.
o It would also be possible to provide the client with a secure
network time by protecting the timestamp as part of a PANA
exchange.
o Should the proposed extension return a full AS_REP instead of only
the TGT? This would allow the end host to learn the current time
based on the information inside the ticket. The TGT also contains
time information but it is not accessible for the end host (i.e.
it is included in the encrypted part).
o In this proposal the TGT is created at the local AAA server.
Therefore the local AAA server needs to wait until a succuessful
network access authentication indication is available. The
EAP-Success message indicates a succesful EAP method protocol run.
Hence, it is necessary for the AAA server to bind the EAP run to
the TGT. Furthermore, the local AAA server needs to inspect the
session key transferred with the AAA attribute in order to create
the TGT. More details need to be provided. It might be possible
to create the TGT at the Authenticator itself rather than in the
local AAA server. This would, however, cause an increase in the
number of entities which need to be trusted by the KDC.
Tschofenig & Sankhla Expires January 10, 2005 [Page 14]
Internet-Draft Bootstrapping Kerberos July 2004
o Finally, it might be possible to replace this entire bootstrapping
mechanism with a new AS_REQ/AS_REP protocol exchange which uses
EAP. This exchange could use EAP and the KDC would act as the
Authenticator in the EAP architecture. The main advantage of this
approach is achieved by protocol separation. A full EAP roundtrip
might not be required since the local AAA server might have stored
the session key of the previous protocol run already.
o Some discussions with regard to the EAP keying framework should go
in Section 7. A future version of this document will contain a
formal verification of the proposed approach.
o The relationship with the work done in the 3GPP Bootstrapping
architecture and the SACRED work needs to be described.
Tschofenig & Sankhla Expires January 10, 2005 [Page 15]
Internet-Draft Bootstrapping Kerberos July 2004
9. Acknowledgments
We would like to thank Guenther Horn, Dirk Kroeselberg and Wolfgang
Buecker for their comments to this draft.
Furthermore, Hannes Tschofenig would like to thank Derek Atkins for
discussions with an older version of this draft (more than a year
ago).
Jorge Cuellar encourage us to publish this document.
Tschofenig & Sankhla Expires January 10, 2005 [Page 16]
Internet-Draft Bootstrapping Kerberos July 2004
10. References
10.1 Normative References
[I-D.ietf-eap-rfc2284bis]
Blunk, L., Carlson, J. and B. Aboba, "Extensible
Authentication Protocol (EAP)",
draft-ietf-eap-rfc2284bis-09 (work in progress), February
2004, <reference.I-D.ietf-eap-rfc2284bis.xml>.
[I-D.ietf-pana-pana]
Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A.
Yegin, "Protocol for Carrying Authentication for Network
Access (PANA)", draft-ietf-pana-pana-04 (work in
progress), May 2004, <reference.I-D.ietf-pana-pana.xml>.
[RFC1510] Kohl, J. and B. Neuman, "The Kerberos Network
Authentication Service (V5)", RFC 1510, September 1993,
<reference.RFC.1510.xml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J.
Arkko, "Diameter Base Protocol", RFC 3588, September 2003,
<reference.RFC.3588.xml>.
10.2 Informative References
[I-D.iab-research-funding]
Atkinson, R. and S. Floyd, "IAB Concerns & Recommendations
Regarding Internet Research & Evolution",
draft-iab-research-funding-03 (work in progress), May
2004, <reference.I-D.iab-research-funding.xml>.
[I-D.ietf-cat-kerberos-pk-cross]
Tsudik, G., Neuman, C., Sommerfeld, B., Tung, B., Hur, M.,
Ryutov, T. and A. Medvinsky, "Public Key Cryptography for
Cross-Realm Authentication in Kerberos",
draft-ietf-cat-kerberos-pk-cross-08 (work in progress),
November 2001,
<reference.I-D.ietf-cat-kerberos-pk-cross.xml>.
[I-D.ietf-cat-kerberos-pk-init]
Tschofenig & Sankhla Expires January 10, 2005 [Page 17]
Internet-Draft Bootstrapping Kerberos July 2004
Tung, B., Neuman, C., Hur, M., Medvinsky, A., Medvinsky,
S., Wray, J. and J. Trostle, "Public Key Cryptography for
Initial Authentication in Kerberos",
draft-ietf-cat-kerberos-pk-init-19 (work in progress),
April 2004, <reference.I-D.ietf-cat-kerberos-pk-init.xml>.
[I-D.ietf-eap-keying]
Aboba, B., "EAP Key Management Framework",
draft-ietf-eap-keying-01 (work in progress), October 2003,
<reference.I-D.ietf-eap-keying.xml>.
[I-D.ietf-kink-kink]
Thomas, M. and J. Vilhuber, "Kerberized Internet
Negotiation of Keys (KINK)", draft-ietf-kink-kink-05 (work
in progress), January 2003,
<reference.I-D.ietf-kink-kink.xml>.
[I-D.ietf-krb-wg-kerberos-clarifications]
Neuman, C., "The Kerberos Network Authentication Service
(V5)", draft-ietf-krb-wg-kerberos-clarifications-05 (work
in progress), February 2004,
<reference.I-D.ietf-krb-wg-kerberos-clarifications.xml>.
[I-D.le-aaa-diameter-mobileipv6]
Faccin, S., "Diameter Mobile IPv6 Application",
draft-le-aaa-diameter-mobileipv6-03 (work in progress),
April 2003,
<reference.I-D.le-aaa-diameter-mobileipv6.xml>.
[I-D.mun-aaa-dbu-mobileipv6]
Kim, M. and Y. Mun, "Dynamic Binding Update using AAA",
draft-mun-aaa-dbu-mobileipv6-00 (work in progress),
December 2002, <reference.I-D.mun-aaa-dbu-mobileipv6.xml>.
[I-D.perkins-aaav6]
Perkins, C., Flykt, P. and T. Eklund, "AAA for IPv6
Network Access", draft-perkins-aaav6-06 (work in
progress), May 2003, <reference.I-D.perkins-aaav6.xml>.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S. and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001, <reference.RFC.3182.xml>.
Tschofenig & Sankhla Expires January 10, 2005 [Page 18]
Internet-Draft Bootstrapping Kerberos July 2004
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Vishal Sankhla
University of Southern California
1860N, Fuller Avenue, Apt 117
Los Angeles, California 90046
USA
EMail: sankhla@usc.edu
Tschofenig & Sankhla Expires January 10, 2005 [Page 19]
Internet-Draft Bootstrapping Kerberos July 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig & Sankhla Expires January 10, 2005 [Page 20]