RT RT/krbdev.mit.edu: Ticket #7672 KDC can emit PREAUTH_REQUIRED error with useless hint list Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

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

 
 

 The Basics  
Id
7672
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:
Referred to by:
 
 Dates  
Created: Tue Jul 2 15:04:08 2013
Starts: Not set
Started: Not set
Last Contact: Not set
Due: Not set
Updated: Mon Feb 12 12:08:47 2018 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]
      Tue Jul  2 15:04:08 2013  ghudson - Ticket created    
     
Subject: KDC can emit PREAUTH_REQUIRED error with useless hint list

Right now if you set +requires_hwauth on a principal without setting up
securid-sam2, the KDC will generate a PREAUTH_REQUIRED error with
preauth types 133 and 136 ("here's a cookie" and "I support FAST").
Older MIT krb5 clients will react to that by retransmitting the request
until the loop count is exceeded; newer clients will notice that they
could not generate any real preauthentication and fail with
KRB5_PREAUTH_FAILED.

The KDC should notice that it failed to propose any real preauth mechs
and should return a failure rather than a preauth-required error.
There's a lot of latitude for producing better or worse error codes in
different scenarios, but almost anything would be better than "please
preauthenticate with one of the following 0 mechanisms:".

Right now this is a marginal concern because the hwauth bit is rarely
used outside of MIT itself, and we don't yet have an admin-facing way to
disable encrypted timestamp/challenge for a principal.  The problem will
get worse if we implement a way to have principals with no long-term
keys or actual per-principal preauth configuration.


Download (untitled) 1k
      Mon Feb 12 12:08:46 2018  ghudson - Comments added    
     
This scenario can also occur if the request enctypes list and the
client keys do not overlap, e.g.:

  make testrealm
  kadmin.local cpw -pw user -e aes256-cts user
  kadmin.local modprinc +preauth user
  in krb5.conf: [libdefaults] default_tkt_enctypes = aes128-cts
  kinit user

We tolerate the lack of a client key in case we can use PKINIT or OTP,
but when we can't offer one of those we offer the same meaningless
133/136 hint list as in the +hwauth case.


Download (untitled) 463b