[Bug 1793594] Re: IAKERB-HEADER "Realm" field incorrectly encoded as OCTET STRING

Robie Basak 1793594 at bugs.launchpad.net
Tue Sep 25 07:24:02 UTC 2018


I think we have a couple of open questions on this bug in Ubuntu then:

1) Is it fixed upstream?

2) Sam's question: what's the actual impact to Ubuntu users?

Since we can't make progress without these questions answered, and
depending on the answers we might not consider this to be a bug in
Ubuntu at all, I'm marking the Ubuntu bug task Incomplete to make it
clear to everyone what the current situation is. Once these questions
are answered, please feel free to change the bug status back to New.

** Changed in: krb5 (Ubuntu)
       Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1793594

Title:
  IAKERB-HEADER "Realm" field incorrectly encoded as OCTET STRING

Status in krb5 package in Ubuntu:
  Incomplete

Bug description:
  Background:

  Under some circumstances, when the client/initiator has a TGT but no
  ticket for a particular principal, it needs to communicate with the
  KDC. The GSSAPI protocol includes a mechanism, a subprotocol named
  IAKERB, for the client to tunnel/proxy through the server/acceptor
  instead of directly communicating with the KDC. (This is useful if
  e.g. the GSSAPI initiator does not have full network access but the
  acceptor does.)

  Problem:

  The formatting of the IAKERB messages is incorrect. Every draft of the
  IAKERB protocol I have been able to find defines the IAKERB-HEADER
  structure to have a field "Realm" which is a UTF8String, like this:

             IAKERB-HEADER ::= SEQUENCE {
                 target-realm      [1] UTF8String,

  However, observed protocol exchanges tag the Realm field as an OCTET
  STRING.

  I believe the bug is in src/lib/krb5/asn.1/asn1_k_encode.c near line
  1146, where the DEFFIELD(iakerb_header_1,...) macro is invoked with
  "ostring_data". I think it should be invoked with "utf8_data" instead.

  Reproduction:

  I observed this using Firefox attempting to authenticate with a webserver using the "Negotiate" protocol. The first Negotiate message from the browser to the server contains:
    GSSAPI token (RFC2743 3.3); mechanism 1.3.6.1.5.5.2 (SPNEGO)
      innerToken is a NegTokenInit (RFC4178 4.2.1)
        mech = 1.3.6.1.5.2.5 (IAKERB)
        mechToken is a (wrapped) GSSAPI token (RFC2743 again) with mech = 1.3.6.1.5.2.5
          innerToken is the concatenation of:
            TOK_ID 05 01 (IAKERB)
            IAKERB-HEADER
            a Kerberos TGS-REQ

  Dumping the IAKERB-HEADER with `openssl asnparse` produces:

      0:d=0  hl=2 l=  12 cons: SEQUENCE          
      2:d=1  hl=2 l=  10 cons:  cont [ 1 ]        
      4:d=2  hl=2 l=   8 prim:   OCTET STRING      :HHHH.ORG

  As you can see the realm (HHHH.ORG) is tagged as OCTET STRING, rather
  than being tagged as UTF8String.

  Versions:

  Description:	Ubuntu 16.04.5 LTS
  Release:	16.04

  libgssapi-krb5-2:
    Installed: 1.13.2+dfsg-5ubuntu2
    Candidate: 1.13.2+dfsg-5ubuntu2
    Version table:
   *** 1.13.2+dfsg-5ubuntu2 500
          500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
          100 /var/lib/dpkg/status
       1.13.2+dfsg-5 500
          500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1793594/+subscriptions



More information about the foundations-bugs mailing list