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

2018-09-21 Thread Sam Hartman
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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  New

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  :.ORG

  As you can see the realm (.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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1793594] [NEW] IAKERB-HEADER "Realm" field incorrectly encoded as OCTET STRING

2018-09-20 Thread Wim Lewis
Public bug reported:

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  :.ORG

As you can see the realm (.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

** Affects: krb5 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 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:
  New

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  :.ORG

  As you can see the realm (.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