RT RT/krbdev.mit.edu: Ticket #6641 Typed-in master passwords should use enctypes in K/M entry Signed in as guest.
[Logout]

[Home] [Search] [Configuration]

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

 
 

 The Basics  
Id
6641
Status
new
Worked
0 min
Priority
0/0
Queue
krb5
 

 Keyword Selections  
Component
Tags
  • enhancement
Version_reported
Version_Fixed
Target_Version
 

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

Refers to:
Referred to by:
 
 Dates  
Created: Thu Jan 14 14:02:06 2010
Starts: Not set
Started: Not set
Last Contact: Not set
Due: Not set
Updated: Thu Jan 14 14:02:06 2010 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]
      Thu Jan 14 14:02:06 2010  ghudson - Ticket created    
     
Subject: Typed-in master passwords should use enctypes in K/M entry

When you use a typed-in password for krb5kdc or kadmind, that password
is converted to a keyblock for a specific enctype, determined either by
realm configuration (master_key_type), command-line flag (krb5kdc's -k
flag), or the built-in default (DEFAULT_KDC_ENCTYPE).

It is unnecessary to require the administrator to specify this enctype,
and it can lead to surprising failures when the built-in default changes
between releases.

Ideally, the password should be tried against each enctype present in
the K/M key data array.  This enhancement requires a change to the
libkdb5 interfaces, since kdb_db_fetch_mkey currently reads the password
and produces a single keyblock.

(A simpler approach would be to use the enctype of the most recent
master key entry.  However, that change could break some working
configurations, where the admin is entering the password of an older
master key entry.)


Download (untitled) 896b