Internet DRAFT - draft-josefsson-kerberos5-i18n
draft-josefsson-kerberos5-i18n
Network Working Group S. Josefsson
Internet-Draft SJD AB
Updates: 4120 (if approved) March 26, 2012
Intended status: Standards Track
Expires: September 27, 2012
Kerberos V5 Internationalization of Error Messages
draft-josefsson-kerberos5-i18n-01
Abstract
This document describes an internationalization extension for the
Kerberos V5 protocol. The extension allows error messages to be sent
in the users' language. This document updates RFC 4120 to add a new
PA-DATA type and to modify the protocol logic related to KRB-ERROR
when the new PA-DATA extension is negotiated.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 27, 2012.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Josefsson Expires September 27, 2012 [Page 1]
Internet-Draft KRB-ERROR i18n March 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
3. Negotiating Support for Internationalization . . . . . . . . . 3
3.1. PA-I18N . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Internationalization of KRB-ERROR . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5
Josefsson Expires September 27, 2012 [Page 2]
Internet-Draft KRB-ERROR i18n March 2012
1. Introduction
The Kerberos V5 [RFC4120] specification uses the KRB-ERROR packet to
signal error conditions. The KRB-ERROR packet contains a field
"e-text" which holds additional text to explain the error. The
"e-text" ASN.1 type is KerberosString, which may only contain US-
ASCII characters. Traditionally the field has been used to send
error messages in English.
There is a desire to provide error messages in the users' own
language. This document specifies how clients and KDC negotiate
support for a internationalization extension. When the extension is
negotiated, this document goes on to describe how the KRB-ERROR
packet is modified in order to support translated error messages.
This document updates RFC 4120 to add a new PA-DATA type and to
modify the protocol logic related to KRB-ERROR when the new PA-DATA
extension is negotiated.
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 [RFC2119].
3. Negotiating Support for Internationalization
The client can request support for internationalization by including
a PA-DATA element with padata-type of PA-I18N in the KDC-REQ. The
PA-DATA carry a list in preference order to indicate the languages
the client needs error messages in. The languages tags are described
by [RFC5646].
3.1. PA-I18N
Language-Tag ::= IA5String
-- RFC 5646 Language-Tag
PA-I18N ::= SEQUENCE OF Language-Tag
An empty list can be used to signal support of this extension without
requesting any particular languages.
The KDC MAY include a PA-DATA element with a padata-type of PA-I18N
in the KDC-REP message, containing a list of languages supported by
the KDC. This can be useful if the languages preferred by the client
Josefsson Expires September 27, 2012 [Page 3]
Internet-Draft KRB-ERROR i18n March 2012
is not supported by the KDC, to allow clients to more easily select
another language tag.
4. Internationalization of KRB-ERROR
When the PA-I18N extension is negotiated the server MAY send the
following structure wherever a KRB-ERROR packet can be sent.
KRB-I18N-ERROR ::= [APPLICATION 4] SEQUENCE {
pvno [0] INTEGER (5),
msg-type [1] INTEGER (30),
ctime [2] KerberosTime OPTIONAL,
cusec [3] Microseconds OPTIONAL,
stime [4] KerberosTime,
susec [5] Microseconds,
error-code [6] Int32,
crealm [7] Realm OPTIONAL,
cname [8] PrincipalName OPTIONAL,
realm [9] Realm -- service realm --,
sname [10] PrincipalName -- service name --,
e-text [11] SEQUENCE OF ErrorMessage,
e-data [12] OCTET STRING OPTIONAL
}
ErrorMessage ::= SEQUENCE {
langtag [0] IA5String -- RFC 5646 Language-Tag --,
msg [1] UTF8String
}
Compared to KRB-ERROR, this changes the type of the "e-text" field
from KerberosString to ErrorMessage. The APPLICATION tag is changed
from 30 to 4 to help automatic decoding of KRB-ERROR and KRB-I18N-
ERROR.
The "ErrorMessage" type holds one error message in a specific
language.
The "langtag" field follows the Language-Tag format [RFC5646].
The "msg" field holds the text message, encoded in UTF-8 [RFC3629].
The "e-text" field holds a list of "ErrorMessage" structures. Each
member of the list will contain the error message in a particular
language.
The languages of messages returned will be in a sub-set of languages
requested by the client. The server MAY return strings in other
Josefsson Expires September 27, 2012 [Page 4]
Internet-Draft KRB-ERROR i18n March 2012
languages as well. It is RECOMMENDED that KDC always return the
error message in the "en" (English) language. This improves
debugging and logging.
5. Security Considerations
If a client requests a large number of languages, it can consume a
significant amount of resources on the KDC and will also increase the
packet size. This can be used as a denial of service attack. KDCs
can chose to temporarily disable translations for a particular
client, or require that clients pre-authenticates themselves.
6. IANA Considerations
TBA
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
Kerberos Network Authentication Service (V5)", RFC 4120,
July 2005.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009.
Author's Address
Simon Josefsson
SJD AB
Email: simon@josefsson.org
Josefsson Expires September 27, 2012 [Page 5]
