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

Bug #1793594 reported by Wim Lewis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
krb5 (Ubuntu)
Expired
Undecided
Unassigned

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

Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

Hi Wim,
this seems like a real quality bug report to me - thank you for that.
I checked other versions up to the latest but eventually found that even in latest upstream the same code exists [1].

To fully understand that and also to make the change that eventually helps all downstreams and not only Ubuntu it would be best to file an issue there.
In any case that should get the subject matter experts thoughts on it, and we can follow depending on what comes up in this upstream discussion.

Please can you verify this by building directly from the latest upstream source? If this can be confirmed as an upstream bug, the best route to getting it fixed in Ubuntu in this case would be to file an upstream bug if you're able to do that. Otherwise, I'm not sure what we can do directly in Ubuntu to fix the problem. You could IMHO as well try the same on Ubuntu Bionic or Cosmis whihc has version 1.16 matching the latest upstream releases (well not the 1.6.1 release, but 1.6 at least).

I'd highly appreciate if you file a bug upstream to mention it here to we can link up the bug tracking with it.

[1]: https://github.com/krb5/krb5/blob/master/src/lib/krb5/asn.1/asn1_k_encode.c#L1128

tags: added: needs-upstream-report
Revision history for this message
Sam Hartman (hartmans) wrote : Re: [Bug 1793594] [NEW] IAKERB-HEADER "Realm" field incorrectly encoded as OCTET STRING

So, is this a spec bug or an implementation bug.
Does the current behavior cause anything to break, or is it simply that
implementations have diverged from the spec in tagging of the string.

--Sam

Revision history for this message
Robie Basak (racb) wrote :

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
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for krb5 (Ubuntu) because there has been no activity for 60 days.]

Changed in krb5 (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.