Subject: [Ietf-krb-wg] Kerberos V5 Internationalization of Error Messages

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 Dec 2007 09:57:48 +0100

All,

to get some krb5-i18n discussions going, I wrote the document below.
The document is currently only about KRB-ERROR.  I believe this is the
simplest part of the bigger i18n problem, and attacking the problems one
at a time may reduce the perceived complexity of the final solution.

Is anyone interested in helping with this document?  I would appreciate
feedback and comments.

Thanks,
/Simon

Network Working Group                                       S. Josefsson
Internet-Draft                                                       SJD
Updates: 4120 (if approved)                            December 21, 2007
Intended status: Standards Track
Expires: June 23, 2008

           Kerberos V5 Internationalization of Error Messages
                     draft-josefsson-kerberos5-i18n

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 June 23, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document describes an internationalization extension for the
   Kerberos V5 protocol.  The extension allows error messages to be sent
   in the users' language.

Josefsson                 Expires June 23, 2008                 [Page 1]

Internet-Draft               KRB-ERROR i18n                December 2007

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
   Appendix A.  Copying Conditions . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 5
   Intellectual Property and Copyright Statements  . . . . . . . . . . 6

Josefsson                 Expires June 23, 2008                 [Page 2]

Internet-Draft               KRB-ERROR i18n                December 2007

1.  Introduction

   The Kerberos V5 [3] 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 code.  The "e-text"
   type is KerberosString, which may only contain US-ASCII characters.
   Traditionally the field has only been used to send english help
   texts.

   There is a desire to provide error messages in a 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.

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 [1].

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.

3.1.  PA-I18N

        Language-Tag      ::= IA5String
                              -- RFC 4646 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
   is not supported by the KDC, to allow clients to more easily select
   another language tag.

Josefsson                 Expires June 23, 2008                 [Page 3]

Internet-Draft               KRB-ERROR i18n                December 2007

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 4646 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.

   The "msg" field holds the text message, encoded in UTF-8 [2].

   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
   languages as well.  It is RECOMMENDED that KDC always return the
   error message in the "en" (English) language.  This improves
   debugging and logging.

Josefsson                 Expires June 23, 2008                 [Page 4]

Internet-Draft               KRB-ERROR i18n                December 2007

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

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Yergeau, F., "UTF-8, a transformation format of ISO 10646",
        STD 63, RFC 3629, November 2003.

   [3]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos
        Network Authentication Service (V5)", RFC 4120, July 2005.

Appendix A.  Copying Conditions

   Regarding this entire document or any portion of it, the author makes
   no guarantees and is not responsible for any damage resulting from
   its use.  The author grants irrevocable permission to anyone to use,
   modify, and distribute it in any way that does not diminish the
   rights of anyone else to use, modify, and distribute it, provided
   that redistributed derivative works do not contain misleading author
   or version information.  Derivative works need not be licensed under
   similar terms.

Author's Address

   Simon Josefsson
   SJD

   Email: [email-masked]

Josefsson                 Expires June 23, 2008                 [Page 5]

Internet-Draft               KRB-ERROR i18n                December 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Josefsson                 Expires June 23, 2008                 [Page 6]

_______________________________________________
ietf-krb-wg mailing list
[email-masked]
https://lists.anl.gov/mailman/listinfo/ietf-krb-wg