RT RT/krbdev.mit.edu: Ticket #8519 AS-REQ session key negotiation can fail with restricted etype list Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

[Display] [History] [Basics] [Dates] [People] [Links] [Jumbo]

 
 

 The Basics  
Id
8519
Status
open
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
Tags
Version_reported
Version_Fixed
Target_Version
 

 Relationships  
Depends on:
Depended on by:
Parents:
Children:

Refers to:
  • 2131: (ghudson) krb5_get_init_creds_keytab() doesn't restrict requested enctypes to those in keytab entry [resolved]
  • 7190: (ghudson) Try harder to make keytab-based AS requests work [resolved]
  • 8199: (ghudson) Only include one key in etype-info [resolved]
Referred to by:
 
 Dates  
Created: Fri Nov 18 17:01:08 2016
Starts: Not set
Started: Not set
Last Contact: Not set
Due: Not set
Updated: Mon Nov 21 12:03:23 2016 by ghudson
 

 People  
Owner
 Nobody
Requestors
 ghudson@mit.edu
Cc
 
AdminCc
 
 

 More about Greg Hudson  
Comments about this user:
No comment entered about this user
This user's 25 highest priority tickets:
 

History   Display mode: [Brief headers] [Full headers]
      Fri Nov 18 17:01:08 2016  ghudson - Ticket created    
     
Subject: AS-REQ session key negotiation can fail with restricted etype list

An AS-REQ contains (in the KDC-REQ-BODY) an etype field containing "the
desired encryption algorithm to be used in the response" (RFC 4120
section 5.4.1).  The KDC must choose three keys for the response:

1. The reply key, which must be a key the client possesses or can
compute.
2. The ticket session key, which must be of an enctype supported by the
client and the server.
3. The ticket encryption key, which must be a key the server possesses.

The KDC-REQ-BODY etype list is used for the first and second keys, while
the server's supported enctypes (either from its set of keys or a string
attribute) is used for the second and third keys.

If a client possesses a limited set of possible reply keys, the
implementor may restrict the etype field to the set of enctypes
corresponding to those keys.  Heimdal does this when getting initial
credentials with a keytab.  MIT krb5 briefly did this for kinit -k on the
master branch between 1.10 and 1.11, but now sends all supported enctypes
with the keytab key enctypes moved to the front (see issues 2131 and
7190).  Based on http://mailman.mit.edu/pipermail/kerberos/2016-
November/021521.html it appears that Windows clients also do this: at
login time they compute a key set from the password and ETYPE-INFO-2
information, and then when refreshing tickets they send an etype list
containing only the enctypes of those keys.

If a client does this, session key negotiation may fail if the server's
supported enctypes (as determined by the KDC) do not intersect with the
client's transmitted etype list.  The fault here likely belongs to the
krb5 protocol or to the client, but with many Windows clients in the
field exhibiting this behavior, our KDC should try to work around the
issue.

The Windows interop case is exacerbated by the change in the MIT krb5
1.14 KDC to send only one etype-info entry in AS-REPs (ticket 8199).
With only one etype-info entry sent, the client computes only one reply
key, and sends an even more restricted etype list for ticket refreshes
than it did when talking to previous versions of the MIT krb5 KDC.

We briefly had a workaround in the KDC (from ticket 7190) which fell back
to assuming that local TGT principals have support for all permitted
enctypes.  The code for that workaround could be improved (it should not
use the realm-global variable tgs_server), but the general idea should
address most cases where this issue arises.  This workaround will not
address AS-REQs where the server principal is different from the local
krbtgt principal, but those cases should be rare.


Download (untitled) 2.5k
      Fri Nov 18 17:01:52 2016  ghudson - Ticket 8519 RefersTo ticket 2131.    
      Fri Nov 18 17:01:52 2016  ghudson - Ticket 8519 RefersTo ticket 7190.    
      Fri Nov 18 17:01:52 2016  ghudson - Ticket 8519 RefersTo ticket 8199.    
      Mon Nov 21 12:03:22 2016  ghudson - Comments added    
     
This problem typically occurs when both of the following are true:

* A client makes an AS-REQ with an overly restrictive (for the session
key) set of etypes.

* The krbtgt/REALM principal has a small set of keys (perhaps just one
key), and no session_enctypes string attribute to override it.

Given that session_enctypes can be used to work around the problem, I am
now leaning towards documentation rather than a code change.  The
proposed workaround assumes that the krbtgt service implicitly supports
all enctypes permitted by this KDC, rather than the set of enctypes
present in the key data (although the enctypes present in the key data
take priority).  That assumption could make some problems more difficult
to diagnose in realms with mixed KDC versions.  For example, if a realm
has a mix of 1.15 and 1.14 KDCs, and a client makes an AS-REQ with only
aes-sha2 enctypes in the etypes field, the 1.15 KDC might issue a ticket
that works with the 1.15 KDCs and not with the 1.14 KDCs.  That would be
a lot more confusing than an ETYPE_NOSUPP error.

At a minimum, if we do add a workaround to the KDC, it should strictly
respect any session_enctypes attribute on the krbtgt/REALM entry.


Download (untitled) 1.1k