One document matched: draft-josefsson-kerberos5-i18n-00.xml

<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc compact="yes"?>
<?rfc toc="yes"?>

<rfc category="std" ipr="full3978"
     updates="4120"
     docName="draft-josefsson-kerberos5-i18n-00">

  <front>

    <title abbrev="KRB-ERROR i18n">
Kerberos V5 Internationalization of Error Messages
    </title>

    <author initials="S." surname="Josefsson" fullname="Simon Josefsson">
      <organization>SJD</organization>
      <address>
	<email>simon@josefsson.org</email>
      </address>
    </author>
    
    <date month="January" year="2008"/>

    <abstract>

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

    </abstract>

  </front>
  
  <middle>

    <section title="Introduction">

      <t>The <xref target="RFC4120">Kerberos V5</xref> 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.</t>

      <t>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.</t>

    </section>

    <section title="Conventions Used in This Document">

      <t>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 <xref target="RFC2119">RFC 2119</xref>.</t>

    </section>

    <section title="Negotiating Support for Internationalization">

      <t>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.</t>

      <section title="PA-I18N">

      <figure>
	<artwork>
     Language-Tag      ::= IA5String
                           -- RFC 4646 Language-Tag

     PA-I18N           ::= SEQUENCE OF Language-Tag
	</artwork>
      </figure>

      <t>An empty list can be used to signal support of this extension
	without requesting any particular languages.</t>

      <t>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.</t>

      </section>

    </section>

    <section title="Internationalization of KRB-ERROR">

      <t>When the PA-I18N extension is negotiated the server MAY send
	the following structure wherever a KRB-ERROR packet can be
	sent.</t>

      <figure>
	<artwork>
   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
   }
	</artwork>
      </figure>

      <t>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.</t>

      <t>The "ErrorMessage" type holds one error message in a specific
	language.</t>

      <t>The "langtag" field follows the Language-Tag format.</t>

      <t>The "msg" field holds the text message, encoded
	in <xref target="RFC3629">UTF-8</xref>.</t>

      <t>The "e-text" field holds a list of "ErrorMessage" structures.
	Each member of the list will contain the error message in a
	particular language.</t>

      <t>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.</t>

    </section>

    <section title="Security Considerations">

      <t>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.</t>

    </section>

    <section title="IANA Considerations">

      <t>TBA</t>

    </section>

  </middle>

  <back>

    <references title="Normative References">

      <?rfc include="reference.RFC.2119.xml"?>
      <?rfc include="reference.RFC.3629.xml"?>
      <?rfc include="reference.RFC.4120.xml"?>

    </references>

    <section title="Copying Conditions">

      <t>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.</t>
  
    </section>

  </back>

</rfc>