oysteikt/heimdal
0
0
Fork 0
Code Issues 5 Pull Requests Releases Activity

x

Browse Source 
git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@18995 ec53bebd-3082-4978-b11e-865c3cabbd6b
This commit is contained in:
Love Hörnquist Åstrand
2006-11-12 17:00:26 +00:00
parent 7ee6102353
commit eed9f58be4
7 changed files with 11801 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1830
doc/standardisation/draft-ietf-krb-wg-preauth-framework-04.txt Normal file
View File

File diff suppressed because it is too large Load Diff

6217
doc/standardisation/draft-ietf-krb-wg-rfc1510ter-03.txt Normal file
View File

File diff suppressed because it is too large Load Diff

447
doc/standardisation/draft-josefsson-kerberos5-starttls-00.txt Normal file
View File

@@ -0,0 +1,447 @@
Network Working Group S. Josefsson
Internet-Draft November 13, 2004
Expires: May 14, 2005
Using Transport Layer Security (TLS) with Kerberos 5
draft-josefsson-kerberos5-starttls-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 May 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document specify how the Transport Layer Security (TLS) protocol
is used in conjunction with the Kerberos 5 protocol.
Josefsson Expires May 14, 2005 [Page 1]
Internet-Draft Using TLS with Kerberos 5 November 2004
Table of Contents
1. Introduction and Background . . . . . . . . . . . . . . . . . 3
2. Extension Mechanism for TCP/IP transport . . . . . . . . . . . 4
3. Kerberos 5 STARTTLS Extension . . . . . . . . . . . . . . . . 4
3.1 STARTTLS requested by client (extension 1) . . . . . . . . 4
3.2 STARTTLS request accepted by server (extension 2) . . . . 5
3.3 Proceeding after successful TLS negotiation . . . . . . . 5
3.4 Proceeding after failed TLS negotiation . . . . . . . . . 5
3.5 STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . 5
3.6 Initial Authentication via TLS . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1 Normative References . . . . . . . . . . . . . . . . . . . . 6
5.2 Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Josefsson Expires May 14, 2005 [Page 2]
Internet-Draft Using TLS with Kerberos 5 November 2004
1. Introduction and Background
This document describe how Shishi, a Kerberos 5 [1] implementation,
upgrade communication between clients and Key Distribution Centers
(KDCs) to use the Transport Layer Security (TLS) [2] protocol.
The TLS protocol offer integrity and privacy protected exchanges that
can be authentication using X.509 certificates, OpenPGP keys [6], and
user name and passwords via SRP [5].
An inconclusive list of the motivation for using TLS with Kerberos 5
is given below.
o Explicit server authentication of the KDC to the client. In
traditional Kerberos 5, authentication of the KDC is proved as a
side effect that the KDC knows your encryption key (i.e., your
password).
o Flexible authentication against KDC. Kerberos 5 assume the user
knows a key (usually in the form of a password). Sometimes
external factors make this hard to fulfill. In some situations,
users are equipped with smart cards with a RSA authentication key.
In others, users have a OpenPGP client on their desktop, with a
public OpenPGP key known to the server. In some situations, the
policy may be that password authentication may only be done
through SRP.
o Kerberos exchanges are privacy protected. Part of many Kerberos
packets are transfered without privacy protection (i.e.,
encryption). That part contains information, such as the client
principal name, the server principal name, the encryption types
supported by the client, the lifetime of tickets, etc. Revealing
such information is, in some threat models, considered a problem.
o Prevents downgrade attacks affecting encryption types. The
encryption type of the ticket in KDC-REQ are sent in the clear in
Kerberos 5. This allows an attacker to replace the encryption
type with a compromised mechanisms, e.g. 56-bit DES. Since
clients in general cannot know the encryption types other servers
support, it is difficult for the client to detect if there was a
man-in-the-middle or if the remote server simply did not support a
stronger mechanism. Clients could chose to refuse 56-bit DES
altogether, but in some environments this leads to operational
difficulties.
o The TLS protocol has been studied by many parties. In some threat
models, the designer prefer to reduce the number of protocols that
can hurt the overall system security if they are compromised.
Josefsson Expires May 14, 2005 [Page 3]
Internet-Draft Using TLS with Kerberos 5 November 2004
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 [4].
2. Extension Mechanism for TCP/IP transport
Kerberos 5 require Key Distribution Centers (KDCs) to accept requests
over TCP. Each request and response is prefixed by 4 octets,
encoding an integer in network byte order, that indicate the length
of the packet. The high bit of the 4 octet length field was reserved
for future expansion. Servers that do not understand how to
interpret a set high bit are required to return a KRB-ERROR with the
KRB_ERR_FIELD_TOOLONG error code, and to close the TCP stream.
We will use the reserved bit to provide an extension mechanism. When
the reserved high bit is set, the remaining 31 bits of the 4 octets
are treated as an extensible typed hole, and thus form a 31 bit
integer enumerating various extensions. Each of the values indicate
a specific extended operation mode, two of which are used and defined
here, and the rest are left for others to use.
If the KDC do not understand a requested extension, it MUST return a
KRB-ERROR with a KRB_ERR_FIELD_TOOLONG value (prefixed by the 4 octet
length integer, with the high bit clear, as usual) and close the TCP
stream.
The following table specify the meaning of the 31 lower bits in the 4
octet field, when the high bit is set:
0 RESERVED.
1 STARTTLS requested by client.
2 STARTTLS request accepted by server.
3...2147483647 AVAILABLE for registration (via bug-shishi@josefsson.org)
.
2147483648 RESERVED.
3. Kerberos 5 STARTTLS Extension
3.1 STARTTLS requested by client (extension 1)
When this message is sent by the client, the client is requesting the
server to start TLS negotiation on the TCP stream. The client MUST
NOT start TLS negotiation immediately. Instead, the client wait for
either a KRB-ERROR (sent normally, prefixed by a 4 octet length
integer) indicating the server do not understand the set high bit, or
4 octets which is to be interpreted as an integer in network byte
order, where the high bit is set and the remaining 31 bit are
interpreted as an integer specifying ``STARTTLS request accepted by
Josefsson Expires May 14, 2005 [Page 4]
Internet-Draft Using TLS with Kerberos 5 November 2004
server'' (extension 2). In the first case, the client infer that the
server do not understand (or wish to support) STARTTLS, and can
re-try using normal TCP, if unprotected Kerberos 5 exchanges are
acceptable to the client policy. In the latter case, it should
invoke TLS negotiation on the stream. If any other data is received,
the client MUST close the TCP stream.
3.2 STARTTLS request accepted by server (extension 2)
This message should be sent by the server when it has received the
extension 1 message. The message is an acknowledgment of the
client's request to initiate STARTTLS on the channel. The server
MUST then invoke a TLS negotiation.
3.3 Proceeding after successful TLS negotiation
If the TLS negotiation ended successfully, possibly also considering
client or server policies, the exchange within the TLS protected
stream is performed like normal UDP Kerberos 5 exchanges, i.e., there
is no TCP 4 octet length field before each packet. Instead each
Kerberos packet MUST be sent within one TLS record, so the
application can use the TLS record length as the Kerberos 5 packet
length.
3.4 Proceeding after failed TLS negotiation
If the TLS negotiation fails, possibly due to client or server policy
(e.g., inadequate support of encryption types in TLS, or lack of
client or server authentication) the entity that detect the failure
MUST disconnected the connection. It is expected that any error
messages that explain the error condition is transfered by TLS.
3.5 STARTTLS aware KDC Discovery
Section 7.2.3 of Kerberos 5 [1] describe how Domain Name System (DNS)
SRV records [3] can be used to find the address of an KDC. To locate
a KDC that support the STARTTLS extension, we use the "_tls" domain.
For example:
_kerberos._tls._tcp.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tls._tcp.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
3.6 Initial Authentication via TLS
The server MAY consider the authentication performed by the TLS
exchange as sufficient to issue Kerberos 5 tickets to the client,
without requiring, e.g., pre-authentication. However, it is not an
Josefsson Expires May 14, 2005 [Page 5]
Internet-Draft Using TLS with Kerberos 5 November 2004
error to require or use pre-authentication as well.
The client may also indicate that it wishes to use TLS both for
authentication and data protection by using the NULL encryption type
in its request. The server can decide from its local policy whether
or not issuing tickets based solely on TLS authentication, and
whether NULL encryption within TLS, is acceptable or not.
4. Security Considerations
Because the initial token is not protected, it is possible for an
active attacker to make it appear to the client that the server do
not support this extension. It is up to client configuration to
disallow non-TLS connections, if that vulnerability is deemed
unacceptable. For interoperability, we suggest the default behaviour
should be to allow automatic fall back to TCP or UDP.
The security considerations of both TLS and Kerberos 5 are inherited.
Using TLS for authentication and/or data protection together with
Kerberos alter the authentication logic fundamentally. Thus, it may
be that even if the TLS and Kerberos 5 protocols and implementations
were secure, the combination of TLS and Kerberos 5 described here
could be insecure.
No channel bindings are provided in the Kerberos messages. It is an
open question whether, and how, this could be solved. One idea for
solving this may be to specify a new encryption algorithm in Kerberos
5 that is similar to the NULL encryption algorithm, but also include
the TLS session identifier.
5. References
5.1 Normative References
[1] Neuman, C., "The Kerberos Network Authentication Service (V5)",
draft-ietf-krb-wg-kerberos-clarifications-07 (work in progress),
September 2004.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
5.2 Informative References
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Josefsson Expires May 14, 2005 [Page 6]
Internet-Draft Using TLS with Kerberos 5 November 2004
Levels", BCP 14, RFC 2119, March 1997.
[5] Taylor, D., "Using SRP for TLS Authentication",
draft-ietf-tls-srp-08 (work in progress), August 2004.
[6] Mavroyanopoulos, N., "Using OpenPGP keys for TLS
authentication", draft-ietf-tls-openpgp-keys-05 (work in
progress), April 2004.
Author's Address
Simon Josefsson
EMail: simon@josefsson.org
Josefsson Expires May 14, 2005 [Page 7]
Internet-Draft Using TLS with Kerberos 5 November 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 for
th therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Josefsson Expires May 14, 2005 [Page 8]

672
doc/standardisation/draft-josefsson-kerberos5-starttls-01.txt Normal file
View File

@@ -0,0 +1,672 @@
Network Working Group S. Josefsson
Internet-Draft SJD
Intended status: Standards Track October 4, 2006
Expires: April 7, 2007
Using Kerberos V5 over the Transport Layer Security (TLS) protocol
draft-josefsson-kerberos5-starttls-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 7, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Josefsson Expires April 7, 2007 [Page 1]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
Abstract
This document specify how the Kerberos V5 protocol can be transported
over the Transport Layer Security (TLS) protocol, to provide
additional security features.
Table of Contents
1. Introduction and Background . . . . . . . . . . . . . . . . . 3
2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 5
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Josefsson Expires April 7, 2007 [Page 2]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
1. Introduction and Background
This document describe how a Kerberos V5 [2] implementation may
upgrade communication between clients and Key Distribution Centers
(KDCs) to use the Transport Layer Security (TLS) [4] protocol.
The TLS protocol offer integrity and privacy protected exchanges that
can be authentication using X.509 certificates, OpenPGP keys [7], and
user name and passwords via SRP [6].
There are several reasons to use Kerberos V5 over TLS.
o Kerberos exchanges are privacy protected. Part of many Kerberos
packets are transfered without privacy protection (i.e.,
encryption). That part contains information, such as the client
principal name, the server principal name, the encryption types
supported by the client, the lifetime of tickets, etc. Revealing
such information is, in some threat models, considered a problem.
o Prevents downgrade attacks affecting encryption types. The
encryption type of the ticket in KDC-REQ are sent in the clear in
Kerberos 5. This allows an attacker to replace the encryption
type with a compromised mechanisms, e.g., 56-bit DES. Since
clients in general cannot know the encryption types other servers
support, it is difficult for the client to detect if there was a
man-in-the-middle or if the remote server simply did not support a
stronger mechanism. Clients could chose to refuse, e.g., 56-bit
DES altogether, but in some environments this leads to operational
difficulties.
o Additional authentication against the KDC. In some situations,
users are equipped with smart cards with a RSA authentication key.
In others, users have a OpenPGP client on their desktop, with a
public OpenPGP key known to the server. In some situations, the
policy may be that password authentication may only be done
through SRP.
o The TLS protocol has been studied by many parties. In some threat
models, the designer prefer to reduce the number of protocols that
can hurt the overall system security if they are compromised.
o Explicit server authentication of the KDC to the client. In
traditional Kerberos 5, authentication of the KDC is proved as a
side effect that the KDC knows your encryption key (i.e., your
Josefsson Expires April 7, 2007 [Page 3]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
password).
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 [1].
Josefsson Expires April 7, 2007 [Page 4]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
2. Kerberos V5 STARTTLS Extension
The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
[3]. The extension uses bit #TBD in the extension bitmask.
The protocol is as follows. After the server has sent the 4-octet
value 0x00000000 to indicate support of this extension, the stream
will be controlled by the TLS protocol and its framing. The TLS
protocol is initiated by the client.
Typically, the client initiate the TLS handshake protocol by sending
a client hello, and the server responds, and the handshake continues
until it either succeed or fails.
If for any reason the handshake fails, the STARTTLS protocol will
also fail, and the TLS error is used as the error indication.
If the handshake succeeds, the Kerberos V5 authentication protocol is
performed within the protected TLS channel, like a normal TCP
Kerberos V5 exchange. In particular, this means that every Kerberos
V5 packet will be prefixed by a 4-octet length field, that indicate
the length of the Kerberos V5 packet.
Josefsson Expires April 7, 2007 [Page 5]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
3. Examples
A complete packet flow for a successful AS-REQ/REP exchange protected
by this mechanism will be as follows. The "STARTTLS-bit" is a
4-octet value with only the bit allocated for this extension set.
Client Server
[ Kerberos V5 TCP extension mechanism negotiation starts ]
[0x70000000 & STARTTLS-bit] -------->
[0x00000000]
<--------
[ TLS negotiation starts ]
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
[ Kerberos V5 negotiation starts ]
Kerberos V5 AS-REQ -------->
Kerberos V5 AS-REP
<--------
* Indicates optional or situation-dependent messages that are not
always sent.
Josefsson Expires April 7, 2007 [Page 6]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
4. STARTTLS aware KDC Discovery
Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System
(DNS) SRV records [5] can be used to find the address of an KDC.
Using the terminology of Section 7.2.3 of RFC 4120, we define a new
Proto of "tls" to indicate that the particular KDC is intended to
support this STARTTLS extension. The Service, Realm, TTL, Class,
SRV, Priority, Weight, Port and Target have the same meaning as in
RFC 4120.
For example:
_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
Josefsson Expires April 7, 2007 [Page 7]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
5. IANA Considerations
The IANA is requested to allocate a bit in the "Kerberos TCP
Extensions" registry for the extension described in this document, as
per [3].
Josefsson Expires April 7, 2007 [Page 8]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
6. Security Considerations
The security considerations in Kerberos V5, TLS, and the extension
mechanism framework are inherited.
To protect against the inherent downgrade attack in the extension
framework, it is suggested that implementations offer a policy to
require that this extension is successfully negotiated. For
interoperability with implementations that do not support this
extension, it is suggested that the policy is disabled by default.
Josefsson Expires April 7, 2007 [Page 9]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005.
[3] Josefsson, S., "Extended Kerberos Version 5 Key Distribution
Center (KDC) Exchanges Over TCP",
draft-ietf-krb-wg-tcp-expansion-01 (work in progress),
September 2006.
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
7.2. Informative References
[6] Taylor, D., "Using SRP for TLS Authentication",
draft-ietf-tls-srp-12 (work in progress), June 2006.
[7] Mavroyanopoulos, N., "Using OpenPGP keys for TLS
authentication", draft-ietf-tls-openpgp-keys-10 (work in
progress), June 2006.
Josefsson Expires April 7, 2007 [Page 10]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
Author's Address
Simon Josefsson
SJD
Email: simon@josefsson.org
Josefsson Expires April 7, 2007 [Page 11]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Josefsson Expires April 7, 2007 [Page 12]

672
doc/standardisation/draft-josefsson-kerberos5-starttls-02.txt Normal file
View File

@@ -0,0 +1,672 @@
Network Working Group S. Josefsson
Internet-Draft SJD
Intended status: Standards Track October 21, 2006
Expires: April 24, 2007
Using Kerberos V5 over the Transport Layer Security (TLS) protocol
draft-josefsson-kerberos5-starttls-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 April 24, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Josefsson Expires April 24, 2007 [Page 1]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
Abstract
This document specify how the Kerberos V5 protocol can be transported
over the Transport Layer Security (TLS) protocol, to provide
additional security features.
Table of Contents
1. Introduction and Background . . . . . . . . . . . . . . . . . 3
2. Kerberos V5 STARTTLS Extension . . . . . . . . . . . . . . . . 5
3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. STARTTLS aware KDC Discovery . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Josefsson Expires April 24, 2007 [Page 2]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
1. Introduction and Background
This document describe how a Kerberos V5 [2] implementation may
upgrade communication between clients and Key Distribution Centers
(KDCs) to use the Transport Layer Security (TLS) [4] protocol.
The TLS protocol offer integrity and privacy protected exchanges that
can be authentication using X.509 certificates, OpenPGP keys [7], and
user name and passwords via SRP [6].
There are several reasons to use Kerberos V5 over TLS.
o Prevents downgrade attacks affecting, e.g., encryption types and
pre-auth data negotiation. The encryption type field in KDC-REQ,
and the METHOD-DATA field with the requested pre-auth types from
the server in KDC_ERR_PREAUTH_REQUIRED errors in KDC-REP, are sent
without integrity or privacy protection in Kerberos 5. This
allows an attacker to replace the encryption type with a
compromised encryption type, e.g., 56-bit DES, or request that
clients should use a broken pre-auth type. Since clients in
general cannot know the encryption types other servers support, or
the pre-auth types servers prefer or require, it is difficult for
the client to detect if there was a man-in-the-middle or if the
remote server simply did not support a stronger encryption type or
preferred another pre-auth type.
o Kerberos exchanges are privacy protected. Part of many Kerberos
packets are transfered without privacy protection (i.e.,
encryption). That part contains information, such as the client
principal name, the server principal name, the encryption types
supported by the client, the lifetime of tickets, etc. Revealing
such information is, in some threat models, considered a problem.
o Additional authentication against the KDC. In some situations,
users are equipped with smart cards with a RSA authentication key.
In others, users have a OpenPGP client on their desktop, with a
public OpenPGP key known to the server.
o The TLS protocol has been studied by many parties. In some threat
models, the designer prefer to reduce the number of protocols that
can hurt the overall system security if they are compromised.
o Explicit server authentication of the KDC to the client. In
traditional Kerberos 5, authentication of the KDC is proved as a
side effect that the KDC knows your encryption key (i.e., your
Josefsson Expires April 24, 2007 [Page 3]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
password).
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 [1].
Josefsson Expires April 24, 2007 [Page 4]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
2. Kerberos V5 STARTTLS Extension
The STARTTLS extension uses the Kerberos V5 TCP extension mechanism
[3]. The extension uses bit #TBD in the extension bitmask.
The protocol is as follows. After the server has sent the 4-octet
value 0x00000000 to indicate support of this extension, the stream
will be controlled by the TLS protocol and its framing. The TLS
protocol is initiated by the client.
Typically, the client initiate the TLS handshake protocol by sending
a client hello, and the server responds, and the handshake continues
until it either succeed or fails.
If for any reason the handshake fails, the STARTTLS protocol will
also fail, and the TLS error is used as the error indication.
If the handshake succeeds, the Kerberos V5 authentication protocol is
performed within the protected TLS channel, like a normal TCP
Kerberos V5 exchange. In particular, this means that every Kerberos
V5 packet will be prefixed by a 4-octet length field, that indicate
the length of the Kerberos V5 packet.
Josefsson Expires April 24, 2007 [Page 5]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
3. Examples
A complete packet flow for a successful AS-REQ/REP exchange protected
by this mechanism will be as follows. The "STARTTLS-bit" is a
4-octet value with only the bit allocated for this extension set.
Client Server
[ Kerberos V5 TCP extension mechanism negotiation starts ]
[0x70000000 & STARTTLS-bit] -------->
[0x00000000]
<--------
[ TLS negotiation starts ]
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- Finished
[ Kerberos V5 negotiation starts ]
4 octet length field
Kerberos V5 AS-REQ -------->
4 octet length field
Kerberos V5 AS-REP
<--------
* Indicates optional or situation-dependent messages that are not
always sent.
Josefsson Expires April 24, 2007 [Page 6]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
4. STARTTLS aware KDC Discovery
Section 7.2.3 of Kerberos V5 [2] describe how Domain Name System
(DNS) SRV records [5] can be used to find the address of an KDC.
Using the terminology of Section 7.2.3 of RFC 4120, we define a new
Proto of "tls" to indicate that the particular KDC is intended to
support this STARTTLS extension. The Service, Realm, TTL, Class,
SRV, Priority, Weight, Port and Target have the same meaning as in
RFC 4120.
For example:
_kerberos._tls.EXAMPLE.COM. IN SRV 0 0 88 kdc1.example.com.
_kerberos._tls.EXAMPLE.COM. IN SRV 1 0 88 kdc2.example.com.
Josefsson Expires April 24, 2007 [Page 7]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
5. IANA Considerations
The IANA is requested to allocate a bit in the "Kerberos TCP
Extensions" registry for the extension described in this document, as
per [3].
Josefsson Expires April 24, 2007 [Page 8]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
6. Security Considerations
The security considerations in Kerberos V5, TLS, and the extension
mechanism framework are inherited.
To protect against the inherent downgrade attack in the extension
framework, it is suggested that implementations offer a policy to
require that this extension is successfully negotiated. For
interoperability with implementations that do not support this
extension, it is suggested that the policy is disabled by default.
Josefsson Expires April 24, 2007 [Page 9]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
7. References
7.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
Network Authentication Service (V5)", RFC 4120, July 2005.
[3] Josefsson, S., "Extended Kerberos Version 5 Key Distribution
Center (KDC) Exchanges Over TCP",
draft-ietf-krb-wg-tcp-expansion-01 (work in progress),
September 2006.
[4] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
Protocol Version 1.1", RFC 4346, April 2006.
[5] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
7.2. Informative References
[6] Taylor, D., "Using SRP for TLS Authentication",
draft-ietf-tls-srp-12 (work in progress), June 2006.
[7] Mavroyanopoulos, N., "Using OpenPGP keys for TLS
authentication", draft-ietf-tls-openpgp-keys-10 (work in
progress), June 2006.
Josefsson Expires April 24, 2007 [Page 10]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
Author's Address
Simon Josefsson
SJD
Email: simon@josefsson.org
Josefsson Expires April 24, 2007 [Page 11]
Internet-Draft Protecting Kerberos V5 with TLS October 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Josefsson Expires April 24, 2007 [Page 12]

1232
doc/standardisation/draft-richards-otp-kerberos-01.txt Normal file
View File

File diff suppressed because it is too large Load Diff

731
doc/standardisation/draft-sakane-krb-cross-problem-statement-01.txt Normal file
View File

@@ -0,0 +1,731 @@
INTERNET-DRAFT S. Sakane
Expires: April 29, 2007 Yokogawa Electric Corp.
S. Zrelli
JAIST
M. Ishiyama
Toshiba Corp.
October 26, 2006
Problem statement on the cross-realm operation
of Kerberos in a specific system
draft-sakane-krb-cross-problem-statement-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 expires in April 29, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
S.Sakane, et al. [Page 1]
Internet-Draft October 2006
Abstract
There are some issues when the cross-realm operation of the Kerberos
Version 5 [RFC4120] is employed into the specific systems. This
document describes some manners of the real example, and lists
requirements of the operation in such real system. Then it clarifies
issues when we apply the cross-realm operation to such specific
system.
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 [RFC2119].
It is assumed that the readers are familiar with the terms and
concepts described in the Kerberos Version 5 [RFC4120].
S.Sakane, et al. [Page 2]
Internet-Draft October 2006
Table of Contents
1. Introduction ................................................. 4
2. Kerberos system .............................................. 4
2.1. Kerberos basic operation ................................ 4
2.2. Cross-realm operation ................................... 5
3. Manner of operations in the real environment ................. 6
4. Requirement .................................................. 7
5. Issues ....................................................... 8
5.1. Scalability of the direct trust model ................... 8
5.2. Exposure to DoS Attacks ................................. 8
5.3. No PFS in case of the indirect trust model .............. 9
5.4. Unreliability of authentication chain ................... 9
5.5. Client's performance .................................... 9
5.6. Pre-authentication problem in roaming scenarios ......... 10
6. Implementation consideration ................................. 10
7. IANA Considerations .......................................... 11
8. Security Considerations ...................................... 11
9. Acknowledgments .............................................. 11
10. References ................................................... 11
10.1. Normative References ................................... 11
10.2. Informative References ................................. 11
Authors' Addresses ............................................... 12
Full Copyright Statement ......................................... 12
Intellectual Property Statement .................................. 13
S.Sakane, et al. [Page 3]
Internet-Draft October 2006
1. Introduction
The Kerberos Version 5 is a widely deployed mechanism that a server
can authenticate a client access. Each client belongs to a managed
domain called realm. Kerberos supports the authentication in case of
situation that a client and a server belong to different realms.
This is called the cross-realm operation.
Meanwhile, there are lots of manners of operation in the real system,
where Kerberos could be applied. Sometimes, there are several
managed domain in such system. and it requires the authentication
mechanism over the different managed domains. When the cross-realm
operation of Kerberos is applied to such specific systems, some
issues come out.
This document briefly describes the Kerberos Version 5 system and the
cross-realm operation. Then, it describes two real systems that can
be applied the Kerberos system, and describes nine requirements of
those systems in term both of management and operation. Finally, it
lists six issues of the cross-realm operation when it is applied to
those system.
Note that it might not describe whole of issues of the cross-realm
operation. It also does not propose any solution to solve issues
described in this document. In further step, we have to analyze, and
compare candidates of solutions. This work will be in another
document.
This document is assumed that the readers are familiar with the terms
and concepts described in the Kerberos Version 5 [RFC4120].
2. Kerberos system
2.1. Kerberos basic operation
Kerberos [RFC4120] is a widely deployed authentication system. The
authentication process in Kerberos involves principals and a Key
Distribution Center (KDC). The principals can be users or services.
Each KDC maintains a principals database and shares a secret key with
each registered principal.
The authentication process allows a user to acquire the needed
credentials from the KDC. These credentials allow services to
authenticate the users before granting them access to the resources.
An important part of the credentials are called Tickets. There are
two kind of tickets: Ticket Granting Ticket (TGT) and Service Ticket.
S.Sakane, et al. [Page 4]
Internet-Draft October 2006
The TGT is obtained periodically from the KDC and has a limited limit
after which it expires and the user must renew it. The TGT is used
to obtain the other kind of tickets, Service Tickets. The user
obtains a TGT from the Authentication Service (AS), a logical
component of the KDC. The process of obtaining a TGT is referred to
as 'AS exchange'. When a TGT request is issued by an user, the AS
responds by sending a reply packet containing the credentials which
consists of the TGT along with a random key called 'TGS Session Key'.
The TGT contains a set of information encrypted using a secret key
associated with a special service referred to as TGS (Ticket Granting
Service). The TGS session key is encrypted using the user's key so
that the user can obtain the TGS session key only if she knows the
secret key shared with the KDC. The TGT then is used to obtain
Service Tickets from the Ticket Granting Service (TGS)- the second
component of the KDC. The process of obtaining service tickets is
referred to as 'TGS exchange'. The request for a service ticket
consists on a packet containing a TGT and an 'Authenticator'. The
Authenticator is encrypted using the TGS session key and contains the
identity of the user as well as time stamps (for protection against
replay attacks). After decrypting the TGT (which was encrypted by
the AS using the TGS's secret key), the TGS extracts the TGS session
key. Using that session key, it decrypts the Authenticator and
authenticates the user. Then, the TGS issues credentials requested
by the user. These credentials consist on a service ticket and a
session key that will be used to authenticate the user with the
desired application service.
2.2. Cross-realm operation
The Kerberos protocol provides the cross-realm authentication
capabilities. This allows users to obtain service tickets to access
services in foreign realms. In order to access such services, the
users first contact their home KDC asking for a TGT that will be used
with the TGS of the foreign realm. If the home realm and the foreign
realm share keys and have an established trust relationship, the home
KDC delivers the requested TGT.
However, if the home realm does not share cross-realm keys with the
foreign realm, the home KDC will provide a TGT that can be used with
an intermediary foreign realm that is likely to be sharing cross-
realm keys with the target realm. The client can use this
'intermediary TGT' to communicate with the intermediary KDC which
will iterate the actions taken by the home KDC: If the intermediary
KDC does not share cross-realm keys with the target foreign realm it
will point the user to another intermediary KDC (just as in the first
exchange between the user and its home KDC). However, in the other
case (when it shares cross- realm keys with the target realm), the
S.Sakane, et al. [Page 5]
Internet-Draft October 2006
intermediary KDC will issue a TGT that can be used with the KDC of
the target realm. After obtaining a TGT for the desired foreign
realm, the client uses it to obtain service tickets from the TGS of
the foreign realm. Finally, the user access the service using the
service ticket.
When the realms belong to the same institution, a chain of trust can
be determined by the client or the KDC by following the DNS domain
hierarchy and supposing that the parent domains share keys with all
its child sub-domains. However, because the inter-realm trust model
is not necessarily constructing the hierarchic approach anytime, the
trust path must be specified manually. When intermediary realms are
involved, the success of the cross-realm operation completely depends
on the realms that are part of the authentication path.
3. Manner of operations in the real environment
This section describes examples of operation in the real environment.
And it also describes its requirement in term of both management and
operation. These requirements make the issues easier understanding.
We refers to the world's largest petrochemical company [SHELLCHEM].
It produces bulk petrochemicals and their delivery to large
industrial customers. There are 43 typical plants of the company all
over the world. They are managed by the operation sites placed in 35
countries. This section shows two examples of them.
One is the CSPC (CNOOC and Shell Petrochemical Company Limited)
[CSPC], an example of the centralized plant. The CSPC is a joint
enterprise of CNOOC and SHELL. Its plant is one of the hugest
systems of a petrochemical industry placed in the area of 3.4 square
meters in the north coast of Daya Bay, Guangdong, which is at the
southeast of China. 3,000 network segments are established in the
system. 16,000 control devices are connected to the local area
network. These devices belong to different 9 sub systems, A control
device has some control points, which are controlled and monitored by
other devices remotely. There are 200,000 control points in all.
They are controlled by 3 different control center.
Another is the NAM (Nederlandse Aardolie Maatschappij), an example of
the distributed plant system. The NAM is a partnership enterprise of
Shell and Exxon. It is a plant system group that geographically
distributes to scatter in the area of 863 square meters of
Netherlands. 26 plants, each is named "cluster", are scattered in
the area. They are connected each other by a private ATM WAN. Each
cluster has approximately 500-1,000 control devices. These devices
are managed by each local control center in each cluster. In the
entire system of the NAM, there are one million control points.
S.Sakane, et al. [Page 6]
Internet-Draft October 2006
The end control devices in the both of the systems are basically
connected to a local network by a twisted pair cable, which is a low
band-width of 32 kbps. Every system supposes that no ad-hoc device
is never connected to the system since they are well designed before
they are implemented. Low clock CPU, for example H8 [RNSS-H8] and
M16C [RNSS-M16C], are employed by many control devices. Furthermore,
to suppress power consumption, these CPU may be lowered the number of
clocks. A controller in this system collects condition of device
from multiple control devices, and the system uses them to make a
decision how to control devices. If it took time for data to reach,
they could not be associated. The travel time of data from the
device to the controller is demanded within 1 second. A part of the
operation, like control of these system, maintenance, and the
environmental monitoring, is consigned to an external organization.
Agents who are consigned walk around the plant to get their
information, or watch the plant from a remote site. Currently, each
plant is independently operated. However, it is not impossible to
monitor and control all of plants distributed in the world.
4. Requirement
This section listed requirements derived from the previous section.
There are seven requirements in term of management domain separation.
A-1 It is necessary to allow different independent management
domains to coexist because two or more organizations enter to
the system.
A-2 It is necessary to allow a management domain to delegate its
management authority to its sub domains or another management
domain because the plants are distributed to the wide area.
A-3 It is necessary that a device controls other devices that belong
to a same domain from remote because the plants are distributed
to the wide area.
A-4 It is necessary that a device controls other devices that belong
to a different domain from local.
A-5 It is necessary that a device controls other devices that belong
to a different domain from remote.
A-6 It is necessary for the agents who are consigned to watch and
control the device at the plant, which is different domain from
the agents' one.
Because of above requirements, the cross-realm operation of Kerberos
S.Sakane, et al. [Page 7]
Internet-Draft October 2006
seems suitable for this system. The requirements derived from other
viewpoints is listed as follows.
B-1 It is demanded to reduce the management cost as much as
possible.
B-2 The communication for observing and controlling devices must
have confidentiality and integrity. And, it is necessary to
think about the threat of other security like the DoS attack.
B-3 It is necessary to consider the processing performance of the
device. And, it is necessary to suppress the power consumption
of the device.
B-4 It is necessary to consider bandwidth of the communication.
5. Issues
This section lists the issues in the cross-realm operation when we
consider the above requirements.
5.1. Scalability of the direct trust model
In the direct relationship of trust between each realm, the realms
involved in the cross-realm operation share keys and their respective
TGS principals are registered in each other's KDC. When direct trust
relationships are used, the KDC of each realm must maintain keys with
all foreign realms. This can become a cumbersome task when the
number of realms increase. This also increases maintenance cost.
This issue will happen as a by-product of a result meeting the
requirements A-1 and A-2, and is related to B-1.
5.2. Exposure to DoS Attacks
One of the assumption made when allowing the cross-realm operation in
Kerberos is that users can communicate with KDCs located in remote
realms. This practice introduces security threats because KDCs are
open to the public network. Administrators may think of restricting
the access to the KDC to the trusted realms only. However, this
approach is not scalable and does not really protect the KDC.
Indeed, when the remote realms have several IP prefixes (e.g. control
centers or outsourcing companies, located world wide), then the
administrator of the local KDC must collect the list of prefixes that
belong to these organization. The filtering rules must then
S.Sakane, et al. [Page 8]
Internet-Draft October 2006
explicitly allow the incoming traffic from any host that belongs to
one of these prefixes. This makes the administrator's tasks more
complicated and prone to human errors. And also, the maintenance
cost increases. On the other hand, when ranges of external IP
addresses are allowed to communicate with the KDC, the risk of
becoming target to attacks from remote malicious users increases.
This issue will happen as a result meeting the requirements A-3, A-4
and A-5. And it is related to B-1 and B-2.
5.3. No PFS in case of the indirect trust model
In [SPECCROSS], any KDC in the authentication path can learn the
session key that will be used between the client and the desired
service. This means that any intermediary realm is able to spoof the
identity either of the service or the client as well as to eavesdrop
on the communication between the client and the server.
This issue will happen as a by-product of a result meeting the
requirements A-1 and A-2, and is related to B-2.
5.4. Unreliability of authentication chain
When the relationship of trust is constructed like a chain or
hierarchical, the authentication path is not dependable since it
strongly depends on intermediary realms that might not be under the
same authority. If any of the realms in the authentication path is
not available, then the principals of the end-realms can not perform
the cross-realm operation.
The end-point realms do not have full control and responsibility of
the success of the operations even if their respective KDCs are fully
functional. Dependability of a system decreases if the system relies
on uncontrolled components. We can not be sure at 100% about the
result of the authentication since we do not know how is it going in
intermediary realms.
This issue will happen as a by-product of a result meeting the
requirements A-1 and A-2, and is related to B-2.
5.5. Client's performance
In the cross-realm operation, Kerberos clients have to perform TGS
exchanges with all the KDCs in the trust path, including the home KDC
and the target KDC. TGS exchange requires cryptographic operations.
S.Sakane, et al. [Page 9]
Internet-Draft October 2006
This exchange demands important processing time especially when the
client has limited computational capabilities. The overhead of these
cross-realm exchanges grows into unacceptable delays.
We ported the MIT Kerberos library (version 1.2.4), implemented a
Kerberos client on our original board with H8 (16-bit, 20MHz), and
measured the process time of each Kerberos message. It takes 195
milliseconds to perform a TGS exchange with the on-board H/W crypto
engine. Indeed, this result seems reasonable to the requirement of
the response time for the control network. However, we did not
modify the clock speed of the H8 during our measurement. The
processing time must be slower in a real environment because H8 is
used with lowered clock speed in such system. Also, the delays can
grow to unacceptable delays when the number of intermediary realms
increases.
This issue will happen as a by-product of a result meeting the
requirements A-1 and A-2, and is related to B-3.
5.6. Pre-authentication problem in roaming scenarios
In roaming scenarios, the client needs to contact her home KDC to
obtain a cross-realm TGT for the local (or visited) realm. However,
the policy of the network access providers or the gateway in the
local network usually does not allow clients to communicate with
hosts in the Internet unless they provide valid authentication
credentials. In this manner, the client encounters a chicken-and-egg
problem where two resources are interdependent; the Internet
connection is needed to contact the home KDC and for obtaining
credentials, and on the other hand, the Internet connection is only
granted for clients who have valid credentials. As a result, the
Kerberos protocol can not be used as it is for authenticating roaming
clients requesting network access.
This issue will happen as a result meeting the requirements A-6.
6. Implementation consideration
This document just describes issues of the cross-realm operation in
the specific systems. However, there are important matters to be
considered, when we solve these issues and implement solution.
Solution must not introduce new problem. Solution should use
existing components or protocols as much as possible, should not
introduce any definition of new component. Solution must not require
a KDC to have any additional process. You must not forget that there
would be a trade-off matter anytime. So an implementation may not
S.Sakane, et al. [Page 10]
Internet-Draft October 2006
solve all of the problems stated in this document.
7. IANA Considerations
This document makes no request of IANA.
8. Security Considerations
This document just clarifies some issues of the cross-realm operation
of the Kerberos V system. There is especially not describing
security. Some troubles might be caused to your system by malicious
user who misuses the description of this document if it dares to say.
9. Acknowledgments
The authors are very grateful to Nobuo Okabe, Kazunori Miyazawa,
Ken'ichi Kamada and Atsushi Inoue. They gave us lots of comments and
input for this document.
10. References
10.1. Normative References
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC
4120, July 2005.
10.2. Informative References
[CSPC] http://www.shellchemicals.com/news/1,1098,72-news_id=
531,00.html
[RNSS-H8] http://www.renesas.com/fmwk.jsp?cnt=h8_family_landing.
jsp&fp=/products/mpumcu/h8_family/
[RNSS-M16C] http://www.renesas.com/fmwk.jsp?cnt=m16c_family_landi
ng.jsp&fp=/products/mpumcu/m16c_family/
[RFC2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
S.Sakane, et al. [Page 11]
Internet-Draft October 2006
[SHELLCHEM] http://www.shellchemicals.com/home/1,1098,-1,00.html
[SPECCROSS] I. Cervesato and A. Jaggard and A. Scedrov and C.
Walstad, "Specifying Kerberos 5 Cross-Realm
Authentication", Fifth Workshop on Issues in the Theory
of Security, Jan 2005.
Authors' Addresses
Shoichi Sakane
Yokogawa Electric Corporation
2-9-32 Nakacho, Musashino-shi,
Tokyo 180-8750 Japan
E-mail: Shouichi.Sakane@jp.yokogawa.com,
Saber Zrelli
Japan Advanced Institute of Science and Technology
1-1 Asahidai, Nomi,
Ishikawa 923-1292 Japan
E-mail: zrelli@jaist.ac.jp
Masahiro Ishiyama
Toshiba Corporation
1, komukai-toshiba-cho, Saiwai-ku,
Kawasaki 212-8582 Japan
E-mail: masahiro@isl.rdc.toshiba.co.jp
Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
S.Sakane, et al. [Page 12]
Internet-Draft October 2006
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.
S.Sakane, et al. [Page 13]