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

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

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
    <!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
    <!ENTITY rfc3629 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3629.xml'>
    <!ENTITY rfc4120 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4120.xml'>
    <!ENTITY rfc5646 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5646.xml'>
]>

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

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

  <front>

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

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

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

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

      <t>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.</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.  The
      languages tags are described by <xref target="RFC5646"/>.</t>

      <section title="PA-I18N">

      <figure>
	<artwork>
     Language-Tag      ::= IA5String
                           -- RFC 5646 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 5646 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 <xref
      target="RFC5646">Language-Tag format</xref>.</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">

      &rfc2119;
      &rfc3629;
      &rfc4120;
      &rfc5646;

    </references>

  </back>

</rfc>